Subscription Services On The Blockchain: ERC-948
This article originally appeared on Consensys Media. It is reposted here with the permission of Consensys, a blockchain venture production studio building decentralized applications on Ethereum.
The Subscription Economy
In the years following the 2008 crisis, subscription-model companies emerged in droves. Recognizing consumers’ preference for the financial consistency of purchasing a small amount over a longer period of time, innovators applied the subscription model to product “boxes,” household goods, media streaming services, and software products. And the innovation has paid off. B2C subscription businesses attracted more than 11 million customers in 2017, and more than 2,000 B2C subscription companies existed as of the end of the year. Since 2014, visitation to subscription company websites has increased more than 800%, with 37 million visitors. A McKinsey study in February of 2018 determined that 15% of online shoppers had subscribed to an e-commerce subscription over the past year. Notably, the streaming-media services (Netflix, etc.) had converted 46% of online shoppers into subscription customers.
The subscription-model economy does not show signs of slowing down. It has proven a modern and successful method of providing services and products to affluent consumers (McKinsey shows the average subscription customer as having an income of $55,000 — $100,000). As more businesses move towards blockchain, it would make sense for blockchain developers and evangelists to ensure the technology can support subscription models. Enter ERC-948, a proposal for a new Ethereum token protocol built specifically to facilitate subscription-based transactions. To use the language of the GitHub thread on which the standard was originally presented, this post will examine the merit and the viability of a new protocol to support this token functionality.
The Merit of a Subscription Protocol
The economic merit for a token standard that facilitates the subscription economy is established by financial statistics of the past decade. The question arises, however, of why a brand new protocol must be debated & developed. Why can’t we use ether or an existing protocol such as ERC-20?
Subscription Models with Ether
Currently, there exists no efficient method for ether to effectively serve as the currency for a subscription-model company. Operating a subscription model with ether would require every transaction to be signed with one’s private key. At scale, customers would not be able or willing to keep up with signing a transaction every month for a service or product. The closest option is for the consumer to establish and control a prepaid subscription with ether held in escrow. S/he can add ether to the escrow to extend the subscription, or cancel the subscription and receive the remaining funds from escrow. The service provider would be able to withdraw from the escrow an amount equal to [subscription rate * time since last withdrawal].
The issue with this model is that it requires the subscriber to place a lot of funds in escrow from the very beginning (to which they do not have access unless they cancel the subscription), or remember to fund the escrow every month with the necessary funds to continue all their subscriptions. The choice, therefore, is either an upfront capital commitment or tedious, regular management. Neither will be scalable from a consumer experience standpoint.
Discussions have emerged proposing that ether becomes an ERC-20 token. However, the ERC-20 protocol is not set up to easily facilitate subscription models either.
Subscription Models with the ERC-20 Protocol
With the current ERC-20 protocol on the Ethereum blockchain, the closest contract we could develop to a true time-based subscription model would require the service to send an email or notification every month to reconfirm. This “opt-in” process would look something like:
Signing a tx
Broadcasting a tx
This method contradicts one of the central marketing and psychological tenets of a subscription model. The “opt-in” method creates friction for the customer — s/he must approve every month to continue with the service. Subscription companies, though successful, constantly struggle with high churn. 40% of e-commerce subscribers canceled one or more subscriptions in 2017. The more friction a company places in front of the user, the more likely that user is to cancel the subscription. The more frequently the customer is reminded of the financial commitment, or is asked to (re)confirm the subscription, the more points of failure exist. In a future where each Ethereum-based consumer could have dozens of subscriptions, an opt-in method is particularly untenable at scale.
Preferable to the “opt-in” method is the “opt-out” method, in which the consumer must decide to discontinue, rather than to continue, but it is currently not commonplace on the ERC-20 standard. One possibility for an opt-out method would require a company to present a user with an approve(x)function in a contract, in which x = price*n (price = monthly cost of service/good and n = number of months). Then, every month, the company would call transfer(x/n).
The issues with this model are twofold. First, a user will want strong guarantees on when they can cancel my subscription. The user will want to be able to cancel their subscription at any time with a cancel() function which provably and immediately cancels the subscription. Implementations should ensure that any unpaid subscription payments are paid to the provider as part of cancellation to ensure providers are able to let subscriptions fees fill up for arbitrary lengths of time, allowing them to reduce overhead from transaction costs.
Second, the ERC-20 “opt-out” standard requires the user to determine from the beginning how long his/her subscription will last, and then requires them to renew the contract each time “n” is reached. The more decisions a company forces a consumer to make about their subscription details, the less likely the consumer is to follow through with the entire process. One possible workaround would be to set the subscription period for a very long time, i.e. n = 1000. The user, however, does not want to pay for 1000 months of subscription, so some assurances must be provided to the user that the company would only charge them at most the monthly cost of service/good, each month.
A minimal opt-out implementation on the ERC-20 protocol, suggested by EF developer Piper Merriam, would require the following fields.
address token: defines the token contract which payments are paid from.
address provider: the address of the provider.
uint256 time_unit: the number of seconds per time unit.
uint256 tokens_per_time_unit: the number of tokens that can be paid towards the subscription per time_unit.
uint256 last_payment_at: the timestamp when the last payment was made.
The triggerPayment method would call token.transfer(provider, (now — last_payment_at) * tokens_per_time_unit / time_unit)`.
Though the ERC-20 protocol would allow for early implementations of a subscription model, both the opt-in and opt-out options possible would likely lead to high consumer churn due to poor UX.
The Viability of the ERC-948 Protocol Proposal
Having established the economic incentive for subscription-capable tokens and the absence of a protocol on which to currently build those tokens, we can now look at what the ERC-948 protocol could look like.
An opt-out method would be most successful from an economic perspective, as it would align consumer and supplier incentives. The opt-out protocol could look something like the following:
User allows “x” tokens to be withdrawn from his/her wallet every “y” time period by “z” company.
User may remove consent at any time.
Owner of “z” company may remove “x” tokens from User’s wallet every “y” time period. Transaction will throw() unless “x” tokens are available, User consent is active, and it has been “y” time period since the last withdrawal.
Leveraging the power of smart contracts on the Ethereum blockchain, an opt-out smart contract for a subscription service built on ERC-948 could look like:
Service deploys a smart contract that can withdraw tokens from users.
User approves the contract for an unlimited allowance and an unlimited amount of time.
User calls createSubscription() function to the contract, permitting “x” tokens to be withdrawn from his/her wallet every “y” time period by “z” Service until User cancels.
Every “y” time period, the Service calls withdrawSubscription(), which uses transferFrom() to collect the “x” tokens that have been authorized for that payment period, dependent on funds being available and User consent being active.
The viability of the ERC-948 protocol is contingent on the following:
- The protocol should be built to support either a shared contract or a contract-per-subscription. With a shared contract, the user would not need to audit every single subscription. S/he would only need to set up one createSubscription() function instead of deploying a contract for every new subscription. From a customer experience perspective, this model is likely preferable. In an economy where 35% of consumers have more than three live subscriptions, a single source of subscription management would be most user-friendly instead of managing all contracts separately. There are also gas-savings considerations that make a shared contract preferable. As with any sort of centralization, however, the shared contract method creates a single source of vulnerability. With a contract-per-subscription model, the user would need to deploy a new createSubscription() function for every new subscription s/he joined. Spreading out contracts reduces the attack surface area, but could decrease user experience by forcing consumers to manage all their subscriptions separately.
- The price volatility of tokens raises challenges when companies ask consumer permission to withdraw “x” tokens every “y” time period over a long period of time. A monthly charge of, let’s say, one particular token, could translate into wildly different USD amounts over a six month period. It could simply be a user’s bad or good luck if funds were withdrawn on one day instead of another. Innovation will not wait for token valuations to stabilize. A short-term remedy may be to set the subscription cost in fiat currency and then charge the consumer whatever the transaction rate is at the time of payment. Another option would be to ensure ERC-948 supports stable coins, such as the recently-released Dai.
- For the service provider, issuing a new contract for each individual subscriber’s wallet is a time-consuming, gas-consuming, and tedious process, and can be economically untenable given high churn rates among subscription customers. A solution could be to mimic the “shared contract” concept, whereby companies deploy one smart contract that can withdraw tokens from all users. This becomes a bit more complicated if/when companies have different tiers of membership or B2C v. B2B subscription models.
- Gas — the fee required to run each operation within a contract on the Ethereum blockchain — is another hurdle future blockchain-based subscription companies will have to face. The current subscription model succeeds off price transparency. Consumers are told what they are going to pay per time period and are often promised no extra or hidden fees. To many, gas may feel like a hidden fee if, on top of the monthly subscription cost, they are required to pay for the gas fee of executing the subscription function every time a payment is due — especially when the gas fees are subject to change. Subscription companies should see the opportunity to mediate gas fees as a customer experience opportunity. If, perhaps, companies are able to estimate gas fees, they could roll those fees into the overall cost of the product, thereby adhering to the customer’s expectation that the advertised subscription price is the final one.
The ERC-948 protocol proposal provides an opportunity for developers to build a platform off of which companies can leverage an economic model that has proven valuable in the retail and software economy in the past decade. If a common standard were built for subscriptions, it could further attract more consumer-facing companies to blockchain technology. And though much blockchain rhetoric lambasts the old and celebrates the new, we should keep an eye towards the incentive structures that have proven successful in our current economy. The subscription economy is certainly one.
Kevin Owocki initiated the protocol proposal on GitHub and helped with this article. He is the founder of Gitcoin.co — an Ethereum-based network for growing open source software with incentivization mechanics. He has a BS in Computer Science, 10 years of engineering leadership experience in startups and Open Source Software, and is a community organizer in the Boulder Colorado Tech Scene.
Kevin believes strongly that the future of work is unbundled; the future of knowledge work will be driven by decentralization, community, and emergent collaboration. Gitcoin a one-stop shop that gives Software Developers the skills & connections to survive and thrive in this new blockchain ecosystem.
Disclaimer: The views expressed by the author above do not necessarily represent the views of Consensys AG. Consensys is a decentralized community with ConsenSys Media being a platform for members to freely express their diverse ideas and perspectives. To learn more about Consensys and Ethereum, please visit our website.