Why Is Financial Engineering Important in Bridging? Episode 1
One Pool
Introduction
As a former tradfi market maker, there is no better feeling than matching off a buyer and seller. You make two clients happy by netting off their exposure and you pocket a little bit of money for yourself. The ability to find the two opposing sides saves you from needing to warehouse any risk and commit any capital.
Across approaches bridging in a similar way. We want to maximize these matches and minimize the amount of capital needed to facilitate bridge transfers. Instead of buyers and sellers, we match users bridging assets to opposing destinations. In order to achieve this goal the Across team designed a cross chain bridge with financial engineering first. This requires an architecture that is very different from existing solutions and results in higher capital efficiency, which benefits users with lower fees and liquidity providers with higher returns.
Across uses this order matching process to achieve more volume per unit of capital than it could otherwise. In a series of articles we will explain how Across is different from other bridges and why the design choices were made to achieve higher capital efficiency and a better user experience.
One Liquidity Pool vs. Fragmented Liquidity Pools
Across bridges transfers using a single liquidity pool on mainnet (L1) where liquidity providers (LPs) can provide passive liquidity and where relayers request their refund after completing a valid bridge transfer for users. This differs from other bridging solutions where assets need to be pooled at every destination which ends up creating a network of fragmented liquidity pools.
Why is Across designed with just one liquidity pool and how is this possible?
Across uses a hub and spoke model where the hub is on L1 and the spokes are on all the L2 destinations. The majority of LP assets are kept safe in the hub on mainnet and every 4 to 8 hours bots, or data workers, rebalance the amount of assets on each spoke with the use of the destination’s canonical bridge. This is in contrast to most other bridge designs that rely on LPs to provide enough liquidity on hand at each and every destination which can result in underutilized assets and higher fees to users. Across moves assets when and where they are needed. We call this Just-In-Time Liquidity.
Here is a simple example on why one liquidity pool is more capital efficient than fragmented liquidity pools:
Bridge B has total liquidity of $100 and supports L1 and 4 different L2s. With fragmented liquidity pools, the bridge hopes LPs deposit into pools in such a way that capital is spread enough to support transfers in any bridge direction requested. A possible allocation as an example could be $40 on L1 and $15 on each of the 4 different L2s. Again, the bridge has no control over this as they rely on users to “get it right” for them. This allocation means the bridge can support up to $40 of L2 to L1 transfers and $15 of L1 to L2 or each L2 to L2 transfers. After this amount of volume has happened, the bridge is effectively shut down until new LPs deposit or arbitrageurs interact with the bridge to rebalance pools. Note that profits in this case for arbitrageurs are being funded by higher fees paid by Bridge B users, and usually in times of system stress when transfers are needed most.
Bridge A uses Across’ one liquidity pool design where all $100 of assets are on L1. Bridge A can support up to the full $100 of L2 to L1 flow (250% more vs the fragmented liquidity approach) without any reliance on LP decision on where to place their capital. For L1 to L2 flow, Bridge A can support almost an unlimited amount. The reason L1 to L2 is unbounded is that this flow does not utilize LP capital (though the constraint is capital on the relayer network). The assets deposited on L1 (by bridge users going to L2) are used to refund relayers directly. No LP capital is utilized, but the LPs still get paid fees! Additionally, the entire system rebalances every 4 to 8 hours so funds are never trapped in a destination due to imbalanced flows or user LP deposit behavior. Any available capital is always able to be deployed wherever it is needed, automatically.
The hub and spoke model also captures the benefits of netting transfers. As users bridge assets between each destination, the pools of assets sitting on L1 and L2 are naturally increasing and decreasing. This creates opportunities for opposing bridge transfers to effectively net off and saves the LPs from actually needing to utilize their assets. Only when imbalances occur, which are defined as parameters set by the protocol, do assets need to be rebalanced and potentially locked in the canonical bridge.
Having one liquidity pool also provides a much better user experience for LPs. LPs only need to worry about depositing and withdrawing assets at one destination. This is a truly passive investment as each individual LP does not need to worry about moving their assets around to optimize their return or arbitraging between pools. All fees paid for bridging an asset — no matter its destination or origin — are paid to the LP of that asset. In addition, the Across LP token is a valuable collateral. Its value only increases as fees are accumulated which differs from other bridge LP tokens which are shares of an AMM pool that can fluctuate due to impermanent loss (more about this in future articles).
Conclusion
Across believes financial engineering plays an important role in building an effective cross-chain bridge. Choosing a one liquidity pool model versus a fragmented liquidity model is just one feature that provides better capital efficiency and user experiences. In the following articles to this series, we explain other unique design choices that help to benefit every participant in the Across ecosystem, from bridge users to LPs and relayers.
If you’re an armchair or professional financial engineer and have thoughts about Across’ design, please engage us by tweeting to @AcrossProtocol or replying in the comments.
