CronFi Streaming Bridge
Hey all, pbj from CronFi, and I wanted to add our new streaming bridge design to the mix here. Our bridge is designed to be simple, secure, 100% on-chain, permissionless, and decentralized. There are a lot more details and in-depth design animations on our GitHub: GitHub - Cron-Finance/fast-bridge
We leveraged the best of AMMs (TWAMMs, concentrated liquidity, transparent execution), and removed the worst bridging risks (honey pots, infinite mint, centralization, delays, etc).
We have made thoughtful decisions on the design trade-offs given our customer base and underlying algorithm (CL + TWAMM) used to move assets across chains.
Common MEV attacks are mitigated because the trade happens for deep liquidity tokens over a long time horizon. Also, because we don’t have a bridging token, infinite mint, double spend, malicious multi-sig, etc are not a concern either.
We have internal mitigations such as queuing transactions 2 epochs for settlement guarantees on large transactions and/or active validation via EigenLayer for guaranteeing near-instantaneous settlement of smaller transactions.
Current bridging solutions force users to make tradeoffs between centralized vs. decentralized, permissioned vs. permissionless, and off-chain vs. on-chain. Our design provides a step-change improvement in performance and ease of use without compromising the ethos of DeFi, similar to what Uniswap did for decentralized exchanges.
|OP_USDC ↔ ARB_USDC
|USDC ↔ WETH
|Cross-chain Liquidity Pool
|Minimize slippage to bridge
|Minimize slippage to swap
We don’t have a separate blockchain, dependencies on relayers, bridging tokens, or multi-sigs. Every aspect of the design is on-chain from initiation to execution to settlement.
See below for Protocol Implementation Risk as well
The design is extensible to any EVM or even non-EVM chain and here are the things that need to be there for this to work:
- LPs with liquidity on the 2 chains being bridged to setup their positions
- A messaging interface we can use (Socket, Hyperlane, etc) to relay the messages
With Hyperlane we can do simpler validation with their ISM, so won’t need EigenLayer or anything heavy for relatively new L2s.
Since the design has 2 inter-dependent AMMs, the primary (math + state) AMM can be deployed on Suave or EVM chain, and the secondary (simple proxy) AMM would be on the L2 of choice.
This is where our fully on-chain design shines. Since everything is on-chain, the whole bridging process is transparent. We don’t rely on off-chain pricing and execution to save gas costs, but instead leverage the benefits of TWAMMs (virtual orders) and arbitrage (transparent price execution).
Non-Atomic Trades (Whales, MM, protocols)
- Lower risk than bridging all assets in 1 swap, TWAMM executes over multiple blocks
- Full control to pause, cancel, withdraw, and transparent execution -- no black boxes
- Transfer in size with minimal slippage, time delays, gas, or MEV extraction
- Use native assets (USDC), not 3rd party wrapped illiquid tokens (ex. hopUSDC, USDC_L0, etc)
- Low TVL needed for execution, so less risk and a higher share of swap fees
- Dynamic & differential fees to meet demand surges
Atomic Trades (Arbitrageur/Retail)
- No need to source arbitrary tokens to correct pool prices
- Easy to arbitrage, simply back-run long-term trade for profit by going in the opposite direction
- PFoF fee structure for dedicated parties
The architecture leverages a combination of TWAMMs for large/unopinionated trades and AMMs for small/opinionated trades. We also have two types of capital in our design as
liquidity at rest which is sourced by liquidity providers and
liquidity in flight which is sourced by arbitrageurs.
Long Term vs Short Term
Most large trades will go through the long-term (non-atomic) interface thus giving the LPs and arbitrageurs time to react accordingly. There will be a cap on the amount that can be swapped via the short-term (atomic) interface for LP safety.
Liquidity at Rest
LP TVL is minimal and acts as the “grease” to start the trades. As shown in our simulations, this amounts to
$10M on each chain — a reasonable upper bound to move $100s of millions in volume.
- Concentrated Liquidity: other than amplifying liquidity, CL provides another safety in the case of an attack. If a malicious trader tries to move a large amount quickly, it will push the trade out of the “active tick zone” and the trade
pauses thus giving LPs and arbitrageurs time to react.
Liquidity at Flight
Arbitrageurs are the party sourcing the majority of the capital in our system and also the more sophisticated actors. For our simulation, we arbitraged the trade immediately. However, arbitrageurs can take longer to be sure the long-term trader is not malicious and their trade has settled.
“The relayer can assume all finality risk and fill the “user intent” on the destination chain as soon as they are confident the user’s deposit transaction is valid.” Hart Lambur, UMA on X
As the above quote expresses, relayer (arbitrageur in our case) takes the risk of filling (back-run) a user’s order. We expect more risk-averse arbitrageurs to be slower to fill at the start of the order. This would either
pause the trade when it pushes the trade out of the active tick zone or allow a risk-seeking arbitrageur to back-run sooner.
Finality & Re-org risks (See Network Risk)
Since our design depends on the liveness of potentially three chains (source: X, destination: Y, and settlement: ETH), lacks a
normalizing account of transfer (bridging token), and can be used to transport large sums cross-chain, we have to take additional precautions against the loss of funds via re-org or finality risks.
We can simply add a delay (L1 Finality or arbitrary) before trade execution and thus ensure transactions/funds are settled before interacting with the protocol. Long-term traders are time-insensitive as TWAMMs are non-atomic and designed to move funds over time, so unaffected. Arbitrageurs can get around this issue by pre-loading their funds before the trade and have it ready for immediate execution. We also provide a Trusted Party for dedicated arbitrageurs to bypass the delay and immediately execute their transactions.
EigenLayer: Economic Security
Building mitigations in protocol has the drawback of adding latency, complexity, gas costs, and centralization amongst other issues. Solving this issue via economic and/or ZK would allow for near-instantaneous settlement of atomic transactions and lower price impact for non-atomic transactions.
EigenLayer’s Active Validation Service (AVS) gives us the most flexibility and control in the design space i.e. L2 support, latency, economic security, validator size, or slashing criteria. LPs can choose between
max short-term trade cap size to
1/2 of the liquidity pool size in economic security to give them the economic security for taking on the risk of near-instant execution of bridging value. Additionally, tools like Hyperlane’s ISM (interchain security model) have built-in support to leverage EigenLayer AVS for validating cross-chain messages.
Arbitrageurs and liquidity providers are required for optimal performance as in any AMM. Beyond that, validators are optional if EigenLayer active validation is needed. Other than those 3 parties, there are no other dependencies for optimal performance of the protocol.