The Meta Transaction Flow

Building a meta transaction relayer network involves quite a few elements that need to be well defined and addressed as this space opens and developers realise the difficulty associated with user onboarding. As we receive feedback from the launch of our alpha Meta transaction SDK, which we call Mexa, we are continuously refining the moving parts and components of it.

If you’re just tuning in and super confused about the above, meta transactions is a simple concept that negates the need for the end-user having to pay gas costs when using a DApp. In other words, the user uses the blockchain without them realizing it, and more importantly without having to download an external wallet or buy cryptocurrencies from an exchange. You can read more about it here.

On our website, we have the following diagram, and this is a simple construct of the moving parts of our meta transaction architecture.

The following are the different components of our architecture:

• User Wallets
• User contract wallets
• Relayers
• Relayer Engine
• Biconomy relay hub contract
• Limits and dashboard

Scalability, transaction ordering, security, and handling dropped transactions if gas fees are too high are all part and parcel of running an effective and efficient relayer network that relies on the above-mentioned components. Let us explore these components in technical detail.

User wallets

One of the innovations of Mexa is that we are compatible with existing Web 3.0 wallets. Since Mexa is Web 3 compatible, we can seamlessly work with any Web 3 provider that supports following rpc methods : personal_sign, eth_accounts, eth_sendTransaction, eth_call and web3 subscriptions.

When a DApp integrates Mexa, it can choose its preferred wallet(s) it would like it’s end users to login with to provide the meta transaction capability.

The reason why this is important is that regardless of the wallet and/or login solution, the solution is agnostic. We aim to work with solutions that provide seamless login experiences that complement our meta transaction capability as well.

How biconomy integrates with existing wallets?

Mexa needs a web3 provider to be initialized and then it acts as a wrapper around the given provider.

After this, dapp developers can use biconomy instance in place of existing provider to initialize the web3 instance as mentioned below:

const biconomy = new Biconomy(<web3 provider>,{dappId: <DApp ID>, apiKey: <API Key>});
web3 = new Web3(biconomy);

User contract wallets

This is a core component of meta transactions because contract wallets allow more flexibility at the contract level meaning that it is possible to customize their behavior.

This provides the following benefits:

1. User contract wallet solves the msg.sender problem

In ethereum smart contracts, msg.sender is used to get the address of the user.

To understand this, let’s say user A sends a transaction to smart contract C1 and C1 internally calls a method on contract C2. Now if we call msg.sender in C2, we’ll get the address of C1 and not the user A.

So if C1 is the user contract wallet and C2 is the DApp smart contract, then msg.sender will be user’s contract wallet that is owned by the user A.

2. Single identity on the blockchain when using multiple DApps

Even if you register on multiple dapps with same user account A and all DApps uses biconomy for meta transactions, then your smart contract wallet will remain the same across all DApps hence keeping single identity across multiple DApps.

3. Meta transactions can be enabled effectively via user contract wallets

When assessing projects that have already implemented meta transactions in house, we see them employing user contract wallets. Argent, Origin, and Nuo are such examples.

Relayers

Relayers are integral for meta transactions as they are the bridge between the end-user and the blockchain. Relayers are essentially responsible for signing transactions the user has made from the DApp and then relaying them to the corresponding blockchain.

In our architecture, it is Biconomy that owns the relayers sending transactions on behalf of the DApp users.

We use multiple relayers to relay different transactions in parallel to increase the throughput of our system and avoid any bottleneck while handling multiple transactions.

Relayer Smart Engine

Relayer smart engine handles the following scenarios:

• Auto fund relayers if any of them are running low on balance.
• Relayer Tracking System to select relayer with the least number of pending transactions from the current active relayers.
• Auto add more relayers and fund it as number of transactions increases.
• Maintain a threshold per relayer for maximum number of transactions that can be in pending state.
• Handle the failed or dropped transactions in case of network congestion due to high gas prices.
• Nonce Tracking System to keep track of nonce internally to pace up the transactions and to keep the nonce accurate. Getting nonce from the network every time results in incorrect nonce as it takes time for the transaction to be broadcasted to the whole network.

Biconomy relay hub contract

Relay hub contract is a single contract deployed per network that acts as a gateway for all meta transactions originated by Biconomy relayers. It maintains the mapping of contract wallets and its owners on-chain so even Biconomy can’t alter the ownership of user contract wallets.

The Relay hub contract maintains a list of active relayers so only relayers registered by Biconomy can relay the transactions.

Limits and Dashboard

Mexa SDK comes with the Mexa Dashboard. Developers register their Dapps on the Mexa dashboard and get assigned API keys that they use to call meta-transactions on their dapp and other dapp methods. Apart from this, the Mexa dashboard is home to many other developer utilities. These include creating APIs of smart contract methods which can be called using a developer API key, setting usage limits on dapp, API & user level. Other features include restricting domains from where the APIs can be called to prevent misuse of dapp funds set aside for meta-transactions.

These features are currently live on our dashboard and we are adding new features as we get feedback from the developer community.

The idea behind this article is to provide an overview of the different components of a meta transaction system and how we built ours so far.

We will be releasing more articles in the future, that will deep dive into the technical aspects of our Relayer Smart Engine, how we handle security and the many use cases that meta transactions can be used for!

Stay tuned.

Thanks to Sachin Tomar and Arnav Vohra for their contribution to this article!

Github: https://github.com/bcnmy/mexa-sdk

Telegram Channel: https://t.me/biconomy

Website: https://biconomy.io

Twitter: https://twitter.com/biconomy

Email: support@biconomy.io