Verifiable Compute’s Hardware Problem: TEEs Keep Getting Broken
Trusted execution environments quietly became verifiable AI compute's default choice. Two 2025 attacks showed the hardware attestation behind them can be forged with under $1,000 in gear.
An AI agent that manages a treasury, prices a loan, or executes a trade on someone else’s behalf makes an implicit promise every time it returns an answer: this is genuinely what the model produced. Nothing forces that promise to be true. An operator could swap an advertised frontier model for a cheaper one, alter an output after the fact, or simply misstate what ran, and no one would necessarily know. Crypto’s answer to that problem is a category now loosely called verifiable compute: using cryptography, hardware, or economic incentives to make a computation’s outcome checkable instead of merely trusted.
Most of the verifiable compute that is actually live today, moving real inference requests rather than sitting in a whitepaper, does not run on zero-knowledge proofs or clever mechanism design. It runs on trusted execution environments: hardware enclaves borrowed from the same chip families that secure parts of mobile payments and enterprise cloud services, repurposed to attest that a specific model ran on specific inputs. That hardware bet looked reasonably solid until the second half of 2025, when two separate teams of academic researchers extracted the cryptographic keys behind that attestation using equipment that costs less than a used laptop.
Why “Verifiable” Became AI Crypto’s Central Problem
The stakes are not hypothetical. On March 18, 2024, the SEC settled charges against two investment advisers, Delphia and Global Predictions, for misrepresenting how much artificial intelligence actually sat behind their products, in what the agency called its first enforcement actions over “AI washing.” Delphia paid a $225,000 penalty and Global Predictions paid $175,000, according to the SEC’s press release. Both cases were resolved the old fashioned way: examiners compared marketing claims against what the firms had actually built and found a gap.
That approach does not scale to autonomous agents transacting thousands of times a day across chains, wallets, and counterparties nobody is manually reviewing. Verifiable compute tries to close the gap by producing something closer to a receipt: a cryptographic or hardware backed artifact asserting which model ran, on which inputs, and that the output was not altered afterward. Without it, every claim an AI agent makes collapses into the same question smart contract auditors already ask, and the honest answer is usually a shrug: you have to trust someone.
Four Ways to Prove a Machine Didn’t Lie
Builders have converged on four broad strategies for making a compute claim checkable, and each trades off against the others in predictable ways.
Zero-knowledge machine learning (zkML) compiles a model into an arithmetic circuit and produces a mathematical proof that a specific output followed from a specific input under a specific model, without requiring trust in any party at all. The catch is cost: the non-linear operations that dominate modern neural networks are expensive to express as circuits, so proving remains far slower and pricier than simply running the model.
Trusted execution environments (TEEs) take the opposite trade. A chip vendor, not a mathematical proof, vouches that a piece of code ran unmodified inside a hardware enclave sealed off from the operating system and the cloud operator. It is fast, cheap, and available today, at the cost of trusting a silicon supply chain that most crypto projects have no way to inspect.
Optimistic, or crypto-economic, verification skips cryptographic proof for most computations and instead posts a bond. Anyone can challenge a result during a set window; if the challenge succeeds, the challenger is paid out of the poster’s stake. It is cheap when nobody cheats and only expensive when someone does, which is the model opML and similar optimistic systems use to bring AI inference onchain without paying for a fresh proof on every request.
Fully homomorphic encryption (FHE) is the outlier of the four: it lets a third party compute directly on encrypted data without ever decrypting it, which solves a privacy problem more than an integrity one. It remains the least mature and most computationally expensive approach, though projects like Zama have pushed real throughput gains over the past two years. Understanding which of the four a project actually uses, and which it merely gestures at in its documentation, is the difference between evaluating a real security model and reading marketing copy.
Why Trusted Execution Environments Won the Adoption Race
Of the four approaches, TEEs are the only one running production workloads at meaningful scale today. EigenCloud’s EigenCompute runs containerized application code inside confidential virtual machines on Google Cloud, using Intel TDX or AMD SEV-SNP hardware, with every execution attested and anchored onchain; its EigenAI product layers a deterministic inference engine on top so outputs are reproducible to the bit, turning verification into a byte-for-byte equality check rather than a fresh cryptographic proof each time. Phala Network built a worker mesh directly on Intel SGX enclaves, migrated its token from a Polkadot parachain to a dedicated Ethereum layer-2 in late 2025, and now says it has processed billions of LLM tokens through its GPU-backed TEE fleet, recently adding DeepSeek V4 Flash and updated Qwen models to its confidential compute catalog. Marlin’s Oyster network deploys workloads into AWS Nitro Enclaves and Intel SGX with onchain attestation verification. Automata Network runs DCAP attestation contracts that verify Intel SGX and TDX quotes directly inside EVM smart contracts, with a SNARK-compressed path to cut gas costs. Atoma Network pairs TEEs with a token-staked “Sampling Consensus” protocol on Sui, built together with the Sui Foundation. EigenCompute’s early production users hint at what actually gets deployed on this kind of stack today: OpenFront runs onchain gaming tournaments on it, the institutional credit market Cap uses it alongside Symbiotic for parts of its risk infrastructure, and EigenCloud has integrated with Google’s Agent-to-Agent protocol, the kind of workload where a chip-signed attestation is treated as good enough to release funds.
The appeal is straightforward. NVIDIA markets its confidential computing mode on H100 and H200 GPUs as delivering close to native performance for confidential workloads, according to the company’s own confidential computing documentation, because the encryption is handled largely in dedicated silicon rather than software. NVIDIA extends the same design across its Hopper, Blackwell and upcoming Rubin GPU generations, which matters because most of the AI inference workloads crypto projects actually want to verify are GPU-bound, not CPU-bound; a verifiable compute stack that cannot cheaply attest a GPU is not very useful for anything larger than a toy model. Compare that to a zkML circuit, where proving a single non-linear layer can cost orders of magnitude more than just running it, and a TEE’s near-native speed looks like the only realistic way to ship a product this year instead of a research paper next year.
| Project | Hardware / TEE | Network | Token | Focus |
|---|---|---|---|---|
| EigenCompute / EigenAI (EigenCloud) | Intel TDX, AMD SEV-SNP (Google Cloud) | Ethereum (restaking) | EIGEN | Deterministic LLM inference, AI agent execution |
| Phala Network | Intel SGX (CPU), GPU TEE | Phala L2 (Ethereum) | PHA | Confidential AI inference, Phat Contracts |
| Marlin (Oyster) | AWS Nitro Enclaves, Intel SGX | Ethereum | POND | General purpose TEE compute marketplace |
| Automata Network | Intel SGX / TDX attestation verifier | Multi-chain EVM (10+ networks) | ATA | Onchain attestation verification (DCAP) |
| Atoma Network | TEE plus staked “Sampling Consensus” | Sui | TOMA | Verifiable AI inference on Sui |
Inside the Black Box: How Remote Attestation Actually Works
Remote attestation is the mechanism that makes any of this trustworthy in theory. When code starts inside a TEE, the processor measures it, producing a cryptographic hash of the code and its initial state, and seals that measurement inside a signed “quote.” A remote verifier, whether that is a smart contract, another server, or a user’s wallet, checks the quote’s signature against a certificate chain rooted in the chip vendor, confirms the measurement matches the expected program, and only then trusts the enclave’s output. Intel calls its version of this DCAP, short for Data Center Attestation Primitives. NVIDIA layers a GPU-specific attestation report signed by the GPU’s own security processor on top, and the two companies now offer a composite attestation that covers both the CPU enclave and the GPU in a single check, according to NVIDIA’s documentation.
Picture a lending protocol that only accepts a credit score if it arrives with a valid attestation. The protocol’s smart contract does not run the scoring model itself; it receives a result plus a quote, checks that quote against Intel’s or NVIDIA’s published root certificate, confirms the enclave measurement matches the scoring model it agreed to trust, and releases funds if everything lines up. That exchange happens in milliseconds and never requires the protocol to see the borrower’s underlying data or to re-run the computation itself. It is an elegant design exactly because it collapses trust in the model provider into trust in a single signature. That elegance is also the design’s biggest liability: one compromised signature can impersonate an unlimited number of legitimate ones.
For AI inference specifically, this chain has to hold across more layers than a typical confidential computing use case. The verifier is not just trusting that some code ran unmodified; it is trusting that the model weights loaded into the enclave matched the weights the provider advertised, that the inference framework did not silently quantize or swap the model under load, and that the GPU driver stack sitting between the enclave and the silicon did not introduce nondeterminism. Every one of those layers ultimately traces back to the same signed quote and the same chip-level key.
The entire chain rests on one assumption: that the private key a chip uses to sign its attestation quotes never leaves the chip. If that key leaks, an attacker does not need to compromise the enclave’s code at all. They can simply forge a quote asserting that whatever they want to have happened, happened, and no verifier further down the chain has any way to tell the difference.
WireTap, Battering RAM and TEE.fail: When the Chips Talked Back
That assumption broke, publicly and repeatedly, in the second half of 2025. At the ACM Conference on Computer and Communications Security in October, two independent research teams presented physical attacks that extract exactly those signing keys.
The first, called WireTap, came from researchers at Georgia Tech and Purdue University. By building a memory-bus interposer, a device that physically taps the connection between the CPU and DDR4 memory, out of off-the-shelf electronics costing under $1,000, the team exploited the fact that Intel SGX’s memory encryption is deterministic: identical plaintext at the same address always produces identical ciphertext. That determinism let them recover the nonce used in an SGX enclave’s ECDSA attestation signature and, from it, derive the enclave’s private signing key. A second, independently developed attack from KU Leuven and the University of Birmingham, called Battering RAM, used a similar physical setup to break SGX’s integrity guarantees rather than its confidentiality.
Weeks later, researchers Jalen Chuang, Nicolas Berrios and Daniel Genkin of Georgia Tech, Alex Seto and Christina Garman of Purdue, and Stephan van Schaik extended the technique to DDR5 memory in a followup called TEE.fail. The newer generation of hardware, Intel TDX and AMD SEV-SNP with Ciphertext Hiding enabled, was supposed to have closed exactly this hole. It had not. The team recovered the complete provisioning certification key from Intel TDX and broke AMD’s ciphertext-hiding protection, writing in their paper that “we can pretend that your data and code is running inside a CVM when in reality it is not.” They were explicit about the financial stakes: “extracted attestation keys can potentially be used by attackers to extract millions of dollars of profit from various cryptocurrency and cloud compute services,” the researchers wrote, according to reporting by The Hacker News.
What the Chipmakers Said Back
Intel and AMD’s response was less a fix than a shrug. Both companies maintain that physical attacks, meaning an adversary who can open a server chassis and attach hardware to the memory bus, sit outside the threat model their confidential computing products were designed to defend against, and neither shipped a patch that closes the underlying hole, according to The Hacker News‘ coverage of the disclosure. That position is defensible on its own terms. TEEs were built to stop a curious cloud operator or a compromised hypervisor from reading your data, not to survive a well-funded attacker with a screwdriver and a $1,000 interposer.
This is not a new posture for either company. Intel’s own security advisories have long carved out physical attacks as a separate category from the remote software vulnerabilities its bug bounty program prioritizes, and AMD’s SEV-SNP documentation makes similar caveats about the limits of its threat model. For a bank’s on-premises server, that caveat is reasonable; the physical perimeter is the bank’s to secure. For a TEE running inside a cloud region a crypto project does not own, operate, or necessarily even know the physical address of, the caveat quietly shifts responsibility for physical security onto a party, the cloud provider, that most end users never agreed to trust in the first place and that the attestation itself was supposed to make irrelevant. It leaves a gap between the language crypto projects use to market this technology, hardware-backed, cryptographically attested, tamper-proof, and the actual guarantee on offer: safe against software attackers, not necessarily safe against anyone who gets a few hours alone with the machine.
The Crypto Projects Named in the Research
The WireTap paper did not stop at Intel’s own threat model. It named specific blockchain deployments, Secret Network, Phala Network, Crust Network and IntegriTEE (a Polkadot-based confidential computing parachain), as SGX-backed systems where the technique could, in the researchers’ own analysis, be used to undermine confidentiality or integrity guarantees, letting an attacker read confidential transaction data or claim rewards it had not earned.
Secret Network’s team confirmed the researchers went further than a paper exercise, at least for one network: the attack was actually tested against Secret Network’s own testnet. In a public response, the team wrote that “this is not a Secret Network vulnerability, but an Intel SGX vulnerability” affecting specific third-generation Xeon processors, and stressed that “data is safe, funds are safe” because the demonstrated attack could only expose data confidentiality rather than steal assets, and mainnet was never touched. The team still shipped a defensive release, version 1.22, that froze new node onboarding, moved to a curated allowlist of trusted validators, and rotated the network’s seed, adding that Secret Network was “the only project that took proactive measures to protect from this vulnerability,” according to the team’s own security update.
Crust Network, a decentralized storage network, took the more consequential step. Its October 2025 security announcement confirmed the attack “does not affect the consensus mechanism or block production process of the Crust mainnet” and that stored files were protected by redundancy regardless, but the team committed to a two-stage hardware migration: a short-term move from SGX to Intel TDX, and a longer-term overhaul called “Crust Plus” that would replace TEE-based storage proofs with zero-knowledge proofs entirely, specifically in order to “completely circumvent such hardware-dependent risks,” per the project’s own announcement. That is about as direct an admission as the industry has offered that hardware attestation alone is a bridge rather than a destination.
Even Ethereum’s own MEV infrastructure got pulled in. Flashbots’ BuilderNet, which uses TEEs so competing block builders can share order flow without seeing each other’s transactions, was the subject of one of the TEE.fail demonstrations. A Flashbots contributor writing as Quintus argued in an October 2025 Flashbots Collective forum post that the finding was, in the post’s own framing, actually bullish for the project: the demonstration ran on “a non-production BuilderNet instance run in a lab,” physical bus access falls outside operators’ real-world cloud deployment constraints, and the attacks “do not enable frontrunning or unbundling” under BuilderNet’s live threat model. Rather than treat the research as a reason to abandon TEEs, Flashbots pointed to it as validation for work already underway: a Proof-of-Cloud scheme letting datacenters prove their physical environment permissionlessly, a Trustless TEE Initiative aimed at hardware that resists supply-chain and physical adversaries, and software projects called DStack and Flashtestations meant to make attestation more transparent and independently auditable.
Why a Lab Attack on a Data Center Still Matters
It is tempting to file all of this under “requires physical access, ignore it,” the way the industry mostly shrugged off early Rowhammer and cold-boot research for years before it became practical. Two things make that complacency riskier here than in a typical enterprise IT context.
First, crypto inverts the usual cost-benefit calculation for attackers. A $1,000 interposer attached to an ordinary enterprise server might expose customer records, a real but diffuse harm. The same interposer attached to a machine running TEE-secured verifiable compute could forge the attestation behind a lending protocol’s risk model, an oracle feed, or an AI agent authorized to move a treasury, producing a directly monetizable result. The TEE.fail researchers made this point themselves when they flagged the risk to cryptocurrency services specifically. Concentrated financial value sitting behind a single attestation is exactly the incentive that turns an academic proof-of-concept into a criminal business plan, the same logic that makes hardware wallets and multisig setups attractive targets for supply-chain tampering rather than brute force.
Second, “physical access” understates who actually has it. It is not just a lone attacker breaking into a data center. It includes any cloud employee with rack access, any government with subpoena or coercion power over a hyperscaler operating in its jurisdiction, and any point in a hardware vendor’s supply chain between the fab and the rack. Crust Network’s response conceded the point implicitly: it did not argue physical attacks were impossible, only that its current design happened to survive this particular one. Even a project that self-hosts its own TEE infrastructure rather than renting from a hyperscaler still depends on chip-level keys provisioned once at the factory and never rotated, which means a chip vendor’s own manufacturing security becomes part of the trust model whether a project chooses that or not. Verifiable compute’s entire pitch is that users should not have to trust the operator. A trust model that still depends on trusting whoever holds a badge for the server room, or the factory that made the chip, is a narrower version of the same problem, not a solution to it.
There is also a pattern worth remembering from the last decade of CPU security research. Meltdown and Spectre, disclosed in 2018, were dismissed by some as impractical lab curiosities requiring precise conditions, and within a few years variants were being folded into real exploit chains while cloud providers rewrote core parts of their isolation stacks in response. Physical side-channel attacks on TEEs look earlier on that curve, not later. Treating a $1,000 proof-of-concept as a ceiling on what a well-resourced, motivated attacker can eventually do more cheaply and with less physical access has historically been the wrong bet.
The Hybrid Fix: Pairing Silicon With Cryptography
The industry’s actual response, as opposed to its marketing, has mostly been to stop treating TEEs as a complete answer and start treating them as one layer in a stack. EigenCloud’s own roadmap is explicit about this: EigenCompute uses TEEs “initially,” with cryptoeconomic security and zero-knowledge proofs listed as planned additions rather than alternatives held in reserve. Its EigenAI product already blends approaches: deterministic inference gives every result a canonical, reproducible output, disputes get resolved through an optimistic re-execution window handled by EigenVerify, and only a challenged result falls back to being recomputed and checked, which keeps a TEE’s near-native speed for the common case while adding an economic backstop for the contested one. “Until issues of transparency and deplatforming risk are addressed, AI agents will remain functional toys rather than powerful peers we can hire, invest in, and trust,” Eigen Labs founder and CEO Sreeram Kannan said at the launch of EigenAI and EigenCompute. “With EigenAI and EigenCompute, we’re providing the essential building blocks for truly unstoppable, verifiable agents,” he added, in comments published on EigenCloud’s blog.
Automata takes a related but distinct approach at the verification layer rather than the compute layer: its DCAP attestation contracts check Intel SGX and TDX quotes directly onchain, with a SNARK-compressed proof path specifically so an attestation can be checked cheaply inside an EVM smart contract, according to the project’s own GitHub repository. That does not fix the underlying hardware risk (an attacker who has already extracted a signing key can still produce a quote that passes this check) but it does mean the verification step itself is transparent and auditable rather than trusted blindly.
The pattern across these responses is the same one that shows up whenever the industry has to reckon with a broken trust assumption: nobody is abandoning TEEs, because nothing else is fast or cheap enough yet, but the more credible teams are all quietly building the cryptographic and economic layer that lets them stop depending on the chip alone.
| Approach | Trust assumption | Overhead vs. native compute | Production maturity (Aug. 2026) | Representative projects |
|---|---|---|---|---|
| Zero-knowledge (zkML) | Math (proof soundness) | High, especially for non-linear layers; improving | Small and mid-sized models only; frontier scale still impractical | EZKL, Lagrange, Succinct, Boundless / RISC Zero |
| Trusted execution (TEE) | Chip vendor plus physical security of the host | Low, often near-native | Production today at meaningful scale | EigenCompute, Phala, Marlin Oyster, Automata, Atoma |
| Optimistic / crypto-economic | Economic incentives plus at least one honest watcher | Low in the common case; cost and delay only when challenged | Early production, mainnet rollouts underway | opML / ORA, Gensyn, EigenAI’s re-execution layer |
| Fully homomorphic encryption (FHE) | Math (encryption hardness) | Highest of the four, though narrowing | Earliest stage; live but narrow use cases | Zama, Fhenix, Inco |
The Market Hasn’t Priced In the Hardware Risk
None of this appears to be showing up in prices. PHA trades around $0.021, a market cap near $17.8 million, according to CoinGecko. EIGEN sits near $0.185, down roughly 97 percent from its December 2024 high of $5.65, for a market cap around $137 million, per CoinGecko. Boundless’s ZKC trades around $0.042, versus an all-time high of $1.78, according to CoinGecko.
That collapse has an obvious explanation that has nothing to do with silicon: token unlocks, a broad rotation away from infrastructure narratives, and the usual gap between a mainnet launch and paying commercial demand. It would be a stretch to claim WireTap or TEE.fail moved any of these prices specifically; none of the named projects show a clean, isolated drawdown tied to the October 2025 disclosures. Investors have piled into AI-linked crypto tokens broadly over the past year, but that enthusiasm has mostly rewarded exposure to the AI narrative rather than any specific assessment of which verification architecture is more defensible, hardware-only, hybrid, or otherwise. A TEE-only design and a hybrid TEE-plus-cryptoeconomic design currently trade on roughly the same narrative multiple. Crypto’s long run of bridge hacks followed a similar pattern for years: a trust assumption, a multisig custodian set, a light client, whatever the bridge leaned on, sat unexamined by the market until it broke, at which point the whole category repriced at once instead of just the specific weak link.
What the Audit Industry Says About Attestation
Smart contract auditors have spent years training the market to expect a specific reassurance: this code was reviewed by a reputable firm, so it is safe. That reassurance has failed often enough that treating an audit as a guarantee, rather than a snapshot of what one team found in one codebase at one point in time, is now understood as a mistake. Hardware attestation invites the same mistake in a new form. A TEE’s attestation is not an audit of the chip’s physical security. It is a signature asserting that an enclave’s measurement matched what was expected, produced by a signing key that both WireTap and TEE.fail demonstrated can, under the right physical conditions, be extracted.
Crypto-native audit firms are not equipped to close this particular gap on their own. Reviewing the smart contracts that check an attestation onchain, the DCAP verifier logic Automata publishes, for instance, is squarely inside their expertise. Reviewing whether Intel’s or AMD’s silicon actually resists a DDR5 bus interposer is not; that work sits with chip vendors, academic security researchers, and a small number of specialized hardware labs, and it moves on a slower, less transparent disclosure cycle than smart contract security does. Until that changes, “audited” and “attested” both describe a process that reduces risk rather than one that eliminates it, and treating them as interchangeable is exactly the gap that has punished plenty of projects before this one.
Where Verifiable Compute Goes From Here
Three trends look durable heading into the rest of 2026.
- Hybrid architectures become the default, not a roadmap item. TEE for everyday speed, with a cryptoeconomic or zero-knowledge fallback for disputes, is now how EigenAI, Crust’s planned migration, and Flashbots’ Proof-of-Cloud work all independently converge on the same answer.
- Hardware diversity starts to matter as much as hardware choice. Relying on a single vendor’s enclave technology means one side-channel disclosure can undermine attestation across dozens of unrelated projects at once, which is exactly what happened when one research paper implicated Secret Network, Phala, Crust and IntegriTEE together.
- Attestation transparency becomes its own subfield. Efforts like Flashbots’ DStack and Flashtestations are trying to make it possible to independently audit what a TEE claims to be running, instead of taking a vendor’s word for it.
What is unlikely to change soon is the core trade-off. Zero-knowledge proofs offer the strongest guarantee and the worst economics for large models. TEEs offer the best economics and a guarantee that is only as strong as a supply chain most crypto projects cannot inspect. Optimistic and crypto-economic schemes offer a workable middle path priced in bonds and delay rather than compute cycles. None of the three is close to making the other two obsolete, which is precisely why the projects with the most credibility right now are the ones building all three into a single stack instead of betting the business on one. For an industry that spent the last two years selling the idea that code, not companies, should be trusted, quietly admitting that the chip needs backup too is not a retreat. It is the same argument, applied one layer further down the stack.
Frequently Asked Questions
What does “verifiable compute” mean in crypto and AI?
Verifiable compute is a set of techniques, mainly zero-knowledge proofs, trusted execution environments, optimistic or crypto-economic verification, and fully homomorphic encryption, that let someone check a computation actually happened as claimed rather than trusting the operator’s word. In AI specifically, it is used to prove which model produced a given output, on which inputs, without the requester having to trust the AI provider.
What is the difference between zkML, TEEs, and optimistic verification?
zkML produces a mathematical proof of correct execution but is slow and expensive for large models. TEEs run computation inside a hardware enclave that a chip vendor attests was not tampered with, which is fast and cheap but depends on trusting that hardware’s physical security. Optimistic, or crypto-economic, verification skips proving most computations and instead lets anyone challenge a result during a set window, backed by a financial bond, which is cheap unless a dispute actually happens.
What is the TEE.fail attack, and should crypto users worry about it?
TEE.fail is a 2025 academic attack from researchers at Georgia Tech, Purdue University and van Schaik LLC that used a low-cost device attached to a server’s memory bus to extract the secret keys Intel TDX and AMD SEV-SNP use to sign attestations. It requires physical access to the target machine, so it is not a remote exploit anyone can run over the internet, but it does mean the attestation guarantees behind TEE-based verifiable compute are weaker than the marketing around them suggests, particularly for high-value targets sitting in a shared data center.
Are trusted execution environments (TEEs) actually safe to use for AI inference?
TEEs are safe against the threat they were originally designed for: a curious cloud operator or a compromised software stack reading your data. They have repeatedly proven vulnerable to physical side-channel attacks, including WireTap, Battering RAM and TEE.fail, when an attacker can get hands-on access to the hardware. For most everyday commercial AI inference, that risk is low enough to accept. For verifiable compute securing large financial value, it is why the more credible projects pair TEEs with cryptoeconomic or zero-knowledge backstops rather than relying on hardware attestation alone.
Will zero-knowledge proofs eventually replace TEEs in verifiable compute?
Not in the near term. zkML proving costs for the non-linear layers that dominate modern neural networks remain far higher than the cost of simply running the model, which keeps zero-knowledge proofs impractical for large-scale inference today. Most credible teams are building hybrid systems that use TEEs for everyday speed and fall back to zero-knowledge proofs or economic penalties only when a result is disputed, rather than betting on either approach winning outright.
Marcus Okafor, HOGE Wire.