SUAVE: Decentralized Block Building
The future of MEV. How Flashbots is decentralizing block building with encrypted mempools, TEEs, and a dedicated chain for transaction ordering.
🎯 What You'll Learn
- Understand why current PBS has centralization risks
- Analyze SUAVE's architecture (MEVM, Kettles, and the SUAVE chain)
- Trace an encrypted transaction through the SUAVE flow
- Evaluate how SUAVE changes the MEV landscape
The Centralization Problem
Today, 3 builders produce 80% of Ethereum blocks.
This is a problem:
- Censorship risk - Builders can exclude transactions
- Trust concentration - Users trust builders not to frontrun
- Single points of failure - If top builders go down, MEV extraction drops
SUAVE (Single Unified Auction for Value Expression) is Flashbots’ answer: a separate chain specifically designed for decentralized block building.
Why Builders Centralized
PBS was designed to democratize MEV. Instead, it concentrated it.
The Economics of Scale
Small builder:
- Sees 10,000 transactions/slot
- Finds $1,000 MEV
- Pays validator $900
- Profit: $100
Large builder (with exclusive orderflow):
- Sees 100,000 transactions/slot
- Finds $10,000 MEV
- Pays validator $9,500
- Profit: $500
→ Large builders can outbid small builders
→ Small builders exit the market
→ Concentration increases
```text
### Exclusive Orderflow
The real moat is **private transaction flow**:
```text
Wallets/Frontends → Private RPC → Builder
(exclusive access)
Who has exclusive orderflow:
- MetaMask → flashbots protect → top builders
- CoW Swap → internal solver → specific builders
- Wintermute → direct channels → preferred builders
```diff
This is a permissioned network **inside** a permissionless blockchain.
---
## The Key Insight
> **What if block building itself was a blockchain?** Instead of trusting centralized builders, users submit encrypted transactions to a decentralized network. TEE-enabled nodes called "Kettles" can see the transactions (inside enclaves) but can't steal MEV or censor without detection. The SUAVE chain coordinates ordering and pays out value fairly.
SUAVE decentralizes the builder role itself.
---
## SUAVE Architecture
```sql
┌─────────────────────────────────────────────────────────────────┐
│ USER LAYER │
│ Users submit encrypted "preferences" (transactions + intents) │
└────────────────────────────────────────────────────────────────┬─┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ SUAVE CHAIN │
│ - Stores encrypted preferences │
│ - Coordinates Kettle selection │
│ - Handles payments and slashing │
└────────────────────────────────────────────────────────────────┬─┘
│
┌─────────────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────────┐
│ KETTLES (TEE Network) │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │Kettle 1│ │Kettle 2│ │Kettle 3│ ... (decentralized) │
│ │ SGX │ │ SGX │ │ SGX │ │
│ │enclave │ │enclave │ │enclave │ │
│ └────────┘ └────────┘ └────────┘ │
│ │
│ MEVM: Modified EVM that runs inside TEEs │
│ - Processes encrypted preferences │
│ - Builds blocks without seeing plaintext │
│ - Produces attestable results │
└────────────────────────────────────────────────────────────────┬─┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ TARGET CHAINS │
│ Ethereum, Polygon, Arbitrum, etc. │
│ - Receive finalized blocks from SUAVE │
└─────────────────────────────────────────────────────────────────┘
```diff
---
## Key Components
### 1. Preferences (User Intents)
Users don't submit transactions; they submit **preferences**-higher-level intents encrypted for Kettles:
```javascript
// Traditional: Submit exact transaction
{
"to": "0xUniswap...",
"data": "0xswapExactTokens(1000 USDC for ETH, 1% slippage)"
}
// SUAVE: Submit preference (encrypted)
encrypt_for_kettle({
"intent": "swap",
"input": "1000 USDC",
"output": "ETH",
"constraints": {
"max_slippage": "1%",
"deadline": "next 3 slots",
"mev_share": "50%" // User gets 50% of MEV their tx creates
}
})
```text
### 2. Kettles (TEE Nodes)
Kettles are nodes running TEE enclaves that can:
- Decrypt user preferences
- Simulate transactions
- Build optimal bundles
- Produce attestable proofs of honest behavior
```python
class Kettle:
def __init__(self):
# Generate keys inside SGX enclave
self.enclave = SGXEnclave()
self.decryption_key = self.enclave.generate_key()
def process_preference(self, encrypted_pref: bytes) -> Bundle:
# All processing happens inside enclave
with self.enclave:
pref = decrypt(encrypted_pref, self.decryption_key)
simulation = simulate(pref)
bundle = optimize_bundle(simulation)
return bundle
def get_attestation(self) -> bytes:
"""Prove we're running honest code."""
return self.enclave.get_quote()
```python
### 3. MEVM (Modified EVM)
SUAVE runs a modified EVM with new precompiles for:
```solidity
// SUAVE-specific precompiles
// Access confidential data inside TEE
function confidentialInputs() returns (bytes memory);
// Submit bid for block space
function submitBid(uint64 slot, bytes calldata bid) returns (bytes32);
// Emit results to target chain
function emit(uint256 chainId, bytes calldata data);
```diff
---
## The Flow: Encrypted Order Execution
### Step 1: User Submits Preference
```python
# User creates preference
preference = {
"type": "swap",
"token_in": "USDC",
"amount_in": 10000,
"token_out": "ETH",
"min_amount_out": 5.5,
"mev_share": 0.5 # Get 50% of MEV created
}
# Encrypt for registered Kettles
encrypted = encrypt(preference, kettle_pubkeys)
# Submit to SUAVE chain
suave_chain.submit_preference(encrypted)
```text
## Step 2: Kettles Process Inside Enclaves
```python
# Inside Kettle's SGX enclave (no one can see this)
async def process_slot(self, preferences: list[bytes]):
decrypted = [decrypt(p) for p in preferences]
# Find MEV opportunities
mev = self.find_mev(decrypted)
# Distribute according to mev_share
for pref, value in mev:
user_share = value * pref["mev_share"]
kettle_share = value * (1 - pref["mev_share"])
# Build optimal block
block = self.build_block(decrypted, mev_distribution)
return block, proof_of_honest_execution
```text
## Step 3: Block Submitted to Target Chain
```python
SUAVE → Finalized Block → Ethereum
(with MEV fairly distributed)
```bash
---
## How SUAVE Changes MEV
| Current PBS | SUAVE |
|------------|-------|
| Users trust builders | Builders run attested code |
| Builders see plaintext | Builders see encrypted preferences |
| MEV goes to builders | MEV shared with users |
| Centralized building | Decentralized Kettle network |
| Single chain | Cross-chain block building |
### MEV Redistribution
```yaml
Current:
User submits tx → Builder extracts $100 MEV → Validator gets $90
→ Builder keeps $10
→ User gets $0
SUAVE:
User submits preference (50% share) → Kettle finds $100 MEV
→ User gets $50
→ Kettle/Validator split $50
```diff
---
## Infrastructure Implications
If you're operating SUAVE infrastructure:
### TEE Requirements
```yaml
# SUAVE Kettle requirements
hardware:
- Intel SGX (or AMD SEV-SNP, or ARM TrustZone)
- DCAP attestation support
- EPC memory sized for your workload (SGX EPC is hardware-limited; verify current Kettle specs)
software:
- SUAVE node (modified Geth + TEE runtime)
- Remote attestation service
- Encrypted networking (mTLS with attestation)
```text
## Monitoring for Kettles
```python
# Key metrics for Kettle operators
metrics = {
"enclave_health": gauge("kettle_enclave_healthy"),
"preferences_processed": counter("preferences_processed_total"),
"attestation_failures": counter("attestation_failures_total"),
"mev_extracted": gauge("mev_extracted_gwei"),
"block_building_latency": histogram("block_building_latency_ms"),
}
```diff
---
## Practice Exercises
### Exercise 1: Trust Model Analysis
```python
Compare trust assumptions:
1. Current PBS (MEV-Boost + Relays)
2. SUAVE with Kettles
For each, answer:
- Who can censor transactions?
- Who can extract MEV?
- What happens if the operator is malicious?
```text
### Exercise 2: Cross-Chain Block Building
```yaml
SUAVE enables block building across chains.
Design:
- User wants to arb ETH between Ethereum and Arbitrum
- Preference: "Buy on cheaper, sell on expensive, share 30%"
How does SUAVE process this atomically?
```text
### Exercise 3: Kettle Deployment
```text
You're deploying a SUAVE Kettle for a trading firm.
Requirements:
- SGX-enabled bare metal
- <10ms latency to SUAVE chain
- High availability
Design the infrastructure. Consider:
- Hardware selection
- Geographic placement
- Failover strategy
Key Takeaways
- PBS centralized building - Exclusive orderflow created moats
- SUAVE decentralizes it - TEE-enabled Kettles replace trusted builders
- Encrypted preferences - Users don’t reveal transactions to anyone
- MEV redistribution - Users can claim share of MEV they create
- DevOps angle - Operating Kettles requires TEE expertise
What’s Next?
- MEV-Boost & Relay Architecture - prerequisite context
- The 100ms Tax - deep dive
- Robert Miller: The Future of MEV is SUAVE - talk from Flashbots
Want to go deeper?
Weekly infrastructure insights for engineers who build trading systems.
Free forever. Unsubscribe anytime.
You're in. Check your inbox.
Questions about this lesson? Working on related infrastructure?
Let's discuss