Initial spec for discussion

[johngriffin]

Hey all,

This is a specification that's based on @sb777's earlier spec. David Kobrosky and I have already started on an implementation of it and it's changed along the way as we've learned from that process. I submit it here as I think it's probably close to a minimum viable spec.

Purpose

I suggest the reason for this standard is interoperability - we want wallets to understand that you’re about to sign a recurring payment contract so that they can present you with a UI that summarises the agreement you’re about to enter into. As your wallet now knows you’ve entered into a subscription contract it can also provide appropriate UI for managing and cancelling your subscriptions in future.

Features

• Payments happen automatically without any action on the subscribers part.
• Strong guarantees on when subscribers can cancel their subscription.
• The ability to charge a fixed fee per subscription time unit (netflix, pandora, etc).
• The ability to charge a dynamic fee per subscription time unit (aws, twilio, etc) upto a pre-authorized limit.
• Calendar time periods like week, month, year, not just intervals in seconds.
• Supports free trials - set the amountInitial to 0, and the startDate to the point that you want to start charging.

Known Issues

We plan to add the following:

• be able to create reasonably accurate forecasts for upcoming subscriptions: Programatic checks that subscription accounts have available balance and that subscription is active.

• Add isValidSubscription()

Limitations

• The method of taking payment is for the subscriber to pre-authorise the contract to transfer ERC-20 tokens directly to the merchant. It is not possible for a contract to reach into the subscribers wallet and take ETH in the future so we do not support this, the only way to support payments in ETH would be for the subscriber to pre-fund the contract with multiple billing periods.

• Any checks to ensure that the subscriber is creating a "valid" subscription are left to the implementation. When createSubscription() is called the contract will probably want to check that the attributes correspond to a valid plan.

• Once a subscription has been created the merchant cannot update it's attributes.

Comparison with other PRs

• 8x

  • All the functions that are defined in 8x's spec could also be added to ours. The underlying data structures seem similar.
  • The spec seems to be missing create and cancel functions. This is the key function IMO because a standard interface here will enable all wallets to understand that you’re about to commit to a recurring payment and will be able to provide appropriate UX for you to confirm this and manage your subscriptions

• PiperMerriam

  • Not a full spec but we think that ours adheres to most of the principles set out here. However it seems this spec is suggesting keeping ETH in escrow?

[gbarros]

Hi @johngriffin =]

Have you thought about having a common interface for wallets to allow pull requests (withdraw money from user smart wallet, with pre-approval)?

[johngriffin]

Hi @gbarros, unless I'm misunderstanding you that is what this spec allows?

[owocki]

@andrewredden perhaps we should fold some of these events into your PR?