Telegram’s Cocoon went live this week, instantly turning the messaging giant into a player in the AI infrastructure market by launching a decentralized, TON‑backed marketplace that routes inference requests to third‑party GPUs running inside
trusted execution environments (TEEs) — notably Intel Trust Domain Extensions (TDX) — and pays hardware providers in Toncoin (TON).
Background and overview
Telegram founder Pavel Durov announced on his channel that
Cocoon — the Confidential Compute Open Network — is live, processing the project’s first real inference requests with “100% confidentiality” and that
GPU owners are already earning TON for processing jobs. The project’s public website, documentation, and source code are available now, and Telegram is positioned as the initial major customer and demand engine for the network. Cocoon is architected as a Decentralized Physical Infrastructure Network (DePIN) that connects three core actors:
- Clients (apps or services) that pay in TON and send inference requests.
- Proxies, which route requests, verify attestations, and handle payment flows.
- Workers (GPU hosts) that execute models inside confidential virtual machines (TDs) protected by Intel TDX.
At the protocol level, Cocoon uses an on‑chain registry for image and model hashes plus smart contracts to settle payments and store reputational metadata. Communication is protected by attestation‑backed RA‑TLS connections and image verification so that only attested VMs with the expected binary image claim can process client inputs. Payments flow through proxy‑mediated payment contracts on TON. This launch arrives at a moment when AI‑specific compute demand is reshaping cloud economics and creating space for specialized “neoclouds” and marketplace approaches to supply GPU capacity. Established hyperscalers still dominate raw market share, but the rapid growth of GPU‑heavy workloads has opened opportunities for alternative architectures — from specialist cloud providers to decentralized DePIN efforts that aim to monetize idle hardware and reduce middle‑man costs.
How Cocoon works — a technical primer
High‑level request flow
- A client prepares a request and pre‑pays the proxy via a TON payment contract.
- The client establishes an RA‑TLS session to the proxy and verifies the proxy’s TEE attestation.
- The proxy selects an attested worker, forwards the request over RA‑TLS, and the worker executes inference inside a TDX‑protected virtual machine.
- The worker returns the response; the proxy pays the worker and returns the result to the client.
This design centers the attestation step:
clients (or their backend instances) verify VM measurements and image hashes against the on‑chain root contract before sending sensitive input. Cocoon’s documentation makes explicit that
both proxy and worker run inside TEEs (currently Intel TDX) and that attestation and RA‑TLS protect the confidentiality of prompts and outputs.
The TEE layer: Intel TDX in brief
Intel Trust Domain Extensions (TDX) create hardware‑enforced trust domains (TDs) — virtual machines whose memory and CPU state are cryptographically isolated from the host VMM and other software. TDX supports remote attestation and secures main memory contents for a TD, making it possible for a client to confirm a workload is running inside a properly measured and signed TD on genuine Intel hardware. Intel’s technical materials describe TDX as a VM‑scale TEE that extends VMX and total memory encryption capabilities to protect entire guest VMs rather than small enclaves. Cocoon’s documentation points to Intel TDX as the current TEE foundation, with image‑hash measurement, RA‑TLS attestation flows, and an attestation verification process integrated into the client and proxy software. The worker VM boots with a verified image and is intended to load models and run inference with only the TD (guest) able to access plaintext inputs and outputs.
GPU and attestation: the tricky part
A central technical challenge for confidential GPU inference is that
GPU memory and device DMA are managed outside the CPU’s TDX protection boundary. Modern GPU vendors (notably NVIDIA) provide attestation/secure frameworks to extend trust to GPU resources — for example, NVIDIA’s nvTrust and related attestation tooling that can prove GPU firmware and driver integrity to a host attestation flow. Cocoon documents a
GPU verification step performed by the VM during boot (to prevent a worker from starting if the GPU verification fails), but currently states that GPU verification is performed locally by the VM rather than being enforced end‑to‑end by remote parties in every case. The doc acknowledges the possibility of a malicious host disabling the GPU, but asserts that such hosts cannot alter successful computations’ correctness.
Why this matters: strengths and potential advantages
- Privacy‑first inference at scale: Cocoon promises client‑verifiable confidentiality — end users and services can verify that inference happened inside an attested TD, preventing node operators from reading prompts or responses. This model directly addresses a common privacy concern with hosted AI: that privileged hosts or operators can inspect sensitive data.
- Monetizing idle GPUs and widening supply: By paying GPU owners in TON, Cocoon creates an economic path for small operators, edge hosts, and data centers to monetize spare cycles. In theory, this can increase global GPU availability and reduce dependence on a handful of hyperscalers. The DePIN model is attractive for distributed supply and cost competition.
- Network bootstrap via Telegram demand: Telegram’s enormous user base and developer ecosystem gives Cocoon an immediate demand channel. Telegram acting as the first major client is a strategic accelerant that can provide predictable load and onboarding momentum for developers and GPU suppliers.
- Open, auditable registry and image verification: Cocoon’s use of an on‑chain root contract for allowed images and model hashes adds transparency: clients can inspect on‑chain records and verify that workers are running exactly the images and models that were attested. This reduces the risk of silent binary substitution or model substitution attacks by rogue hosts.
- Economic integration with TON: Using Toncoin as the settlement currency loops payments into Telegram’s broader in‑app economy, making incentives, micropayments, and developer payouts simple and on‑chain. This could reduce friction for small payments and enable a fast, tokenized marketplace for per‑request compute.
These competitive angles are particularly relevant because
AI workloads carve out new pricing and distribution patterns — hyperscalers still dominate, but specialized providers and marketplace models are taking share in certain inference and specialized deployment scenarios. Cocoon positions itself to capture inference traffic that values privacy and tokenized micropayments.
Critical analysis — technical, security, economic and governance risks
Cocoon is bold, but several areas require careful scrutiny before enterprises or sensitive applications treat its confidentiality claims as axiomatic.
1) The TDX threat model and GPU surface
- TDX protects CPU memory and guest state, but GPUs are separate devices. TDX secures the TD’s memory and CPU registers and enables attestation, but GPUs have their own memory space and DMA engines. Extending the trust chain from TDX to GPUs requires vendor‑level GPU attestation (e.g., NVIDIA’s nvTrust stack) and careful DMA protections. Cocoon’s docs state worker VMs run GPU verification scripts at boot and will not start if verification fails, but remote proof that GPU memory and firmware were uncompromised at runtime is a harder guarantee to establish universally. This is a nuanced point: the TDX boundary helps, but GPUs present additional attack surface that must be addressed for true end‑to‑end confidentiality.
- Side‑channel and microarchitectural risks remain. Hardware TEEs are powerful but not invulnerable. Historically, SGX and other TEEs have been subject to side‑channel research and attacks. Intel’s TDX program has gone through security reviews and mitigations, but the broader class of microarchitectural side channels — particularly in shared cloud environments or with complex GPU‑CPU DMA — must be considered. Intel’s documentation highlights mitigation work and ongoing research; risk‑aware deployments must plan for layered defenses, not just attestation.
2) Centralization vectors: proxies and governance
Although Cocoon is framed as fully decentralized, documentation admits proxies are currently
operated by the Cocoon team for simplicity and that the root contract and registry are presently managed centrally. This creates short‑term centralization and a governance dependency that could be a single point of control or a target for legal/regulatory pressure. The stated roadmap includes DAO governance and permissionless proxies in future phases, but the live net’s early centralization is material for enterprise risk assessments.
3) Performance and reliability tradeoffs
Confidential VMs and attestation layers introduce overhead and complexity. Cocoon’s docs clearly state
TEE does not guarantee performance; slow or crippled workers are handled via reputation systems and proxies’ monitoring, which is a pragmatic approach, but not equivalent to enterprise SLAs. High‑throughput, low‑latency inference might be difficult to guarantee across a diverse, decentralized fleet. Enterprises relying on strict latency and availability SLAs may still find hyperscalers more suitable for critical workloads.
4) Token economics and market risk
Cocoon pays workers in TON. While tokenized micropayments enable low friction and global settlement, they also expose hardware providers and developers to crypto market volatility, liquidity constraints, and regulatory uncertainty in some jurisdictions. The immediate market response in TON price has been muted relative to the technical upgrade, and token valuation dynamics will materially affect supply incentives. Market conditions can create unpredictable supply shocks (too few operators during selloffs or oversupply when TON rallies), complicating pricing stability.
5) Compliance, data residency, and legal exposure
Processing sensitive data (health, finance, personal identifiers) in a decentralized network raises compliance questions. Even if a TD provides strong attestation, regulatory regimes often require contractual and physical controls (data residency, certified operators, audit trails). Cocoon’s model can be adapted for regulated use, but enterprise adoption will require explicit contractual and audit frameworks — something Cocoon’s current docs acknowledge but have not yet formalized.
Cross‑checks and independent verification
Key technical claims have been independently verified across Cocoon documentation and third‑party reporting:
- Cocoon’s architecture, attestation flow, and TDX reliance are documented on cocoon.org.
- Multiple cryptocurrency and industry outlets reported Durov’s announcement and described the network’s use of Intel TDX and TON payments. These reports align with the on‑chain and project statements.
- Intel’s official materials describe TDX as a VM‑level TEE with remote attestation and memory confidentiality, including notes on security research and mitigations — matching Cocoon’s choice of TDX as the trust base.
Where definitive nuance matters — for example, precise guarantees about GPU memory confidentiality at runtime — Cocoon’s documentation is explicit: GPU verification exists, but
remote parties may not yet have the same degree of independent end‑to‑end attestation for GPUs as they do for TDX‑protected CPU memory. That distinction matters for high‑assurance applications and must be treated as such until GPU attestation tooling is universally deployed and integrated into the attestation chain.
Market and competitive implications
Cocoon’s arrival changes several dynamics:
- Hyperscalers face a new class of competitor for inference workloads that value privacy and tokenized payments. While AWS, Azure, and Google Cloud maintain large advantages in scale, integration, and enterprise SLAs, the AI compute market is fragmenting — specialized providers and marketplace models can win particular use cases.
- Neoclouds and marketplaces will intensify. The “neocloud” phenomenon — specialist GPU providers winning inference traffic — is already reshaping procurement strategies. Cocoon adds a privacy‑oriented option to that competitive set, which may be attractive for apps that want to avoid hyperscaler lock‑in or preserve a privacy posture that cannot be achieved with standard cloud VMs.
- Tokenized settlement layers create alternative economics. Paying per‑request in TON reduces friction for micropayments and global contributions but requires robust liquidity and integration with off‑ramp services to be practical for many operators. If TON remains illiquid or volatile, hardware operators may convert earnings swiftly or discount their price to hedge — affecting long‑term network economics.
Practical guidance for stakeholders
For enterprise architects and procurement leads
- Treat Cocoon as an emerging option for privacy‑sensitive inference pilots — not yet a direct replacement for production hyperscaler inference unless you can accept the current performance, governance, and compliance tradeoffs.
- Run proof‑of‑concepts that replicate regulated workflows (data residency, audit logs, incident response) and insist on attestation proofs, independent audit traces, and contractual remedies before placing sensitive data on any decentralized TEE network.
For developers and product leads
- Use Cocoon for features that require cryptographic proof of private execution (e.g., private prompts, confidential model endpoints) and design products that degrade gracefully if worker latency varies.
- Validate the client attestation flow early; design systems that verify RA‑TLS attestations and image hashes. Build monitoring and fallback strategies to alternate inference backends in case of worker unavailability.
For GPU owners and small data‑center operators
- Evaluate earnings potential in TON against local electricity costs and required uptime. The token model can be lucrative in favorable market conditions, but it also introduces volatility risk. Consider partial hedging strategies or immediate fiat conversion options if available.
For the broader security community
- Encourage independent attestation and measurement tooling that extends TDX measurements to GPU firmware and runtime state (in collaboration with GPU vendors). Public, reproducible attestations will increase trust and accelerate adoption.
Where Cocoon could go next
- Stronger GPU attestation integration: Automated, remote verifiable GPU attestation (firmware, driver, runtime checks) would materially raise the assurance level for end‑to‑end confidentiality and could be a decisive competitive advantage.
- Permissionless proxies and DAO governance: Transitioning proxy operations and root contract updates to decentralized governance would reduce short‑term centralization risk and align incentives if done securely.
- Enterprise SLAs and compliance artifacts: Publishing audit reports, independent penetration tests, and compliance artifacts (SOC 2, ISO) would be necessary to attract large regulated customers.
- Multi‑TEE support and hybrid routing: Supporting AMD SEV‑SNP, future GPU native TEEs, and multi‑cloud bridging could improve geographic coverage and supply resilience.
Conclusion
Cocoon is a noteworthy experiment at the intersection of confidential computing, decentralized marketplaces, and tokenized economics. It brings a credible technical stack to the table — Intel TDX‑backed attested VMs, on‑chain image verification, RA‑TLS attestation flows, and a pragmatic client/proxy/worker topology — and it leverages Telegram’s ecosystem to seed demand. For privacy‑sensitive inference and for projects that can accept the current performance and governance tradeoffs, Cocoon represents a new, compelling option. At the same time, real‑world guarantees still hinge on
GPU attestation and runtime protections beyond CPU TEEs, the evolution of proxy decentralization and governance, and the economic realities of token‑denominated payments. These are solvable engineering and policy problems, but they are non‑trivial. Until GPU attestation and enterprise compliance artifacts are standardized and widely audited, Cocoon should be treated as a promising platform for pilots and privacy‑first features rather than a wholesale replacement for established cloud SLAs. Cocoon’s launch has already moved the market needle: it demonstrates that large consumer platforms can bootstrap decentralized confidential compute offerings and that alternative economic rails for inference (tokenized micropayments) are viable in practice. Whether Cocoon grows into a robust competitor to hyperscalers will depend on its technical hardening, governance evolution, token economics, and the pace at which GPU vendors and the broader ecosystem deliver verifiable, end‑to‑end attestation for GPU workloads.
Source: CryptoRank
Telegram Launches ‘Cocoon’ Network to Rival AWS for AI Compute, Leveraging Intel TDX | Market Telegram | CryptoRank.io