Try   HackMD

Subscription Friendly Fungible Token


Problem

The existing standard for fungible tokens, known as ERC20, includes a function called transferFrom. The purpose of this function is to delegate control over a certain amount of a user's token balance to another smart contract. This allows a specific quantity of tokens to be transferred from the user's address to the contract's address, and so on.

This concept has its roots in the traditional banking system and the credit card model. For instance, when you subscribe to a service like Spotify, you grant Spotify the right to withdraw a specific amount of money from your bank account each month. The transferFrom function aims to replicate this concept.

Let's say Spotify accepts an ERC20 token (e.g., DAI) as a payment method, and you can subscribe to Spotify using this token. As we've already noted, the ERC20 transferFrom function provides the infrastructure needed for this subscription model. Therefore, a Spotify user can use the approve function to grant allowance to the Spotify access manager contract, which can then use this allowance to charge users each month.

At first glance, everything seems fine, right? However, there are a few problems.

Imagine a scenario in which a million users subscribe to Spotify using the DAI token, granting allowance to the Spotify contract to charge them. Now, the Spotify contract needs to be triggered to use the allowance that users have granted. We could have a manager role in the Spotify contract to trigger the chargeUser function, but assuming we have a million users, the operational cost of triggering the contract would be prohibitively high and unacceptable. Consequently, as a service provider, we would have to pass this operational cost onto the user, affecting both user expenses and the business's operational effort and cost. While the account abstraction approach can mitigate the effort, the core problem remains.

The main issue is that in the current ERC20 standard, when we call the transferFrom function, it uses SSTORE to update the balance of the user and the Spotify manager contract. We could address this by using a new approach at a higher level. In this work, we aim to identify and design a better data structure for the Subscription-Friendly Fungible Token to tackle the existing problem - the cost and heavy operational burden of using the current ERC20 as a payment method for subscription services.


I stoped working on it because i found the Superfluid and its good approach for solving the problem i described.