Privacy 2.0 will enable new economies, new applications—new whitespace to be unlocked.

It is arguably the biggest unlock in crypto since smart contracts and oracles.

Yet, most are left wondering what these technologies are and what they achieve—shared private state.

In this article, I’ll break down each privacy-enhancing technology, their impact, and the projects bringing them to life.

Transparency has kept crypto in chains, but privacy is the key that sets it free...

Phase 1 - Special-Purpose Privacy

Crypto privacy is still in its early stages, defined by fragmented solutions targeting narrow use cases. Innovations like mixers and shielded transactions powered by zk-SNARKs and Monero’s ring signatures focus on financial privacy but operate as standalone tools and currencies. While they obscure transactional data, they fail to address broader privacy needs or integrate into a unified system.

Current State: Phase 2 - Private State

Phase 2 advances beyond isolated financial privacy to enable Private State—a more integrated approach where zero-knowledge proofs (ZKPs) enable verifiable computations on private data by proving correctness without revealing the underlying inputs, unlocking programmable privacy. Blockchains like Aztec and Aleo support decentralized applications with private state, enabling private transactions, smart contracts, and identity-preserving interactions.

However, Phase 2 remains limited: privacy is still siloed within individual applications and blockchains. There is no shared private state to support collaborative, multi-party use cases, restricting composability, interoperability, and the creation of complex economies.

The Real Transformation: Phase 3 - Shared Private State

Phase 3 marks a true paradigm shift—Privacy 2.0. It extends privacy to full-spectrum blockchain interactions by enabling shared private state (also called private shared state). This unlocks advanced use cases such as dark pools, private AI model training, and monetizable, privacy-preserving computation. Unlike its predecessors, Privacy 2.0 redefines what blockchains can achieve, powered by technologies like Multi-Party Computation (MPC) and Fully Homomorphic Encryption (FHE), with Trusted Execution Environments (TEEs) offering complementary guarantees.

Modular privacy networks enable shared private state across transparent blockchains like Ethereum and Solana, mitigating fragmentation and reducing wallet fatigue. Meanwhile, L1s and L2s can implement their own solutions, though at the cost of further fragmentation and isolated ecosystems.

Why It Matters

Until Phase 3 (shared private state) fully materializes, crypto privacy remains fragmented and insufficient to meet the complex demands of a digital-first world. The shift from transactional privacy to comprehensive digital privacy will redefine how we interact and protect our data.

Blockchains are celebrated for their transparency—every transaction and piece of data is visible to all participants. While this is excellent for trust, it’s a nightmare for use cases requiring confidentiality. For crypto to fulfill its potential, we must forge a path where transparency and privacy coexist—a path where innovation isn’t constrained by the fear of exposure, which includes transformative applications like:

• Dark pools and private trading strategies: Confidentiality protects trading strategies in dark pools, which account for 10-40% of U.S. spot trading volume. Blockchains alone offer no privacy for such use cases.

• Confidential AI: Private AI training, inferencing, and private AI agents remain unattainable, hindering breakthroughs in medicine, finance, and personalized models.

• AI on Private Data: Companies are stuck relying on public datasets due to the inability to securely train AI models on proprietary, high-value data.

• Private DeFi: On-chain services are blocked by the inability to securely share data like lending rates and collateral. The lack of privacy also hinders private DEXs and secure cross-chain swaps, exposing positions and limiting adoption.

• Hidden-Information Games: Transparency stifles innovation in games like poker or strategic bidding, essential for gaming and prediction markets.

• Monetizing Your Personal Data: Big tech has profited from selling your data while you earned nothing. With confidential compute, you can securely share private data for AI training, research, or analytics, monetize it on your terms, and stay anonymous—putting you in control of your data and its value.

There’s no shortage of examples to highlight, but I’ll keep it brief for now. What’s clear is this: solving the privacy gap will address real-world challenges, from empowering individuals to monetize their data securely to enabling businesses to collaborate on sensitive information without risk. It will also pave the way for transformative use cases we haven’t even imagined yet—bigger and more impactful than we can currently foresee.

Data breaches are not isolated incidents; they are symptoms of a deeper issue: incumbent computation and storage systems are inherently flawed. Every time data is processed, it’s exposed, creating a ticking time bomb for sensitive information. This vulnerability is magnified in crypto, where transparent blockchains reveal every transaction and piece of data to all participants, leaving critical industries hesitant to adopt blockchain technology despite its potential.

Imagine waking up to headlines of a massive data breach—your health records, finances, or even DNA leaked. Companies scramble to contain the damage, but for most, it’s already too late. This same flaw extends to modern AI platforms like ChatGPT or cloud-based services. Every prompt involves data decryption for processing, creating another window of vulnerability.

As a result, companies often restrict AI and cloud adoption, fearing data exploitation. While Trusted Execution Environments (TEEs) offer a partial solution by isolating data in secure hardware zones, they depend on trust in hardware vendors and are vulnerable to sophisticated attacks. For high-value use cases, TEEs alone are insufficient. More on this later…

Solving the privacy gap isn’t just about preventing breaches—it’s about unlocking entirely new industries and use cases that were once unimaginable, making privacy a launchpad for innovation.

Privacy-enhancing technologies (PETs) like MPC, FHE, and TEEs have been in development for decades—MPC and FHE were first conceptualized in the 1980s, while TEEs emerged as a concept in the early 2000s and entered production in the mid-2000s to early 2010s. Today, these technologies have advanced to a point where they are efficient and practical enough for real-world applications.

While ZKPs are widely discussed, they aren’t designed to enable shared private state by themselves, limiting their use in applications like privacy-preserving machine learning. Emerging approaches like zkML use ZKPs for verifiable inference, but shared private state is better addressed by MPC and FHE. TEEs also play a role but fall short on their own due to security vulnerabilities, which I will explore alongside the unique strengths and challenges of each approach in this article.

Multi-Party Computation (MPC) enables multiple parties/nodes to jointly compute a function while keeping their private inputs secure. By distributing computations across participants, MPC eliminates the need for trust in any single entity. This makes it a cornerstone of privacy-preserving technology, enabling collaborative computation while ensuring data confidentiality throughout the process.

Custody and Production Use: While MPC’s broader potential lies in privacy-preserving computation, it has found significant product-market fit in custody solutions—where it secures private keys without a single point of failure. Platforms like @FireblocksHQ have successfully used MPC in production to enable secure digital asset management, addressing market demand for robust key custody. This is important to note as many in the industry equate “MPC” primarily with custody, a misconception that highlights the need to showcase MPC's broader capabilities.

Example: Collaborative AI Model Training Across Organizations

Imagine multiple hospitals wanting to collaboratively train an AI model on healthcare data, such as improving diagnostic algorithms using patient records. Each hospital is unwilling to share its sensitive data due to privacy regulations or competitive concerns. By leveraging an MPC network, the hospitals can securely train the model together without any of them giving up custody of their data.

In this setup, each hospital's data is split into cryptographic "shares" using secret sharing techniques. These shares are distributed across nodes in the MPC network, where individual shares reveal no information about the original data on their own, ensuring the process is not a viable attack vector. The nodes then collaboratively compute the training process using secure MPC protocols. This results in a shared, high-quality AI model trained on a collective dataset, while each hospital retains full control over its data and compliance with privacy regulations. This approach not only preserves data confidentiality but also unlocks insights that would be impossible for any one hospital to achieve alone.

Challenges and Limitations:

MPC can be resource-intensive, with communication overhead increasing as the number of nodes grows. It also carries varying risks of collusion, where participants might attempt to compromise privacy depending on the security model. Academic approaches typically detect malicious behavior but lack enforcement mechanisms, a gap addressed in blockchain-based systems through staking and slashing to incentivize honesty.

The lifecycle of a Multi-Party Computation (MPC) protocol typically involves two main phases: the preprocessing phase and the online phase. These phases are designed to optimize performance and efficiency, particularly for protocols with complex cryptographic operations.

Preprocessing Phase (Offline Phase)

The preprocessing phase happens before inputs are known, performing computationally expensive operations upfront to make the online phase fast and efficient—like setting the table before dinner.

Random values like Beaver triples (in protocols like SPDZ) are generated for secure operations without exposing private inputs. Cryptographic materials, such as keys or data shares, are also prepared to ensure all parties agree on the setup. Precomputed values may undergo varying levels of verification for integrity depending on the security model. Crucially, this phase is input-independent, meaning it can be performed at any time, even if the details or occurrence of future computations are uncertain. This makes preprocessing highly flexible and resource-intensive, with its costs spread across multiple computations to improve efficiency later.

Online Phase

The online phase begins when the parties provide their private inputs. These inputs are split into shares using a secret sharing scheme and distributed securely among the participants. The actual computation is then performed on these shared inputs, using precomputed values from the preprocessing phase. This ensures the privacy of the inputs, as no party can see another’s data during the process.

Once the computation is finished, the parties combine their shares to reconstruct the final result. The online phase is typically fast, secure, and efficient, but its actual performance and security can vary depending on the protocol design, quality of implementation, and computational or network constraints.

Post-Processing Phase (Optional)

Some MPC protocols may include a post-processing phase where outputs are verified for correctness, additional transformations or privacy enhancements are applied to the final results, and any protocol-specific cleanup is performed.

MPC protocols like BGW, BDOZ, and SPDZ (and many others) are designed to meet varying requirements for security, efficiency, and resilience to dishonest behavior. Each protocol is defined by its trust model (e.g., honest-majority vs. dishonest-majority) and adversarial behavior type (e.g., semi-honest vs. malicious adversaries). Examples include:

• BGW: A first-generation MPC protocol that laid the groundwork for modern secure computation, inspiring numerous subsequent protocols like BDOZ and SPDZ. Designed for honest-majority settings, and provides security against semi-honest adversaries.

• BDOZ: MPC protocol for secure computation in dishonest-majority settings, providing security against malicious adversaries. Optimized for efficient secure multiplications and complex computations. It improves performance through optimized preprocessing to reduce online costs.

• SPDZ: A widely used MPC protocol for secure computation in dishonest-majority settings, providing security against malicious adversaries. Built upon BDOZ, it optimizes performance through offline/online phase separation, precomputing intensive tasks offline for faster online execution.

Security models in MPC encompass both the trust model (how many participants can be trusted) and the adversary model (how untrusted parties might behave).

Trust Models:

Trust models describe the assumptions about how much collusion can be tolerated before privacy or correctness is compromised. In MPC, collusion risks vary based on the trust model. Examples include:

• Honest Majority: Requires more than 50% of participants to be honest. Efficient, but less secure (e.g., BGW, NMC, Manticore)

• Dishonest Majority: Privacy is preserved as long as at least one party remains honest, even if all others are malicious. Less efficient, but more secure (e.g., SPDZ, BDOZ, Cerberus)

• Threshold-Based: A superset of the above models, where a predefined threshold (k out of n) determines how many parties can collude before compromising privacy or correctness. This encompasses honest majority (k = n/2) and dishonest majority (k = n). Lower thresholds tend to be more efficient but less secure, while higher thresholds increase security at the cost of greater communication and computation.

Adversary Behavior

Adversary behavior describes how participants in the protocol might act dishonestly or attempt to compromise the system. The behavior assumed under different trust models influences the protocol’s security guarantees. Examples include:

• Semi-Honest (Honest-But-Curious): Semi-honest adversaries follow the protocol correctly, adhering to its steps and rules, but attempt to infer additional information from the data they receive or process during execution.

• Malicious (Active): Malicious adversaries can deviate arbitrarily from the protocol, including submitting false inputs, tampering with messages, colluding with other parties, or refusing to participate, all with the aim of disrupting computation, compromising privacy, or corrupting results.

• Covert: Covert adversaries may deviate from the protocol but aim to avoid detection, often due to the presence of deterrence mechanisms, such as penalties or monitoring, that make malicious actions risky.
  

Ensuring input privacy in MPC settings is relatively straightforward, as cryptographic techniques like secret sharing prevent reconstruction of private inputs unless a predefined threshold (e.g., k out of n shares) is met. However, detecting protocol deviations, such as cheating or denial-of-service (DoS) attacks, requires advanced cryptographic techniques and robust protocol design.

Reputation serves as a foundational building block in ensuring trust assumptions hold in MPC protocols. By leveraging participants’ credibility and historical behavior, reputation reduces collusion risks and reinforces thresholds, adding an extra layer of confidence beyond cryptographic guarantees. When combined with incentives and robust design, it enhances the overall integrity of the protocol.

To enforce honest behavior and uphold trust model assumptions in practice, protocols often incorporate a combination of cryptographic techniques, economic incentives, and other mechanisms. Examples include:

• Staking/Slashing Mechanisms: Participants stake collateral, which can be slashed (penalized) if they deviate from the protocol.

• Actively Validated Services (AVS): Mechanisms like EigenLayer enable economic security by penalizing misbehavior.

• Cryptographic Cheater Identification: Techniques to detect and address malicious actors ensure deviations are identified and deterred, making collusion and dishonest behavior more difficult and less appealing.

By incorporating cryptographic tools, economic incentives, and real-world considerations like reputation, MPC protocols are designed to align participants’ behavior with honest execution, even in adversarial settings.

Trusted Execution Environments (TEEs) provide hardware-based isolation for sensitive computations, complementing Multi-Party Computation (MPC) protocols as part of a defense-in-depth strategy. TEEs ensure execution integrity (code runs as intended) and data confidentiality (data remains secure and inaccessible to the host system or external parties). By running MPC nodes with TEEs inside them, sensitive computations within each node are isolated, reducing the risk of compromised systems or malicious operators tampering with the code or leaking data. Remote attestation cryptographically proves that computations occurred securely within a verified TEE, reducing trust assumptions while retaining MPC’s cryptographic guarantees. This layered approach strengthens both privacy and integrity, ensuring resilience even if one layer of defense is compromised.

@ArciumHQ: Chain-agnostic network with stateless computation optimized for Solana. Powered by Cerberus, an advanced SPDZ/BDOZ variant with enhanced security properties, and Manticore, a high-performance MPC protocol tailored for AI use cases. Cerberus offers security against malicious adversaries in dishonest-majority settings, while Manticore assumes semi-honest adversaries with an honest majority. Arcium plans to integrate TEEs to enhance the defense-in-depth strategy for its MPC protocols.

@NillionNetwork: Chain-agnostic network. Their orchestration layer, Petnet, supports both computation and storage, currently leveraging multiple MPC protocols including the NMC protocol (secure against semi-honest adversaries in honest-majority settings) and others (TBA) while planning to integrate other Privacy-Enhancing Technologies (PETs) in the future. Nillion aims to be the go-to PET orchestration layer, making it simple for builders to access and utilize various PETs for diverse use cases.

@0xfairblock: Chain-agnostic network delivering confidentiality to EVM, Cosmos SDK chains, and native applications. Offers general-purpose MPC solutions, but focused on DeFi use cases like confidential auctions, intent matching, liquidations, and fair launches. Uses threshold identity-based encryption (TIBE) for confidentiality, but expanding functionality to include dynamic solutions like CKKS, SPDZ, TEEs (security/performance), and ZK (input verification), optimizing operations, overhead, and security trade-offs.

@renegade_fi: The first on-chain dark pool, launched on Arbitrum in September, leveraging MPC and ZK-SNARKs (coSNARKs) to ensure confidentiality. Uses maliciously secure two-party SPDZ, a fast secret-sharing-style scheme, with potential future expansion to more parties.

@LitProtocol: Decentralized key management and compute network using MPC and TSS for secure key operations and private compute across Web2 and blockchains. Supports cross-chain messaging and transaction automation.

@partisiampc: Layer 1 blockchain leveraging MPC for privacy, powered by REAL—an MPC protocol secure against semi-honest adversaries with a threshold-based trust model.

@QuilibriumInc: MPC Platform-as-a-Service with a focus on messaging privacy at the peer-to-peer layer. Its homogenous network primarily uses FERRET for MPC, assuming semi-honest adversaries in a dishonest majority setting, while integrating other schemes for specific network components.

@TACEO_IO: Taceo is building an open protocol for encrypted computation that combines MPC and ZK-SNARKs ( coSNARKs). Using MPC for confidentiality and ZK for verifiability. Combines multiple different MPC Protocols (ABY3 and others).

@Gateway_xyz: Layer 1 unifying public and shared private state natively. Its programmable PET marketplace supports MPC, TEEs (AWS Nitro, Intel SGX), and soon NVIDIA H100 GPUs, garbled circuits, federated learning, and more giving developers the flexibility to choose their preferred PET.

All of the projects above primarily use MPC but take unique approaches to multimodal cryptography, combining techniques like homomorphic encryption, ZKPs, TEEs and more. Read their respective documentations for more details.

FHE, famously called the 'Holy Grail of Cryptography', enables arbitrary computations on encrypted data without decrypting it, maintaining privacy during processing. This ensures that results, when decrypted, are the same as if computed on plaintext, preserving confidentiality without sacrificing functionality.

Challenges and Limitations:

• Performance: FHE operations are highly computationally intensive, particularly for non-linear tasks, running 100 to 10,000 times slower than standard unencrypted computations depending on the complexity of the operations. This limits its practicality for large-scale or real-time applications.

• Verifiability Gap: Ensuring that computations on encrypted data are correct (zkFHE) is still under development and adds significant complexity and introduces a computational slowdown of 4–5 orders of magnitude. Without it you may have confidentiality but need to have 100% trust in the node(s) computing your e.g. DeFi operation in FHE to prevent them from stealing your money via computing a different function than you requested.

Key FHE Schemes

• FHEW: An optimized version of an earlier scheme called GSW, making bootstrapping more efficient. Instead of treating decryption as a Boolean circuit, it uses an arithmetic approach. It supports flexible function evaluation with programmable bootstrapping, and speeds up processing with Fast Fourier Transform (FFT) techniques.

• TFHE: Utilizes "Blind Rotation" for fast bootstrapping, refreshing ciphertexts to prevent unusable errors. It combines basic LWE encryption with ring-based encryption for efficient computation, building on FHEW techniques with enhancements like "modulus switching" and "key switching." It is Zama's flagship implementation, and is the first FHE scheme to reach production in a blockchain context.

• HFHE: A novel FHE scheme developed by Octra, leveraging hypergraphs to enhance efficiency. Initially inspired by schemes like FHEW, it has evolved into a fully unique implementation. It’s the second FHE scheme (after TFHE) to reach production in blockchain and the only proprietary one not licensed or developed by a third party. HFHE encrypts entire network states rather than individual values, and achieves ~11x faster operations than TFHE.

• CKKS: Introduces an innovative way to map real (or complex) numbers for encryption. It includes a "rescaling" technique to manage noise during homomorphic computations, reducing ciphertext size while preserving most of the precision. Originally a leveled scheme, it later incorporated efficient bootstrapping to become fully homomorphic and added support for packed ciphertexts.

Efficiency Optimizations

• Batched FHE Operations: Traditional FHE processes one encrypted value at a time, making computations on large datasets inefficient due to repeated operations and high computational overhead. Techniques like ciphertext packing allow FHE schemes to process multiple plaintexts simultaneously, improving efficiency.

• Noise Management: FHE operations introduce noise into ciphertexts, which accumulates with each operation due to the additional randomness required for security. If left unchecked, noise accumulates to the point where it disrupts decryption, making it impossible to recover the correct plaintext. Methods like bootstrapping and modulus switching reduce noise to maintain decryption accuracy.

Advancements in specialized chips and ASICs from @FabricCrypto, Intel, and others are reducing FHE’s computational overhead. Innovations like @Octra’s hypergraph-based efficiency enhancements are also particularly exciting. While complex FHE computations may remain challenging for years, simpler applications such as private DeFi, voting, and similar use cases are becoming increasingly feasible. Managing latency will be key to achieving a smooth user experience.

Key Projects Primarily Using FHE:

@Zama_FHE: Building FHE tooling for blockchains, including the fhEVM and the TFHE libraries, both widely used by several FHE projects. Recently introduced the fhEVM coprocessor, bringing FHE functionality to EVM-compatible blockchains.

@Octra: Universal chain leveraging HFHE, a proprietary FHE scheme over hypergraphs, enabling high-speed FHE computations. Features Proof-of-Learning (PoL), a machine-learning-based consensus, and serves as a standalone network or sidechain for outsourcing encrypted computations for other blockchains.

@FhenixIO: Ethereum Layer 2 Optimistic Rollup leveraging Zama's FHE technology to bring confidentiality to Ethereum, enabling private smart contracts and transactions.

@IncoNetwork: Cosmos SDK Layer 1 blockchain that combines FHE, zero-knowledge proofs, trusted execution environments, and multi-party computation to enable confidential computing. Utilizes EigenLayer's dual staking to tap into Ethereum L1 security.

@theSightAI: Secure Computation Layer with FHE. Chain-agnostic, supporting EVM Chains, Solana, and TON. Flexible with multiple FHE schemes like CKKS and TFHE. Researching verifiable FHE to ensure computation integrity and FHE GPU acceleration to enhance performance.

@FairMath: FHE coprocessor capable of supporting various FHE schemes. Adopts an IPFS-based strategy to efficiently manage large data off-chain, avoiding direct blockchain storage.

@Privasea_ai: FHE Network that uses Zama’s TFHE scheme for AI & Machine learning.

@SunscreenTech: Building an FHE compiler using the BFV Scheme, but has designed their compiler so that they can swap out the backend FHE scheme in the future.

TEEs create hardware-based secure zones where data is processed in isolation. Chips like Intel SGX and AMD SEV shield sensitive computations from external access, even from the host operating system. For years, TEEs have been available on leading cloud platforms, including AWS, Azure and GCP.

Code executed inside the TEE is processed in the clear but is only visible in encrypted form when anything outside tries to access it.

NVIDIA GPUs and TEEs: TEEs have traditionally been limited to CPUs, but GPUs like the NVIDIA H100 are now introducing TEE capabilities, opening up new possibilities and markets for hardware-backed secure computation. The NVIDIA H100 TEE feature was launched in early access in July 2023, positioning GPUs as a key driver of TEE adoption and expanding their role in the industry.

TEEs are already widely used for biometric verification in devices like smartphones and laptops, where they ensure that sensitive biometric data (e.g., facial recognition or fingerprint scans) is processed and stored securely, preventing malicious attacks.

Challenges and Limitations:

While TEEs provide efficient security, they rely on hardware vendors, making them non-trustless. If the hardware is compromised, the entire system is vulnerable. Additionally, TEEs are susceptible to sophisticated side-channel attacks (see sgx.fail and badram.eu).

Enhanced Trust Models

• Multi-Vendor TEE Collaboration: Frameworks enabling collaboration between TEEs from different providers (e.g., Intel SGX, AMD SEV, AWS Nitro) reduce reliance on a single vendor. This model mitigates the risk of a single hardware provider’s breach by distributing trust across multiple providers, improving resilience.

• Open Source TEE Frameworks: Open-source TEE frameworks, such as Keystone and OpenTEE, enhance trust by offering transparency and community-driven security audits, reducing reliance on proprietary, opaque solutions.

Key Projects Primarily Using TEEs:

@OasisProtocol: A Layer 1 blockchain that utilizes TEEs, specifically Intel SGX, to ensure confidential smart contracts. It features the ParaTime Layer, which includes confidential EVM-compatible runtimes (Sapphire and Cipher) that empower developers to build EVM-based on-chain dApps with configurable privacy options.

@PhalaNetwork: A decentralized cloud platform and coprocessor network that integrates various TEEs, including Intel SGX, Intel TDX, AMD SEV, and NVIDIA H100 (in TEE mode), to provide confidential computing services.

@SecretNetwork: A decentralized confidential computing layer that employs TEEs and GPUs, specifically Intel SGX and Nvidia H100 (in TEE mode), to provide on-chain confidential compute to nearly every major blockchain. Secret is also adding FHE to allow private data to be used securely outside the TEE while staying encrypted.

@AutomataNetwork: Coprocessor using TEEs for secure computing across blockchains. Ensures the liveness of a TEE through cryptoeconomic security using Multi-Prover AVS with EigenLayer to mitigate liveness risks.

@tenprotocol: Ethereum L2 using TEEs, specifically Intel SGX for confidential computing, enabling encrypted transactions and smart contracts with enhanced privacy.

@MarlinProtocol: TEE Coprocessor that integrates various TEEs, including Intel SGX, AWS Nitro Enclaves, and NVIDIA H100 (in TEE mode), to provide confidential computing services.

@Spacecoin_xyz: Building a TEE blockchain on satellite-operated infrastructure. Nodes orbit Earth at 7km/s, over 500km high, using low-cost CubeSats—making the hardware tamper-proof and data secure from adversarial physical access.

Quantum resistance protects cryptographic protocols against quantum computers, while Information-Theoretic Security (ITS) ensures systems remain secure even with unlimited computational power.

MPC protocols are typically quantum- and ITS-secure, as secrets are split into shares, requiring access to a sufficient number of them for reconstruction. However, ITS depends on assumptions like an honest majority; if these fail, ITS no longer holds. ITS is generally a baseline for MPC unless the protocol diverges significantly from standard designs.

Fully Homomorphic Encryption (FHE) is considered quantum-secure, leveraging lattice-based cryptography like Learning with Errors (LWE). However, it is not ITS-secure, as its security relies on computational assumptions that theoretically could be broken with infinite resources.

Trusted Execution Environments (TEEs) do not provide quantum resistance or information-theoretic security (ITS) because they rely on hardware-based security guarantees, which can be compromised through hardware vulnerabilities or side-channel attacks.

Ultimately, while ITS and quantum security are important, the practical security of a protocol depends on its underlying assumptions and its ability to withstand real-world adversarial conditions.

We can envision a future where TEEs become the default for low- to medium-stakes applications, offering a practical balance between efficiency and security. However, for high-stakes use cases—like AI and DeFi protocols—using TEEs alone could inadvertently create massive "bug bounties," incentivizing attackers to exploit any vulnerabilities and compromise user funds. For these scenarios, more secure frameworks like MPC and FHE as it matures––will be essential.

Each PET has unique capabilities and trade-offs, so understanding their strengths and limitations is crucial. The ideal approach combines flexible, multimodal cryptographic schemes tailored to specific needs. Signal’s PIN recovery system exemplifies this by combining PETs like Shamir's Secret Sharing (SSS), Secure Enclaves (TEE), and client-side encryption. By splitting sensitive data into shares, encrypting it on the user’s device, and processing it in secure hardware, Signal ensures no single entity can access the user’s PIN. This highlights how blending cryptographic techniques enables practical, privacy-preserving solutions in production.

You can combine MPC + TEE, MPC + Homomorphic Encryption, MPC + ZKPs, FHE + ZKPs, and more. These combinations enhance privacy and security while enabling secure, verifiable computations tailored to specific use cases.

Privacy-enhancing technologies like MPC, FHE, and TEEs open a zero-to-one moment—a new whitespace in blockchains with shared private state. They enable what was once impossible: truly private collaboration, scalable confidentiality, and trustless privacy that push the boundaries of innovation.

Privacy 2.0 unlocks a completely new design space that makes crypto limitless, enabling innovations we’ve only begun to imagine.

The time to build some cool shit is now.

Privacy 2.0 will enable new economies, new applications—new whitespace to be unlocked.

It is arguably the biggest unlock in crypto since smart contracts and oracles.

Yet, most are left wondering what these technologies are and what they achieve—shared private state.

In this article, I’ll break down each privacy-enhancing technology, their impact, and the projects bringing them to life.

Transparency has kept crypto in chains, but privacy is the key that sets it free...

Phase 1 - Special-Purpose Privacy

Crypto privacy is still in its early stages, defined by fragmented solutions targeting narrow use cases. Innovations like mixers and shielded transactions powered by zk-SNARKs and Monero’s ring signatures focus on financial privacy but operate as standalone tools and currencies. While they obscure transactional data, they fail to address broader privacy needs or integrate into a unified system.

Current State: Phase 2 - Private State

Phase 2 advances beyond isolated financial privacy to enable Private State—a more integrated approach where zero-knowledge proofs (ZKPs) enable verifiable computations on private data by proving correctness without revealing the underlying inputs, unlocking programmable privacy. Blockchains like Aztec and Aleo support decentralized applications with private state, enabling private transactions, smart contracts, and identity-preserving interactions.

However, Phase 2 remains limited: privacy is still siloed within individual applications and blockchains. There is no shared private state to support collaborative, multi-party use cases, restricting composability, interoperability, and the creation of complex economies.

The Real Transformation: Phase 3 - Shared Private State

Phase 3 marks a true paradigm shift—Privacy 2.0. It extends privacy to full-spectrum blockchain interactions by enabling shared private state (also called private shared state). This unlocks advanced use cases such as dark pools, private AI model training, and monetizable, privacy-preserving computation. Unlike its predecessors, Privacy 2.0 redefines what blockchains can achieve, powered by technologies like Multi-Party Computation (MPC) and Fully Homomorphic Encryption (FHE), with Trusted Execution Environments (TEEs) offering complementary guarantees.

Modular privacy networks enable shared private state across transparent blockchains like Ethereum and Solana, mitigating fragmentation and reducing wallet fatigue. Meanwhile, L1s and L2s can implement their own solutions, though at the cost of further fragmentation and isolated ecosystems.

Why It Matters

Until Phase 3 (shared private state) fully materializes, crypto privacy remains fragmented and insufficient to meet the complex demands of a digital-first world. The shift from transactional privacy to comprehensive digital privacy will redefine how we interact and protect our data.

Blockchains are celebrated for their transparency—every transaction and piece of data is visible to all participants. While this is excellent for trust, it’s a nightmare for use cases requiring confidentiality. For crypto to fulfill its potential, we must forge a path where transparency and privacy coexist—a path where innovation isn’t constrained by the fear of exposure, which includes transformative applications like:

• Dark pools and private trading strategies: Confidentiality protects trading strategies in dark pools, which account for 10-40% of U.S. spot trading volume. Blockchains alone offer no privacy for such use cases.

• Confidential AI: Private AI training, inferencing, and private AI agents remain unattainable, hindering breakthroughs in medicine, finance, and personalized models.

• AI on Private Data: Companies are stuck relying on public datasets due to the inability to securely train AI models on proprietary, high-value data.

• Private DeFi: On-chain services are blocked by the inability to securely share data like lending rates and collateral. The lack of privacy also hinders private DEXs and secure cross-chain swaps, exposing positions and limiting adoption.

• Hidden-Information Games: Transparency stifles innovation in games like poker or strategic bidding, essential for gaming and prediction markets.

• Monetizing Your Personal Data: Big tech has profited from selling your data while you earned nothing. With confidential compute, you can securely share private data for AI training, research, or analytics, monetize it on your terms, and stay anonymous—putting you in control of your data and its value.

There’s no shortage of examples to highlight, but I’ll keep it brief for now. What’s clear is this: solving the privacy gap will address real-world challenges, from empowering individuals to monetize their data securely to enabling businesses to collaborate on sensitive information without risk. It will also pave the way for transformative use cases we haven’t even imagined yet—bigger and more impactful than we can currently foresee.

Data breaches are not isolated incidents; they are symptoms of a deeper issue: incumbent computation and storage systems are inherently flawed. Every time data is processed, it’s exposed, creating a ticking time bomb for sensitive information. This vulnerability is magnified in crypto, where transparent blockchains reveal every transaction and piece of data to all participants, leaving critical industries hesitant to adopt blockchain technology despite its potential.

Imagine waking up to headlines of a massive data breach—your health records, finances, or even DNA leaked. Companies scramble to contain the damage, but for most, it’s already too late. This same flaw extends to modern AI platforms like ChatGPT or cloud-based services. Every prompt involves data decryption for processing, creating another window of vulnerability.

As a result, companies often restrict AI and cloud adoption, fearing data exploitation. While Trusted Execution Environments (TEEs) offer a partial solution by isolating data in secure hardware zones, they depend on trust in hardware vendors and are vulnerable to sophisticated attacks. For high-value use cases, TEEs alone are insufficient. More on this later…

Solving the privacy gap isn’t just about preventing breaches—it’s about unlocking entirely new industries and use cases that were once unimaginable, making privacy a launchpad for innovation.

Privacy-enhancing technologies (PETs) like MPC, FHE, and TEEs have been in development for decades—MPC and FHE were first conceptualized in the 1980s, while TEEs emerged as a concept in the early 2000s and entered production in the mid-2000s to early 2010s. Today, these technologies have advanced to a point where they are efficient and practical enough for real-world applications.

While ZKPs are widely discussed, they aren’t designed to enable shared private state by themselves, limiting their use in applications like privacy-preserving machine learning. Emerging approaches like zkML use ZKPs for verifiable inference, but shared private state is better addressed by MPC and FHE. TEEs also play a role but fall short on their own due to security vulnerabilities, which I will explore alongside the unique strengths and challenges of each approach in this article.

Multi-Party Computation (MPC) enables multiple parties/nodes to jointly compute a function while keeping their private inputs secure. By distributing computations across participants, MPC eliminates the need for trust in any single entity. This makes it a cornerstone of privacy-preserving technology, enabling collaborative computation while ensuring data confidentiality throughout the process.

Custody and Production Use: While MPC’s broader potential lies in privacy-preserving computation, it has found significant product-market fit in custody solutions—where it secures private keys without a single point of failure. Platforms like @FireblocksHQ have successfully used MPC in production to enable secure digital asset management, addressing market demand for robust key custody. This is important to note as many in the industry equate “MPC” primarily with custody, a misconception that highlights the need to showcase MPC's broader capabilities.

Example: Collaborative AI Model Training Across Organizations

Imagine multiple hospitals wanting to collaboratively train an AI model on healthcare data, such as improving diagnostic algorithms using patient records. Each hospital is unwilling to share its sensitive data due to privacy regulations or competitive concerns. By leveraging an MPC network, the hospitals can securely train the model together without any of them giving up custody of their data.

In this setup, each hospital's data is split into cryptographic "shares" using secret sharing techniques. These shares are distributed across nodes in the MPC network, where individual shares reveal no information about the original data on their own, ensuring the process is not a viable attack vector. The nodes then collaboratively compute the training process using secure MPC protocols. This results in a shared, high-quality AI model trained on a collective dataset, while each hospital retains full control over its data and compliance with privacy regulations. This approach not only preserves data confidentiality but also unlocks insights that would be impossible for any one hospital to achieve alone.

Challenges and Limitations:

MPC can be resource-intensive, with communication overhead increasing as the number of nodes grows. It also carries varying risks of collusion, where participants might attempt to compromise privacy depending on the security model. Academic approaches typically detect malicious behavior but lack enforcement mechanisms, a gap addressed in blockchain-based systems through staking and slashing to incentivize honesty.

The lifecycle of a Multi-Party Computation (MPC) protocol typically involves two main phases: the preprocessing phase and the online phase. These phases are designed to optimize performance and efficiency, particularly for protocols with complex cryptographic operations.

Preprocessing Phase (Offline Phase)

The preprocessing phase happens before inputs are known, performing computationally expensive operations upfront to make the online phase fast and efficient—like setting the table before dinner.

Random values like Beaver triples (in protocols like SPDZ) are generated for secure operations without exposing private inputs. Cryptographic materials, such as keys or data shares, are also prepared to ensure all parties agree on the setup. Precomputed values may undergo varying levels of verification for integrity depending on the security model. Crucially, this phase is input-independent, meaning it can be performed at any time, even if the details or occurrence of future computations are uncertain. This makes preprocessing highly flexible and resource-intensive, with its costs spread across multiple computations to improve efficiency later.

Online Phase

The online phase begins when the parties provide their private inputs. These inputs are split into shares using a secret sharing scheme and distributed securely among the participants. The actual computation is then performed on these shared inputs, using precomputed values from the preprocessing phase. This ensures the privacy of the inputs, as no party can see another’s data during the process.

Once the computation is finished, the parties combine their shares to reconstruct the final result. The online phase is typically fast, secure, and efficient, but its actual performance and security can vary depending on the protocol design, quality of implementation, and computational or network constraints.

Post-Processing Phase (Optional)

Some MPC protocols may include a post-processing phase where outputs are verified for correctness, additional transformations or privacy enhancements are applied to the final results, and any protocol-specific cleanup is performed.

MPC protocols like BGW, BDOZ, and SPDZ (and many others) are designed to meet varying requirements for security, efficiency, and resilience to dishonest behavior. Each protocol is defined by its trust model (e.g., honest-majority vs. dishonest-majority) and adversarial behavior type (e.g., semi-honest vs. malicious adversaries). Examples include:

• BGW: A first-generation MPC protocol that laid the groundwork for modern secure computation, inspiring numerous subsequent protocols like BDOZ and SPDZ. Designed for honest-majority settings, and provides security against semi-honest adversaries.

• BDOZ: MPC protocol for secure computation in dishonest-majority settings, providing security against malicious adversaries. Optimized for efficient secure multiplications and complex computations. It improves performance through optimized preprocessing to reduce online costs.

• SPDZ: A widely used MPC protocol for secure computation in dishonest-majority settings, providing security against malicious adversaries. Built upon BDOZ, it optimizes performance through offline/online phase separation, precomputing intensive tasks offline for faster online execution.

Security models in MPC encompass both the trust model (how many participants can be trusted) and the adversary model (how untrusted parties might behave).

Trust Models:

Trust models describe the assumptions about how much collusion can be tolerated before privacy or correctness is compromised. In MPC, collusion risks vary based on the trust model. Examples include:

• Honest Majority: Requires more than 50% of participants to be honest. Efficient, but less secure (e.g., BGW, NMC, Manticore)

• Dishonest Majority: Privacy is preserved as long as at least one party remains honest, even if all others are malicious. Less efficient, but more secure (e.g., SPDZ, BDOZ, Cerberus)

• Threshold-Based: A superset of the above models, where a predefined threshold (k out of n) determines how many parties can collude before compromising privacy or correctness. This encompasses honest majority (k = n/2) and dishonest majority (k = n). Lower thresholds tend to be more efficient but less secure, while higher thresholds increase security at the cost of greater communication and computation.

Adversary Behavior

Adversary behavior describes how participants in the protocol might act dishonestly or attempt to compromise the system. The behavior assumed under different trust models influences the protocol’s security guarantees. Examples include:

• Semi-Honest (Honest-But-Curious): Semi-honest adversaries follow the protocol correctly, adhering to its steps and rules, but attempt to infer additional information from the data they receive or process during execution.

• Malicious (Active): Malicious adversaries can deviate arbitrarily from the protocol, including submitting false inputs, tampering with messages, colluding with other parties, or refusing to participate, all with the aim of disrupting computation, compromising privacy, or corrupting results.

• Covert: Covert adversaries may deviate from the protocol but aim to avoid detection, often due to the presence of deterrence mechanisms, such as penalties or monitoring, that make malicious actions risky.
  

Ensuring input privacy in MPC settings is relatively straightforward, as cryptographic techniques like secret sharing prevent reconstruction of private inputs unless a predefined threshold (e.g., k out of n shares) is met. However, detecting protocol deviations, such as cheating or denial-of-service (DoS) attacks, requires advanced cryptographic techniques and robust protocol design.

Reputation serves as a foundational building block in ensuring trust assumptions hold in MPC protocols. By leveraging participants’ credibility and historical behavior, reputation reduces collusion risks and reinforces thresholds, adding an extra layer of confidence beyond cryptographic guarantees. When combined with incentives and robust design, it enhances the overall integrity of the protocol.

To enforce honest behavior and uphold trust model assumptions in practice, protocols often incorporate a combination of cryptographic techniques, economic incentives, and other mechanisms. Examples include:

• Staking/Slashing Mechanisms: Participants stake collateral, which can be slashed (penalized) if they deviate from the protocol.

• Actively Validated Services (AVS): Mechanisms like EigenLayer enable economic security by penalizing misbehavior.

• Cryptographic Cheater Identification: Techniques to detect and address malicious actors ensure deviations are identified and deterred, making collusion and dishonest behavior more difficult and less appealing.

By incorporating cryptographic tools, economic incentives, and real-world considerations like reputation, MPC protocols are designed to align participants’ behavior with honest execution, even in adversarial settings.

Trusted Execution Environments (TEEs) provide hardware-based isolation for sensitive computations, complementing Multi-Party Computation (MPC) protocols as part of a defense-in-depth strategy. TEEs ensure execution integrity (code runs as intended) and data confidentiality (data remains secure and inaccessible to the host system or external parties). By running MPC nodes with TEEs inside them, sensitive computations within each node are isolated, reducing the risk of compromised systems or malicious operators tampering with the code or leaking data. Remote attestation cryptographically proves that computations occurred securely within a verified TEE, reducing trust assumptions while retaining MPC’s cryptographic guarantees. This layered approach strengthens both privacy and integrity, ensuring resilience even if one layer of defense is compromised.

@ArciumHQ: Chain-agnostic network with stateless computation optimized for Solana. Powered by Cerberus, an advanced SPDZ/BDOZ variant with enhanced security properties, and Manticore, a high-performance MPC protocol tailored for AI use cases. Cerberus offers security against malicious adversaries in dishonest-majority settings, while Manticore assumes semi-honest adversaries with an honest majority. Arcium plans to integrate TEEs to enhance the defense-in-depth strategy for its MPC protocols.

@NillionNetwork: Chain-agnostic network. Their orchestration layer, Petnet, supports both computation and storage, currently leveraging multiple MPC protocols including the NMC protocol (secure against semi-honest adversaries in honest-majority settings) and others (TBA) while planning to integrate other Privacy-Enhancing Technologies (PETs) in the future. Nillion aims to be the go-to PET orchestration layer, making it simple for builders to access and utilize various PETs for diverse use cases.

@0xfairblock: Chain-agnostic network delivering confidentiality to EVM, Cosmos SDK chains, and native applications. Offers general-purpose MPC solutions, but focused on DeFi use cases like confidential auctions, intent matching, liquidations, and fair launches. Uses threshold identity-based encryption (TIBE) for confidentiality, but expanding functionality to include dynamic solutions like CKKS, SPDZ, TEEs (security/performance), and ZK (input verification), optimizing operations, overhead, and security trade-offs.

@renegade_fi: The first on-chain dark pool, launched on Arbitrum in September, leveraging MPC and ZK-SNARKs (coSNARKs) to ensure confidentiality. Uses maliciously secure two-party SPDZ, a fast secret-sharing-style scheme, with potential future expansion to more parties.

@LitProtocol: Decentralized key management and compute network using MPC and TSS for secure key operations and private compute across Web2 and blockchains. Supports cross-chain messaging and transaction automation.

@partisiampc: Layer 1 blockchain leveraging MPC for privacy, powered by REAL—an MPC protocol secure against semi-honest adversaries with a threshold-based trust model.

@QuilibriumInc: MPC Platform-as-a-Service with a focus on messaging privacy at the peer-to-peer layer. Its homogenous network primarily uses FERRET for MPC, assuming semi-honest adversaries in a dishonest majority setting, while integrating other schemes for specific network components.

@TACEO_IO: Taceo is building an open protocol for encrypted computation that combines MPC and ZK-SNARKs ( coSNARKs). Using MPC for confidentiality and ZK for verifiability. Combines multiple different MPC Protocols (ABY3 and others).

@Gateway_xyz: Layer 1 unifying public and shared private state natively. Its programmable PET marketplace supports MPC, TEEs (AWS Nitro, Intel SGX), and soon NVIDIA H100 GPUs, garbled circuits, federated learning, and more giving developers the flexibility to choose their preferred PET.

All of the projects above primarily use MPC but take unique approaches to multimodal cryptography, combining techniques like homomorphic encryption, ZKPs, TEEs and more. Read their respective documentations for more details.

FHE, famously called the 'Holy Grail of Cryptography', enables arbitrary computations on encrypted data without decrypting it, maintaining privacy during processing. This ensures that results, when decrypted, are the same as if computed on plaintext, preserving confidentiality without sacrificing functionality.

Challenges and Limitations:

• Performance: FHE operations are highly computationally intensive, particularly for non-linear tasks, running 100 to 10,000 times slower than standard unencrypted computations depending on the complexity of the operations. This limits its practicality for large-scale or real-time applications.

• Verifiability Gap: Ensuring that computations on encrypted data are correct (zkFHE) is still under development and adds significant complexity and introduces a computational slowdown of 4–5 orders of magnitude. Without it you may have confidentiality but need to have 100% trust in the node(s) computing your e.g. DeFi operation in FHE to prevent them from stealing your money via computing a different function than you requested.

Key FHE Schemes

• FHEW: An optimized version of an earlier scheme called GSW, making bootstrapping more efficient. Instead of treating decryption as a Boolean circuit, it uses an arithmetic approach. It supports flexible function evaluation with programmable bootstrapping, and speeds up processing with Fast Fourier Transform (FFT) techniques.

• TFHE: Utilizes "Blind Rotation" for fast bootstrapping, refreshing ciphertexts to prevent unusable errors. It combines basic LWE encryption with ring-based encryption for efficient computation, building on FHEW techniques with enhancements like "modulus switching" and "key switching." It is Zama's flagship implementation, and is the first FHE scheme to reach production in a blockchain context.

• HFHE: A novel FHE scheme developed by Octra, leveraging hypergraphs to enhance efficiency. Initially inspired by schemes like FHEW, it has evolved into a fully unique implementation. It’s the second FHE scheme (after TFHE) to reach production in blockchain and the only proprietary one not licensed or developed by a third party. HFHE encrypts entire network states rather than individual values, and achieves ~11x faster operations than TFHE.

• CKKS: Introduces an innovative way to map real (or complex) numbers for encryption. It includes a "rescaling" technique to manage noise during homomorphic computations, reducing ciphertext size while preserving most of the precision. Originally a leveled scheme, it later incorporated efficient bootstrapping to become fully homomorphic and added support for packed ciphertexts.

Efficiency Optimizations

• Batched FHE Operations: Traditional FHE processes one encrypted value at a time, making computations on large datasets inefficient due to repeated operations and high computational overhead. Techniques like ciphertext packing allow FHE schemes to process multiple plaintexts simultaneously, improving efficiency.

• Noise Management: FHE operations introduce noise into ciphertexts, which accumulates with each operation due to the additional randomness required for security. If left unchecked, noise accumulates to the point where it disrupts decryption, making it impossible to recover the correct plaintext. Methods like bootstrapping and modulus switching reduce noise to maintain decryption accuracy.

Advancements in specialized chips and ASICs from @FabricCrypto, Intel, and others are reducing FHE’s computational overhead. Innovations like @Octra’s hypergraph-based efficiency enhancements are also particularly exciting. While complex FHE computations may remain challenging for years, simpler applications such as private DeFi, voting, and similar use cases are becoming increasingly feasible. Managing latency will be key to achieving a smooth user experience.

Key Projects Primarily Using FHE:

@Zama_FHE: Building FHE tooling for blockchains, including the fhEVM and the TFHE libraries, both widely used by several FHE projects. Recently introduced the fhEVM coprocessor, bringing FHE functionality to EVM-compatible blockchains.

@Octra: Universal chain leveraging HFHE, a proprietary FHE scheme over hypergraphs, enabling high-speed FHE computations. Features Proof-of-Learning (PoL), a machine-learning-based consensus, and serves as a standalone network or sidechain for outsourcing encrypted computations for other blockchains.

@FhenixIO: Ethereum Layer 2 Optimistic Rollup leveraging Zama's FHE technology to bring confidentiality to Ethereum, enabling private smart contracts and transactions.

@IncoNetwork: Cosmos SDK Layer 1 blockchain that combines FHE, zero-knowledge proofs, trusted execution environments, and multi-party computation to enable confidential computing. Utilizes EigenLayer's dual staking to tap into Ethereum L1 security.

@theSightAI: Secure Computation Layer with FHE. Chain-agnostic, supporting EVM Chains, Solana, and TON. Flexible with multiple FHE schemes like CKKS and TFHE. Researching verifiable FHE to ensure computation integrity and FHE GPU acceleration to enhance performance.

@FairMath: FHE coprocessor capable of supporting various FHE schemes. Adopts an IPFS-based strategy to efficiently manage large data off-chain, avoiding direct blockchain storage.

@Privasea_ai: FHE Network that uses Zama’s TFHE scheme for AI & Machine learning.

@SunscreenTech: Building an FHE compiler using the BFV Scheme, but has designed their compiler so that they can swap out the backend FHE scheme in the future.

TEEs create hardware-based secure zones where data is processed in isolation. Chips like Intel SGX and AMD SEV shield sensitive computations from external access, even from the host operating system. For years, TEEs have been available on leading cloud platforms, including AWS, Azure and GCP.

Code executed inside the TEE is processed in the clear but is only visible in encrypted form when anything outside tries to access it.

NVIDIA GPUs and TEEs: TEEs have traditionally been limited to CPUs, but GPUs like the NVIDIA H100 are now introducing TEE capabilities, opening up new possibilities and markets for hardware-backed secure computation. The NVIDIA H100 TEE feature was launched in early access in July 2023, positioning GPUs as a key driver of TEE adoption and expanding their role in the industry.

TEEs are already widely used for biometric verification in devices like smartphones and laptops, where they ensure that sensitive biometric data (e.g., facial recognition or fingerprint scans) is processed and stored securely, preventing malicious attacks.

Challenges and Limitations:

While TEEs provide efficient security, they rely on hardware vendors, making them non-trustless. If the hardware is compromised, the entire system is vulnerable. Additionally, TEEs are susceptible to sophisticated side-channel attacks (see sgx.fail and badram.eu).

Enhanced Trust Models

• Multi-Vendor TEE Collaboration: Frameworks enabling collaboration between TEEs from different providers (e.g., Intel SGX, AMD SEV, AWS Nitro) reduce reliance on a single vendor. This model mitigates the risk of a single hardware provider’s breach by distributing trust across multiple providers, improving resilience.

• Open Source TEE Frameworks: Open-source TEE frameworks, such as Keystone and OpenTEE, enhance trust by offering transparency and community-driven security audits, reducing reliance on proprietary, opaque solutions.

Key Projects Primarily Using TEEs:

@OasisProtocol: A Layer 1 blockchain that utilizes TEEs, specifically Intel SGX, to ensure confidential smart contracts. It features the ParaTime Layer, which includes confidential EVM-compatible runtimes (Sapphire and Cipher) that empower developers to build EVM-based on-chain dApps with configurable privacy options.

@PhalaNetwork: A decentralized cloud platform and coprocessor network that integrates various TEEs, including Intel SGX, Intel TDX, AMD SEV, and NVIDIA H100 (in TEE mode), to provide confidential computing services.

@SecretNetwork: A decentralized confidential computing layer that employs TEEs and GPUs, specifically Intel SGX and Nvidia H100 (in TEE mode), to provide on-chain confidential compute to nearly every major blockchain. Secret is also adding FHE to allow private data to be used securely outside the TEE while staying encrypted.

@AutomataNetwork: Coprocessor using TEEs for secure computing across blockchains. Ensures the liveness of a TEE through cryptoeconomic security using Multi-Prover AVS with EigenLayer to mitigate liveness risks.

@tenprotocol: Ethereum L2 using TEEs, specifically Intel SGX for confidential computing, enabling encrypted transactions and smart contracts with enhanced privacy.

@MarlinProtocol: TEE Coprocessor that integrates various TEEs, including Intel SGX, AWS Nitro Enclaves, and NVIDIA H100 (in TEE mode), to provide confidential computing services.

@Spacecoin_xyz: Building a TEE blockchain on satellite-operated infrastructure. Nodes orbit Earth at 7km/s, over 500km high, using low-cost CubeSats—making the hardware tamper-proof and data secure from adversarial physical access.

Quantum resistance protects cryptographic protocols against quantum computers, while Information-Theoretic Security (ITS) ensures systems remain secure even with unlimited computational power.

MPC protocols are typically quantum- and ITS-secure, as secrets are split into shares, requiring access to a sufficient number of them for reconstruction. However, ITS depends on assumptions like an honest majority; if these fail, ITS no longer holds. ITS is generally a baseline for MPC unless the protocol diverges significantly from standard designs.

Fully Homomorphic Encryption (FHE) is considered quantum-secure, leveraging lattice-based cryptography like Learning with Errors (LWE). However, it is not ITS-secure, as its security relies on computational assumptions that theoretically could be broken with infinite resources.

Trusted Execution Environments (TEEs) do not provide quantum resistance or information-theoretic security (ITS) because they rely on hardware-based security guarantees, which can be compromised through hardware vulnerabilities or side-channel attacks.

Ultimately, while ITS and quantum security are important, the practical security of a protocol depends on its underlying assumptions and its ability to withstand real-world adversarial conditions.

We can envision a future where TEEs become the default for low- to medium-stakes applications, offering a practical balance between efficiency and security. However, for high-stakes use cases—like AI and DeFi protocols—using TEEs alone could inadvertently create massive "bug bounties," incentivizing attackers to exploit any vulnerabilities and compromise user funds. For these scenarios, more secure frameworks like MPC and FHE as it matures––will be essential.

Each PET has unique capabilities and trade-offs, so understanding their strengths and limitations is crucial. The ideal approach combines flexible, multimodal cryptographic schemes tailored to specific needs. Signal’s PIN recovery system exemplifies this by combining PETs like Shamir's Secret Sharing (SSS), Secure Enclaves (TEE), and client-side encryption. By splitting sensitive data into shares, encrypting it on the user’s device, and processing it in secure hardware, Signal ensures no single entity can access the user’s PIN. This highlights how blending cryptographic techniques enables practical, privacy-preserving solutions in production.

You can combine MPC + TEE, MPC + Homomorphic Encryption, MPC + ZKPs, FHE + ZKPs, and more. These combinations enhance privacy and security while enabling secure, verifiable computations tailored to specific use cases.

Privacy-enhancing technologies like MPC, FHE, and TEEs open a zero-to-one moment—a new whitespace in blockchains with shared private state. They enable what was once impossible: truly private collaboration, scalable confidentiality, and trustless privacy that push the boundaries of innovation.

Privacy 2.0 unlocks a completely new design space that makes crypto limitless, enabling innovations we’ve only begun to imagine.

The time to build some cool shit is now.