ERC948 Recurring Payments Standard Progress Update — July 1st 2018
These updates are based on the discussions between the working group for ERC948 — a standard for recurring payments on Ethereum that is currently in development. I will endeavour to focus on the ideas that are being discussed and not on who said what, however I will also express my opinion!
Hopefully these updates will assist anyone who is interested in following the progress of the standard and will encourage a broad range of input. I’m also expecting that they will help me to formulate my views more clearly!
Purpose of the standard
As this is the first update post, let’s address why we need a standard in the first place.
The chief reason for any standard is interoperability, and so in the case of ERC948 there seems to be consensus that there should be interoperability between the smart contract that is responsible for taking recurring payments and the wallet that payments are being taken from.
If there is a standard interface for all recurring payments contracts, then wallets and other software will be able to interact with these contracts, allowing us to manage all our subscriptions in one place.
Open Questions
Here I’ll briefly outline what I see as some of the most important points that we don’t currently have consensus on.
Scope of the standard
There is a lot of variation in how organisations want to bill their customers and attempting to define a data structure that can handle all these cases is a considerable undertaking.
One school of thought is that the standard should be as light as possible, in the extreme this could mean that the only standard only specifies a subscription ID format and perhaps a “Cancel” function. It has been proposed that the standard should not deal with creation of a subscription.
Personally I agree that we should be aiming to keep the interface relatively light but I do think that there is a lot of merit to having a standard interface for creation of subscriptions too. This would allow wallets to understand that you’re about to enter into a recurring payment contract and show appropriate UI that summarises the agreement, for example:
While there is an almost infinite amount of variation in how a subscription could be defined there is also a lot of overlap. I’m hopeful that we can agree on a data structure for subscriptions that covers 80% or more of the cases so that wallets can provide this functionality. There will always be scenarios that fall outside a standard, and in those cases it should be possible that they can use their own custom “create” function yet still adhere to the other aspects of the standard such as the subscription ID and “cancel” function.
Payment mechanisms
There are two main mechanisms that could be used to make payments happen without the subscriber having to sign a transaction at each payment time.
- Escrow (supports ETH and tokens)— the subscriber transfers some ETH or tokens to a contract and these are then released to the merchant by the contract over time. This method has the advantage of being able to handle payments in ETH, but the disadvantage that the subscriber has to pre-fund the contract with a multiple payments up-front.
- Pre-approval (supports only tokens) — the subscriber holds some ERC-20 tokens in their wallet and pre-approves the contract to transfer these tokens on their behalf. The contract can then transfer up to an agreed amount of tokens from the subscriber’s wallet to the merchant’s wallet at each billing period.
There is clearly an advantage in being able to make payments in ETH but this comes with the distinct disadvantage that a contract can’t reach into your wallet and transfer this ETH on your behalf, so in effect you have to pre-pay for multiple billing periods up-front and then take some action to make another transaction if you want to continue your subscription after this period.
Data Structure
If we consider the most minimal interpretation of this standard that may only allow you to list your subscriptions; in this case, and in every other, we would need to define some sort of a data structure to represent a subscription.
At the minimum this could be simply a subscription ID. This appears in all the proposed specs as a bytes32 value. It may also be good to have a short name so that a wallet UI could list your subscriptions.
Now at this point there are a whole host of possibilities for other metadata that could make up the description of a subscription. For example:
- Payee address
- Currency and amount of recurring payment (this may be a fixed amount or a variable amount with a maximum cap)
- Billing period (the simplest system would be a fixed number of seconds, but in reality the majority of consumer use cases involve calendar intervals, e.g. monthly / weekly / annual)
- Start time (this could set some time in the future to enable a subscription to start off with a free trial)
- Expiry time
The specs that have been submitted so far contain overlapping subsets of these properties and also some others that haven’t been mentioned.
Spec Contributors
Many thanks to all those who have contributed draft specifications so far:
If you’re interested in getting involved there’s a EIP discussion thread on github, and a slack channel where some of the working group hang out.
