# Request for Comments: Bridge Designs for SUAVE

Source: https://collective.flashbots.net/t/suave-bridge/2696
Kiwi News: https://news.kiwistand.com/stories/Request-for-Comments-Bridge-Designs-for-SUAVE?index=0x65c280d3474da11928343ae4e3500d8a910094d1ebd3b9035409bc31fcf932adbdfdebba
Submitted by gokhan.eth on 2024-02-06 UTC, 2 upvotes, 0 comments

## Summary

SUAVE is a platform for building MEV applications such as OFAs, block builders, and intent executors, and its bridge to Ethereum and future chains is central to its architecture. The team is seeking input on bridge designs because the SUAVE client currently uses a centralized, highly trusted bridge meant only for rapid prototyping, not mainnet use. The requirements listed are security, decentralization, chain scalability, and user experience, and the post references Uniswap Foundation risk categories: protocol architecture, implementation, and operational risk. Whether SUAVE is an L1 or L2 remains an open question that also affects bridge design.

## Article

SUAVE Bridge

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.