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.

---

What You’ll Learn

By the end of this lesson, you’ll understand:

1. Why PBS centralized - The economic forces that created builder monopolies
2. SUAVE architecture - MEVM, Kettles, and the SUAVE chain
3. The encrypted mempool - How TEEs enable private orderflow
4. Migration path - How SUAVE replaces current MEV-Boost

---

The Foundation: 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

Exclusive Orderflow

The real moat is private transaction flow:

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

This is a permissioned network inside a permissionless blockchain.

---

The “Aha!” Moment

Here’s what makes SUAVE different:

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

┌─────────────────────────────────────────────────────────────────┐
│                         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                           │
└─────────────────────────────────────────────────────────────────┘

---

Key Components

1. Preferences (User Intents)

Users don’t submit transactions; they submit preferences-higher-level intents encrypted for Kettles:

// 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
  }
})

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

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

3. MEVM (Modified EVM)

SUAVE runs a modified EVM with new precompiles for:

// 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);

---

The Flow: Encrypted Order Execution

Step 1: User Submits Preference

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

Step 2: Kettles Process Inside Enclaves

# 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

Step 3: Block Submitted to Target Chain

SUAVE →  Finalized Block  → Ethereum
         (with MEV fairly distributed)

---

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

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

---

Infrastructure Implications

If you’re operating SUAVE infrastructure:

TEE Requirements

# SUAVE Kettle requirements
hardware:
  - Intel SGX (or AMD SEV-SNP, or ARM TrustZone)
  - DCAP attestation support
  - Minimum 64GB EPC memory

software:
  - SUAVE node (modified Geth + TEE runtime)
  - Remote attestation service
  - Encrypted networking (mTLS with attestation)

Monitoring for Kettles

# 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"),
}

---

Practice Exercises

Exercise 1: Trust Model Analysis

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?

Exercise 2: Cross-Chain Block Building

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?

Exercise 3: Kettle Deployment

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

1. PBS centralized building - Exclusive orderflow created moats
2. SUAVE decentralizes it - TEE-enabled Kettles replace trusted builders
3. Encrypted preferences - Users don’t reveal transactions to anyone
4. MEV redistribution - Users can claim share of MEV they create
5. DevOps angle - Operating Kettles requires TEE expertise

---

What’s Next?

🎯 Prerequisite review: MEV-Boost & Relay Architecture

🔬 Deep dive: The 100ms Tax

📺 Watch: Robert Miller: The Future of MEV is SUAVE

Now you understand the future of decentralized block building. 🚀