👾 How to make self-sustainable cross-chain bridges — Kirill Fedoseev
What is the cost of operating a bridge? There are the fees for the relays and MEV, the oracles, the safety audits, the employees’ wages, and the risk costs. In the end, you have to pay a lot of money for the follow-up processes.
Kirill Fedoseev, developer and researcher at Gnosis chain and Blockscout, covered the topic of how to create a model for self-sustainable bridges at our Cross-Chain Builders’ Meetup in Paris. We have summarized the key points in this article. Enjoy!
What are Gnosis Chain, xDAI bridge and OmniBridge
Gnosis Chain is a PoS EVM side chain whose native currency xDAI pegged to DAI. Operates on top of two primary bridges between the main net and GC: xDAI Bridge and OmniBdridge. Numerous integrations with other third-party managed solutions: Hop Protocol, Connext Network, etc.
Let us take a closer look at the xDAI bridge and how it works. It is one of the oldest bridges on the market and will soon be four years old (live since October 2018). It allows depositing a certain amount of DAI ERC20 tokens into the main network, which triggers the minting of the same amount of bridged xDAI coins. Similarly, it can also go in the opposite direction by burning a certain amount of the native xDAI coin. This removes the same amount of DAI ERC20 coins from the main network. The xDAI bridge currently contains more than 50 million DAI coins from TVL (Total Value Blocked) and is secured by the network of oracles that make up the multisig wallet.
OmniBridge went live almost two years ago. Its main feature is that it inherently enables the support of any ERC20 token without configuration. It works in the same way as the xDAI bridge: You can simply deposit any type of ERC20 asset on a page and coin the bridged ERC20 into Gnosis Chain. The bridge supports around 330 unique ERC20 tokens and holds more than $80 million (in stablecoins) of TVL and 130 million TVL of volatile digital assets.
The typical costs of operating the bridge today
Here we have three different types of expenses.
Development and support costs:
- Salaries of the team;
- Safety testing;
- Maintenance after the launch.
Infrastructure costs: hosting fees for oracle, validator, UI, monitoring, bridge checker, gas costs for validator and relayer transactions.
Risk costs:
- Premiums for insurance of locked assets;
- Bug bounty programs.
What is the typical revenue from bridges?
In the earlier days of Ethereum, this was usually not a problem because each bridge followed a simple rule: 1 EVM chain — 1 bridge. Each bridge was just a small part of a larger overarching project. No one really cared about the sustainability of the bridges themselves. But today the situation is different. There are definitely more bridges out there. We can also see unique EVM networks. More and more bridges are being created independently of the idea of a parent chain. Some solutions are built on top of other bridges or between them. Now it makes sense for developers to think about generating revenue streams.
We tried three different approaches at Gnosis Chain:
- Bridge fees;
- Idle capital compounding;
- Relayer and MEV fees.
Bridging fees
In GC, the daily bridging volume of xDAI is only 3% of TVL. In DEXs, the daily volume is usually much higher (about 25% in UniswapV3). This definitely affects the amount of fees you can collect. The second problem is more of a psychological one. The idea that the DEX can have hidden fees. The fees on bridges are much more obvious, as the fee on a single asset is harder to hide. With DEXs, the fee is hidden because the assets sent and received are different With bridges, the fee is more obvious because the assets sent and received are identical.
The idea is to collect a small portion of the bridged amount in favor of the protocol. The idea can be used to make some profit. The complexity is not high, it is easy to implement. As for the risks, we can see that there is usually an increased involvement of the authorities. But the impact on UX is not really nice: users might find the fees intrusive and unattractive. Expected revenue: just enough to prevent DoS attacks or cover the transaction fees.
Compounding of the idle capital
The second approach is much more interesting and is related to the compounding of idle capital. Usually, the bridge locks a certain amount of tokens on one side of the bridge and mints the bridge representation tokens on the opposite side. Locked bridged assets have very low capital efficiency by themselves, unlike DEXs or credit markets. This means that a large portion of TVL is really “idle capital.” Could we find a meaningful way to delegate the use of idle capital to a more efficient and less risky protocol?
If the daily volume of our bridge can be covered by 3% of TVL, this essentially means that the remaining 97% of the capital can be used elsewhere (a third party protocol). So the easiest option here is to put the consent in compound or AAVE. There is also such a thing as a Dai savings rate, which comes from Maker DAO. The idea here is that when our initial 3% buffer is exhausted by an increase in withdrawals, another 3% is seamlessly withdrawn by the third party and the protocol can operate without any external intervention. Any interest earned over and above the capital invested can be considered as profit of the protocol and used to finance the operation of the bridge, the bridge costs.
The idea of Idle Capital Compounding is about how to seamlessly bring locked assets into the credit market and withdraw them. The complexity of the deployment is medium. Risks associated with counterparty protocol issues, insufficient liquidity for withdrawals. UX Impact: increased gas costs, reduced transparency in the chain. Expected return: “single digit” annual interest rate on TV — so this approach is probably the best in terms of expected returns.
Since the solution was launched last October, Stablecoins’ total TVL was about $1–2M, all pooled together. This allowed our protocol to make a safe profit of about $300,000 this month.
Fees for Relayers and MEV
When completing the bridge transaction, the user usually has two options. He can complete the final transaction manually and pay the gas charges. Or he can hire a Relayer to perform a transaction on behalf of the user. To become profitable, the relayer can charge users a fee that’s higher than the gas cost of the transaction. To ensure that only profitable transactions are processed, the relayer can be wrapped in MEV bundles. The OmniBridge approach involved custom integration with the Tornado Cash Nova application. The way this project works and takes into account the privacy of the centralized relayer can allow users to protect themselves from revealing private data. Users can set any referral fee (in ETH) in Tornado Cash UI. Once the fee is sufficient to cover the transaction cost, the relayer sends a MEV bundle. The rest of the fee goes into the relayer’s profit.
So the idea is to optionally execute user transactions in exchange for a fee. The great thing about this approach is that it doesn’t add any risk. Also, there are more options for users, gasless transactions, faster UX. So this method really means great risk-free revenue.
The solution was launched about five months ago and now has four independent relayers handling these types of packages. Also, ~8000 withdrawals have been made, ~125 ETH in fees collected, and ~32 ETH in pure relayers profit collected.
