From TEEs to ZK: The Pragmatic Path to the Rollup Future Is Conditional Settlement

In the race to evolve blockchains, two technologies have emerged as the foundation for rollup pessimistic security: Zero-Knowledge proofs and Trusted Execution Environments, both offering very different tradeoffs. ZK proofs promise cryptographic finality, but they’re expensive, complex, and slow to evolve. TEEs offer a faster, more flexible alternative, one that’s already practical today — but they rely on trusted hardware and remain vulnerable to vendor compromise and side-channel attacks, making proper safeguards essential.

While many rollup networks, including Dymension, currently rely on optimistic designs, the shift toward more verifiable rollup execution is already underway. This article explores how TEEs and ZK proofs compare across security, performance, and usability — and makes the case that TEEs, when combined with conditional settlement rules, are a pragmatic stepping stone toward the ZK-powered future. They’re not the endgame, but they may be the bridge that gets us there. And while this article explores the current viability of TEEs and ZK proofs in the rollup ecosystem, it also examines a deeper point: none of it matters if control over the bridge remains centralized. Rollup ecosystems must embed L1-level custody into the bridge design like Dymension or offer an alternative solution to maintain non-custodial settlement at the bridge layer.

Security Models and Trust Assumptions

Zero-Knowledge Proofs

ZK rollups rely on strong cryptographic assumptions. The rollup state transitions are expressed as arithmetic circuits or programs, and a prover generates a proof (e.g., a SNARK or STARK) that the new state is correct given the previous state and the batched transactions. Every validator (or an on-chain verifier contract) can verify this proof quickly, which eliminates the need to trust the sequencer for correctness – the math ensures invalid state updates are rejected. The trust assumptions for ZK proofs include the soundness of the cryptographic scheme (e.g., hardness of certain math problems) and the correctness of the implementation (circuit and prover). If those hold, even a malicious sequencer cannot push through an invalid state. However, bugs in the proof system or circuits are a concern; a flaw could be exploited to produce an incorrect proof that still verifies. In fact, a vulnerability was found in one ZK-rollup (zkSync Era) that could have put nearly $1.9B at risk – demonstrating that software bugs in complex ZK circuits or proving systems are a systemic risk. Aside from such bugs, ZK rollups are trustless in terms of state correctness: no additional trusted party is needed once the proofs are verified. (Some ZK systems do require a trusted setup ceremony for parameters, but newer proofs avoid this.)

Trusted Execution Environments

A TEE-based rollup sequencer shifts trust from cryptography to hardware-backed execution. Code runs inside a secure enclave (e.g., Intel SGX or AMD SEV-SNP) and produces a signed attestation that proves a specific binary was executed. In rollups, this lets the sequencer attest to correct transaction execution, and on-chain logic verifies the enclave’s measurement and signature before accepting the new state root.

However, TEE security depends on several assumptions. Enclave-based TEEs like SGX isolate execution at the CPU level and protect against host tampering, but VM-based TEEs like SEV-SNP and TDX rely on the hypervisor and boot process. This opens the door to memory remapping, stale state injection, or boot-time manipulation, even if the code itself is correct.

Importantly, TEEs prove what code ran — not whether the inputs were honest. If the enclave accepts host-provided state or transactions without cryptographic validation (e.g., Merkle proofs), it can be tricked into signing false results. Attestation alone does not protect against this.

Finally, TEE trust is rooted in the hardware vendor — Intel or AMD — and their ability to secure keys, firmware, and supply chains. In this model, the TEE acts as a “black box” prover: execution is trusted because the chip says it happened, unlike ZK rollups where correctness is mathematically proven.

TEEs can still offer value when combined with other mechanisms, such as input commitment schemes, multi-TEE quorums, or vendor diversity — but they do not eliminate the need for careful threat modeling.

Proving, Finality, and Throughput

One of the main advantages of TEEs over ZK proofs is performance. Generating ZK proofs—especially for complex workloads like zkEVMs—is computationally expensive, often taking seconds to minutes per batch and requiring specialized hardware or parallelization. On-chain verification is also costly—verifying a SNARK on Ethereum can cost hundreds of thousands of gas (tens of dollars), and STARKs typically cost more. Proving complexity often leads to centralization, as only a few nodes are equipped to generate these proofs at scale.

In contrast, TEE-based rollups execute transactions directly in a secure enclave, without needing to generate cryptographic proofs. The sequencer simply computes the post-state inside the TEE at near-native speed, and produces a signed attestation confirming the result. This attestation is lightweight and fast to verify on-chain—typically just a signature check or a short proof tied to a trusted enclave measurement. A recent prototype showed that TEE-based rollups can reduce on-chain verification costs by ~86% compared to zk-based systems.

This architectural difference enables near-instant finality in TEE rollups. Unlike optimistic rollups (which wait for a challenge period) or ZK rollups (which wait for a proof to be generated and submitted), TEE-based systems can finalize a batch as soon as the attestation is available—often within seconds of execution—assuming enclave integrity.

In terms of throughput, both ZK and TEE rollups can process high volumes, but they scale differently. ZK rollups are constrained by how fast they can generate proofs, which creates a trade-off between throughput, latency, and cost. Larger batches increase throughput and reduce cost per transaction by amortizing proof overhead, but they also introduce higher latency and slower finality. Smaller batches improve responsiveness but require more frequent proof generation, which increases cost and can lower effective throughput unless prover speed scales accordingly. TEE rollups, by contrast, are bottlenecked primarily by how quickly the enclave can execute state transitions. They avoid the proving bottleneck entirely and operate closer to real-time, executing transactions inside a secure enclave at near-native CPU speed. Modern CPUs with TEEs (like Intel TDX or AMD SEV-SNP) can handle thousands of transactions per second, especially with larger secure memory regions and full VM support. A single high-end TEE server can likely match or exceed the throughput of current ZK rollup provers—without incurring the same latency or infrastructure complexity.

Developer Flexibility and Compatibility

One area where TEEs shine is flexibility of computation. They can execute general-purpose logic — including EVM or WASM runtimes — without requiring custom circuits, making them far more accessible than ZK-based systems. Developers can often reuse existing rollup frameworks, VM interpreters, or smart contract engines with minimal modification. This dramatically lowers the barrier to launching new rollups or updating existing logic, especially when compared to building and maintaining a zkEVM.

However, running a full EVM Rollapp inside a TEE is not plug-and-play. Practical limitations include secure memory constraints (especially in SGX), syscall restrictions, and the need to defend against side-channel attacks. In VM-level TEEs like AMD SEV-SNP or Intel TDX, developers must also be aware of host-controlled memory mappings — which means the enclave must explicitly validate all inputs and avoid relying on host-supplied pointers to ensure execution integrity. This requires careful architecture design, particularly around state access and transaction batching.

By contrast, implementing an EVM in a ZK circuit is a massive engineering effort — often requiring deep trade-offs between compatibility and prover efficiency. ZK rollups must translate EVM semantics into custom circuits, which limits upgrade agility and often introduces long iteration cycles. With TEEs, rollups can deploy upgraded logic (via updated enclave measurements or sealed state migrations) far more easily — though this still requires secure governance to avoid unauthorized logic changes.

Comparison Table: TEE vs ZK in Rollup Sequencers

The Path Forward: Conditional Settlement Rules

In rollup terms, TEEs enable that fast-path experience: quick execution and confirmation for most use cases. But when a state update exceeds a risk threshold (like unlocking significant funds), a ZK proof can step in as the "manager's approval" — cryptographically verifying the correctness before settlement is finalized.

In hybrid rollup designs where TEEs serve as the main attestation layer, ZK proofs can act as a fallback — but not always for everything. A more nuanced model allows for conditional settlement rules on the L1 settlement logic:

• For standard transactions or withdrawals below a defined threshold, a valid TEE attestation is enough.
• But for higher-risk operations — such as unlocking large amounts of funds from escrow — the system could require a ZK proof in addition to (or instead of) the TEE proof.

This conditional design ensures that:

• The rollup can settle quickly and cheaply under normal operation.
• Sensitive state transitions get cryptographic validation when the stakes are higher.

A useful analogy is how transaction approvals work at a bank. For small transfers, your request is processed instantly — no manager needs to sign off. But when the amount exceeds a certain threshold, the system requires extra scrutiny, perhaps a manager's approval. In rollup terms, TEEs enable that fast-path experience: quick execution and confirmation for most use cases. But when a state update exceeds a risk threshold, a ZK proof can step in as the "manager's approval" — cryptographically verifying correctness before finality.

Such thresholds can be encoded in the L1 verifier logic, making the ZK layer selectively engaged based on transaction value or type. This enables fast paths for low-value UX and ZK-enforced security when it matters most.

Final Thoughts: A Converging Path — With a Crucial Caveat

ZK rollups represent the theoretical endgame for trust-minimized infrastructure: their security is rooted entirely in cryptography, and their proofs can be verified independently by anyone. But today, they remain complex, costly to prove, and limited in terms of general-purpose privacy or off-chain data access.

TEEs offer a compelling, practical step forward — enabling fast execution, rich privacy, and oracle integration. While they rely on hardware trust, their limitations can be mitigated through multi-TEE setups, diversity of vendors, and cryptographic attestation verification.

Rather than competing paradigms, TEEs and ZK proofs are increasingly seen as complementary. In practice, rollups may adopt conditional settlement, using TEEs to accelerate execution and support private computation, while relying on ZK proofs as a fallback or for final settlement when stronger guarantees are needed.

The long-term future may be ZK-proven everything — but TEEs is how we get there, securely and efficiently, today.

However, neither TEE attestations nor ZK proofs offer true security if the bridge contract itself is custodial. In other words, a perfectly valid state proof is meaningless if a centralized bridge can still override outcomes. The endgame must include a non-custodial bridge design, where settlement logic is entirely governed by verifiable proofs and on-chain enforcement — not by privileged parties.