Layer 1 Economic Abstraction

How to drive more blockchain and dApp usage through layer 1 economic abstraction on the current transaction fee model.

Full Service Gas Station

Who wants to interact with the underlying blockchain, we just care about the things built on top of it.

Preface

Remember those times when you withdrew some ERC20 tokens to a fresh address and now your ETH-less address only has tokens that cannot be withdrawn… Or when you wanted to interact with a dApp but only had ERC20s in your wallet. This happens to nearly everyone and is inhibiting the UX and usability of blockchains. We need to have an economic abstraction of the underlying blockchain to encourage token and dApp usage to drive adoption to a mass audience.

Users are concerned with:

1. Interacting with a dApp / service independently of the underlying chain
2. Preventing loss aversion from transactions fees
3. Accounting for capital gains for every single transaction
4. Interacting with a censorship resistance protocol

Can’t Send?

Attempting to transfer ERC20 tokens, some methods fail, other succeeds

We¹ devised a mechanism to transfer ERC20s and interact with smart contracts without requiring any ether in the originating wallet. This is achieved by having an off chain delegator pay the transaction fee on behalf of a signer. As a token of appreciation, the delegator receives a fee denominated in the underlying token.

The Need

Users can normally can only interact with a blockchain using the native token. In a store of value chain this does not matter, as there is only one kind of transaction and fee is paid in the same token that is being transferred. But this encompasses a very small number of blockchains. Most chains allow and encourage assets and applications to live on top of them. In these cases, users are interested in interacting with the applications on the blockchain, and if the apps have their own tokens why should the user need to use the underlying native blockchain token? If blockchain is truly going to be the infrastructure for the future must everyone be concerned about the multiple native tokens that they must have to interact with the decentralised web?

Economic Abstraction Use Cases

Some use cases of economic abstraction

1. Interacting with a dApp → often time an end user only wants to interact with a specific dApp and does not care which chain it lives on. Developers can build a service and be the delegator to enable all fees be paid in the dApp utility token. This also provides the added benefit of chain portability, where the developers can switch the underlying blockchain without affecting the underlying user experience.
2. Airdrops → instead of simply airdropping tokens that a user can’t spend unless they have ether in their address. Send them wrapped tokens that they can use immediately on a dApp / service.
3. Accounting in a stablecoin → There is a case where a company / individual wants to do all their accounting in a stablecoin rather than the underlying native token, as every single transaction would be a taxable event.

How this Drives Adoption

By tying a dApp to an underlying chain, it intrinsically ties a user to it. Users must always ensure that they have a sufficient balance of ether / native coin to transact in a variety of network conditions. This added accounting and complexity is mental overhead that makes usage more difficult and discouraging. The difficulty with self sovereignty is that a user must rely on themselves much more for basic needs. By reducing mental complexity from the user experience, the end user can just interact with the dApp. And by removing loss aversion, there will be less onboarding friction. This removes all the previous barriers to usage.

1. Enterprise Adoption: If a large enterprise is a using a dApp, how will accounting work for all the users? Imagine a decentralised ordering system. Every time an individual needs more paper, etc they will have to submit an onchain order. The enterprise has to distribute ether / native coins to every users’ wallet in order. This adds a layer of accounting complexity and waste, as users will use their ether at different rates and some will have dust that is lost. But with transaction fee delegation, there only needs to be one account with ether, and the enterprise can still use on chain as a source of truth as each user has a public private key pair.
2. Individual User Adoption: Every transaction has a protocol required transaction fee on top of potential token fees the user must pay to use the dApp. Rather than having to pay in effectively 2 different tokens, developers can be delegators for their users and pay for all the blockchain transaction fees. This encourages both new users to try out the dApp and existing users to transact more. Developers can implement models where n number of transactions are free and any transactions afterwards are paid, etc. Many models from the traditional app / SaaS world can be applied here: ads, freemium, paid, subscription, pay-as-you-go, etc models to encourage growth. Users rather pay slightly more in a subscription model rather than suffer the overhead of tracking of every single transaction fee.

Standardization

To encourage this development there needs to be standardization for delegated transaction fee payments for both the sending of tokens and smart contract execution. Some blockchains have this delegated gas paying native into the protocol such as VeChain and Stellar². VeChain call it multi party payment, and allow for a 3rd party pay for fees. In their implementation[1][2], the master address gives credit to all the users which is deducted from their balance every time they transact. A comparable in Ethereum is an ERC20 allowance. The advantage of VeChain’s implementation is censorship resistance, instead of having to delegate the transaction through an off-chain relayer network, users can submit their transaction directly to the blockchain. Stellar’s feature is called channels, where the source account is different from the one originating the transaction.

Already there have been attempts to create these standard in Ethereum through ERC-1077, ERC-777, ERC-865 and ERC-1228.

But the biggest question is why does this exist on the smart contract layer, ideally this should be implemented natively into the protocol to make dApp usage easier for all users. So users can submit their transactions directly to a miner / validator instead of an off-chain delegator. (Users can also be running full nodes, in the delegator model there is no point).

Reducing Friction

The sole goals of these systems are to reduce friction and encourage adoption. Blockchain won’t be able to become the next internet if there are so many fees that users have to pay to simply interact with their favourite applications. A simple prediction, but nearly all dApps in the future will pay for their users fees and implement system such as subscription fees which more users are accustomed to.

Technical Details:

Look here in the GitHub repository.

Alternatives

Although there is a lot of value delegating fees for on chain transactions, if the transaction does not need to achieve on chain finality, there are other methods that serve similar functionality. This includes: State Channels / Plasma and Oracles (these could be considered layer 2 economic abstraction :)).

Further Reading:

1. Against Economic Abstraction — Vlad Zamfir
2. On Abstraction — Vitalik Buterin

Footnotes:

1. Leland Lee, Alan Lai (Blockchain at Berkeley) and Phillip Liu Jr. (JD Capital) worked on this project at a hackathon sponsored by MakerDAO and Wyre.
2. I have never held VeChain or Stellar.