The State of Meta Transactions

Published in

HackerNoon.com

8 min readMay 7, 2019

**Figure**: The feeling when the latest batch of gas is delivered

How many steps does it take to claim that kitten? The official guide from the creators of CryptoKitties instructs users to first install Metamask before purchasing Ether, followed by many additional steps. This shows how terrible Blockchain UX is. Users are helpless without having the underlying protocol token. This locks out a huge portion of the population from adopting blockchain.

There’s a concept called “meta-transactions” or “fee delegation” that permits a third party to pay for a transaction fee on behalf of a user. Today we will survey the different techniques across Ethereum, Stellar and VeChain that enable these transactions and compare them with our evaluation framework.

Meta Transaction Use Cases

A common use case for meta transactions is for improving usability for first-time users, but they have more applications.

dApps want users to only use their native token (ex: for paying fees)
dApps want users to use their native token for governance, voting, etc, without users being tied to the underlying chain (which makes chain migration easier)
Streamlining accounting for users. Calculating capital gains for every single transaction across multiple accounts is painful for even the most intrepid accountant.
Streamlining key management. Have one master wallet that contains funds and child wallets for every single device
Encouraging particular behaviors. Ex: encouraging the users to add rather than remove liquidity on a DEX [Granted there are other ways of facilitating this that might make more sense such as exchange rebates]
Potential increases in privacy if accounts don’t need to be funded for transactions. It is not as obvious that user of dApp A is also a user of dApp B as they don’t usually need to send native tokens to each other.

Ethereum

Having one of the largest developer communities in the blockchain space, Ethereum has a diverse set of proposals that enable meta transactions. Note some of these are still proposals while others are being used in the wild and there is no consensus on what the best approach is as of now. (also DM me if you feel that the categorizations are off in any way)

Smart Contract Based Delegators

New Token Standards

ERC-1776 Native Meta Transactions
ERC-865 Pay transfers in tokens instead of gas, in one transaction
ERC-1003 Token Standard (ERC20 Extension)
ERC-1228 Delegated Execution

Wrapper Contracts

ERC-20 Wrapper

Changes to EVM

EIP1035 Transaction execution batching and delegation

Relayer Networks

Uport TxRelay (requires compatible smart contracts)
Aragon’s Pay Protocol
EIP-1613 Gas Station Networks

Signature Standards

ERC-1077 Executable Signed Messages refunded by the contract

Due to the plethora of proposals for Ethereum, we will not go into detail for every one, instead we will focus on Proxy Bouncers and EIP-1613.

Proxy Bouncers

A relayer can deploy a proxy contract and add additional addresses to its whitelist and enable them to transact through the contract. This allows any dApp user to interact with any smart contract that it chooses to, as the transactions are forwarded by the proxy contract. The limitation of this system is that the msg.sender is the proxy contract rather the account which might be an issue when interacting with particular types of smart contracts.

EIP-1613

Because meta transactions rely on a third party to relay transactions, early implementations had a single point of failure, the sole relayer. There have been attempts at creating decentralized relayer networks that are censorship resistant. However without a coordination layer the thundering herd problem might arise, resulting in all relayers trying to relay the same transaction with only one succeeding and the rest wasting gas.

EIP-1613 uses an anchor of trust called the RelayHub which acts as a registrar of relays (aka gas stations). The RelayHub mediates transactions between relays and dApp contracts. Relays are staked and they build reputation scores which will enable users to select relays with a decreased worry of being censored.

Stellar

Channels

Stellar channels were originally intended as a method to increase the transaction throughput of a single address. This is because Stellar transactions must be ordered and submitted in sequence and there is no guarantee of ordinality with the Horizon server (node software), potentially leading to bad sequence errors. Channels were a roundabout way to increase throughput by using different accounts to send transactions while maintaining the same “source” account for funding of these transactions.

Creatively, the concept of channels can be retooled for meta transactions.

Create Stellar account
Fund account with a minimum balance
Users create a transaction, specifying their sponsor as the `source` address (ie the payer)
Users transfer the unsigned transaction to their sponsor
Sponsors sign the transaction
Users sign the transaction and submit it (note users can sign the transaction before sending it to sponsors, however they will have to trust the sponsors to submit the transaction in a timely manner)

Note that the Stellar protocol mandates each account to have a minimum account balance of 0.5 XLM. Therefore channels may not be optimal for first-time users unless a third party is fronting the cost (perhaps the dApp the user is trying to interact with). However because the current cost is rather low, it might not be a huge issue (compared to say EOS account creation costs). But it is still a constraint that must be noted.

VeChain

Multi-Party Payment (MPP)

Protocols should elaborate in their documentation on the origin of their naming system, why is there so much diversity in naming, fee delegation or is it meta transactions again :p.

Anyhow, MPP is VeChain’s native form of fee delegation.

dApp creator deploys contract, they are the default master of the account.
A sponsor can sponsor the smart contract and pay for gas fees, if there is no sponsor then the contract pays for transaction fees (if toggled)
The master sets a credit plan for their smart contract. Credit is the max amount of VTHO (VeChain’s gas) per user and recoveryRate is the amount of VTHO that can be accumulated per block. This mechanism allows for automatic top off of users’ allowances for gas, and functions as a mechanism to reduce abuse.
The master adds or removes User(s) to use their smart contract
User sends signed transaction to the dApp
Check that User has sufficient credit (each user has their own credit balance)
Transaction is executed and the sponsor or master account’s gas balance is deducted

Unlike the other protocols that we have explored, MPP exists entirely on-chain, there is no off-chain co-signing process involved. Whether this is considered a desirable behaviour or not is up for debate.

(Fun side note: the VeChain foundation is currently sponsoring several dApps gas to encourage adoption and usage.)

Note: MPP applies to the entire contract. It is not possible to sponsor only particular function calls.

VIP191: Designated Gas Payer

To increase the flexibility of VeChain’s MPP protocol, a new standard has been approved and is awaiting implementation. VeChain Improvement Proposal 191 allows for any arbitrary “gas payer” to co-sign any transaction on behalf of the sender.

The signing flow follows:

Transaction Creation → Gas Payer Signing → User Signing → Submission.

Because the user is the one who submits the transaction to the Blockchain, he or she can control the submission timing.

VIP191 enables:

dApp creators and sponsors to pay fees only for particular actions rather than for all interactions with a particular smart contract. For example, in the case of a DEX that allows for fee-less limit orders and paid market orders. This encourages participants to add liquidity rather than take it away.
Sponsor interactions with other contracts that the dApp developer does not own. If one wants to use the VET+ contract (similar to WETH in Ethereum), the developer would not be able to sponsor the wrapping in MPP as the contract is owned by someone else.
Attaching additional operations by the payee/delegator. The payee can attach a clause saying he or she will accept payment in another token, the user can either sign and agree or toss the half signed transaction. This is useful for dApps who have their own internal token.

Desired Features / Comparison Matrix

Just because there are dozens of different ways to build meta transactions does not mean that they are all equal in feature set and capabilities. It is necessary to understand both the trade off space along with the associated use cases of each implementation.

Self Sovereignty — Are users the custodian of their own keys? (This a is a must).
Liveness — Do users require someone else beyond the the maintainers of the underlying blockchain to be online? (ie: relayer network or individual relayers)
Multiple Delegators — Can there be multiple delegators / relayers.
Integration — Can dApps implement this features without changes to their underlying smart contract code?
Cost — How much is the cost of such transactions, how much more is it compared to a non delegated transaction
Rate Limiting — Are there constraints on how many fees can be delegated per user?
Versatility — Can this implementation work for many use cases or just one?
Payee Flexibility — Can the payee be anyone, or is it just the creator of the contract, etc?
Timing / Censorship — Does the user have control over the timing of the final transaction?
In or Extra Protocol — Is this feature native to the blockchain?

What’s Next?

Ultimately meta transactions are an interesting strategy for improving the user experience when interacting with blockchains. But perhaps that is the wrong mindset to have, maybe blockchains should be difficult to transact with. Nonetheless this is the status quo, what trade offs should protocols make make when building meta transactions?