ERC-1337: Subscriptions on the blockchain

Metadata

Status: StagnantStandards Track: ERCCreated: 2018-08-01

Authors

Kevin Owocki (kevin@gitcoin.co), Andrew Redden (andrew@blockcrushr.com), Scott Burke (scott@blockcrushr.com), Kevin Seagraves (k.s.seagraves@gmail.com), Luka Kacil (luka.kacil@gmail.com), Štefan Šimec (stefan.simec@gmail.com), Piotr Kosiński (@kosecki123), ankit raj (tradeninja7@gmail.com), John Griffin (john@atchai.com), Nathan Creswell (nathantr@gmail.com)

Requires

EIP-20, EIP-165

Links

GitHub page Discussion on Ethereum Magicians

Simple Summary

Monthly subscriptions are a key monetization channel for legacy web, and arguably they are the most healthy monetization channel for businesses on the legacy web (especially when compared to ad/surveillance) based models. They are arguably more healthy than a token based economic system (depending upon the vesting model of the ICO) because

For a user:

you don't have to read a complex whitepaper to use a dapps utility (as opposed to utility tokens)
you don't have to understand the founder's vesting schedules
you can cancel anytime

For a Service Provider:

since you know your subscriber numbers, churn numbers, conversion rate, you get consistent cash flow, and accurate projections
you get to focus on making your customers happy
enables you to remove speculators from your ecosystem

For these reasons, we think it's imperative to create a standard way to do 'subscriptions' on Ethereum.

Abstract

To enable replay-able transactions users sign a concatenated bytes hash that is composed of the input data needed to execute the transaction. This data is stored off chain by the recipient of the payment and is transmitted to the customers smart contract for execution alongside a provided signature.

Motivation

Recurring payments are the bedrock of SaSS and countless other businesses, a robust specification for defining this interaction will enable a broad spectrum of revenue generation and business models.

Specification

Enum Contract

EIP-1337 Contracts should be compiled with a contract that references all the enumerations that are required for operation

EIP-165

EIP-1337 compliant contracts support EIP-165 announcing what interfaces they support

Public View Functions

isValidSubscription

getSubscriptionStatus

getSubscriptionHash

getModifyStatusHash

Public Functions

modifyStatus

executeSubscription

Rationale

Merchants who accept credit-cards do so by storing a token that is retrieved from a third party processor(stripe, paypal, etc), this token is used to grant access to pull payment from the cx's credit card provider and move funds to the merchant account. Having users sign input data acts in a similliar fashion and enables that merchant to store the signature of the concatenated bytes hash and input data used to generate the hash and pass them off to the contract holding the subscription logic, thus enabling a workflow that is similliar to what exists in the present day legacy web.

Backwards Compatibility

N/A

Test Cases

TBD

Implementation

TBD