At Multis, we recently announced the launch of our Standard Premium plan at $49/month. When setting up our payment solution, we wanted to stay aligned with our values and offer a non-custodial and decentralized approach to paying subscription fees while making the experience as smooth as possible: just like our app!
However, setting up recurring payments on the blockchain has been a challenging topic for years.
Monthly subscriptions: a channel that's difficult to adapt to the blockchain
As of today, there are two main ways to monetize content or services on the web:
An advertising model gives access to free online services but at a huge cost in user privacy (and to hardware as well). There is a growing consumer-lead resistance to ad based business models that sell user data. This has resulted in over 47% of internet users installing ad blockers in their browsers or even boycotting companies that make money off of user data.
On the other hand, monthly subscriptions are seen as a more sustainable, transparent, and healthier business model because they involve a clear contract of exchange between a provider/content creator and a consumer.
How recurring payments work in the legacy world
Before talking about blockchain and the challenges implementing an automated subscriptions system, let's see how this works in the legacy world. When people subscribe to a service provider like Netflix, Spotify, a car insurance or an online media, they have to trust these providers in order to share personal financial information with them such as a credit card numbers or a bank direct debit authorization so those services can take a payment on a monthly or annual basis.
Trust usually comes from the reputation of the provider or the insurance that comes with credit cards or banks, so consumers can subscribe safely without risking much in case of scam or hack (well, it's not that safe, credit card fraud cost $190 billion last year).
Recurring payments on the Blockchain is hard
The Blockchain is often considered trust-less because it is a network of pseudonymous actors, so instead of trusting people or institutions, you have to trust programs (called smart-contracts) which are open-sourced and visible to anyone. What's more, every single transaction on the blockchain has to be signed by the payer using his private key, so considering this, non-custodial automated recurring payments are technically impossible because the payer would have to sign a new transaction every month.
But the benefits of blockchain remain: data/fund ownership, censorship resistance, and transparency — much needed qualities for building tomorrow's digital systems.
Previous attempts to build recurring payments on the blockchain
In the summer of 2018, a group of crypto actors saw the potential that a subscriptions business model had for mainstreaming crypto, as opposed to the dominant business model which was based on complex token economic systems. They launched EIP-1337: Subscriptions on the blockchain (an Ethereum Improvement Proposal to standardize subscriptions on Ethereum). Unfortunately, despite some initial funding and an alliance to work on this, the standard has yet to be finalized or adopted by the Ethereum community.
Coincidentally around the same time, another player called Ʉnlock Protocol started working at this problem from a different angle: decentralized paywall and content monetization, that has evolved over the years into a more generalized solution to manage memberships on the blockchain.
How Multis integrates Ʉnlock Protocol for recurring payments
About Ʉnlock Protocol
Ʉnlock is a protocol for memberships built on a blockchain and offers a solution to lock and manage access to content, apps, communities and even real life events. This protocol enables creators to monetize their content or software without relying on a third-party. It's a practical way to manage subscriptions and it's structurally and ideologically consistent with the blockchain.
Recently, a new release of the protocol introduced a smart-contract called KeyPurchaser to support recurring membership through a standard ERC20 allowance mechanism. Read more about it in their recurring memberships announcement blogpost.
Multis saw in Ʉnlock Protocol a reusable and secure solution to handle monthly subscriptions in a decentralized and non-custodial way similarly to our multi-signature wallet.
The Lock smart-contract
The Lock smart-contract represents an access to a resource and can provide an expirable access key in exchange for crypto-currencies (ETH or ERC20 depending how the lock is configured).
It has multiple capabilities (source: documentation)
- Administrative: these are the functions which change ownership of the lock or change the address of the Ʉnlock Protocol smart contract, as well as the maximum number of keys, their release mechanism (public, pre-validated, private) or their expiration (period, date or interval) and of course their price (including the mechanism used to set the price: fixed or variable). Finally, there is a method to withdraw funds from the lock contract itself.
- Transferring key ownership: keys can be purchased from the lock smart contract itself or from another user who purchased one previously. Another element is that keys can be purchased on behalf of somebody else (this is important because this lets somebody pay gas fees on behalf of somebody else).
- Changing key attributes: the keys have an expiration date which can be changed as well as data attributes which can be changed to something else.
Keys are NFTs (following the ERC-721 Non-Fungible Token Standard) so it automatically expends all the properties from this type of token: ownership, transferable, tradable.
Another interesting property are Hooks, allowing to expand Lock functionalities. For example, the Discount hook allows to apply a discount to the price of the key using a cryptographic mechanism based on a discount code.
The KeyPurchaser smart-contract
The KeyPurchaser smart-contract allows users to purchase a single key or start a regular subscription to a Lock. Users only need to configure an ERC20 allowance with the KeyPurchaser and an automated program takes care of buying/renewing keys on behalf of the users on a regular basis as long as the allowance permits it and the users has enough funds (ERC20).
Basically, this works almost same as a bank Direct Debit authorization where you allow a third-party to debit a limited amount every month. The ERC20 allowance on the other hand does not have the concept of periodicity, so users have to authorize the KeyPurchaser to spend a specific amount which must be a multiple of the key price (e.g 12 * key-price to authorize a debit of the price of the key every month for a year). Finally the KeyPurchaser has a mechanism preventing it to automatically renew a key more than once in a period or renew a key if the price has increased more than a fixed percentage.
For more information.
Integration with Multis
Multis deployed a Lock to manage access to our Crypto-first Business Banking solution. The client-side application is now restricted to Key owner only.
Our Multis Lock is configured with the following properties:
- Currency: DAI
- Key price: 49.00
- Expiration: 30.5 days
- Max keys: 99999
When a user creates a Multis account, they begin with a free 30 day trial. Following this period, account owners have to obtain enough DAI to cover the subscription costs and set up an allowance for our Multis Subscription smart-contract (our KeyPurchaser) so we can automatically process the payment and create or renew a key for the next 30 days. If the payment fails, the user has a grace period of 14 days before we close their account.
Under the hood, a Firebase Cloud function monitors expired trials and expired subscriptions on a daily basis. For each expired wallets, our function will first determine the final key price by calling the method keyPrice = lock.purchasePriceFor(_recipient, _referrer, _data) where:
- _recipient represents the expired account we try to renew a subscription
- _referrer represents a referral account (0x0000000000000000000000000000000000000000 for no referral)
- _data is a unique signature representing a discount for this account (read more about the Discount Codes Hook)
Once we retrieved the keyPrice, the cloud function will verify if the wallet owns enough DAI and have enough DAI authorized as allowance for the KeyPurchaser:
- balance = dai.balance(_account: <wallet-addr>) => balance ≥ keyPrice
- allowance = dai.allowance(_spender: <key-purchaser-addr>, _owner: <wallet-addr>) => allowance ≥ keyPrice
Finally, accounts with enough DAI and allowance are renewed for the next 30 days by sending a transaction txHash = keyPurchaser.purchaseFor(_recipient, _referrer, _data) and another process will track successful transactions to notify the payment in the Multis App (transaction history).
For accounts without enough DAI or allowance, we notify the owners of the accounts by email.
Finally, Multis is proud to earn revenue directly on-chain without unnecessary middlemen. Ʉnlock Protocol provides all the functionalities needed to run membership and recurring payment systems on Ethereum leveraging ERC20s and allowances.
If you are looking for a convenient way to manage your company's crypto, Sign-up here and enjoy a 30-day free trial of Multis.
Links & resources
- Multis Introduces Automated Subscription Payments
- Ʉnlock Protocol Twitter
- Ʉnlock Protocol GitHub
- Ʉnlock Protocol Documentation (Lock, KeyPurchaser, Discount Codes)