## Why liquidity must flow seamlessly

Last weekend all my Farcaster friends were talking about a hot new coin - $DEGEN on [Base](https://base.org/). Feeling FOMO, I checked out my [Rabby](https://rabby.io/) wallet to see how much I could invest:


"Ok cool, I can put $500 into this coin, just need to sell some other assets. What does my portfolio look like anyway"



"Oh no"

Almost every token is on a different L2. To acquire $DEGEN I must perform multiple bridges and swaps, one after the other, to get there. Even with low fees it's still a frustrating hour of bridging and swapping. 

We must solve this, and our north star is making the entire Ethereum ecosystem feel like one network. Lets see how unified liquidity, combined with wallet upgrades, can abstract bridging away and make the cross-chain L2 experience feel like using a single chain.

### Bridging shouldn't need to be done

Why does bridging currently suck? There are a number of flaws:

- You must visit a separate website, connect wallet, approve, transfer, pray it arrives on the other end...
- Bridging often takes 5 - 30 minutes to complete, which is far too slow. Less than 10 seconds is achievable and ideal.
- Most Bridges require locking liquidity on both networks. The more L2's we have the thinner this liquidity gets. Low liquidity makes it hard to move substantial amounts between chains and you'll get a worse price as a result.
- Only certain tokens with liquidity can be bridged, for most networks this is ETH + Stablecoins.
- There are wrapped token bridges which don't require locking liquidity up and can support any token. However after bridging you get a non-native version of the token you desire and must swap it for the real token in order to use any apps on the new network, which requires liquidity, and thus we end up in the same trap.

Most of all, if bridging doesn't *have* to be done, why are we collectively wasting millions of hours doing it?

### Wallets and Apps should handle bridging automatically

When you use a DEX or Lending protocol it should track your tokens on all chains. When you deposit a token from another chain it should automatically bridge it to the correct chain in the background, so the process feels exactly the same as Ethereum Mainnet.

Apps and Wallets *want* to make this happen, but the underlying infrastructure isn't good enough. If it takes 10 minutes to do this bridging and you lose 1% of your tokens in the process, most users will hate the experience.

Lets dig deeper into the infrastructure layer to see how this can be fixed.

## How liquidity can flow seamlessly

There are 3 main ways for liquidity to be unified across L2 networks, and one enhancement to improve their speed. These methods have different trade-offs but complement each other.

They are:
- **Shared Ecosystem Bridges** - Enabling seamless aggregated liquidity across an entire ecosystem of chains.
- **Mint/Burn Tokens** - Which can be transferred in unlimited size between any supported chains.
- **Native Bridges Trusting Each Other** - Enabling cross-ecosystem aggregated liquidity.

### Shared Ecosystem Bridges

When you bridge from Ethereum Mainnet to any L2 it looks something like this:


Each of these bridges are a smart contract on Ethereum, we call these "Native bridges". When you bridge to an L2 your assets are locked on L1 and a copy is minted on the L2. These networks have the power to mint unlimited amounts of any asset their native bridge supports.

Despite having the same name and explicitly not being called a wrapped asset, every asset bridged from Ethereum to any L2 through a chain's native bridge is actually a wrapped asset because the contract address, and sometimes even code, is different. The contract address of USDC on Ethereum begins with [0xa0b8](https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48), while on [Arbitrum](https://arbitrum.io/) it begins with [0xaf88](https://arbiscan.io/token/0xaf88d065e77c8cc2239327c5edb3a432268e5831), on [Optimism](https://www.optimism.io/) it begins with [0x0b2c](https://optimistic.etherscan.io/token/0x0b2c639c533813f4aa9d7837caf62653d097ff85), and on [Polygon zkEVM](https://polygon.technology/polygon-zkevm) it's [0xa8ce](0xa8ce8aee21bc2a48a5ef670afcc9274c7bbbc035).

These assets look and feel the same because wallets and apps have a list of official assets with official images to display so users never know the difference.

What if instead of having one bridge for every L2, they all shared a bridge. Assets could be minted on a shared chain, called an interop layer, which then mints them on the final destination L2.


Polygon calls this new design an [Aggregated Blockchain](https://polygon.technology/blog/aggregated-blockchains-a-new-thesis).

What's useful about this design? When moving an asset from one chain to another in this ecosystem, say from Polygon zkEVM to OKX X1, it doesn't have to be moved via a traditional bridge or bridged back to Ethereum first. Instead you can burn the asset and have the interop layer mint the exact same amount of the asset on the destination chain!


Every asset bridged via this interop layer is now exactly the same across every chain in the ecosystem. Assuming the interop layer is free to use and fast (Polygon have said theirs will take < 20s to finalize) you'll be able to bridge assets of unlimited size, between any L2 in the ecosystem, within seconds, for free!

Both [Polygon](https://polygon.technology/) and [zkSync](https://zksync.io/) are working on this interop layer design for their ecosystems, from [Optimism's design documents](https://docs.optimism.io/stack/explainer) containing a shared bridge it appears they are pursuing it too, though have yet to confirm it.

The disadvantage is it only works within one ecosystem and requires all chains to use one bridge, which increases risk, however the reward of having liquidity flow seamlessly between all chains in the ecosystem more than makes up for it.

Because all tokens are interchangeable across ecosystems, there's no need for your wallet to show what chain you're on or separate tokens by chain. Instead your wallet could look like this:


When performing transactions across multiple chains your wallet can simply show you're using the "Polygon" network and perform all bridging automatically in the background.

If this design is so great why wasn't it done earlier? ZK Proofs only recently become fast and cheap enough to make this possible. The Interop Layer uses ZK Proofs for all mint/burns so it can finalize in seconds without any challenge period needed.

#### Advantages
- Fast, simple, standard way to move tokens between chains
- Can move any amount of tokens with no slippage
- Likely to be completely free to use

#### Disadvantages
- Only works within a single ecosystem
- One bridge is a single point of failure / attack for an entire ecosystem
- Must be designed from the beginning, can't add to an existing ecosystem without major changes

### Mint/Burn Tokens

Rather than relying on a shared ecosystem bridge, chains could leave bridging to tokens. A token needs to implement mint/burn functionality and allow users to burn the token at any time to mint it on another chain.


These mint/burn messages can be sent via middleware such as [Layer Zero](https://layerzero.network/) or [Chainlink CCIP](https://chain.link/cross-chain). Layer Zero is working on a project called [Omnichain](https://l2beat.com/bridges/projects/omnichain) which will allow tokens to implement this.

Some tokens have already implemented this system - Circle recently rolled out their [Cross Chain Transfer Protocol (CCTP)](https://www.circle.com/en/cross-chain-transfer-protocol) which does exactly this for USDC across 8 different networks.

As USDC has high liquidity on many networks, and no cap on liquidity available, it could be the perfect go-between to move assets between chains. Wallets could swap the token you want to bridge to USDC, bridge that USDC using CCTP, then swap it back to the token you desire on the destination chain. This could be done with little fees or slippage and handled automatically by your wallet.

The downside of leaving liquidity unification to tokens, is it is up to the individual tokens to implement it, and wallets and apps must know which tokens they can bridge automatically vs not.

It also requires tokens to wait for the chain to finalize before the token can be sent, which can take minutes to hours depending on how often the data is written to Ethereum. If the token doesn't wait for finality it could be double spent by being minted on the destination chain and then having the send reverted in a re-org on the sending chain.

Another risk to consider is the tokens security relies on every chain and relaying system to be secure. If one L2 is compromised it could print new tokens by sending malicious messages (e.g. saying it burnt a token when it really didn't) to other chains. If the tokens relayer or oracle becomes compromised the same scenario could occur. This would cause the token to break on *all* chains.

Cross-chain tokens have been implemented before, in the Cosmos ecosystem with [ICS-20](https://github.com/cosmos/ibc/blob/main/spec/app/ics-020-fungible-token-transfer/README.md). It solves the issue of "One chain breaking the token on all chains" by having tokens track the path they took to get to the current chain. If token X is sent via chains A -> B -> C, and some X tokens are sent A -> C, then chain B is compromised, the first set of X tokens will be worthless but the second set of the same X token will still hold value because they didn't cross chain B. This creates additional issues with token fungibility that wallets and apps must solve, but it is a solution.

#### Advantages
- Tokens can move freely across any L2 chain
- Can move any amount of tokens with no slippage

#### Disadvantages
- Chains must be secure, one compromised chain can break the token across all chains.
- Wallets must know what individual tokens are capable of to simplify UX for them
- Tokens must wait for finalization before moving, which takes minutes, occasionally hours

### Native Bridges trusting each other

L2 chains with ZK bridges could allow fast, free token transfers by trusting the native bridges of other L2 chains. This would work by users burning a token on one chain, then using a proof of burn to mint that token via the native bridge of another chain.

For example if [Scroll](https://scroll.io/) reviews the [Linea](https://linea.build/) bridge and believes it is secure (and cannot be made insecure via upgrades), they can setup a service monitoring the L1 state root of the Linea bridge, allow any user on Linea to post a proof they burnt a token on Linea and this burn transaction is included in the L1 state root, and mint the equivalent token on Scroll.


The process of chains checking each others state is covered in greater technical detail in [this post from Vitalik](https://vitalik.eth.limo/general/2023/06/20/deeperdive.html).

This is similar to bridging back to Ethereum then to the other L2, but this method saves the exorbitant L1 gas fees.

The risk is now those native bridges won't have exactly the same amount of tokens locked in them as has been minted on the L2, a core property that up until now has not been broken. If in the above example a user moves $1M DAI from Linea to Scroll, the Scroll bridge will be $1M DAI short, and if a user wishes to withdraw many tokens out of the native Scroll bridge there won't be enough available. Bridges could reconcile these differences through bulk L1 token transfers with each other, or by always having 2-way trust between them, so the whale could withdraw funds via the Linea bridge even after the Scroll bridge has been emptied.

#### Advantages
- Tokens can move freely between trusted chains
- Can move any amount of tokens with no slippage

#### Disadvantages
- If one bridge is compromised it could compromise all bridges that trust it
- Bridges will have differing amounts of tokens locked vs minted on their network. This could cause issues with withdrawals.

## An Economically Secure Fast Finality Layer

These three methods have great scaling and security properties, but have one flaw that dramatically slows down transfers - waiting for finalization. Finalizing a block requires both the sending network to write it's data to Ethereum, which [could take up to an hour](https://l2beat.com/scaling/finality), and then Ethereum to finalize which could take [up to a further 15 minutes](https://ethereum.org/fil/roadmap/single-slot-finality).

Through economic incentives we can create "soft finalization" where a transaction is finalized by more economic value than it is worth. This can work via nodes staking on a service like Eigenlayer, where their stake can be slashed, and attesting that a transaction is finalized. If the transaction is somehow reverted the nodes are slashed and that slashing can potentially be used to plug the hole caused by the revert.

The benefit of this is transactions can be soft finalized in seconds, greatly speeding up all cross-chain token transfers.

This is something [Near](https://near.org/) is working on. Rather than proofs of sending/burn needing to be written to Ethereum L1 and finalized, instead the proof is written to a NEAR fast finality chain, where finalization is secured by Eigenlayer stakers who get slashed if there are rollbacks or reverts. [This tweet thread](https://twitter.com/mraltantutar/status/1732153887476322600) goes into further detail on how it can work.

Lets see how this fast finality layer could improve on all 3 methods of token transfers:

- **The Interop layer** is already a fast finality layer, managed by the ecosystem team (Polygon, zkSync etc). It allows transfers within the ecosystem to take seconds.
- When **tokens are mint/burnt across layers**, instead of waiting for the transaction to be finalized on Ethereum which can take up to 20 minutes, the fast finality layer can attest that the transaction is complete and won't be reverted, and the attesting nodes will be slashed if it is. The destination chain can then trust this layer and mint as soon as it has attested to the transaction.
- Similarly, **when networks trust each others bridges**, they can settle token transfers via this fast finality layer instead of waiting for Ethereum, and use attestors in the same way as token sending.

#### Advantages
- Token transfers can finalize and complete in seconds.

#### Disadvantages
- Unclear how slashing can be used to repair the hole caused by a revert that causes a double spend.
- Reliance on a secondary chain that is not Ethereum to be secure.

## A Future Wallet experience

After these new unified liquidity improvements are implemented, what steps remain for cross-L2 wallets to feel like you're using one chain? The two biggest remaining issues are cross-chain gas, and integrating apps with this system.

### Shared gas between chains

If a user is constantly moving across many chains, how do they get gas on all these chains to pay for transfers?

This is being solved with [Account Abstraction AKA EIP-4337](https://eips.ethereum.org/EIPS/eip-4337) and [paymasters](https://eips.ethereum.org/EIPS/eip-4337#paymasters). A paymaster is an address you can ask to pay for your transaction fees for you. Some wallets such as [Avocado](https://avocado.instadapp.io/) and [Ambire](https://www.ambire.com/) allow you to pre-load a gas balance, and then use this gas on any chain, similar to a pre-paid debit card.

Another simple solution is the [Bungee Exchange Refuel](https://www.bungee.exchange/refuel) which takes gas on one chain and gives you a little gas on another. This is worse UX than a paymaster, and will leave users with a little gas on many chains, but it works for EOA Accounts (standard non smart contract accounts).

### Apps covering gas fees

Paymasters also unlock the ability for Apps themselves to run a paymaster and cover all user transaction fees. This would allow anyone to use an app on its own chain without needing to bridge at all. The app could make profits in other ways, such as selling premium goods that do require tokens, or having a demo mode that is free but you must pay for the full experience.

### Making it easy for apps to utilize unified liquidity

Many apps load user token balances via calling `balanceOf` on every known ERC-20, which is a slow process and doesn't work cross-chain. They know generally nothing about tokens that may be bridged from other networks.

This problem should be solved at the wallet level, so every app doesn't have to re-invent the wheel to support a multi-chain future. [EIP-2256](https://eips.ethereum.org/EIPS/eip-2256) introduces a standard function wallets can implement which allows loading all token balances at once, though this is only single chain for now.

If a wallet is multi-chain aware and knows ways of bridging tokens from one chain to another, it could tell the app the user has those bridgeable tokens available immediately, and when the user interacts with the app the wallet bridges it immediately before performing the interaction. This could use any of the above mechanisms for bridging the tokens.

## Conclusion

Hopefully you now have a better understanding of how liquidity will more seamlessly flow between L2's in the future, and how wallets can use these new technologies to abstract away chains completely in order to make using Ethereum as simple as it was in 2020, without the high gas fees!

*Thanks to Chad Fowler, Alejo Salles, Mike B, Montana Wong and Centauri.eth for reviewing drafts of this post*