EIP1192: Standard interface for reading & cancelling subscription payments

[kermankohli]

Problem We need a standard way of dealing with recurring/subscription payments on Ethereum. The original discussion began with EIP948, however there are currently 2 ideas around what a subscription payment standard should have be (read vs edit/write).

Solution Rather than creating a lowest common denominator for competing standards, at 8x we propose to create a new standard to separate the two altogether. We propose EIP1192 will be a standard for applications such as wallets to allow users to view their existing subscriptions and manage them at a basic level (eg. cancelling). However, it should be up to each protocol/network to determine how they would like to handle the creation of a payment or be compliant with EIP948.

Current Progress

So far we have these basic functions defined for a read/cancel only standard. These are not in any way finalised, but merely a starting point for a discussion. One problem which needs to be addressed is a potential metadata format for both EIP948 and EIP 1992 to be in agreement with.

Some potential issues include:

• Formate for dates (epoch vs unit of dates)
• Fields that should or should not be included
• Format for meta/extra data
• Standard way to communicate once a subscription has been created (event logs)

Apart from the above, this is the current implementation proposal for EIP1192.

/** @dev Checks if the subscription is valid.
      * @param _subscription is the identifier of the customer's subscription with its relevant details.
      * @return success is the result of whether the subscription is valid or not.
    */
    function isValidSubscription(bytes32 _subscription)
        public
        view
        returns (bool success);

    /** @dev Gets the token contract address within the subscription.
      * @param _subscription is the identifier of the customer's subscription with its relevant details.
      * @return subscriptionTokenAddress is token contract address within the subscription.
    */
    function getSubscriptionTokenAddress(bytes32 _subscription)
        public
        view
        returns (address subscriptionTokenAddress);

    /** @dev Returns the from (customer) and to (business) addresses of a subscription.
      * @param _subscription is the identifier of the customer's subscription with its relevant details.
      * @return from is the address where recurring payments are deducted (customer).
      * @return to is the address where recurring payments are sent (business).
    */
    function getSubscriptionFromToAddresses(bytes32 _subscription)
        public
        view
        returns (address from, address to);

    /** @dev Gets the token amount due from the subscription.
      * @param _subscription is the identifier of the customer's subscription with its relevant details.
      * @return amount is token amount due from the subscription.
    */
    function getAmountDueFromSubscription(bytes32 _subscription)
        public
        view
        returns (uint amount);

    /** @dev Gets the subscription fee.
      * @param _subscription is the identifier of the customer's subscription with its relevant details.
      * @return fee is the subscription fee.
    */
    function getSubscriptionFee(bytes32 _subscription)
        public
        view
        returns (uint fee);

    /** @dev Cancel the subscription. User or service node iniated.
      * @param _subscription is the identifier of the customer's subscription with its relevant details.
    */
    function cancelSubscription(bytes32 _subscription)
        public;

[owocki]

However, it should be up to each protocol/network to determine how they would like to handle the creation of a payment or be compliant with EIP948.

I don't feel that the rest of the working group for #948 agrees with this.

My personal view is that there will be too much fragmentation in the marketplace if there are no standards around creation of a subscription.

If you we are going to break the standard into two components, then there should be a separate set of standards for writing/creation of a standard.

So far we have these basic functions defined for a read/cancel only standard. These are not in any way finalised, but merely a starting point for a discussion.

Your proposal is not a starting point . The starting point was https://github.com/EthereumOpenSubscriptions/standard , which we had all previously been working towards together until you stopped showing up to the #948 calls and then submitted this EIP without any communication with the rest of the working group.

its not a standard if it’s just 8x in the working group.

[kermankohli]

Hey @owocki, I think there's been some cross wires around what's been communicated due to the calls being at 12:30am and me trying to catch up via chat.

My personal view is that there will be too much fragmentation in the marketplace if there are no standards around creation of a subscription.

We believe that there's a magnitude of use cases (donation, up to X, oraclised etc) that might want to be created and it'll be unfair to be locked into one interface to create these subscriptions. It's also worth considering that a user isn't expecting a standard way to create subscriptions since you subscribe to services from various businesses/developers. Although, what the user does want is a standard way to view all of their current subscriptions and cancel them if required. Hence, our intent is for the two standards to be complimentary to each other and not competing :)

I'd also like to thank you for starting the EIP948 group as that's been where we've been able to collaborate together. I don't intend to come off as going rogue or being the only one in the working group, this is simply an idea to resolve the differences we have to move forward and get the standards over the line. Apologies in advance if you felt offended that I've forked the standard you originally created.

[sb777]

Having a recurring subscription standard without subscription initiation doesn't make sense. That's the whole point of ERC-948 - to initiate, manage, and process subscriptions.

[kermankohli]

@sb777 Could you explain why initiation doesn't make sense to not be in a standard? Use cases would be helpful to understand :)

[sindarknave]

I'd be in favor of separating subscription initiation from a subscription management interface standard, so long as the reference implementation includes an example of subscription initiation. All the contract needs to return is an amount due; there's a lot of business logic (first time free, price stabilization, etc.) that would be better modularized in a separate contract than through an interface standard.

In fact, I think the word "subscriptions" is too opinionated because it attaches the concept of recurring payments to an enterprise use-case, whereas in real life recurring payments are used in other forms such as license fees, rentals, donations etc.

[AC0DEM0NK3Y]

Wondering about the decision to use bytes32 for the subscription parameter? Why restrict this when you can store a lot more data in a uint256 and it's faster for the EVM to process.

I agree with the choice for a standard for view may be better than a standard for initiation because subscription to what exactly? It could be many things. Which makes me think amount due and fee returns...I guess this standard as is will be only useful for tokens and fiat representation subscriptions?

Do you think there's merit in adding array params to the gets so you can pull out many subscription details for the chain at once rather than hitting the chain many times for use cases where there are many subscriptions?

[kermankohli]

Thank you for your input and apologies for the late reply!

@sindarknave Definitely. The idea behind what a subscription actually is so varied that it's better to find what should be in common and cutting where ideas/implementation diverge too greatly. Out of the existing standard, what do you thinks should be changed though?

@AC0DEM0NK3Y Honestly, I didn't really know that uint256 was more gas efficient than bytes32. Would be keen to learn more about this - any links would be greatly appreciated! Could you elaborate more about your points of amount due and return fees. Regarding array params, it's still dependent on some kind of format or structure for the subscription. eg. what should index 0 contain, what format do you store dates/time intervals in (epoch or some kind of enum based system) etc. Also returning a dynamic array in Solidity is really messy right now so wanted to avoid going down that rabbit hole altogether haha. It's easier to have s JSON object serialised as a string, data or uint imo.

[github-actions[bot]]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions[bot]]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.