Understanding Flashbots' SUAVE Chain from a Developer Perspective: Beyond MEV, What Other Possibilities Exist with EVM + TEE?

Author: ZHIXIONG PAN, DUGUBUYAN

SUAVE is a decentralized project developed by Flashbots that establishes a network with a TEE (Trusted Execution Environment), addressing issues such as key custody and mutual trust among multiple parties in the MEV process. Additionally, the integration of TEE into SUAVE unlocks possibilities beyond solving MEV problems.

SUAVE-related Code Repositories

As an Ethereum extension, SUAVE is inherently EVM-compatible. Its current GitHub projects include SUAVE-geth, SUAVE-std, and SUAVE-examples.

SUAVE-geth is an execution layer codebase extended from geth, primarily adding an encrypted computing environment and several precompiles within this secure environment. Notably, it includes a precompile for standard HTTPS requests, enabling developers to leverage the TEE environment to provide users with access to external networks. It also incorporates a series of TEE-based functional precompiles, such as retrieving encrypted parameters, storing and retrieving encrypted information—forming the foundational development infrastructure under a trusted environment.

SUAVE-std is a developer-focused utility library. For example, it encapsulates HTTP request handling and even provides a ready-to-use ChatGPT integration library, eliminating the need for developers to manually construct or parse ChatGPT API messages. Developers only need to insert their own API key when setting up the HTTP request. The security of the API key is ensured because all operations occur within the TEE environment. Initially, this standard ChatGPT library used the GPT-3.5-turbo model with a default temperature of 0.7. Now, it offers flexible interfaces allowing models and other parameters to be passed in dynamically.

The SUAVE-examples repository serves as a collection of application development case studies—or more accurately, beginner tutorials. Newcomers to SUAVE application development can learn and compare implementations through these examples.

SUAVE Development Practices

Since SUAVE extends Ethereum (its execution environment is known as MEVM—Modified Ethereum Virtual Machine), smart contract development remains EVM-compatible, and official documentation uses Solidity for explanations. Therefore, developers’ existing Solidity experience applies directly. Developing SUAVE applications can be understood as Solidity development enhanced with encrypted computation capabilities within a TEE environment.

There are several key SUAVE MEVM precompiles. The first is confidentialInputs, which receives encrypted parameters from application requests—typically sensitive data like private keys or API keys. Security requires that plaintext only exists within the TEE environment, and this interface enables accessing the decrypted data during application development. The transmission process is fully encrypted and secure; we'll explain the underlying mechanism later. The second is confidentialStore, used to store sensitive information after retrieval, holding it securely for future use. The third is confidentialRetrieve, which retrieves plaintext data from the TEE context when needed for subsequent computations.

SUAVE’s secure storage of sensitive information enables scenarios such as: "Users upload their private keys, and third parties perform business logic; upon meeting certain conditions, the third party can directly sign transactions using the user's private key—yet they never gain access to the actual plaintext of the key."

SUAVE performs cross-chain operations via HTTPS requests. Its toolkit includes a gateway library for reading cross-chain data—essentially allowing users to set RPC nodes, or more commonly, upload API keys for services like Infura or Etherscan. When needed, HTTP requests are sent directly to the relevant node. For cross-chain writes, the toolkit provides a transaction package to help encode EIP-1559 compliant payloads, ultimately broadcasting transactions via the eth_sendRawTransaction interface.

Another notable use case involves uploading and storing Solidity-compiled bytecode as confidential parameters, then deploying and invoking it when conditions are met—effectively creating a private code library. This scenario can be expanded to combine private keys with private bytecode libraries, enabling completely private transactions during third-party delegated calls.

SUAVE Features

The ultimate form of SUAVE is a standalone blockchain—referred to as the SUAVE chain. We can view the SUAVE chain as a blockchain implementing MEVM. As an EVM-compatible chain, it supports standard assets like ERC20 and ERC721, with on-chain operations identical to other EVM-based chains. However, its uniqueness lies in supporting off-chain operations such as sending transactions to nodes on other chains. The results or conditions of these off-chain actions can be stored on the SUAVE chain, with consensus guarantees ensuring consistency between off-chain computations and on-chain state. For instance, a developer could write a smart contract that records certain conditions on-chain (which may be modified), and when a query to another chain returns a matching result, triggers a predefined transfer of an ERC20 asset.

These capabilities stem from SUAVE’s off-chain trusted computing. Since SUAVE is developed by the Flashbots team and regarded by them as “The Future of MEV,” bundle transaction processing is naturally supported. On the TEE-enabled SUAVE chain, the MEV mechanism is straightforward: assemble bundle transactions and send them to Flashbots relay nodes. Private keys—and even code—can be stored confidentially, unlocking vast potential. For example, builders can earn not only gas rewards on target chains but also receive digital assets on the SUAVE chain. In the MEV market, being able to flexibly define business logic with guaranteed privacy protection represents a significant leap forward compared to today’s reliance on off-chain trust, contracts, and reputation.

SUAVE Development Tools and Infrastructure

For developers, dapp development involves not only on-chain smart contracts but also frontend tools like ether.js. Since the SUAVE chain is an EVM variant, tools such as ether.js and web3.js remain compatible. These tools interact with SUAVE smart contracts just as they do with other EVM-compatible chains—but only for non-confidential functions. A SUAVE smart contract typically separates operations into on-chain (i.e., on the SUAVE chain) and off-chain components (including cross-chain interactions), where off-chain refers specifically to confidential computation within the TEE. For confidential computation, the Flashbots team provides SDKs in two languages—Go and TypeScript—with usage details documented in SUAVE’s official documentation. When sending a privacy-preserving compute transaction (called a Confidential Compute Request by Flashbots) to a SUAVE node, developers can include confidentialInputs—private parameters that remain encrypted throughout transmission, with plaintext only exposed inside the TEE environment.

Regarding smart contract deployment, SUAVE’s testnet was initially named Regil but has since been upgraded to Toliman. Deployment methods are thoroughly detailed in the SUAVE documentation, and the process—including post-deployment interaction—is nearly identical to Ethereum smart contract deployment.

Kettle

After deployment, the actual execution model differs significantly from Ethereum. SUAVE’s primary execution unit is called Kettle. A Kettle is essentially SUAVE’s TEE runtime environment, comprising an MEVM node and a confidential data store. Once developers deploy a smart contract, users send Confidential Compute Requests (CCRs), and any operation requiring confidential computation is executed within a Kettle.

The architecture of Kettle is shown below:

Developers write and deploy applications using Solidity. When requests reach the Kettle, they are processed by the MEVM. Beyond standard geth functionality, MEVM includes additional precompiles for storing and retrieving sensitive data, as well as modifying and querying SUAVE chain state.

The main tasks of Kettle include receiving and processing confidential computations, along with managing the storage and retrieval of sensitive data. For example, when storing sensitive data: the user’s frontend sends a CCR to a specific smart contract on the SUAVE chain via SDK or suave geth tools. These tools encrypt the sensitive data using a symmetric key, which only appears within the Kettle’s TEE environment. The SUAVE RPC node only sees ciphertext. Whether each Kettle corresponds to one node is unclear from available documentation. Similarly, the exact mechanisms behind Kettle itself, node relationships, and key exchange are not detailed. However, based on known encryption flows, developers can reasonably trust that sensitive data remains protected from the frontend to the internal TEE environment of the Kettle.

Kettle stores sensitive data in its confidential data store. During development, developers specify who can access or modify the data. Kettle broadcasts this via its Transport network. If access is restricted to the originating contract, subsequent CCRs must be directed to the same Kettle, as Kettle’s data storage is not globally synchronized. After contract deployment, users access the corresponding Kettle (a Kettle address must be specified in the CCR). When requesting sensitive data within a smart contract, developers retrieve it using the ID and key established during storage—meaning access is key-value based.

HTTP requests are also handled by Kettle. Clearly, these are off-chain activities—meaning they run on a single node. Although SUAVE is a blockchain, its decentralized characteristics are weakened here: when a Kettle processes a CCR, there isn't broad validation across many nodes. The reason is simple—accessing external resources cannot guarantee idempotency. Thus, the outcome of these off-chain tasks relies heavily on individual nodes. Therefore, developers must pay attention to the Kettle address at deployment (in this sense, Kettle acts like a special smart contract), and users must include the correct Kettle address in their CCRs.

Additionally, developers should note one critical point: on the current Toliman testnet, Kettles are not guaranteed to run within a TEE environment. Therefore, when developing on the testnet, avoid exposing real sensitive data.

Conclusion

By introducing a TEE environment, the SUAVE chain empowers application development with powerful new capabilities and opens up numerous potential use cases. Its streamlined cross-chain operations further expand design possibilities for Dapps.

The Kettle design allows SUAVE to interact with external resources, but this raises challenges around verification and consensus. A malicious Kettle could severely damage the network. Ensuring Kettles behave honestly—or face meaningful penalties—and making malicious behavior prohibitively costly are critical unresolved issues. SUAVE currently uses a PoA (Proof-of-Authority) consensus model, whose resilience in practice remains to be seen by the developer community.