Deep Dive: Biconomy

11 min readJan 10, 2022

As we see the web 3.0 world grow more and more, we are seeing a huge rise in both developers and users in this space. From the open-source Decentralized-Finance that provides a better alternative to the current traditional financial system, to small projects using their own tokens as forms of currency allowing users a new way of interaction, the web 3.0 world is expanding beyond everyone’s imagination. The vision of web 3.0 brings all of the dreamers together to build a community where everyone is an equal part of it.

This however, begs a question- To build this huge decentralized machine, do we have the correct tools required to build it? Is it smooth enough for everyone to experience or can only the experts partake in it?

This is where the dream of web 3.0 hits a roadblock.

Now before we start depressing ourselves thinking all hopes and dreams are lost, let’s dissect the problems one by one and maybe, just maybe, there’s a solution to all this. (Spoiler alert: There is)

Understanding that at the heart of any blockchain(s) that allows the web 3.0 space to exist, every interaction with any decentralized application or a wallet is a transaction. These transactions are usually the transfer of tokens (such as Bitcoins, or shitcoins) from one address to another, and require additional fee called Gas fees for them to be executed. The reason for paying money to pay money, is because currently the process these transactions undergo is quite complicated. To brief it out:

A user signs a transaction thus confirming it from their end.
Transaction is then written to a wallet/decentralized-application according to the use-case.
The transaction is sent to a peer node.
The peer node verifies the transaction, adds it to the mempool, and broadcasts the now verified transaction.
The process is repeated by each peer node that receives the transaction.
Transaction is then sent to a miner node.
Miner node then receives and validates the transaction, and adds it to a block. (Remember, block-chain)
Process is repeated by each miner node that receives the transaction.
Once included in a block, the block is broadcasted over the entire network.
The transaction is finally confirmed.

Most of the time this is the order of events unless a transaction stays in the pending state and eventually fails. Which then requires the user to re-submit their transaction (and sometimes pay more gas fee).

But you’d think now the problems are over now, right?

Some of the concerns that plague us today:

With Ethereum’s Layer-1 (known as Ethereum Mainnet) blockchain only being able to process upto 15 transactions a second, sometimes your transaction may require hours to process before failing due to it being not ideal for miners. Miners will usually select transactions that have higher gas fee (i.e transactions with more tokens involved) which result in smaller transactions taking much more time and clogging the process. With Ethereum’s L1 only allowing few transactions every second, users may even have to re-submit their transactions with HIGHER gas fee giving miners an incentive to actually verify the transaction.
There’s a necessity to pay Gas fee at every step of interaction today, which should not be the case for users to experience in any application. Netflix doesn’t charge you for their AWS hosting, and yet a simple web 3.0 interaction costs the end-user much more than it should, while also stuttering the experience.
Ethereum offers a second L2 blockchain, known as Polygon (Matic) Network, with somewhere between 2,000–4,000 transactions happening each second. However, the transfer of funds and onboarding on L2 systems are slow and expensive, causing liquidity issues and creating isolated communities that lower the composability for multi-chain web 3.0.
Gas fees are not known for their stability. They are highly volatile and sometimes too high for the transaction to actually happen. So it is a possibility that you might have to add more funds just for the transaction to happen, which you had already paid for.

This is where Biconomy comes in.

How it began

Biconomy was founded by Ahmed Al-Balagh, Aniket Jindal and Sachin Tomar on Oct 8th 2019. The three co-founders initially started a staking operation and began learning and building in the web 3.0 space. After some development and corresponding with other people, they realized at the heart of user and developer experience lay huge holes that led to this unnecessary pain of complicated transactions. This led them to look into meta transactions and they decided to make a developer platform around it.

At the beginning of 2020 they were finalists at the Meta Transaction hackathon which was organized by Metamask. This success gave them confidence in their thesis. In the coming months they refined their methods of solving the problems, and initiated with their beta launch in May 2020 with Biconomy.

What is Biconomy?

At the heart of it, Biconomy is a Multichain relayer protocol, which means an off-chain order book that can be used to find, create, fill, or cancel orders.

Their function is to discover counter-parties, move orders cryptographically between them and create such a pool to increase liquidity. Biconomy intends to solve the above mentioned problems using their own technologies that aid developers to hand out a smoother experience for their users. It tackles exactly the issues that cause troubles in decentralized development.

Developers can in fact create their own re-layer infrastructure from scratch in-house for their Dapps using knowledge of smart contracts and frameworks required to build a relayer network. But this includes huge tasks of management and maintenance such as the need for monitoring gas prices at all times, keeping track of nonces and managing the transaction queue, ensuring the relayers are scalable as transactions increase, and addressing the security associated with relaying. For managing ERC20 payments, developers would need to hold a treasury and apply risk management for the acceptance of ERC 20 tokens for users wanting to pay gas fee.

All of this is simplified and done using Biconomy’s SDK/APIs that enable a simple and customized transaction journey allowing the users a seamless, smooth-sailing experience and reduces the friction between decentralized applications and their end-users.

All of this sounds like a lot of technical jargon that says a lot without actually saying anything, so let’s take a look at how Biconomy actually implements these functionalities with the products it provides. Starting with their implementation of Meta Transactions.

Mexa: Gasless Transactions

Meta transactions allow users to interact with a public blockchain without paying a transaction fee. This leads to a more seamless UX as users no longer have to understand the inner workings of public blockchains and market dynamics for transaction fees.

At its core, meta transactions are like network transactions but with the addition of a proxy contract, also known as a relayer. With meta transactions, users still use their signature to send and authenticate transactions. The difference is that- the transaction is now managed by the relayer who pays the gas and sends the transaction to the receiving address.

Meta transactions, also known as Gasless transactions, aim to simplify user onboarding so grandmas can start using your Dapp as well. The principle behind it is long term: the future condition of gas fee will not be like the present. Inevitably, gas fees will become cheaper and cheaper and will be paid out by the developer simply as server fees.

Biconomy currently provides three different approaches to using Meta Transactions in your smart contracts:

1. EIP 2771 Standard Implementation: Instead of actually integrating meta transaction logic directly into the contract, it allows inheriting another ‘recipent’ contract that accepts validated calls from a trusted forwarder. Essentially, before calling the smart contract, the trusted forwarder complies with EIP 2771 so inside of your Dapp everything remains smooth.

2. Smart Contract Wallet Implementation: If your smart contract does not allow for updates, this approach allows you to create a contract wallet for each end user and all the transactions are routed from their smart contract wallet.

3. Custom Implementation: If your Dapp requires specific custom requirements, or you need to implement a standard compliant function, biconomy provides contracts for you to inherit this functionality in your Dapp.

But what about small-scale applications where the developer can not afford to pay out the gas fees for their user acquisition? Biconomy provides another solution:

Forward: Paying Gas in ERC20

Forward allows developers to allow their users to pay out the gas fee in any ERC20 token, which can be used to work over Ethereum or any Dapp. For smaller applications it is impractical for developers to cover the gas fees, so it is essential that the user can pay in any token they want and not just ETH. Currently there is support to pay Gas in DAI, USDC and USDT with plans to expand further.

It works is via the Biconomy relayer, where first an ERC-20 Forwarder node verifies the Gas price, deducts the tokens based on the gas used and forwards the transaction to a trusted forwarder, which is used to sign the verification and append the user address, and send it to the smart contract.

It is essential to understand that any Dapp being Gas-less does not mean Gas is free. The majority of ERC20 token transfers on Ethereum Mainnet involve large amounts of capital — more than 90% of token transfers are above $1,000 in value. These are huge costs for developers to pay, and so forward is just a service that allows the end users to pay their Gas in non-ETH tokens. And hence it is built to be used for two main purposes -

Allowing your users to save their ETH.
No stuck transactions while using Dapps.

With Forward, Biconomy takes ERC20 tokens from users as payment for meta transactions. These tokens can be used to replenish our relayers with ETH.

Hyphen: Instant cross-chain transfers

First of all, what is cross-chain transfer? Since we’re talking in the language of block-chains, where we have several different ‘chains’ like the Ethereum Mainnet and the Polygon (Matic) blockchain, cross-chain transfers are basically the transfer of funds from one blockchain, to another. The ability for a blockchain to support cross-chain transfers smoothly is also known as blockchain interoperability.

Cross-chain transfers are essential since the value of assets in web 3.0 increases hugely if they can be transferred over different platforms. We want to be able to use the same tokens over different applications, and that too without having to withdraw funds from one blockchain, just to reinvest in another.

Now that we know what they mean, suppose if you were to deposit your funds to a Layer2 native bridge, and wanted to transfer them to a Layer1 block-chain, it would take you somewhere between an hour and seven days. Seven days, for you to be able to use your own funds. For example, currently it takes around 40–50 min to get your ERC20 tokens from Polygon Network to Ethereum via their native bridge.

This creates a huge issue in providing a fluid experience, and Hyphen allows the solution for this exact issue.

The general principle is to maintain token liquidity at both sides of the chain, and instantly transfer the tokens to the second chain after accepting them on the first. When transferring the funds from chain 1 to chain 2, there’s a 0.1% fee charged that goes directly to liquidity providers which allow all of this to happen. The transfer transaction fee (generally gas fee in ETH) is also deducted directly from the token transfer.

For example — If you were to transfer 500 USDC from Polygon to Ethereum, and there was a $10 Gas fee, you would receive 489.5 USDC on Ethereum.

Hyphen works using LiquidityPoolManager(s), which are contracts deployed on all Biconomy supported chains where the Liquidity is stored. These are monitored by off-chain servers that are called Executor Nodes. These Executor Nodes have two parts:

Watch Tower: It monitors the LiquidityPoolManager to listen for any incoming deposit transaction on all the chains. Once it finds any transaction, the Executor component is notified.
Executor: It verifies the incoming deposit and initiates a transfer transaction on the other chain. The deposit transaction contains the other chain id, receiver address and the amount to be transferred.

The LiquidityProvider fee and transfer transaction fee is deducted on-chain on LiquidityPoolManager smart contract, and only Executors have the right to transfer funds from The LiquidityProviderManager contract.

Re-Balancing needs to happen to make sure liquidity on all chains is balanced. Re-balancing scripts are run to find that if there is less liquidity on a particular chain it triggers re-balancing operation and funds are transferred from other chains to balance the liquidity via corresponding native bridges

A developer’s brief guide to Biconomy

Biconomy provides several APIs that are plug and play. It requires a simple username and password sign up for any developer to start a Biconomy account, connect their wallet and voila!

You can enable meta transactions, or gasless transactions with their Native Meta Transaction API via a POST request to https://api.biconomy.io/api/v2/meta-tx/native (Note: Your smart contract should support native meta transaction, if they don’t, you can check out how)

Biconomy also provides several Dashboard API calls. More can be read about them here.

Additionally, if you are using external contract wallets to enable meta transactions you need to use whitelisting APIs to whitelist your user’s contract wallet and target addresses in order to avoid misuse. If user contract wallet address and target addresses are not whitelisted then a hacker could use your Dapps API Key to send gasless transaction to any smart contract e.g. Uniswap contracts via his contract wallet that is not even registered on your Dapp and you would end up paying gas fees for his transaction.

Biconomy in Numbers

This graphic from their website sums up where they stand today: having a highly supportive community where both the users and developers put their brains together to make Biconomy the future- it is also backed by some of the biggest names in the space:

Currently, Biconomy supports over 35+ Dapps in its bicosystem that cater to thousands of users every day over DeFi, NFTs and Gaming categories.

Conclusion

If we want to make web 3.0 as intuitive and free flowing as web 2.0, if not more, there has to be certain standards with solving problems that exist today and these problems need to be addressed quickly in order to make the general user experience better.

Simple solutions such as making gas fee payable via several tokens instead of just ETH, the ability for a developer to pay gas as infrastructure costs and transfers of tokens from one chain to another are several problems that are provided by Biconomy today. Their intentions to bring more solutions for the web 3.0 world make this project a big player for developers, and something to keep an eye on for web 3.0 enthusiasts.

Links

Following are few links if you crave more information related to these topics: