Jun 25, 2020
Who pays the ferryman?
The internet model of “free” services is underpinned by the advertising world and the consumer is the product. In blockchain, things are different, the infrastructure is maintained through rewards to pay to secure the network and transaction fees. Transaction fees serve two purposes, a revenue stream that pays the miners or validators and to prevent spamming of the network.
When we consider smart contracts then we must think about transaction fees as there is a cost to run them. The orthodoxy in blockchain is that consumer pays. The user drop off is huge when they need to start writing down a recovery phrase to set up a wallet, have to go through KYC in order to buy a native token, install a browser extension to sign transactions.
These are some barriers to the adoption of decentralised applications (dApps), and for dApp developers there needs to be a clear advantage over building an App and deploying it on the cloud. For the end users the blockchain technology needs to be made as seamless as using a traditional App.
Let’s re-examine fees
When a user downloads an App from Google Play or Apple’s App store, they either expect it to be free or pay a one-off fee and at most pay for add-ons (skins, weapons, players etc). Users do not expect to have to fund a wallet containing native tokens, nor to pay for every single interaction when the something changes.
As was explained in the introduction, it is clear that network fees need paying as they form a powerful anti-spam mechanism and the fees paid contribute to the running of the blockchain. The first question is who pays the network fees? In looking at the cost structures of traditional Apps, there are hosting fees for running the back-end services, databases and HTTP servers paid for by the companies running them , why then do the end users of dApps have to pay the fees? The “free” expectation is managed in the App world by the consumer/user becoming the “product”, this is done by intrusive tracking, and selling the data to “ad brokers” who will build sophisticated target markets to sell to advertisers. This is objectionable to many in the blockchain bubble but millions of people around the world care less about privacy than price but this is changing.
What if…?
Let’s consider defying convention, what if the dApp builder paid the fees?
The dApp builder pays the network fees through a form of subscription, either buying fees in blocks in advance or having an account set in the dApp that is the payer and the account is maintained by the dApp builder. From a business aspect they can either sell subscriptions for a service or include the network fee in one off purchases.
The alternative is the other tried and tested way namely to sell advertising which would fund the network fees, this may involve selling customer behaviour information through data gathering cookies. This is a non-starter on many grounds.
The dApp builders need to work on business models to recoup the subscriptions from users and find a way to manage the “transaction fee cash-flow”.
The dApp builder wants to remove as many barriers to the customer using their software, and builds a subscription based web app. The dApp builder uses these subscriptions to fund a wallet that pays the transaction fees. This hybrid of off- and on-chain business will increase the adoption by removing many of the barriers.
There are two issues around building this functionality, it goes against the permissionless convention of the blockchain and introduces a Spam attack vector.
The permissionless argument is more philosophical, however, the introduction of boundaries around a smart contract while creating some centralisation is contained and very limited. In other words the dApps themselves cannot be interfered with, in no way can a central authority censor writing interactions with a dApp such as freezing tokens. It should also be noted that there is no impact on the overall decentralised nature of the blockchain.
The Spam attack vector, is the scenario where a spammer repeatedly calls the dApp which empties the wallet of the dApp builder by deducting the transaction fees.
What are the options?
The obvious solution is for the dApp builder to allow anyone to use the dApp with the understanding that they pay the fees themselves, however, they will offer to pay the fees for “known users”. This might involve the person registering on the dApp builder’s website, as part of a “value add or enhanced user experience”.
Once the user is known there are several options.
- The dApp builder runs the contract on their behalf and pay the fees from the central wallet.
- A “fee allowance” method to delegate some limited number of my tokens to your account to be used as fees.
- As a customer you send any transaction you want to submit to my node with my address marked as the fee payer, and just signed by you
- If you are on the whitelist on my server, and the transaction only contains calls to my app, then I “co-sign” the transaction to pay the fee and submit it
By paying the blockchain fees and charging the customer through a subscription service a dApp builder will lower the barriers to adoption and help grow their business. The mechanisms to do this are possible and can be designed with safeguards around known attack vectors.
