TEEs vs E3s: Two Approaches to Secure Computation

Trust is shaped as much by computation as it is by culture. As governance, cognition, and economic coordination become increasingly computational, trust is shifting from institutional reputation to verifiable systems, cryptographic proofs, and algorithmic enforcement. Ensuring technical and systemic trust isn’t just about protecting data and preventing breaches; it’s about building infrastructure that enables new forms of collaboration, governance, and intelligence.

Trusted Execution Environments (TEEs) have become the standard for securing sensitive computation, but their reliance on hardware-based security guarantees fundamentally limits their application. Our team has built Encrypted Execution Environments (E3s) as both an alternative and complement to TEEs, enabling secure, multi-party computation that is private, provable, and deployable on any machine. Where TEEs embed trust in hardware attestations, E3s distribute it cryptographically.

Below, we unpack these execution environments, their strengths and limitations, and the contexts in which they are most optimally deployed.

TEEs: Embedded Hardware Trust

TEEs isolate sensitive computation within specialized hardware, providing an execution space within processors. By running computation in dedicated hardware, TEEs protect data integrity and execution from external tampering, even by the host system. This approach is fundamentally hardware-dependent, meaning security is rooted in attestations from vendor supply chains.

Advantages of TEEs:

• Relatively Low Overhead: TEEs decrypt data locally and operate on plaintext, resulting in minimal computational and latency overhead.
• Ecosystem Maturity: TEEs benefit from established tooling and integration pathways that support fast deployment and development.
• Regulatory Compliance: Hardware-based security is verifiable and typically aligned with existing compliance frameworks.
• Global Infrastructure Support: TEEs are widely supported by major cloud providers and device manufacturers, making adoption and deployment easier.
• Standards Alignment: Many TEEs conform to established security certification standards.

Risks & Limitations of TEEs:

• Plaintext Decryption: TEEs require plaintext data to be decrypted in CPU registers, making them susceptible to various side-channel attacks.
• Single Points of Failure: Centralized hardware dependencies create single points of failure tied to supply chains and geopolitical influences, with numerous documented vulnerabilities.
• Closed Source & Hardware Trust: Security audits and transparency are limited, as TEEs are often closed-source, requiring trust in vendors.
• Specialized & Expensive Hardware: TEEs can only be run on specialized hardware such as Intel TDX-enabled CPUs and AMD SEV-SNP-enabled CPUs, with limited support on edge devices. These types of servers are much more expensive and are mostly available on large cloud platforms, limiting the democratization of compute.
• Complexity & Scalability: TEEs require the use of complex attestation protocols that introduce large overhead when scaling to large systems. Any communication between TEEs and other sources requires attestation.

Despite associated risks and limitations, TEEs remain the most widely used solution for secure computation in organizations today. Examples include Intel SGX, Amazon Nitro Enclaves, and Apple’s Secure Enclave, underpinning protocols such as Oasis Network, Secret Network, Near Protocol, and Fireblocks.

E3s: Distributed and Programmable Trust

Unlike TEEs, which rely on attestation-based hardware security, we designed E3s to distribute trust through programmable cryptography and decentralized coordination. This architecture keeps data encrypted even during computation, significantly reducing centralized security risks. E3s can also be deployed flexibly across different machines and infrastructures, offering a modular and open-source alternative to TEEs.

How E3s Work:

E3s use a composable approach to secure computation, combining:

• Fully Homomorphic Encryption (FHE) to compute on encrypted data without decryption.
• Zero-Knowledge Proofs (ZKPs) for verifiable, privacy-preserving computation.
• Distributed Threshold Cryptography (DTC) to ensure no single entity holds a full decryption key.
• Blockchain-based (dis)incentives for strong economic guarantees of data privacy.

This modular cryptographic framework allows organizations to configure security parameters, such as compute bonds, node distribution, and threshold settings, depending on their needs. (For a high-level overview of how E3s work, see this explainer.)

Advantages of E3s:

• Continuous Encryption: Data remains encrypted at every computation stage – even during computation — minimizing exposure risks.
• Mathematical Security Guarantees: Security relies on lattice-based cryptography, not hardware vendors, and is believed to resist future quantum attacks, including those aimed at harvesting encrypted data for later decryption.
• Distributed Trust: No single node holds decrypted data, reducing vulnerabilities through a decentralized architecture.
• Provable Integrity: Computations and outcomes can be cryptographically verified, ensuring correctness and accountability.
• Modular Deployment: Compatible with various encryption schemes and infrastructures, allowing customization based on workload.
• Open Source & Auditable: Unlike current-generation TEEs, E3s can be fully audited, ensuring transparency and verifiable security.
• Economic Security Mechanisms: E3s includes staking mechanisms, proportional fees, and punitive measures to reinforce security and reliability.

Risks & Limitations of E3s:

• Computational Overhead: Encrypted computation introduces performance costs, potentially challenging real-time or latency-sensitive applications. (Note: ongoing advances in GPU- and ASIC-based accelerators are expected to reduce this overhead.)
• Latency Issues: Certain cryptographic operations, especially in multiparty settings, may introduce delays in high-throughput environments.
• Scalability Constraints: Intensive cryptographic processes might pose scalability challenges for extensive applications or large datasets.
• Integration Considerations: E3-based systems introduce new trust models and coordination patterns that may require shifts in infrastructure or workflows, depending on the application.
• Ecosystem Maturity: Tooling and developer infrastructure for programmable cryptography (FHE, MPC, ZKPs) is still evolving, with fewer standardized frameworks than those supporting TEEs.

Toward Hybrid Computation Environments

TEEs and E3s reflect a philosophical divergence in how they enforce trust. TEEs establish trust through centralized, hardware attestation, reinforcing traditional structures that assume controlled environments and vendor oversight. E3s, by contrast, rely on decentralized, cryptographic proofs of correctness, aligning with emerging societal preferences for collective governance, transparency, and distributed accountability.

Acknowledging their complementary strengths can lead to hybrid models where both TEEs and E3s coexist strategically:

• TEEs thrive in latency-sensitive, performance-critical environments and where hardware trust can be comfortably managed.
• E3s are ideally suited for scenarios where persistent privacy and verifiable correctness matter most (e.g., sealed-bid auctions, secret ballots, and confidential data pools).

A hybrid approach can balance both architectures, offering performance where needed and privacy where required. For example, organizations handling high-frequency financial trading may continue using TEEs for their speed advantages while adopting E3s for confidential settlement processes requiring stronger privacy guarantees.

Here is a table comparing their trust assumptions and trade-offs:

Looking Ahead: Making Computation Work for Your Needs

Organizations balancing performance, privacy, and verifiability should consider where each execution environment could fit within their stack. TEEs remain a practical choice for latency-sensitive applications where hardware-based security is sufficient. E3s, on the other hand, provide strong privacy guarantees and verifiable execution, making them well-suited for multi-party collaboration, confidential data processing, and applications requiring cryptographic trust over vendor-controlled security.

As computational trust continues to evolve, the key question is: what assumptions are you willing to make about security, transparency, and control? Evaluating these trade-offs now will determine how computational systems are designed — and who has control over them — in the future.

Enclave is an open-source protocol for Encrypted Execution Environments, with Gnosis Guild as its initial development team. Follow Enclave on social media (X, Farcaster) for updates, and subscribe for articles and announcements. For partnership inquires, business opportunities, and more, join the Enclave Telegram group.