ERC-8191: Onchain Recurring Payments

ERCs
, , , ,
4

Would this ERC be intended to support subscriptions where the terms of the deal can change mid-subscription while keeping the same ID? If so, how?

We’ve previously implemented a pseudo-subscription pattern which required manual renewal at the end of each term (RedisProvisionObligation, de-redis-clients) based on the escrow architecture described in ERC-8183: Agentic Commerce - #37 by mlegls. I like the idea of this ERC in abstracting ongoing payments with a pull-based mechanism without requiring re-attestation after the first payment.

Two suggestions:

  • I’d recommend adding a generic bytes data and bytes32 schema field to SubscriptionTerms for subscription-specific data. The downside to a mapping(bytes32 => CustomTerms) per implementation is that there’s no shared interface for accessing it.
  • token and amount may be worth generalizing to any on-chain action rather than just ERC-20 and ETH transfers, to support ERC-1155, bundles of tokens, or other recurring non-token actions. e.g. bytes32 paymentSchema and bytes paymentData instead of address token and uint256 amount. The external function interfaces wouldn’t have to change.

There are very natural integrations with our general purpose conditional escrow system Alkahest, where

Happy to work on these together if you’d like.