TEEs and BAM: Secure Block Building in Practice

A core technical pillar of the Block Assembly Marketplace (BAM) is the use of Trusted Execution Environments (TEEs).

Researchers and academics have been theorizing about the use of TEEs in blockchain architecture since at least 2016, and the technology is borderline ubiquitous in many contemporary devices (there are TEEs in all iPhones since 2013). Although TEEs have been used in other blockchain contexts, BAM will be among the first large-scale implementations of this technology in a high-performant ecosystem like Solana, which naturally raises questions about TEE’s specifications. 

This blog post explains what TEEs are, why BAM uses them, how they compare to other possible privacy-preserving technologies, and then analyzes TEEs through the lens of blockchain security.

What are TEEs?

In simple terms, TEEs are specialized computer chips that allow a system to perform computational functions that – crucially – the rest of the system cannot monitor. 

TEEs provide four fundamental security properties:

• Confidentiality: Memory contents remain encrypted, inaccessible to the host
• Integrity: Cryptographic protection against code or data tampering
• Attestation: Verifiable cryptographic proof of the execution environment's state
• Isolation: Hardware-enforced separation from the host OS and hypervisor

What does BAM do inside TEEs?

BAM seeks to deliver privacy-enabled, verifiable and programmable block building on Solana. It does so by leveraging BAM Nodes, a network of schedulers that run inside confidential virtual machines secured by AMD SEV-SNP, latest-model AMD TEEs that provide the performance and security needed for high-throughput, low-latency block building on Solana. 

Within these isolated environments, BAM’s code and transaction data are shielded from tampering by the host system, operators, or external actors. These nodes receive transactions (either from RPCs, applications or users directly), order them using an internal, customizable scheduler, and send them as a package to validators in the leader queue for execution. The TEEs ensure that transactions remain private before being sent to validators, reducing the attack vectors for malicious MEV.

Additionally, TEEs creates attestations of transaction ordering, that can detect tampering from validators downstream. Think of attestations like a notarized certificate for software. Just as a notary confirms a document is authentic and unaltered, TEE attestations provide cryptographic proof that the BAM Node is running specific, audited code. Validators can check this certificate to verify they're talking to legitimate BAM software, not a modified version.Even if an operator’s system were compromised, the enclave prevents them from altering execution or accessing transaction data; ensuring BAM’s security model rests on hardware-backed cryptography and transparent verification rather than fully trusting operators. While no hardware is immune to all potential vulnerabilities, TEEs like AMD SEV-SNP substantially raise the bar by making software-level or physical attacks highly impractical in real deployments.

Why TEEs?

For BAM, four approaches were evaluated: TEEs, MPC (Multi-Party Computation), FHE (Fully Homomorphic Encryption), and ZKPs (Zero-Knowledge Proofs). Each technology has certain theoretical guarantees and optimal use cases, which were measured against BAM’s requirements.

Review of those options made clear that AMD SEV-SNP TEEs were the only option that make real-time, verifiable block building on Solana feasible today and in the near future by making the right tradeoffs between security and performance. A valuable resource that compares these technologies is Flashbots’ Zero Trust Execution environments.As Flashbots researchers have written, TEEs are currently the worst they’ll ever be. As technology evolves, and different primitives improve their capabilities, BAM will stay at the cutting edge of innovation, potentially layering additional technologies together for complementary guarantees if necessary.

Learning from History: SGX vs. SEV-SNP

Many concerns about physical attacks on TEEs stem from Intel SGX, an older technology where the operating system and hypervisor remain untrusted actors that can actively interact with the protected code. SGX isolates individual processes in small "secure enclaves," but leaves page tables, scheduling, and system interrupts under OS control. This architectural choice creates multiple well-known attack surfaces.

AMD SEV-SNP and Intel TDX represent a fundamentally different approach: they protect entire virtual machines rather than individual processes. The VM's operating system, applications, memory, and execution state all exist within an encrypted, integrity-checked boundary that the hypervisor cannot penetrate. The hypervisor becomes an external entity that can manage resources but cannot observe or manipulate the protected environment. SEV-SNP strengthens this model further with a dedicated security processor (the AMD PSP) that manages encryption and attestation operations independently from the main CPU, placing critical security functions beyond the reach of even a compromised hypervisor.

Recent research has demonstrated physical hardware attacks, such as Battering RAM, that can compromise memory encryption by physically installing devices between the CPU and RAM. However, these attacks require direct physical access to servers—a threat vector that datacenter operators address through physical security controls, supply chain verification, and hardware attestation. Both Intel and AMD consider such physical attacks outside the scope of their threat models, which focus on software-level compromises. BAM's security model similarly focuses on software-level threats where the hypervisor or host OS is compromised, which SEV-SNP defends against.

Mitigating Physical TEE Attacks

With attacks like the Battering RAM exploit bringing renewed attention to TEEs and their potential for physical tampering, it’s important to separate theory from reality. Scenarios where someone gains direct access to a server to probe or modify enclave memory are possible in theory but highly impractical in practice, given the prevailing security guarantees.

BAM Nodes will run in geographically distributed, enterprise-grade data centers. For example, the current early set of BAM Nodes run in Teraswitch data centers, which operate under strict compliance regimes (such as SOC 2, ISO 27001, HIPAA, PCI 27001). These facilities enforce 24/7 monitoring, multi-factor access, mantraps, and escort-only entry, which makes “walking up and tampering with a server” infeasible.

BAM will be compatible with the other leading data centers which today support the majority of Solana stake, while ensuring that the same security and compliance standards are maintained. Leveraging this network of facilities will contribute to Solana's decentralization, as BAM will have a much larger global footprint than the Jito Block Engine, without imposing additional requirements on validators.

What are the risks?

Despite the attack surface being extremely low, it’s worth answering: What’s the worst case scenario if one of BAM’s TEEs gets compromised?

A key consideration to keep in mind is that given the number of unique BAM Nodes that will exist globally (potentially in the hundreds), any compromise to an individual node would have no impact on the rest of the network, as these nodes don’t share information amongst each other and validators connect to only one node at a time.

In the case that a node is compromised, one outcome is that transaction privacy through that node would be lost, increasing the likelihood of frontrunning or sandwiching in blocks it produces. This would simply represent a reversion to the status quo for that specific node, where none of BAM’s assurances apply. In addition, such behavior will be detectable through analysis of transaction sequencing  patterns in those blocks, allowing validators to disconnect from the compromised node once identified.

Another risk is that validators connected to the compromised node would lose connectivity to it and would stop receiving new transactions. In this case, the validator could fallback to another node or one of the Jito-Solana, Agave or Firedancer clients (once this integration is in place) and continue processing transactions as usual.

Closing Thoughts

By using AMD SEV-SNP TEEs, BAM has a robust foundation to deliver low-latency, high-throughput block building with verifiable guarantees of integrity and confidentiality, crucial to provide the best on-chain execution environment for institutions, retail users and decentralized applications alike.

Like any technology, TEEs will keep evolving, and BAM will stay at the forefront of innovations to deliver improvements and make the network more performant and resilient. BAM’s use of TEEs is about making the right tradeoffs: secure enough to withstand realistic threats, efficient enough to deliver efficient block-building at scale, and verifiable enough that trust is anchored in cryptography rather than operator reputation.