**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.