*EDIT: Subbi is live! Read more about it here.

Tl;dr Subbi* is solving decentralised subscription payments and opening up the recurring revenue economy, powered by Polygon. Currently live on the Mumbai Polygon testnet, you can help shape the future of Subbi in our discord, join today!

Subscription payments are everywhere. In the UK the average person spends £55 / month on subscriptions. In the US the average individual subscribes to 12 different entertainment services alone. It has become the de facto business model for almost any product entering the market today; aided by VCs favouring regular recurring revenue as early as possible and our acceptance of smaller more regular payments for services that we enjoy. There is an abundance of infrastructure and payment solutions to support fiat subscription payments. For the cryptocurrency backed web3 economy, this poses somewhat of a problem.

The problems

One of the core tenets of cryptocurrency is self custody. Every single transaction you make interacting with the blockchain of your choice needs to be signed and approved with the private key that you control associated with a particular public address. While very powerful and a fantastic tool combatting the potential negatives of centralisation, it throws somewhat of a spanner in the works with regards to subscription payments. If a user has to sign every single transaction, do they effectively have to ‘resubscribe’ every month they want to continue using a service?

The current demand on the main Ethereum network also poses another problem: gas prices. If we take the price of Netflix’s service in the US as an example, how can it be economically viable to process a transaction every month for a product charged at $9.99 with gas costs in the range of $20 for a value transfer?

To summarise, to gain UX parity with the traditional fiat economy around subscription payments, two issues need to be addressed:

1. Automated handling of recurring payments on behalf of a user, while maintaining decentralisation as much as possible.
2. Providing this at a much lower cost than the Ethereum mainnet currently allows.

Easy peasy, right?

The solution

So, how has Subbi solved both of these problems? The first is purely technical and involves something a lot of you will have heard of already: ERC20 tokens.

The ERC20 token standard is a boon here for two reasons: It allows businesses to transact in a stablecoin, providing far less volatility than fully native cryptocurrencies, beneficial when dealing in smaller, regular payments for goods and services. The interface for ERC20 tokens also has built in support for users giving authority to a third party to spend on their behalf. From a code perspective, this looks like:

    /**
     * @dev See {IERC20-approve}.
     *
     * NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on
     * `transferFrom`. This is semantically equivalent to an infinite approval.
     *
     * Requirements:
     *
     * - `spender` cannot be the zero address.
     */
    function approve(address spender, uint256 amount) public virtual override returns (bool) {
        address owner = _msgSender();
        _approve(owner, spender, amount);
        return true;
    }

A snippet from the brilliant OpenZeppelin’s ERC20 implementation

Now, granting a third party address the ability to transfer an unlimited amount of an ERC20 token may be raising a few alarm bells for some, and rightly so. How about granting control to a verified smart contract with very limited control over when and how much of said ERC20 token can be taken in one go? That seems like a far more palatable proposition. Each subscription set up with Subbi is an instantiation of a verifiable smart contract that can ONLY process Subbi powered subscription payments, ONLY once every 30 days and ONLY for the specified monthly cost. We will go into this in depth in a later, more technical, post. Each subscription also includes built in cancellation support and can be interacted with either directly or through the Subbi UI dashboard.

Ok, very cool you think, but are we not going backwards a bit? Just because it’s on a blockchain doesn’t make it decentralised if Subbi is the only entity that can process transactions. What if a government or other centralised powers puts pressure on Subbi to stop processing an individual creator or business’ transactions? This is where the beauty of Ethereum comes in. The contracts deployed by Subbi that trigger the processing of payments can be triggered by *anyone. *As long as a user is scheduled for payment and is still subscribed, anybody can trigger the payment to be processed, not just Subbi.

So, first problem solved. Fortunately, the second issue has been solved for us. While the Ethereum mainnet may be prohibitively expensive to process mass amounts of low value transactions, multiple fantastic Layer 2 (L2) chains have broken ground in the last 18 months. Allowing for faster transactions per second, these chains also unlock the potential for smaller ticket transactions to be processed. Subbi will be hosted on Polygon for launch, but in the future will be deployable and usable on any Ethereum Virtual Machine (EVM) compatible L2 chain. As a business or content creator, you want to focus on what you do best: providing your product to the world. Polygon allows Subbi to process near infinite payments every single day at an affordable cost, putting as much money in the pockets of businesses and creators as possible.

Subbi — The future of decentralised subscription payments

The first instalment of Subbi will be launched to Polygon mainnet very soon, aimed at helping you support your favourite content creators in the web3 space. You can play with our Mumbai testnet environment, or join our discord and help shape the future of Subbi.

We have big plans to help develop all the tools companies need to start accepting and managing decentralised subscription payments. Stay tuned!