Why MEV Block Building Infrastructure Is Moving to TDX Bare Metal

Block builders occupy a structurally awkward position in Ethereum’s transaction supply chain. They see sensitive orderflow from searchers before those bundles are committed to a block. Searchers, reasonably, want some guarantee that builders aren’t reading their strategies and front-running them. For most of Ethereum’s history, that guarantee has been reputational: trust that the builder won’t cheat, because cheating destroys the relationships they depend on. That works until it doesn’t. Hardware-enforced isolation changes the trust model in a way that reputation can’t.

The Operator Trust Problem

Proposer-builder separation (PBS) introduced a cleaner division of labor into Ethereum’s block production. Validators propose blocks but don’t build them. Builders aggregate transactions and bundles from searchers, assemble the most valuable block possible, and submit it to a relay. The relay forwards the best block to the validator, who signs it without seeing the contents in advance.

The relay itself is another trust point. It needs to verify that the block is valid and worth what the builder claims, without leaking the contents to the validator before the commitment is final. Every step in this chain involves parties handling economically sensitive data they’re not supposed to act on.

Software-only solutions to this problem have limits. You can audit code, publish it, and promise not to run modified versions. You can use legal agreements and reputation. But a motivated operator with access to the machine running the builder software can, in principle, do things the published code doesn’t. Hardware-enforced isolation removes that possibility from the threat model.

This is exactly the problem Trusted Execution Environments (TEEs) were designed for.

Why Software-Level Isolation Is Not Enough

A TEE creates a hardware-isolated execution environment where code and data are encrypted and protected from the host operating system, hypervisor, and anyone with physical access to the machine. Two properties matter most for MEV infrastructure.

The first is memory encryption. Inside a TEE, memory contents are encrypted with keys managed by the CPU. The host OS cannot read or modify the in-use memory of a workload running inside a trust domain, regardless of privilege level.

The second is remote attestation. A TEE can produce a cryptographic proof that a specific piece of code is running, with specific measurements, on genuine hardware with a valid trust chain back to the chip manufacturer. This means a searcher can verify, before sending orderflow, that the builder is actually running the code they claim to be running and not a modified version.

The trust assumption shifts from “trust the operator’s word” to “trust that Intel’s attestation chain is intact and the loaded code matches the audited measurement.” That’s a meaningful reduction in required trust.

Why Block Builders Moved from SGX to TDX

The first generation of TEE-based MEV infrastructure ran on Intel SGX. Flashbots began moving block building and orderflow auction infrastructure into SGX in 2023. SGX works, but it has a significant operational constraint: it requires partitioning application code into enclave and non-enclave portions. Complex software has to be restructured to run inside SGX, which introduces engineering overhead and limits what can be protected.

Intel TDX takes a different approach. Instead of protecting individual application components, TDX isolates an entire virtual machine. A standard Linux VM runs inside an encrypted Trust Domain. The host OS and hypervisor cannot access its memory. The guest doesn’t require modification to gain TDX’s protection.

For block building software, this is the practical difference. Rbuilder, the Rust-based block building engine at the core of Flashbots’ BuilderNet, is a complex piece of software managing transaction simulation, bundle merging, and block assembly. Running it inside an SGX enclave would require significant rearchitecting. Running it inside a TDX VM means deploying it on compatible hardware and booting the VM. The software itself doesn’t change.

Flashbots’ published roadmap describes this shift explicitly. Their SUAVE infrastructure began with SGX-based components and has moved toward TDX for the full VM isolation it provides. BuilderNet, their production block building network, runs as TDX VM images rather than Docker containers.

BuilderNet Shows What Production Looks Like

BuilderNet is the clearest evidence that TDX-based block building is production infrastructure, not a research prototype. Launched in November 2024 and jointly operated by Flashbots, Beaverbuild, and Nethermind, BuilderNet is now responsible for building roughly 30% of Ethereum blocks.

The technical architecture is specific about its hardware requirements. BuilderNet nodes run as full Linux TDX VM images built with Yocto, in VHD format. They require TDX-capable hardware: either cloud-based TDX confidential VMs or Intel Xeon Scalable hardware with TDX support. The nodes are not containers. The isolation is at the VM level.

The trust model works through attestation. Every BuilderNet node generates its TLS certificates inside the TEE. The private key never leaves the trust domain. Users who want to verify they’re sending orderflow to a genuine BuilderNet node can validate the attestation before establishing a connection. BuilderNet supports fully reproducible TDX image builds, meaning anyone can build the node image from source and verify that the resulting TDX measurements match what’s running in production.

This is what hardware trust looks like in practice. The operator cannot modify the running code without changing the attestation measurements. Searchers can verify the measurements before trusting the node with their bundles.

What Bare Metal Adds That Cloud TDX Doesn’t

BuilderNet currently runs on both cloud TDX instances and bare metal hardware. But the two have meaningfully different trust properties, and the difference matters for infrastructure teams who care about the full attestation chain.

When a TDX workload runs on a cloud provider’s infrastructure, the attestation chain proves the CPU is genuine and the TD’s memory is protected. What it doesn’t prove is anything about the physical environment above the CPU. The cloud provider controls the physical hardware, the BIOS, the firmware, and the TPM provisioning process. None of that is covered by TDX attestation alone.

This is the “physical-access gap” that Flashbots researchers described in an April 2026 paper. Their DCEA protocol attempts to close it by binding TDX attestation together with a hardware TPM measurement, establishing that the workload is running on specific known infrastructure, not just on some TDX-capable machine somewhere in a shared data center. The paper notes that bare metal providers including OpenMetal are exploring these configurations precisely because bare metal eliminates the shared physical layer that creates the gap in the first place.

On bare metal, the TDX attestation chain goes from the CPU to Intel’s attestation service without a cloud provider hypervisor in the path. There’s no shared physical layer to trust. The operator running the bare metal server is the same party attesting to the hardware. For infrastructure teams who want to minimize the number of entities in the trust chain, single-tenant bare metal is a meaningful step beyond shared cloud TDX.

There are also practical performance considerations. Block building is latency-sensitive. Timing matters for PBS: a builder who assembles a more valuable block a few hundred milliseconds too late loses to a faster competitor. Shared cloud infrastructure introduces scheduling variability that bare metal doesn’t. On dedicated hardware, every CPU cycle and every network path is available to the block building software without competition from neighboring tenants.

The Same Problem Applies to L2 Sequencers

The operator trust problem in MEV is essentially the same problem that rollup sequencers face, and TEE-based solutions are moving into sequencer infrastructure for the same reasons.

A centralized L2 sequencer orders transactions before they’re submitted to the base layer. In that window, the sequencer operator can front-run users, reorder transactions for profit, or censor specific addresses. The fix for this is either decentralized sequencing (complex, adds latency, still being worked out across most rollup designs) or a TEE-based sequencer that can prove it ordered transactions according to a published rule without operator interference.

Flashbots is already moving in this direction. The Introducing BuilderNet post notes that BuilderNet will be available as a drop-in solution for decentralized sequencing on L2s through Rollup-Boost. The infrastructure requirements overlap substantially with block building: TDX VMs, attestation, reproducible builds, dedicated hardware with predictable latency.

For operators running sequencer infrastructure, the hardware requirements are the same. TDX-capable CPUs, sufficient RAM to meet TDX’s full channel population requirement, dedicated networking with consistent latency, and ideally a bare metal environment where the attestation chain is as short as possible.

What TDX Infrastructure Actually Requires

TDX has a specific hardware requirement that’s worth understanding clearly: all memory controller channels must have at least one DIMM slot populated. Intel’s implementation requires full IMC channel population to activate TDX. That requirement isn’t about a specific RAM capacity number; it’s about the memory subsystem configuration.

OpenMetal’s TDX-capable servers satisfy this requirement at their base configurations. The XL v4 ships with 1TB DDR5-4800 across 16 DIMM slots on a two-socket Emerald Rapids platform, with all IMC channels populated. The XL v5 ships with 1TB DDR5-6400 on a two-socket Granite Rapids platform in the same configuration. Both are TDX-active out of the box. Neither requires a RAM upgrade or special configuration to enable TDX.

The 1TB capacity at these configurations is not arbitrary. Running multiple Trust Domains concurrently (the typical production use case for block building, where multiple instances handle different orderflow streams) carries per-TD overhead for encrypted page table metadata and integrity tracking. At lower RAM, this overhead becomes a larger fraction of available capacity. At 1TB across two sockets, production multi-TD workloads run reliably.

The network requirements are also specific to this workload. Block building software needs to receive orderflow from relays and external sources, communicate with other builder nodes over encrypted channels, and submit finished blocks to relays with minimal latency. OpenMetal’s infrastructure includes 20 Gbps of private bandwidth per server (with the option to upgrade to 40 Gbps) and dedicated customer VLANs, which keeps inter-node traffic off shared network segments.

FAQ

What is the difference between Intel SGX and Intel TDX for block building?

SGX protects specific application components by partitioning code into enclave and non-enclave portions. TDX protects an entire VM, so block building software runs unmodified inside a hardware-isolated trust domain. For complex software like block builders, TDX is far easier to deploy and doesn’t require rearchitecting the application.

Does BuilderNet require bare metal hardware?

BuilderNet nodes run on TDX-capable hardware, which includes both cloud-based TDX confidential VMs and bare metal servers with TDX-capable CPUs. Bare metal provides a shorter attestation chain (no cloud provider hypervisor layer) and more predictable performance, which matters for latency-sensitive block building work.

What RAM is required to run TDX workloads?

Intel TDX requires all IMC memory channels to have at least one DIMM populated, not a specific capacity. On OpenMetal’s XL v4 and XL v5 servers, TDX is active at the base 1TB configuration because all channels are already fully populated at that configuration. Operators running multiple confidential VMs concurrently benefit from the additional headroom 1TB provides.

Can OpenStack manage TDX Trust Domains?

No. TDX Trust Domains are a bare metal feature. OpenStack Nova does not manage TDX workloads. Operators running TDX block building or sequencer infrastructure deploy directly on bare metal, outside the OpenStack layer.

Is this infrastructure relevant to L2 sequencers as well as Ethereum block builders?

Yes. The operator trust problem is structurally similar: a sequencer operator orders transactions in a window where they could extract value or censor addresses. TEE-based sequencers use the same hardware primitives (TDX VMs, remote attestation, reproducible builds) to prove that ordering followed a published rule without operator interference. Flashbots’ Rollup-Boost project is explicitly designed to bring this approach to L2 sequencing.

For teams evaluating confidential computing infrastructure for MEV, sequencer, or other trust-sensitive blockchain workloads, start with OpenMetal’s confidential computing infrastructure page or apply for a proof of concept to test TDX workloads on XL v4 or XL v5 hardware.