I was once asked whether we can trust a billion dollars to a Web3 TEE project. Not to a single TEE in a Google datacenter, but to a decentralized TEE network. My answer was “No, but I believe we can get there.” For that we need to solve both permissionlessness and decentralization for TEEs - making TEE systems open to anyone while keeping them secure when the hardware itself can be physically compromised. This is my take on where that stands, drawing on work I’ve been doing since 2024, on recent physical attacks that changed the conversation, and on a provider-by-provider assessment of what’s available today. I work at Ritual, which is building a decentralized L1 that uses TEEs. Everything I describe here applies to us too.
1. Prior work and how we got here
TEE attestation has a structural gap that most of the Web3 community has been ignoring. I’ve been writing about it since mid-2024.
In June 2024, I published TEE Engineering Part 1 on the Flashbots forum. The thesis: cloud attestation replaces direct hardware attestation with trust in opaque hyperscaler verifier services. Microsoft Azure Attestation is a proprietary black box. You trust their signature, not an independently verifiable hardware claim. I called what cloud attestation actually gives you “Data Center Execution Assurance” - a statement that a TEE is running inside the cloud provider’s physically protected environment, and not in somebody’s side-channel lab.
That post ended with a future-work section that reads, in retrospect, like a checklist for everything that happened in 2025: check alternative cloud attestation from other providers, ask for auditable attestation with reproducible builds, research open-source toolchains for datacenter execution assurance, and develop “Proof of Cloud” - the idea that you could prove an enclave is associated with a cloud operator even if the provider doesn’t support it. Every one of those items found its way into the 2025 conversation. Google Cloud’s attestation turned out to have no real operator endorsement for TDX or SEV-SNP. The reproducible-builds ask for GCP’s firmware went nowhere because Google’s internal OVMF fork is built with a proprietary toolchain that diverges from upstream edk2 and nobody has picked up the work. The formal academic treatment of datacenter execution assurance became the DCEA paper. Proof of Cloud shipped as a separate, witness-based approach to the same problem.
In November 2024, I gave a talk at TEE.salon Bangkok titled “Where you run your TEEs matters”. The talk argued that cloud attestation is insufficient, that physical TEE security is brittle, and that permissionless TEE systems need something beyond what the current stack provides. After the talk, a working group convened with people at Google and others in the ecosystem to push for DCAP attestation improvements. The work fizzled when several of us moved on to other things.
None of this was prediction. The structural weaknesses were visible. What changed in 2025 is that someone built the hardware to exploit them.
Three things get conflated in almost every TEE discussion. I need to separate them before any of what follows makes sense.
- Confidential execution: memory encryption and hardware isolation. AES-XTS, SGX enclaves, TDX trust domains, SEV-SNP.
- Measurement and attestation: cryptographic proof of what software and configuration is running.
- Custody and physical integrity endorsement: a verifiable statement, bound into or alongside the attestation chain, covering two things - custody (who physically controls the hardware) and physical integrity (that the hardware is protected from tampering). Throughout this post, “endorsement” refers to this layer.
Layers 1 and 2 are what CPU vendors give you. Layer 3 is what this entire post is about. Before 2025, you could argue that a verified attestation chain implicitly covered physical integrity: if the measurements matched, the platform couldn’t be silently impersonated. That argument is dead.
2. What broke
In September and October 2025, two related attacks showed that anyone with physical access to a server and about $1,000 in equipment can extract signing keys from Intel’s attestation chain, then forge attestation quotes that pass standard DCAP verification.
WireTap (disclosed September 30, 2025; paper) targeted DDR4-based Intel SGX. Under $1,000 in hardware, under 45 minutes, and they had a signing key that let them forge SGX quotes verified by Intel’s DCAP Quote Verification Library. They demonstrated the attack against four Web3 networks [1][2][3][4], including joining Secret Network’s test network with a forged attestation and receiving the consensus seed. The paper’s explicit recommendation: “We recommend not allowing arbitrary entities to join as trusted nodes, instead requiring further permissions to obtain trusted status.” That is, quite literally, an argument against permissionless TEE network participation.
TEE.fail (disclosed October 28, 2025; paper) extended this to DDR5 and Intel TDX - meaning every TDX-capable CPU shipped since 4th gen Xeon Scalable. Same cost. About 15 minutes. They forged a TDX quote with nonsensical measurements that verified at Intel’s highest trust level, UpToDate. They demonstrated it against a non-production Flashbots BuilderNet instance and against Automata’s on-chain DCAP verification on testnet.
Intel’s position: physical bus interposition is explicitly out of scope. No CVE. The memory-encryption engine cannot be fixed via microcode. AMD’s position: also out of scope (AMD-SB-3040). No firmware updates planned.
This is a hardware-level physical attack. Software side-channel attacks and microarchitectural vulnerabilities can be patched through microcode updates and TCB recovery. Physical bus interposition cannot. The vulnerability persists for the lifetime of the hardware.
3. Physical security: what we get wrong
Most of us are software-native. We don’t have professional intuitions about physical security. Our mental model of physical attacks is either the $5 wrench attack on individuals or spy movies where agents break into vaults, bypassing laser grids. Both paint a picture of physical security that isn’t representative of how datacenters actually work, and that shapes how we evaluate the topic.
But there’s no fiction in physical security at hyperscaler datacenters, it’s real and substantial. Here’s what a Google datacenter actually looks like from a security perspective: armed guards, biometric access control, 24/7 surveillance, six layers of physical access controls, and physical destruction of decommissioned storage media. Amazon and Microsoft operate comparable facilities. A random attacker cannot walk into a GCP datacenter and start attaching interposers onto DIMMs. That’s a meaningful security property.
But the TEE.fail briefcase puts the attack cost at $1,000 and the attack time at 15 minutes. Datacenter physical security is the only thing standing between that briefcase and your attestation keys. If someone gets physical access - even briefly, even through an insider - the attack is cheap and fast. The security guarantee is entirely dependent on the datacenter preventing unauthorized physical access. That’s a reasonable thing to depend on for most threat models, and it’s important to acknowledge that rather than dismissing physical security as worthless.
Physical attacks sit on a stealth spectrum. A hardware interposer attack like TEE.fail is loud: someone has to obtain the equipment, get past armed guards and biometrics, install it on a live system, and retrieve the data - a chain of people who know what’s happening. That’s hard to pull off without traces or internal whistleblowers, and hyperscaler physical security raises the cost of every step. The quieter end is where the structural critique bites. Someone with a national security letter will likely get everything via the cloud provider’s legal team, won’t even have to show up physically and the customer never finds out it happened. A software-level attack through unmeasured ACPI tables or a compromised firmware build pipeline sits at the same quiet end: potentially executable by a single malicious insider with privileged access.
A national security letter is a US government demand for records with a built-in gag order. The cloud provider cannot tell the customer the demand exists. The US government issued over 11,000 NSLs in 2023. These are routine, not exceptional.
For a TEE workload, the threat from compelled access has two components. First, the cloud operator controls the hypervisor, firmware pipeline, network, and I/O channels around the TEE. A compelled operator can instrument that environment to capture data in transit, at I/O boundaries, or through the firmware update pipeline. TEE memory encryption is supposed to protect data in DRAM, but it doesn’t prevent data from flowing through operator-controlled interfaces. Second, and this is speculative but structurally sound: Intel and AMD almost certainly retain the root key material for every CPU they ship, since they need it for the provisioning ceremony. An NSL to the CPU vendor could compel disclosure of per-platform signing keys. With both the man-in-the-middle position (from the cloud operator) and the CPU root keys (from the vendor), the full TEE security model collapses because both encrypted data and encryption key are in the same hands. Neither alone is sufficient, but both are achievable via legal process if the operator is within reach.
This is globally exploitable. If the infrastructure and all communication paths are within the jurisdiction of the entity emitting the equivalent of an NSL, one must expect the TEE security guarantees of the nodes running in that particular jurisdiction to be compromised. Jurisdictional diversity of operators isn’t a proper mitigation alone, if all nodes are treated equal, have full view of confidential data, one compromised jurisdiction is enough. With such a threat model, additional data fragmentation measures such as MPC wrapping must be taken.
TEE systems offer two different guarantee types that behave oppositely under operator diversity. Integrity guarantees stack: run the same workload across N operators, and one honest operator detecting output divergence is enough to flag the problem. More diversity, more robust. Confidentiality guarantees do the opposite: each operator that holds the secret is another single point of failure. More diversity, more brittle. Patching this with MPC restores the stacking property but pays a real cost in latency, throughput, and network traffic that fights against the premise of global distribution.
Which is why permissionlessness is not decentralization. Permissionlessness is a prerequisite for decentralization. A system can be permissionless in protocol - anyone can spin up a node - while being centralized in hosting: every node running on GCP TDX VMs in US regions is permissionless but operationally concentrated. The reverse doesn’t hold: a network gated by an invitation list isn’t really decentralized, since the gatekeeper itself is a point of control. This post is about permissionlessness - anyone can produce a valid endorsed attestation and participate. Decentralization splits along the integrity/confidentiality line: for integrity it’s straightforward - add more operators across more jurisdictions running the same workload, the guarantee gets stronger. For confidentiality it runs into the double conflict named above - more operators breaks confidentiality directly, and the standard patch (MPC) carries costs that work against global distribution. How to actually build confidential decentralized TEE systems under that double conflict is its own engineering problem and is out of scope here. Where the discussion below touches on jurisdictional diversity, treat it as relevant context, not a recipe.
4. The current toolkit
The provider analysis below focuses on confidential VM deployments (TDX, SEV-SNP) rather than SGX enclaves; SGX figures in the WireTap discussion earlier but isn’t the subject here.
GCP: the most used, the most exposed, and the closest to being fixed
GCP is where most hyperscaler Web3 TEE projects run. We got here due to a Web3-facing team that genuinely engaged with the community and tooling that builds on vanilla Intel TDX DCAP rather than rolling a proprietary attestation protocol. Those are real strengths.
The problem: GCP has no cryptographic operator-signed custody statement for TDX or SEV-SNP. When you verify a TDX quote from a GCP Confidential VM, you verify that the hardware is genuine Intel TDX and that firmware measurements match expected values. You do not verify that the VM was running inside Google’s infrastructure. There is no Google signature binding hardware identity to their physical environment.
There’s a feature people may mistake as a genuine custody statement: Google does publish firmware binaries and sign their measurements via gce-tcb-verifier. You can verify that the binary running in your CVM is the binary Google intended to deploy. That’s a real step above providing nothing. But the source code for that binary isn’t published. The build isn’t reproducible - Google’s internal OVMF fork uses a proprietary toolchain that diverges from upstream edk2, and upstream itself has non-deterministic builds. So the firmware is inspectable but not independently auditable. You can see the binary. You cannot verify what it does without reverse engineering it.
And I can run that binary in my basement lab. Google publishes the OVMF binaries in a GCS bucket. I take one, boot it in QEMU, and the resulting TDX attestation looks exactly like one from a GCP datacenter. Because nothing in the attestation says “this came from Google.” No signature, no endorsement, no binding of hardware identity to Google’s physical infrastructure.
If publishing binaries as a transparency measure feels incomplete to you, it is. Most of the push came from one person: Dionna Glaze. If you watch her presentation on UEFI transparency at the CCC TAC Meeting there was much more planned, including attested builds and possibly release of source at some point. The problem is: she left Google for Apple in 2025. Before leaving, she documented the state of things:
- Google’s OVMF fork is not published as source, built with an internal toolchain, not reproducible
EV_POST_CODEevents are deliberately not measured to PCR0 so Google can change firmware and ACPI tables across reboots- ACPI table digest signing is not done
That last point about ACPI tables matters because of BadAML (ACM CCS 2025, previewed at BlackHat Europe 2024). Host-supplied ACPI tables carry AML bytecode that the guest kernel executes with arbitrary physical-memory read/write, including into private encrypted pages. Edgeless Systems reproduced this end-to-end on bare-metal SEV-SNP. On GCP, ACPI tables come through an unmeasured FwCfg interface and GCP publishes no signed ACPI reference values. Intel TDX’s TDVF does measure installed ACPI tables into RTMR[0] when configured correctly, but GCP’s configuration doesn’t sign those measurements.
So what this all means is that GCP could easily backdoor any TEE via their boot firmware, and even if they’d open source it and add reproducible builds, not signing the ACPI tables would reintroduce that backdoor in a more opaque way. You could also frame it in this way: What use is a signed firmware binary that may be benign if you can sideload the unsigned backdoor via ACPI tables on demand.
Dionna also said something worth quoting about the real value proposition of the present day confidential computing technology: “The confidential computing threat model to remove your host from the trust boundary is a bad one. No security layer has ever been bulletproof. CC is for making compelled disclosure of customer data technically too expensive… It makes no business sense to destroy customer trust by ordering anyone at any time to steal from their customers because one whistleblower destroys your multi-billion dollar business.” That framing is honest, and it’s what physical security at datacenters actually provides. The economic-cost argument relies on a specific legal and business regime - it holds within a single CSP-jurisdiction pair, but doesn’t translate cleanly to a node sitting in a different legal context. Our difficulty is accepting that trusting a datacenter’s physical security is the most practical approach available right now for using TEEs with any meaningful integrity.
Google does offer Confidential Space, a managed PaaS that runs customer containers (not arbitrary VMs) and produces Google-signed OIDC attestation tokens. Architecturally this is the same shape as Azure - a proprietary cloud-verifier (Google Cloud Attestation) appraises the hardware quote and issues claims tokens. For permissionless TEE systems Confidential Space helps - the Google-signed token can serve as an operator endorsement - but the workload is constrained to containers.
Here’s the thing about GCP that gets lost in the criticism: GCP is the closest of the three hyperscalers to having a clean permissionlessness story. They build on vanilla Intel TDX DCAP. They don’t wrap the attestation in a proprietary layer. Intel has published Platform Ownership Endorsement (PoE), a standardized mechanism for operators to cryptographically sign custody of specific CPUs, using the PIID that already exists in every DCAP quote. If GCP adopted PoE, they’d have: vanilla DCAP attestation (already there) plus a Google-signed operator endorsement (PoE) plus on-chain verifiability for both (DCAP is already on-chain via Automata). That combination would actually be the strongest of any hyperscaler. Stronger than Azure (whose proprietary attestation is too complex for direct on-chain verification) and stronger than Nitro (which isn’t really a TEE in the CPU-confidential-computing sense and locked to one operator). The gap between where GCP is and where it needs to be is technically small - adopt PoE, bridge their internal protobuf-based measurement infrastructure to Intel’s CoRIM format, sign the PIID. That bridging work was in progress before Dionna left, then went quiet. As of this writing, internal binding work is reportedly underway via the PPID, possibly landing by end of Q2. Google has a bare-metal confidential-computing option where customers can bring their own software stack. Whether the in-progress work lands as a Google-specific binding only or if Intel PoE will be integrated as well is still open, and whether the bare-metal option includes any operator endorsement is unclear.
Azure: has the endorsement, makes everything else harder
Azure wraps TDX and SEV-SNP in a paravisor (OpenHCL/OpenVMM) and uses nested virtualization. The TDX MRTD measures Microsoft’s paravisor binary, not your guest OS - your guest’s boot measurements come through vTPM PCRs that the paravisor manages inside the trust domain. Azure then provides a vTPM with an AK certificate chain rooting in the Azure Virtual TPM Root Certificate Authority 2023. That AK chain is an operator endorsement - it says “this is running in Azure.” That’s the one thing GCP doesn’t have for TDX/SEV-SNP. But the hardware attestation underneath is attesting Microsoft’s code, not yours.
Thus what you gain in endorsement, you lose everywhere else. The paravisor is an opaque proprietary setup. Microsoft open-sourced it but there’s no reproducible-build path, no public binary-to-attestation linkage, and Microsoft’s own FAQ says the TDX boot attestation process is “opaque to the user”. You can’t externally verify that the running paravisor corresponds to the published source. The attestation chain is heavyweight: dual PKI (Intel plus Azure), TPM quote parsing, event log replay, Runtime Claims JSON canonicalization, and cross-binding through report_data. Direct on-chain verification is not practical. Indirect verification is possible in two ways 1. verify Azure attestation off-chain inside a non-Azure TEE, then verify that TEE on-chain - but that’s a two-hop path with its own trust assumptions or 2. Only verify the JWT claims emitted by Microsoft Azure Attestation (MAA), Microsoft’s hosted verifier service, onchain - but no one has worked on this yet.
During my time at Flashbots, we tried repeatedly to engage Azure on Web3 use cases. They weren’t interested. Azure has the endorsement property the ecosystem needs, but no apparent interest in making it accessible to Web3 builders.
AWS Nitro: not a TEE, but the model everyone should study
Nitro is not a hardware TEE. No memory encryption, no hardware isolation in the Intel/AMD sense. If your threat model includes an AWS insider with physical access, Nitro does not help.
But if you accept that all three hyperscalers require operator trust - which they do - Nitro is the cleanest model. A Nitro attestation is a single CBOR-encoded, COSE-signed document. One signature chain to the AWS root. Verify it, check the measurements, done. No dual PKI, no event log replay, no JSON canonicalization. This is why Nitro attestation is directly verifiable on-chain (Base’s Solidity validator, Automata’s library) and why it’s the only attestation where operator endorsement and measurement verification happen in a single on-chain step. Azure can achieve operator-endorsed on-chain verification, but only indirectly through a TEE intermediary. GCP can do direct on-chain DCAP verification, but without operator endorsement.
One operational limitation we hit directly at Ritual: Nitro enclave networking is bottlenecked through vsock to the parent EC2 instance. High-throughput workloads degrade severely.
Hardware integrity and operator identity are fused into a single trust anchor: AWS. That’s a strength for verification simplicity and a limitation for decentralization - the only entity who can ever emit a Nitro attestation is AWS.
The real comparison
Today, the practical result across all three is the same: you trust the operator. GCP’s firmware is a signed binary you can’t audit. Azure’s paravisor is open-source code you can’t tie to a running attestation. None of them give you independent verification of what’s actually executing in the TEE. Nitro doesn’t even try - it tells you upfront that AWS is the trust root and that’s the deal.
The difference is in the path forward, not the present. GCP stands apart by not enshrining proprietary protocols into the attestation chain. Because GCP uses standard DCAP, Intel’s PoE mechanism can plug in cleanly. Azure rolled its own protocol, and as of this writing it doesn’t look like they’re planning to move off of that path. Nitro is a completely separate model, with trust in the operator enshrined.
Intel Platform Ownership Endorsement (PoE)
Intel PoE is the most important near-term development. It evolves an earlier Intel proposal floated and approved during the 2024 working group with Google: using the PPID (Platform Provisioning ID, a per-CPU identifier in every DCAP quote) as a hardware-to-quote binding. PoE replaces PPID with PIID (Platform Instance ID), a related identifier with cleaner revocation properties, and adds an operator-signed endorsement on top of the binding rather than binding alone.
PoE lets a platform operator sign an endorsement of the PIID using the IETF CoRIM format. That signature says: this operator controls the physical platform that produced this attestation. It’s the layer-3 primitive that’s been missing.
The factory-reset semantics matter for post-TEE.fail recovery: run an SGX factory reset and the PIID regenerates. Old endorsements become invalid. Forged quotes under the old identity fail verification against current endorsements.
PoE is opt-in and the tooling hasn’t shipped yet. What it unlocks: any hosting provider - OVH, OpenMetal, colocation facilities - can act as an operator root on equal footing with hyperscalers. That materially widens the set of parties who can produce a valid physical-integrity endorsement and is the most direct path to operator diversity. No equivalent mechanism has been announced for AMD SEV-SNP.
Proof of Cloud
Where PoE is an operator-signed endorsement, Proof of Cloud takes a different approach: a tiered alliance/registry. Today only Level 1 is operational - human witnesses verifying that specific TEE hardware is under a specific provider’s control. The spec also describes a Level 2 cryptographic tier that incorporates the DCEA paper’s vTPM cross-linking approach, and a Level 3 continuous-monitoring tier. Neither L2 nor L3 is deployed.
The project is early. The website accepts attestation quotes for verification via Phala and Nillion backends, but the public hardware registry - the append-only transparency log described in the charter - doesn’t have a queryable interface yet and has no on-chain verification path. The L1 human-witness model requires per-CPU verification that doesn’t scale. But it’s the first attempt at a custody-endorsement layer that doesn’t reduce to a single operator’s PKI. Secret, NEAR, Oasis, and Nillion announced a joint Proof-of-Cloud effort alongside their TEE.fail responses.
PoE and Proof of Cloud target related but distinct problems. PoE assumes a cooperating operator who signs an endorsement; Proof of Cloud solves a related problem for scenarios where the operator can’t or won’t sign an endorsement themselves. The DCEA approach now adopted as PoC’s L2 spec further targets a setting where the hypervisor itself is potentially malicious, binding hardware identity to runtime state via TPM cross-linking independently of the operator’s signature.
Large and mid-sized hosting providers
OVH announced bare-metal TDX in 2024 - the earliest non-hyperscaler offering without proprietary firmware in the attestation chain. OpenMetal and similar providers support TDX on XEON hardware.
These providers are the natural substrate for permissionless TEE systems. Direct hardware access, no hyperscaler abstraction layer, potential for jurisdictional diversity. But none provide a native operator endorsement today. Without PoE, a TDX attestation from an OVH server is indistinguishable from one produced in an attacker’s garage. PoE is what makes these providers viable.
Phala Cloud, running on dstack, uses these same hosting providers underneath but is working to close the endorsement gap through Proof of Cloud rather than waiting for PoE adoption. The operator-endorsement gap today is the same as any other mid-sized host, but Phala is one of the platforms behind the Proof of Cloud effort working to fill it.
Trustless TEE hardware
The Trustless TEE Initiative is the long-horizon answer: open-source, community-fabricated TEE hardware that doesn’t require trust in Intel, AMD, or cloud operators. PUF-based signing hardware where the key isn’t stored - it’s regenerated from physical silicon variations that probing tends to destroy (UCLouvain/SIMPLE-Crypto), open silicon with IRIS non-destructive chip inspection, and a full next-gen TEE driven by Fabric Cryptography. These are multi-year, multi-million-dollar research programs. The PUF signer is a four-year program. The Next-Gen TEE needs a feasibility study before the actual build. This is the only path to full permissionlessness, and it’s years away.
Darkbloom
A recent project worth watching is Darkbloom (Eigen Labs), which takes a completely different approach: decentralized AI inference on consumer Apple Silicon Macs, using Secure Enclave key custody and Apple managed-device attestation instead of server-grade TEE hardware. If this worked as advertised, it would be close to the dream - consumer hardware enabling genuinely decentralized, permissionless participation without datacenter dependencies. But the reality is early and constrained. The isolation is software-based (macOS hardening, SIP, Hardened Runtime, optional Hypervisor.framework page tables), not hardware memory encryption. The TEE technologies discussed in this post use hardware to enforce isolation; Darkbloom uses the operating system. The confidence level is roughly comparable to trusting that nobody can break into a hardened Linux container from the host - the direction is inverted (protecting the workload from the machine owner rather than protecting the host from the workload), but the strength of the boundary is in the same class. The coordinator is centralized under Eigen Labs. The source is proprietary (“All rights reserved”) and the repo contains a provisional patent draft for the core technique, which makes the intention around reuse clear enough.
Comparison table
| Provider | TEE technology | Custody endorsement | On-chain TEE verification | On-chain custody endorsement | PoE ready |
|---|---|---|---|---|---|
| AWS Nitro | Hypervisor (no memory encryption) | Yes, operator-signed (fused into attestation) | Direct (~63M gas Solidity) | Direct (same signature) | N/A |
| Azure | TDX, SEV-SNP via paravisor + vTPM | Yes, operator-signed (AK cert chain) | DCAP only (~4-5M gas); composite not direct | Indirect (via TEE intermediary) | Complex (proprietary attestation) |
| GCP | TDX, SEV-SNP (vanilla DCAP) | No | Direct (DCAP ~4-5M gas) | No (nothing to verify) | Clean fit (vanilla DCAP + PIID) |
| OVH / OpenMetal | Bare-metal TDX or SEV-SNP | No | Direct (DCAP) | No (not yet) | Natural fit |
| Phala Cloud | TDX via dstack | Yes, witness-based (PoC, early) | Via Automata DCAP | No (PoC has no on-chain path) | Yes (but pursuing PoC) |
5. How the ecosystem responded
| Pattern | Networks | Status |
|---|---|---|
| Directly attacked | Secret, Phala, Crust, IntegriTEE (WireTap); BuilderNet lab, Automata testnet, Phala dstack (TEE.fail) | Migrated or added allowlists |
| Automata-downstream | ElizaOS, Espresso, Puffer UniFi (named in TEE.fail paper) | Exposure inherited from Automata |
| BuilderNet-class block builders | BuilderNet, Unichain (via Rollup-Boost) | Permissioned by design, IP allowlists |
Here’s what nobody wants to talk about: Automata provides the on-chain DCAP verification infrastructure that most of the ecosystem anchors to - deployed across 11 mainnets with code-level integrations from Taiko, Flashbots, Uniswap, ElizaOS, Phala, Puffer, Espresso, and others. TEE.fail demonstrated that a forged quote passes their verification. The TEE.fail paper names ElizaOS, Espresso, and Puffer’s UniFi as projects relying on Automata that “lose the guarantees” under the forged-quote attack. Several of those integrators wrap Automata’s bare verification with additional admission controls - MRENCLAVE allowlists, IP gating, slashing layers - but the structural failure stands: on-chain DCAP attestation covers only Layers 1 and 2 (hardware attestation and measurement). What’s missing is on-chain Layer 3 verification. Anyone whose admission decision rests solely on bare DCAP acceptance inherits the failure mode.
Every network that published a response to these attacks either already had operator admission controls beyond raw attestation, or added them afterward. None of them said they would remain open to anyone with just a valid attestation quote.
Everyone moved to permissioned. Or was already there.
6. Where permissionlessness actually stands
Permissionlessness in TEE systems is possible today if you use endorsements - though whether endorsement-gated participation counts as “permissionless” depends on how strict your definition is. The mechanisms exist: Intel PoE provides a standardized endorsement that any DCAP-capable operator can sign. Azure’s AK chain provides an operator endorsement for Azure-hosted CVMs. Nitro’s fused attestation provides operator endorsement for AWS.
Systems running on AWS or Azure already have endorsements by design - Nitro’s fused attestation and Azure’s AK chain are endorsements. Most are using them within a permissioned context, not to enable open participation. There are early exceptions: Secret Network’s semi-permissioned model lets Azure-hosted nodes join without manual approval - Azure’s signature acts as the endorsement that gates admission. Non-Azure nodes still need a whitelist or governance vote. Marlin Oyster describes permissionless operator onboarding on Nitro. These are real steps, but stay locked to a single provider’s endorser.
This is not full permissionlessness. Using endorsements means trusting the endorser. Full permissionlessness requires hardware that doesn’t need an endorsement at all - trustless hardware where the physical design itself prevents key extraction. That hardware is being researched by the Trustless TEE Initiative. It is not close to production.
Partial permissionlessness through endorsements is achievable now and should be reintroduced. Full permissionlessness through trustless hardware is years away.
7. What needs to happen
A TEE network where nodes run across multiple hosting providers in different jurisdictions, each producing verifiable operator endorsements, verified end-to-end on-chain - that doesn’t exist today. Here’s what’s blocking it, who needs to do the work, and what builders can do meanwhile.
Someone needs to write a CoRIM PoE verifier for EVM. DCAP quote verification is already on-chain via Automata at ~4-5M gas. A CoRIM-encoded PoE endorsement is CBOR, which is far simpler to parse on-chain than ASN.1/X.509. Verify the operator’s signature over the PIID, check it matches the PIID in the DCAP quote. If the signature uses secp256k1, verification is near-free on EVM. This is the missing piece that would give the full stack - hardware attestation plus operator endorsement, both on-chain - without exotic proving infrastructure.
Automata should build on-chain Layer 3 verification mechanisms. Automata has been the project for on-chain attestation and is best positioned to produce on-chain verifiers for both PoE and Proof of Cloud. Acknowledging the landscape shift since TEE.fail and joining the Proof of Cloud effort would be the natural next move.
Intel needs to ship PoE integration into DCAP. The spec exists but the tooling isn’t live and PoE endorsements are still external artifacts that operators need to distribute out-of-band. Intel has described a future DCAP version where PoE is embedded directly in the quote, which would make adoption straightforward - the endorsement travels with the attestation, one artifact to verify. Until that ships, rational operators won’t invest in building a stage-1 endorsement pipeline they’d have to scrap once stage 2 lands. PoE adoption is blocked on Intel, not on operator willingness.
GCP needs to ship its binding work and consider PoE. Internal work is reportedly underway to bind TDX quotes to GCE instance identity via the PPID, possibly landing by end of Q2; a bare-metal confidential-computing option exists where customers can bring their own software stack. The technical gap to fully PoE-compatible operator endorsement is small: bridge their internal protobuf measurement infrastructure to CoRIM, sign the PIID. This would give GCP vanilla DCAP plus operator endorsement plus on-chain verifiability - the strongest combination of any hyperscaler. Whether the in-progress work lands as a Google-specific binding only or also integrates Intel PoE is still open.
Proof of Cloud needs an on-chain registry. The verification mechanism works. The charter describes an append-only transparency log. That log doesn’t have a queryable public interface yet and has no on-chain verification path. Without it, Proof of Cloud results are off-chain assertions that a relying party can’t independently verify in a smart contract.
At least one mid-sized hosting provider needs to adopt PoE. OVH or OpenMetal signing PIIDs for their bare-metal TDX servers would be the first real test of permissionless TEE operation outside hyperscalers. This is where jurisdictional diversity starts - not with three US cloud providers, but with hosting operators across geographies each producing their own verifiable endorsements.
Meanwhile, if you’re building today, the choices are narrow. Phala / dstack is a viable option - TEEs, GPUs, partial permissionlessness via PoC, currently used at Ritual. Not the cheapest, and the risk is single-vendor lock-in and a capacity ceiling that gets tighter as agent workloads land.
GCP (vanilla TDX) is the most promising of the hyperscalers - vanilla DCAP, tracking PoE, internal binding work in motion. If they ship, you get the strongest combination on the market. If they don’t, no operator endorsement to fall back on.
Azure, Nitro, or GCP Confidential Space is fine if you want something solid right now - AK chain, fused attestation, or Google-signed OIDC token. Among these, only Nitro is directly verifiable on-chain today. Don’t expect them to evolve; none have shown appetite to change what they ship.