Let’s stop trying to be liquidity protocols

After a number of large-scale exploits of bridges, a lot of oxygen is being given to the narrative that cross-chain technology is inherently flawed — that cross-chain interoperability means risk. With an estimated $2 billion lost across 13 bridge hacks this year, it’s becoming increasingly difficult to ignore this argument.

At deBridge, we think that it’s not only imperative but inevitable that all cross-chain bridges completely rethink their approach to liquidity aggregation.

The limitations of locked liquidity

By locking liquidity to provide cross-chain routing (as almost every bridge does right now), bridges have placed themselves in a competition they’re bound to lose. We’re seeing bridges face off against established, purpose-built liquidity protocols like AAVE, Compound, and Frax, projects that will undoubtedly monetize liquidity more effectively and securely. Examples abound of bridges with hundreds of millions of dollars in TVL, with extremely low utilization of locked liquidity.

With this design, bridge projects are forced into running unsustainable liquidity mining campaigns that fail to offer long-term capital efficiency solutions. Unless token incentives are maintained indefinitely — an unsound ambition for any project — liquidity providers will inevitably remove capital to pursue higher-yielding opportunities.

To aggregate liquidity safely, bridges would need to acquire insurance policies to let liquidity providers have the ability to hedge risks. This is another expense that makes liquidity monetization even more difficult. That’s why most existing bridges are not profitable, as costs and paid liquidity mining rewards often exceed the protocol’s net profit.

There are also architectural considerations at play here, given that a cross-chain value transfer is a request that can be settled in different ways. All existing bridges settle these orders from their own liquidity pools where liquidity is continuously locked when it’s needed only at the precise moment the value transfer should be fulfilled.

The size of the order can also differ — if it exceeds the size of the bridge’s liquidity pool, then the sender will end up with wrapped tokens or an indefinitely suspended/stuck transaction. On the other hand, if the order is too small for the liquidity pool’s size, the liquidity utilization is very low and inefficient. This vicious circle further highlights that this liquidity protocol approach to bridge design is ineffective and fundamentally wrong.

Solving the security problem

As important of an issue as this is, economic unsustainability is not the only main challenge here. Even supposing bridges figured out a way to use the locked liquidity approach and stay capital-efficient, by now, it’s evident that building a secure liquidity protocol is an all-consuming task. Indeed, by knowingly or unknowingly becoming liquidity protocols, bridge projects are giving themselves the immense task of safeguarding a multi-faceted attack surface.

To start high level, one of the evident issues with a locked liquidity-style bridge is that it creates a risk-multiplier effect, where the vulnerabilities of one supported chain can spill over to compromise capital held in other ecosystems.

Here, there’s the issue of security by proxy. A bridge can have its entire liquidity base compromised if there’s a potential vulnerability in the codebase of one supported blockchain/L2. We saw this possibility earlier this year with a vulnerability discovered in Optimism, which would have allowed attackers to mint an arbitrary quantity of assets and foreseeably exchange these for tokens in other ecosystems.

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 arbitrary quantity of tokens, for which I won a $2,000,042 bounty. https://t.co/J6KOlU8aSW

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

Again, any issues with the consensus mechanism of one chain can also lead to systemic contagion, putting at risk any liquidity locked in other supported chains. In this case, the bridge simply broadcasts the exploit to other chains. This could include 51% attacks or other protocol-level failures.

Aside from these types of inherited risks, we’re increasingly seeing situations where mistakes by the bridge projects themselves have, in one way or another, causing a loss of locked liquidity. From botched protocol upgrades, poor smart contract design, or compromised infrastructure of validators, there are many scenarios where bad actors can exploit vulnerabilities in the bridge itself.

All these risks are quickly compounded and — as we’ve seen on too many occasions — are eventually born by liquidity providers when they lose the redeemability of their wrapped assets. Such a possibility should be unacceptable.

Few are denying the vast promise of cross-chain interoperability to push Web3 adoption to new heights. But with the sheer size and frequency of bridge exploits, it has become painfully clear that the fundamental design of bridging technology needs to be reimagined from first principles. The bridge-turned-liquidity-protocol design just isn’t working.

Is there any way we can devise a fundamentally new and unique approach to bridge design, one that completely removes risks for liquidity providers, eliminates attack vectors, and at the same time preserves the highest level of capital efficiency?

There may be exactly that in the near future. At deBridge, we are working on a new cross-chain liquidity routing that solves all these problems. Stay tuned.