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.

Marko Vidrih

source: Consensys