Skip to content
This repository has been archived by the owner on Aug 19, 2019. It is now read-only.

Latest commit

 

History

History
111 lines (91 loc) · 4.8 KB

8x.md

File metadata and controls

111 lines (91 loc) · 4.8 KB

Specification

Summary

A standardized interface for interacting with recurring subscriptions.

Abstract

This standard defines a contract interface for interacting with subscription data. The 8x suggestions come under the feelings that implementation of how a subscription is created, is left up to the implementor. If we define a standard for implementation, we'll be locking ourselves into one way of doing things.

Our Thoughts

The idea behind a standard should be an easy way for developers to read/access data regardless of an implementation. A standard shouldn't govern the architecture of a system. It's for this reason that functions such as adding and editing seem application/protocol specific.

Also features such as editing go against the principal of putting users-first. Just because we have the approval to take tokens from a user's wallet, that doesn't mean they should be uninformed of what happens. In the case of a vendor changing prices, they need to create a new plan, revoke the old one and users then need to explicitly upgrade.

For variable subscriptions, that should be a completely new agreement the user enters into. They should be aware they're actually authorizing up to X per every Y. Trying to accommodate it in a standard feels too far fetched as there's multiple ways you might want to implement it.

The code presented is 8x's collectible interface. The bare minimum to have recurring subscription payments for different use-cases. It's what we plan to use when the executor references a subscription contract.

Rather than instantiating that specific contract, it simply instantiates a collectible interface with a particular address. We believe other developers should be able to do this for their applications too.

Motivation

We want to set a standard for interacting with Layer 2 protocols, not how those protocols operate.

Public View Functions

isValidSubscription
/** @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);
getSubscriptionTokenAddress
/** @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);
getSubscriptionFromToAddresses
/** @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);
getSubscriptionOwnerBalance
/** @dev Gets token balance of the subscription owners address.
  * @param _subscription is the identifier of the customer's subscription with its relevant details.
  * @return balance the token balance of the address where the recurring payments will be deducted (the customer).
*/
function getSubscriptionOwnerBalance(bytes32 _subscription)
    public
    view
    returns (uint balance);
getAmountDueFromSubscription
/** @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);
getSubscriptionFee
/** @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);

Public Functions

cancelSubscription
/** @dev Cancel an existing subscription.
  * @param _subscription is the identifier of the customer's subscription with its relevant details.
*/
 cancelSubscription(bytes32 _subscription) public onlyAuthorized;

Conclusion

This is our suggestions for the beginning of a standardization on interaction with subscription data on the Ethereum blockchain. We are open to suggestions, concerns, or rejections. Let's collaborate and build a better ecosystem.