Lets stop trying to be liquidity protocols

After a number of large-scale exploits of bridges, more oxygen has been given to the story that cross-chain technology is inherently flawed cross-chain interoperability means risk. . This year, we lost an estimated $2 billion to 13 bridge hacks, so it’s getting harder to ignore the debate.

At deBridge, we believe it is not only essential, but inevitable, that all cross-chain bridges completely rethink their approach to liquidity aggregation.

Locked liquidity limits

By locking liquidity and offering cross-chain routing (as almost all bridges do today), bridges are in a race they are destined to lose. We see bridges to established proprietary liquidity protocols such as AAVE, Compound and Frax. These projects will definitely monetize liquidity more effectively and safely. There are many examples of hundreds of millions of dollars of bridges in TVL and very low utilization of locked liquidity.

This design would force the bridge project to run an unsustainable liquidity mining campaign, failing to provide a long-term capital efficiency solution. Unless token incentives are maintained indefinitely (an unsound ambition for any project), liquidity providers will inevitably shed capital and pursue higher yield opportunities.

In order to safely aggregate liquidity, the bridge must obtain an insurance policy to enable liquidity providers to hedge their risks. This is another cost that makes liquidity monetization even more difficult. That is why most existing bridges are not profitable, as the costs and liquidity mining rewards paid often exceed the net profit of the protocol.

Given that cross-chain value transfer is a request that can be solved in many ways, there are also architectural considerations here. All existing bridges settle these orders from their own liquidity pool where liquidity is continuously locked when the transfer of value is needed only at the exact moment when it should be executed.

Order sizes may also vary. If the size of the bridge liquidity pool is exceeded, the sender will eventually have their tokens wrapped or their transactions suspended/stuck indefinitely. On the other hand, if the order is too small for the size of the liquidity pool, liquidity utilization is very low and inefficient. This vicious circle further underscores that this liquidity protocol’s approach to bridge design is ineffective and fundamentally wrong.

Resolving security issues

This is an important issue, but economic sustainability is not the only major challenge here. Even if Bridge has figured out how to maintain capital efficiency using a fixed liquidity approach, it is now clear that building a secure liquidity protocol is an all-consuming task. Or by unwittingly becoming a liquidity protocol, the bridge project gives itself the immense task of protecting a multi-faceted attack surface.

To start loosely, one obvious problem with locked liquidity-style bridges is that they create a risk multiplier effect. This could lead to a ripple effect of vulnerabilities in one supported chain, putting capital held in other ecosystems at risk.

Now there is a security issue with proxies. Any potential vulnerability in the blockchain/L2 codebase that it supports could jeopardize the entire liquidity base of the bridge. We confirmed this possibility with a vulnerability discovered in Optimism earlier this year. This allowed attackers to create arbitrary amounts of assets and preemptively exchange these for tokens from other ecosystems.

Last week I discovered (and reported) a critical bug (which has been fully patched). @Optimism PBC (Ethereum’s “Layer 2 Scaling Solution”) allowed the attacker to print any number of tokens, resulting in a $2,000,042 bounty. https://t.co/J6KOlU8aSW

Jay Freeman (saurik) (@saurik) February 10, 2022

Again, problems with the consensus mechanism on one chain can lead to systemic contagion, jeopardizing liquidity locked in other supported chains. In this case the bridge just broadcasts the exploit to other chains. This could include 51% attacks or other protocol level failures.

Apart from this type of inherited risk, we increasingly see situations where mistakes in the bridge project itself cause some form of locked liquidity loss. There are many scenarios in which a malicious person could exploit vulnerabilities in the bridge itself, such as a failed protocol upgrade, a poorly designed smarthis contract, or a compromised validator infrastructure.

All of these risks deteriorate rapidly and, as is often the case, are ultimately created by liquidity providers when they lose the redemption potential of wrapped assets. Such a possibility should not be accepted.

Few deny the huge potential of cross-chain interoperability that will propel Web3 adoption to new heights. However, the sheer scale and frequency of bridging exploits has made it painfully clear that the basic design of bridging technology needs to be rethought from the ground up. The design of conversion from bridge to liquidity protocol is not working.

Is there a way we can devise a radically new and unique approach to bridge design that completely de-risks the liquidity provider, eliminates attack vectors, and at the same time maintains the highest levels of capital efficiency?

That may be exactly what happens in the near future. At deBridge, we are working on a new cross-chain liquidity routing that will solve all these problems. stay tuned.