From Theory to Practice – Building on SUAVE

How a SUAVE Transaction Works

A typical SUAVE transaction does not begin in a mempool. Instead, it starts with an intent. This intent might be a user’s desire to swap a token, bid on an NFT, participate in a liquidation, or perform a cross-chain action. Unlike traditional transactions, which are fully specified and publicly broadcast, an intent in SUAVE is encrypted and only partially specified. It leaves room for solvers to propose optimal execution paths.

Once the user signs and submits this intent to the SUAVE Membrane, the privacy layer encrypts it and sends it into a secure environment. This environment may be a trusted execution environment (TEE), a zero-knowledge proof system, or a replicated secure enclave network. Within this environment, the intent is held confidentially until the solver network evaluates it.

Solvers access a batch of encrypted intents and compete in a universal auction to provide the best execution. Each solver proposes a complete transaction path along with a bid—representing either a rebate to the user, a guaranteed minimum output, or some other measurable advantage. These bids are not visible to other solvers during the auction, preserving fairness.

The MEVM, SUAVE’s execution engine, evaluates the proposed solutions and selects the winner based on programmable logic. The winning solver’s execution bundle is then decrypted, finalized, and routed to the appropriate blockchain through the Membrane. The receiving chain accepts the transaction as a standard bundle or inclusion proof, finalizes it on-chain, and returns confirmation to SUAVE.

At no point in this process is the user’s transaction data exposed to the public. Finality is guaranteed by the settlement layer of the destination chain, but ordering and privacy are handled by SUAVE.

Roles and Responsibilities in the SUAVE Ecosystem

The SUAVE ecosystem consists of several distinct actors, each playing a critical role in the system’s functionality. Understanding these roles is essential for anyone looking to build on or integrate with SUAVE.

Users are the source of order-flow. They interact with dApps or wallets to express their intent. SUAVE supports both individual users and protocols submitting transactions on behalf of their users. Users retain full control over their intent and can select preferences for slippage tolerance, speed, or privacy.

Solvers are entities that interpret user intents and propose execution plans. Solvers analyze encrypted intents within the privacy layer and compete in auctions to fulfill them. They may be arbitrageurs, liquidity routers, market makers, or bots optimized for specific tasks. Their incentives are aligned with users—they only profit if they provide the most valuable execution.

Builders are optional intermediaries that aggregate multiple solved intents into a single bundle. While solvers can submit directly to the Membrane, builders can optimize for gas efficiency, reordering, or co-packaging multiple transactions. Builders add scalability and flexibility, particularly when dealing with high-throughput periods.

The MEVM handles arbitration and execution logic. It evaluates solver proposals, enforces auction rules, and ensures that only valid solutions are selected. Developers can write custom rules for the MEVM, such as giving priority to decentralized solvers, enforcing minimum user rebates, or requiring cross-chain liquidity proofs.

The Membrane functions as the bridge between SUAVE and external chains. It receives user input, delivers finalized transactions, and handles state synchronization. The Membrane also manages permissioning and proof-of-integrity for cross-chain settlement.

Validators, in this context, are limited to the settlement chain. They are unaware of SUAVE’s inner workings and simply process finalized bundles. This keeps SUAVE’s operation lightweight and avoids the need to convince consensus layers to adopt new infrastructure.

Writing and Deploying a Value Router

A key innovation in SUAVE is the concept of value routers—smart-contract-like services that live inside the MEVM and handle specific classes of intents. A value router is similar to a dApp but operates on private, pre-chain order-flow rather than public transactions.

To build a value router, a developer defines three components:

• Intent format – What data does the user need to provide? How is it encrypted?
• Auction logic – How should solvers be scored and selected? Is it based on price, latency, slippage, or other custom metrics?
• Settlement logic – Where should the output be sent? Should it settle on Ethereum, Optimism, or both?

Once deployed to the MEVM, a value router begins accepting intents through the Membrane. Solvers connect to the router via a standardized API and begin competing to fulfill incoming requests. Because routers operate in a privacy-preserving environment, they can safely process large volumes of sensitive data without revealing strategy.

Use cases for value routers include:

• NFT batch auctions with sealed bids
• DeFi rebalancing across multiple lending markets
• On-chain games that require hidden move execution
• DAO governance actions requiring coordinated settlements

Because the MEVM is chain-agnostic, a single router can serve multiple chains, allowing developers to write once and serve a global user base.

Wallet Integration and User Experience

One of SUAVE’s long-term goals is to make MEV resistance invisible to users. For this to happen, wallets must integrate with SUAVE at the UI and RPC levels. Instead of submitting transactions to a traditional mempool, the wallet routes them through the Membrane and displays execution options returned from solvers.

From a user’s perspective, nothing changes. They click “Swap,” “Mint,” or “Vote” as usual. But behind the scenes, their transaction is encrypted, auctioned, and fulfilled through SUAVE. The user sees better pricing, faster confirmation, or a rebate—without needing to understand how any of it works.

Wallets can optionally display solver options, ranked by price, privacy, or speed. This allows power users to customize their experience while casual users benefit from default settings optimized for fairness. Future wallet SDKs from Flashbots and third parties will likely simplify this integration path.

Cross-Chain Execution and Composability

Because SUAVE does not settle transactions itself, it must work in harmony with external chains. This introduces complexity but also opens opportunities for advanced workflows. Consider a user who wants to:

• Swap ETH for USDC on Ethereum
• Bridge USDC to Arbitrum
• Use that USDC to buy an NFT on an Arbitrum-based marketplace

In a traditional setup, this would require multiple steps, approvals, and trust in bridge relayers. In SUAVE, the entire workflow can be expressed as a single intent. Solvers compete to fulfill that intent in the most efficient way possible. The best solution is selected, settled across chains, and confirmed to the user with a single signature.

This kind of multi-chain composability is difficult to achieve with existing architectures. SUAVE enables it by decoupling execution from settlement, allowing workflows to be coordinated before being submitted to each chain in sequence.

Incentives, Payment, and Trust

A final question for practical adoption is how participants are paid. Solvers, builders, and relays must be incentivized to perform computation, participate in auctions, and route transactions.

In SUAVE, incentives are programmable. Solvers submit bids that include a payment to the user (a rebate), to the system (a fee), and to the settlement chain (gas). These payments are enforced at the MEVM level and are only finalized once the settlement confirms the transaction.

Reputation systems can track solver performance over time. Poor performance, failed execution, or slippage beyond declared tolerances can be punished by excluding solvers from future auctions. Users can also blacklist solvers that behave maliciously.

This balance of incentives and reputation is essential to making SUAVE sustainable. Rather than relying on altruism or trust, it creates a market where honest behavior is the most profitable strategy.

Real-World Example: Cross-Chain NFT Purchase with Best Execution

Scenario:

Sarah wants to buy an NFT listed on an Arbitrum marketplace, but she only holds ETH on Ethereum Mainnet. In a typical Web3 setup, this would involve:

1. Swapping ETH for USDC via a DEX on Ethereum (e.g., Uniswap).
2. Bridging USDC to Arbitrum (via Hop or Stargate).
3. Waiting for confirmation and bridging delays.
4. Navigating to the NFT marketplace on Arbitrum and finalizing the purchase manually.

This flow takes time, involves multiple interfaces, exposes her to MEV and bridge risks, and costs high gas fees on Ethereum.

A final question for practical adoption is how participants are paid. Solvers, builders, and relays must be incentivized to perform computation, participate in auctions, and route transactions.

In SUAVE, incentives are programmable. Solvers submit bids that include a payment to the user (a rebate), to the system (a fee), and to the settlement chain (gas). These payments are enforced at the MEVM level and are only finalized once the settlement confirms the transaction.

Reputation systems can track solver performance over time. Poor performance, failed execution, or slippage beyond declared tolerances can be punished by excluding solvers from future auctions. Users can also blacklist solvers that behave maliciously.

This balance of incentives and reputation is essential to making SUAVE sustainable. Rather than relying on altruism or trust, it creates a market where honest behavior is the most profitable strategy.

Real-World Example: Cross-Chain NFT Purchase with Best Execution

Scenario:

Sarah wants to buy an NFT listed on an Arbitrum marketplace, but she only holds ETH on Ethereum Mainnet. In a typical Web3 setup, this would involve:

1. Swapping ETH for USDC via a DEX on Ethereum (e.g., Uniswap).
2. Bridging USDC to Arbitrum (via Hop or Stargate).
3. Waiting for confirmation and bridging delays.
4. Navigating to the NFT marketplace on Arbitrum and finalizing the purchase manually.

This flow takes time, involves multiple interfaces, exposes her to MEV and bridge risks, and costs high gas fees on Ethereum.

Same Scenario on SUAVE

Step 1: Submit Intent

Sarah uses a SUAVE-enabled wallet. She clicks “Buy NFT” from the marketplace UI and approves a single intent:

• “I want to buy this NFT on Arbitrum, spending at most 0.5 ETH, with the fastest confirmation and lowest cost.”

Step 2: Privacy & Solver Auction

• The intent is encrypted and submitted to SUAVE’s Membrane.

• Solvers receive this batch of intents. One solver suggests:

• Swap ETH→USDC via MEV-optimized path on Ethereum.

• Bridge USDC via fast bridge with proof-of-liquidity.
• Settle the NFT purchase directly on the marketplace.
• Provide Sarah with a 0.2% rebate on the transaction.
• Other solvers propose different paths, but this is the most efficient.

Step 3: Execution and Finality

• MEVM selects the winning bundle and routes it through the Membrane.
• The ETH→USDC swap, bridge, and NFT purchase are settled atomically across chains.
• Sarah receives the NFT on Arbitrum, a rebate in USDC, and a confirmation—all from one click

This example shows how SUAVE transforms a multi-step, high-friction UX into a one-click, cross-chain private execution, with optimized costs and built-in incentives. It mirrors familiar DeFi behaviors (like swaps and bridging) but executes them better, making the technical vision of SUAVE both intuitive and powerful in practice.