After a series of large-scale bridge exploits, the narrative that cross-chain technology is inherently flawed—that cross-chain interoperability is a risk—gets a lot of lift. With an estimated $2 billion lost to 13 bridge hacks this year, it’s becoming increasingly difficult to ignore this argument.
At deBridge, we believe it is not only imperative, but inevitable that all cross-chain bridges completely rethink their approach to liquidity aggregation.
The limits of blocked liquidity
By locking in liquidity to provide cross-chain routing (which almost every bridge is currently doing), bridges enter a competition they are bound to lose. We see Bridges confronting established, purpose-built liquidity protocols such as AAVE, Compound and Frax, projects that will no doubt monetize liquidity more effectively and securely. There are numerous examples of bridges with hundreds of millions of dollars in TVL and extremely low utilization of the blocked liquidity.
With this design, bridge projects are forced to undertake unsustainable liquidity reduction campaigns that do not provide long-term capital efficiency solutions. Unless token incentives are maintained indefinitely – an unreasonable goal for any project – liquidity providers will inevitably withdraw capital to pursue higher-yielding opportunities.
To safely aggregate liquidity, bridges would need to take out insurance policies to allow liquidity providers to hedge risk. This is another expense that makes monetizing liquidity even more difficult. Because of this, most existing bridges are not profitable as the costs and liquidity mining rewards paid often exceed the net profit of the protocol.
Architectural considerations also come into play here, since cross-chain value transfer is a request that can be handled in a number of ways. All existing bridges process these orders from their own liquidity pools, where liquidity is continuously locked in when it is needed, precisely when the value transfer is to be fulfilled.
The size of the order can also vary – if it exceeds the size of the bridge’s liquidity pool, the sender will receive wrapped tokens or an indefinitely suspended/stalled transaction. On the other hand, if the order is too small for the size of the liquidity pool, the liquidity utilization is very low and inefficient. This vicious circle further clarifies that this liquidity protocol’s approach to bridge construction is ineffective and fundamentally wrong.
solving the security problem
Important as this issue is, economic unsustainability is not the only major challenge here. Even if bridges had found a way to leverage the locked liquidity approach and remain capital efficient, it is now clear that building a secure liquidity protocol is an arduous task. In fact, by knowingly or unknowingly becoming liquidity protocols, bridge projects face the daunting task of protecting a multifaceted attack surface.
To start at a high level, one of the obvious problems with a locked liquidity bridge is that it creates a risk multiplier effect, where vulnerabilities in one supported chain can spill over to capital held in other ecosystems.
This is about proxy security. A bridge’s entire liquidity base can be at risk if there is a potential vulnerability in the code base of a supported blockchain/L2. We saw this possibility earlier this year with a vulnerability discovered in Optimism that would have allowed attackers to mint any amount of assets and likely tokenize them in other ecosystems.
See more
Last week I discovered (and reported) a critical bug (which has been fully patched) in @optimismPBC (a “layer 2 scaling solution” for Ethereum) that would have allowed an attacker to print any amount of tokens for what I won a bounty of $2,000,042. https://t.co/J6KOlU8aSW
— Jay Freeman (saurik) (@saurik) February 10, 2022
Again, issues with a chain’s consensus mechanism can also lead to systemic contagion, putting liquidity locked in other supported chains at risk. In this case, the bridge simply sends the exploit to other chains. This may include 51% attacks or other protocol-level failures.
Aside from this type of inherent risk, we are increasingly seeing situations where failures of the bridge projects themselves have, in one way or another, resulted in a loss of the blocked liquidity. From botched protocol upgrades, poor smart contract design, or compromised validator infrastructure, there are many scenarios where malicious actors can exploit vulnerabilities in the bridge itself.
All of these risks compound quickly and, as we have seen too many times, are eventually borne by liquidity providers as they lose the redeemability of their packaged assets. Such a possibility should be unacceptable.
Few deny the great promise of cross-chain interoperability to take Web3 adoption to a new level. However, given the sheer size and frequency of bridge attacks, it is painfully clear that the fundamental design of bridge technology needs to be rethought from the ground up. The bridge liquidity protocol design just doesn’t work.
Is there a way to create a fundamentally new and unique approach to bridge design that completely eliminates risk for liquidity providers, eliminates attack vectors while maintaining the highest level of capital efficiency?
That could be the case in the near future. At deBridge we are working on a new cross-chain liquidity routing that will solve all these problems. Stay tuned.
Disclaimer: The opinions of our writers are solely their own and do not reflect the opinions of CryptoSlate. None of the information you read on CryptoSlate should be construed as investment advice, nor does CryptoSlate endorse any project mentioned or linked in this article. Buying and trading cryptocurrencies should be considered a high-risk activity. Please conduct your own due diligence before taking any action related to the content of this article. Finally, CryptoSlate takes no responsibility in case you lose money trading cryptocurrencies.
Learn Crypto Trading, Yield Farms, Income strategies and more at CrytoAnswers
https://nov.link/cryptoanswers
Comments are closed.