SUAVE Bridge

[dmarz]

Request for Comments: Bridge Designs for SUAVE

SUAVE is a platform for building MEV applications such as OFAs, block builders, and intent executors in a decentralized and private way. SUAVE does not replace other blockchains: it is intended to aggregate and coordinate things that ultimately change the state of other chains. Because of this relationship, the bridge from SUAVE to Ethereum, and other chains in the future, plays a crucial role in the network’s architecture.

In the current implementation of the SUAVE client we use a centralized and highly trusted bridge. This was chosen to enable rapid prototyping and is not intended for mainnet usage. We’re seeking input on not only ideas that satisfy these loose requirements below, but also expertise in how to refine these requirements and think about the trade-off space:

• Security: Not all assets need to be bridge to SUAVE, but of those that do we want to ensure highest level of security and understand the trade-off space.
• Decentralization: Removing a single point of trust reduces the attack surface.
• Chain Scalability: SUAVE is planning to expand to many chains so it’s important to have a solution that works with as many chains as possible, or at least does so with less effort than an entirely custom bridge per chain.
• User Experience: Although this is more of an app-specific concern, the bridge would ideally work easily with cross-chain intent executors.

Risk categories from the Uniswap Foundation Bridge Assessment Committee Results - Framework and Evaluations:

• Protocol Architecture Risk: Encompasses the risks stemming from the design of a protocol, including its primary validation mechanism and other architecturally significant components that impact the fundamental security properties, assumptions, and trust model associated with the protocol.
• Protocol Implementation Risk: Includes the risks associated with the implementation of a protocol’s specification. Building cross-chain protocols involves creating complex on-chain and off-chain components while accounting for the peculiarities and pitfalls of different programming languages, frameworks, and execution environments.
• Protocol Operational Risk: Refers to the various risks that arise from the operational security and management of different components, often by different actors with different trust assumptions and incentives. This could include upgrading and managing bridge smart contracts, as well as operating off-chain systems such as external validator nodes.
• Network Risks:

Another thing to keep in mind which affects a bridge architecture is that it is still an open question whether SAUVE is an L1 or L2, this post SUAVE Economic Security Models dives into relevant considerations of this choice.

Your insights and suggestions are invaluable to us. We are looking for diverse opinions and creative ideas to help shape the future of SUAVE.

[cankisagun]

I think a robust light client and an agreed upon method to address L1 forks is potentially much more important than bridge to move assets.

If Suave is a bulletin board and the TXs eventually end up on Ethereum (L1), do you really need to move assets?

[eljhfx]

Have you thought about the case where an intent-app doesn’t require a bridge and one solver invalidates the others’ solutions by submitting a ‘fake’ intent from a sybil account and front-running the solutions by moving their funds ?

This looks like an active problem CowSwap is facing based on this thread.

I think it points to a broader class of intent-apps where bridging is necessary ( roughly when u(winning solution) > front run costs )

[cankisagun]

could you get mempool data from devp2p to ensure the attacker is not trying to front-run? RETH is supposed to be super fast

[Quintus]

Mempool monitoring is not nearly robust enough. Only block builders themselves can provide these kinds of guarantees. If they’re rational (in the short term at least) and the cancel tx was paying them, the solution would have to outbid the cancel.

[georgios_axelar]

Flashbots x Axelar - SUAVE Bridge Proposal

Hi everyone, I’m representing the Axelar Foundation. We recommend that SUAVE leverages Axelar network’s decentralized infrastructure for cross-chain use-cases.

Situation

In the current implementation of the SUAVE client, Flashbots uses a centralized bridge. Flashbots seeks input and expertise in bridge designs that optimize security, decentralization, chain scalability, and user experience.

Proposed Solution

Replace the existing centralized bridge with Axelar network’s decentralized, proof-of-stake solution to transfer assets for gas and MEV applications.

Security

Security of cross-chain systems has requirements similar to those of blockchain consensus protocols, namely safety and liveness.

• Safety: It must be extremely hard for an attacker to steal funds.
• Liveness: Transactions will always go through within some timeframe.
• Decentralization: This is not necessarily a separate requirement but rather a means towards satisfying the properties of safety and liveness.

Axelar network security is powered by a combination of:

• Proof-of-stake decentralized design at the core.
• Novel quadratic voting mechanism increases the decentralization of the network.
• Validator security policies, such as mandatory key rotations.
• Network functions that enable mitigation of malicious interconnected chains [suspend traffic from them].
• Contract limits that specify how much can be transferred over a time period.
• Docs
• Rigorous audits & bug bounties.
• Code

Uniswap Foundation announced in June of 2023 that Axelar network & Wormhole are approved to support the next phase of its development for cross-chain governance. The foundation has used a group of nine experts to analyze six of the leading crypto bridge providers. After a comprehensive review involving code evaluation and direct interaction with the bridge teams, the committee approved Axelar network & Wormhole for Uniswap’s specific use case of protocol governance. Other bridges, including LayerZero, Celer, DeBridge, and Multichain, did not meet the committee’s criteria.

“The analysis of Axelar concluded that it conditionally satisfies the requirements of the Uniswap DAO’s cross-chain governance use case, as outlined in the Assessment Framework. Axelar employs a proof-of-stake mechanism with sound cryptoeconomic guarantees to secure the protocol. Various aspects of the design of the protocol appear to be well-considered. The size of the validator set and the thresholds for ensuring safety and liveness are sufficient. Its technology stack is built to high standards, and the team maintains good development practices, with strong attention to detail and high activity levels for ongoing improvements. A source of concern for the Committee is a 4-of-8 multisig that governs key aspects of the protocol. Axelar has communicated its plans to move away from reliance on this multisig in Q2 2023 and the committee has weighed in on that process. The Committee recommends that the Uniswap DAO adopt Axelar, conditional on a successful transition away from this multisig. Additionally, the Committee recommends ongoing monitoring of updates to identify areas for improvement in the protocol.” Read more here.
Since then, Axelar network has upgraded to fully decentralized governance. Details of the new Axelar Gateway Governance can be found here. Changes to protocol parameters, including upgrades, now require a quorum of validators to take effect. Axelar network uses the same trust assumptions as message passing for protocol governance changes.

Decentralization

Axelar network is a full-stack decentralized transport layer governed by permissionless PoS consensus. Axelar network is the only “open stack” on the market. All of its components can be upgraded and improved by the community. It provides universal composability of programs with any-to-any cross-chain capability. Users access consolidated pools of liquidity. Developers do not need to speak any custom language; they do not need to make any changes to their chains or UIs.

The Axelar network has three critical components across two functional layers.

• The first is the network itself, composed of validators responsible for maintaining the network and executing transactions. The validators run the cross-chain gateway protocol, a multi-party cryptography overlay on top of a Layer 1 blockchain. They are responsible for performing read-and-write operations to gateway accounts deployed on connected external chains, voting, and attesting to events on those chains.
• The second are the gateways, effectively smart contracts that connect the Axelar network and its interconnected external chains. Validators monitor gateways for incoming transactions, which the validators READ. They then come to a consensus on the validity of that transaction, and once agreed, they WRITE to the destination chain’s gateway to execute the cross-chain transaction. The funds are sent to a generated address on the source chain and are locked, and a corresponding asset is minted on the destination chain. The validators and gateways compose the core infrastructure layer.
• Sitting on top of the validators and gateways are the APIs that enable developers to access the tools and infrastructure enabled by those validators and gateways. This is the application-development layer that applications will interact with to go cross-chain. The underlying core infrastructure layer is used to pass customizable, generalized messages across chains. These APIs are how developers can easily lock, unlock, and transfer assets between any two addresses on any two blockchain platforms, execute cross-chain application triggers, and, more generally, handle any cross-chain requests.

Chain Scalability

Presently, Axelar network connects 54 chains, the highest coverage of all available interoperability solutions.

Axelar network’s coverage and scalability of chains is set to grow exponentially with the launch of Axelar Virtual Machine. The Axelar Virtual Machine is a programmable interoperability layer that automates complex multi-chain deployment and management. The Axelar VM helps developers to span the whole of Web3, as if they were building on a single chain. It is powered by Cosmwasm and turns interoperability into a programmable layer.

The Interchain Amplifier enables developers to permissionlessly set up connections to the Axelar network. Developers gain access to Axelar network’s interconnected network of chains and can “amplify” their resources by paying the cost equivalent to developing only one connection. They can establish connections between new ecosystems or existing chains to add new network properties, such as improved security or better delivery and availability.

For example, once Ethereum develops robust light-clients & ZK proofs for its state, a developer can easily integrate them into the Axelar network to replace or enhance an existing connection.

Developers can also leverage independent connectivity paths to enhance security at the application layer. In a blog introducing multi-path routing, it is described how, for lower-value transfers, an application can choose to accept messages authorized by any of the available connections. For higher-value transfers, the application can require messages to travel multiple independent paths, before approval. This architecture, combined with forward-compatible dApp deployments, enables developers to build scalable interchain technologies while adapting to future improvements in the cross-chain networking layer.

User Experience

Most cross-chain user experiences are complex and painful. 1-click user experiences are necessary to onboard billions of users. Unlike alternative solutions on the market, Axelar network is programmable: it’s a blockchain that connects blockchains, providing an innovative contract platform that supports superior UX:

• Tools like Interchain Token Service allow dApps and tokens to function on multiple chains in the same way as they function on their native chains.
• Tools like Axelar Gas Service automate burdensome user tasks like converting into multiple gas tokens to execute a cross-chain transaction.

Cross-chain Intents are live on the Axelar network: Squid, a liquidity router, has used intents on Axelar network to execute cross-chain swaps in seconds. Axelar network can easily work with new cross-chain intent executors. Intents create fluidity between off-chain and on-chain worlds by allowing third parties to fulfill users’ desired actions efficiently. Intents improve interop UX by settling actions almost instantly and then safely finalizing them later.

On the Axelar network, intents have been seamlessly operational. They are exceptionally efficient for transactions that tie value to a specific token, enabling swift order fulfillment. They can also be expanded to more generic messages as long as developers can define their intent structures meticulously. If the value of an intent can be quantified, then solvers can price the risk of it failing to finalize. The risk to the solver of executing a solution to a complex set of user intents between many chains could be aggregated into a single fee, allowing them to execute simultaneously but finalize separately. A small fee to the solver is vastly offset by the improvement in usability and efficiency for the user. We like the work that Essential is currently doing with the concept of “Intent Standards."

One notable Axelar ecosystem application, Squid, has successfully employed intents on Axelar network by integrating with the GMP Express interface. The result? Instant cross-chain communication.

Squid is a cross-chain liquidity router built using Axelar GMP. The dApp finds liquidity in DEXs on connected chains so users can initiate swaps with a single click. The user experience (UX) mimics what users expect when transacting between different chains’ tokens on centralized exchanges – except the entire transaction runs on decentralized infrastructure.

However, there is one aspect in which Squid cannot duplicate a centralized order book using exclusively on-chain infrastructure: as discussed above, finality on connected chains can take 10 to 15 minutes. Instead of making the user wait, risking slippage, Squid employs intents in a fast-finality gadget called Boost. Squid Boost completes the action described hypothetically above in real transactions. It serves a user’s intent to swap X for Y between chains A and B. Boost completes the intent on B, then recoups funds when the transaction finalizes, absorbing bridge risk and delay. Here’s an example transaction.

Conclusion

Axelar network’s architecture meets Flashbots’ requirements on Security, Decentralization, Chain Scalability, and User Experience. We believe Axelar network’s cross-chain infrastructure presents the right solution for SUAVE Bridge.

[pbj]

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).

Protocol Security

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.

Decentralization

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.

	CronFi Bridge	Uniswap DEX
Assets	OP_USDC ↔ ARB_USDC	USDC ↔ WETH
Connector	Cross-chain Liquidity Pool	Liquidity Pool
Action	Bridge	Swap
Optimization	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.

Scalability

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.

User Experience

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

Liquidity Provider

- 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

Risks

Liquidity Risk

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.

Operational Risks

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.

[jkol]

Jon, Hyperlane co-founder here. Wanted to add some additional color that would be relevant for Cron’s proposal. Using Hyperlane means they will be able to ensure Suave can connect with any new chain or L2, as they themselves, the Hyperlane core team, the Flashbots team, or really anyone in the world, can add Hyperlane to a new network.

Beyond that flexibility the security of the bridge can evolve over time thanks to Hyperlane’s modular security architecture. As economic security is added via the AVS and other means, as new state proof modules are added, those can be leveraged to secure the bridge, with minimal disruption to users and the chain itself.

[ssweck]

Bridging Over the IBC

Summary

Composable proposes that SUAVE uses the Inter-Blockchain Communication (IBC) Protocol as its native bridge. The IBC is a trust-minimized interoperability protocol that Composable is working to connect to all chains. The IBC is compatible with 100+ Cosmos SDK chains, Ethereum (in testnet), Solana (in testnet), Polkadot, and Kusama, with more connections planned in the future. Using the IBC, SUAVE could have a mechanism for trust-minimized, scalable, and decentralized bridging.

Proposed Solution: The IBC

The Inter-Blockchain Communication (IBC) Protocol is a protocol for trust-minimized communication between different blockchain networks/ecosystems. This trust-minimization is a core advantage of the IBC protocol, and a large reason why we selected the IBC as a cornerstone of Composable’s efforts to connect ecosystems, as we explain below.

The following summary of IBC is taken from IBC’s documentation.

The following diagram shows how IBC works at a high level:

The transport layer (TAO) provides the necessary infrastructure to establish secure connections and authenticate data packets between chains. The application layer builds on top of the transport layer and defines exactly how data packets should be packaged and interpreted by the sending and receiving chains.

IBC provides a reliable, permissionless, and generic base layer (allowing for the secure relaying of data packets), while allowing for composability and modularity with separation of concerns by moving application designs (interpreting and acting upon the packet data) to a higher-level layer.

This separation is reflected in the categories:

• IBC/TAO comprises the Transport, Authentication, and Ordering of packets, i.e. the infrastructure layer.

• IBC/APP consists of the application handlers for the data packets being passed over the transport layer. These include but are not limited to fungible token transfers (ICS-20), NFT transfers (ICS-721), and interchain accounts (ICS-27).

• Application module: groups any application, middleware or smart contract that may wrap downsteam application handlers to provide enhanced functionality.

Note three crucial elements in the diagram:

• The chains depend on relayers to communicate. Relayers are the “physical” connection layer of IBC: off-chain processes responsible for relaying data between two chains running the IBC protocol by scanning the state of each chain, constructing appropriate datagrams, and executing them on the opposite chain as is allowed by the protocol.

• Many relayers can serve one or more channels to send messages between the chains.

• Each side of the connection uses the light client of the other chain to quickly verify incoming messages.

Decentralization

By using IBC, SUAVE can implement a decentralized bridge.

Most bridges and connections between blockchains are built in a centralized manner and rely on trusted architecture. This is a massive security risk for users’ assets as can be seen from the numerous hacks and exploits over the past few years. A trusted bridge is a connection between blockchain networks that relies on a third party to facilitate asset transfers between these networks. This third party is tasked with upholding bridge security and reliability. Users must therefore trust this entity to properly handle their transactions.

In contrast, a trust-minimized architecture like one using IBC is based on light client bridging and connecting two blockchain networks without any trusted third party intermediaries. Users can transfer assets between the two networks without needing to trust a third party, instead only needing to trust in code, which is made publicly available to and auditable by all. However, existing trustless bridging solutions are generally not extensible across ecosystems or often sacrifice speed or UX in the bridging process. For more information on the advantages of trustless connections and the current limitations of trusted bridges, check out our blog on this topic.

IBC is designed to be trust-minimized for several key reasons:

1. It relies on light clients that interact to keep each other updated on the states of counterparty chains.
2. It can update chain states through the transmission of finality proofs and other types of verifiable transactions and packets.

A more technical explanation of why we chose to expand IBC is that it is an end-to-end stateful protocol for reliable, ordered, and authenticated communication between blockchains. It enables bi-directional asynchronous communication between two blockchains within a relatively short time window: an average of less than one minute per IBC message, as reported by Kim, Essaid, and Ju, 2022. Thus, IBC is our mechanism of choice for facilitating cross-chain communication in a trust-minimized manner, and we believe that it is similarly optimally suited as SUAVE’s bridge.

Security

If SUAVE adopts an IBC bridge, security will be augmented by the trust-minimized nature of IBC. As the IBC website states the protocol’s “…light client-based interoperability removes the need for a trusted third party in cross-chain interactions, securing tens of billions in annual value transfer without a single exploit since launch.”

Light clients serve as a lightweight, trustless mechanism for verifying the state of connected blockchains. They are essential components of the IBC protocol as they facilitate secure and efficient cross-chain interactions without the necessity of fully synchronizing and managing the complete history of every connected blockchain.

Chain Scalability

If SUAVE uses the IBC, its bridge will be quite scalable, given that the reach of the IBC is quite wide and rapidly expanding. IBC originated as the standard messaging protocol for Cosmos. Composable has expanded the IBC from this initial deployment; IBC thus connects all 100+ IBC-enabled Cosmos SDK chains, ~80 Polkadot and Kusama parachains, Ethereum (in testnet), and Solana (coming soon), with more connections planned for the future. Our eventual goal is to connect all major chains over IBC.

User Experience

The IBC supports an improved user experience for cross-chain transactions. In fact, user (and developer) experience are one of IBC’s top priorities (source).

For one thing, the IBC is highly performant; It enables bi-directional asynchronous communication between two blockchains within a relatively short time window (an average of less than one minute per IBC message) (Kim et al., 2022).

Moreover, IBC is compatible with a wide array of transactions, serving a user’s many needs. These transactions include the transfer of both fungible and non-fungible tokens, generic message passing, cross-chain contract calls, cross-chain fee payments, and interchain collateralization, all executed in a trust-minimized environment.

Similarly, the IBC offers a very mature and expansive solution for developers. Using IBC, it is possible to build extremely sophisticated distributed programs, with autonomous execution over untrusted domains. Thus, performant and manifold solutions can be developed with the IBC, serving whatever needs a user may have.

IBC also enables cross-chain bridging to be:

• One-stop: users can bring any asset from any chain, swap natively, and instantly earn yield

• Flexible: users can maximize the potential of their assets with any number of DeFi processes such as lending, staking, restaking, liquidity provisioning, vault participation, lockdrops, NFT borrowing, limit orders, and perpetual swaps

• Optimized: users get best-price execution with dark pools and cross-chain MEV subsidies

• Simplified: users experience a seamless, intuitive interface

These benefits in user experience can be delivered to SUAVE bridge users if IBC is leveraged in the bridge design.

Conclusion

IBC is a battle-tested protocol that has been gaining rapid adoption. Its use in a SUAVE bridge will likely bring cross-chain composability, and a truly trust-minimized mode of communication with other chains.