Cocoon
Cocoon is a decentralized AI inference network built on the TON blockchain by Telegram. Developers buy low-cost inference through a client library; GPU owners rent out TEE-capable hardware and earn Toncoin, with prompts sealed inside the enclave.
What is Cocoon?
Cocoon, short for Confidential Compute Open Network, is a decentralized AI inference platform built on the TON blockchain and presented as a Telegram project, unveiled by Pavel Durov in a keynote at Blockchain Life 2025. Its pitch comes down to four goals: anyone with a GPU server can rent it out and earn money; requests and responses stay private; the client can verify that a response came from the model it asked for; payment goes through TON.
Three components make that work. The client is a library that sends requests and pays for them. The proxy picks a worker, collects the payment and takes a commission. The worker runs the model on its GPU. Both proxy and worker execute inside a trusted execution environment, currently Intel TDX, so prompts and responses are out of reach of whoever owns the machine. A request travels over RA-TLS: the client checks the proxy's attestation against a root contract on TON before sending anything, pays up front, and the proxy settles with the worker through a smart contract once the work is done. That root contract is the network's registry, holding proxy addresses, allowed image hashes, supported model hashes, network parameters and contract code.
The intended shape is many clients, few proxies (10 to 100) and a large fleet of workers (1,000+). Because an enclave guarantees confidentiality but says nothing about speed, workers also carry an on-chain reputation built from response time and success rate.
For developers, Cocoon presents a marketplace that dynamically offers the best price for each request, paid in Toncoin. The client library is designed to sit in a backend, and Telegram's own backend is cited as running several client instances; a lighter library for mobile and desktop apps is still in development. For GPU owners the bar is high: Intel TDX, an NVIDIA H100 or newer with confidential computing, Linux kernel 6.16 or later, QEMU 10.1 or later. Models come from Hugging Face, with Qwen/Qwen3-0.6B as the documented example, and are verified with dm-verity against hashes recorded on-chain. Two repositories are public and releases are reproducible. Maturity is mid-stage: the proxies and the root contract are still run by the COCOON team, with open proxies and DAO governance only announced.
What it does
- Run LLM inference requests inside a confidential virtual machine, served through vLLM.
- Rent out a GPU server's capacity to the network and get paid in Toncoin.
- Buy inference compute on a marketplace that reprices every individual request.
- Verify by attestation that a response really came from the model that was requested.
- Settle payments on-chain through TON smart contracts (proxy, client and worker).
- Follow workers' on-chain reputation, built from response time and success rate.
- Rebuild the TDX image from source and compare it against the published checksums.
When to use Cocoon / When not to
A quick filter to help you decide if Cocoon is the right fit.
When to use Cocoon
- Developers wiring LLM inference into a server-side backend who want a pay-per-request alternative to a centralized API.
- Owners of TEE-capable GPU servers (Intel TDX, NVIDIA H100 or newer with confidential computing) looking to monetize idle hardware in Toncoin.
- Teams under a hard prompt-confidentiality requirement, where inference must run inside an enclave the machine's owner cannot read.
- Infrastructure and MLOps engineers at ease with Linux, QEMU, CMake builds and an INI configuration file edited by hand.
- Builders in the Telegram and TON ecosystem: Telegram is announced as the network's first large consumer of inference.
When not to use Cocoon
- Non-technical end users: there is no web app, no mobile app and no account to open, only a library and a terminal.
- Owners of consumer graphics cards: a worker demands Intel TDX, an NVIDIA H100 or newer with confidential computing, Linux kernel 6.16+ and QEMU 10.1+.
- Buyers who need a fixed price in conventional currency before committing: no pricing page exists, rates are set request by request by an on-chain market and settled in Toncoin.
- Mobile and desktop developers who want the application itself to reach the network: the lightweight client library is announced as still in development.
- Anyone who requires terms of service, a privacy policy, a DPA or a contractual GDPR commitment, since none of these documents exist on the site.
How to use Cocoon
A typical end-to-end flow, from setup to results.
- Read the developers page for the economics, then the architecture page for the trust model, before writing any code.
- As a developer, embed the client library in a server-side backend: it validates the proxy's TEE attestation before a prompt ever leaves your infrastructure.
- Fund a client contract on TON with a balance and a stake, the stake size driving how often you are billed. A Docker route for self-hosting a client instance is announced, not yet available.
- As a GPU owner, prepare the hardware: enable Intel TDX in the BIOS, switch the NVIDIA GPU into confidential-computing mode with gpu-admin-tools (a VBIOS update may be required), then bind it using the setup-gpu-vfio script.
- Download the worker distribution from ci.cocoon.org (cocoon-worker-release-latest.tar.xz) and unpack it.
- Start seal-server with the signed enclave supplied: it is mandatory in production and derives the worker's persistent keys.
- Copy worker.conf.example to worker.conf and fill in model, owner_address (your TON wallet), gpu (PCI address), node_wallet_key, hf_token, ton_config and root_contract_address.
- Launch with ./scripts/cocoon-launch worker.conf, or add --test --fake-ton to rehearse the whole flow without spending real Toncoin.
- Monitor the worker over HTTP on port 12000 (/stats, /jsonstats, /perf) or with health-client for status, system, GPU and logs.
- Optionally rebuild the image from source with CMake and Ninja, then compare sha256sum against the published checksums before trusting a release.
Pros & Cons
Pros
- Confidentiality is architectural rather than declarative: enclave execution, RA-TLS and attestation verified against an on-chain registry.
- The model that served a request is verifiable client-side, since allowed model hashes are recorded in the root contract.
- A new revenue line for idle GPU capacity, settled automatically in Toncoin.
- Market-priced inference, presented as cheaper than centralized providers.
- Source code is public across two repositories and builds are reproducible, so a release can be verified rather than trusted.
- External audit is actively encouraged, with a published disclosure channel at security@telegram.org.
- Demand is backed by the Telegram ecosystem, announced as the network's first large customer.
Cons
- No terms of service, no privacy policy, no legal notice, no DPA and not a single mention of the GDPR anywhere on the site.
- Decentralization is still partial: the proxies and the root contract are operated by the COCOON team, and DAO governance is only announced.
- No public pricing at all, so an integration cannot be budgeted in advance.
- A steep hardware bar for workers: Intel TDX, NVIDIA H100 or newer with confidential computing, kernel 6.16+, QEMU 10.1+, sometimes a VBIOS update.
- Demanding setup with CMake and Ninja builds, a seal-server to keep alive and an INI file to fill in by hand; there is no interface of any kind, and the lightweight client library for apps is still work in progress.
- Exposure to cryptocurrency volatility plus a locked stake, which can take around a day to recover if the proxy goes offline.
- The enclave guarantees confidentiality, not performance: quality of service rests on on-chain reputation rather than an SLA.
Pricing & Plans
No price is published anywhere. Cocoon has no pricing page and quotes no amount in any conventional currency. The model is usage-based and settled in Toncoin on the TON blockchain, described on the developers page as a transparent marketplace that dynamically offers the best price for each request: the rate is therefore set by the market, request by request, rather than by a published rate card. The proxy takes a commission on every transaction. On the worker side a worker_coefficient parameter (default 1000, meaning 1.0x) scales the price offered, and changing a core parameter such as the price per token requires the proxy contract to be redeployed. Blockchain fees of roughly 0.01 TON per operation mean settlements are committed in batches rather than one by one, and a client must lock a stake, the documentation suggesting no less than ten minutes of consumption. No free plan is advertised. A local test mode with fake Toncoin (--test --fake-ton) exists for rehearsal, but it is a development facility, not a commercial offer.
Data, GDPR & hosting
A consolidated view of how Cocoon handles your data.
GDPR overview
There is no mention of the GDPR anywhere on cocoon.org. Not one occurrence of the regulation, and no privacy policy, no DPA, no subprocessor list and no Article 27 representative either. No data controller is identified and no postal address is published. The only contact address exposed on the entire site is security@telegram.org, a channel for vulnerability reports. Everything Cocoon says about privacy is technical: inference runs in an Intel TDX trusted execution environment, traffic is encrypted with RA-TLS, image and model hashes are verified against an on-chain registry. That is a serious engineering claim, and it is not the same thing as legal compliance. Technical confidentiality is documented; regulatory compliance is neither claimed nor evidenced, so a buyer carrying GDPR obligations has nothing here to rely on.
Who owns the data?
Cocoon publishes no terms of service, no privacy policy and no legal notice, so no contract states who owns what: the question has no documented answer. The architecture stands in place of a contract. Proxy and worker both run inside a trusted execution environment, and the site states that all data, prompts and responses alike, "remains private and cannot be accessed by server owners", with "only the client" able to see them. As the client is a library running on the developer's own infrastructure, the developer holds the data in practice. The code is public on GitHub, under no license stated on the site.
Reuse rights
With no terms of service, Cocoon publishes no license grant, no reuse clause and no usage restriction. Nothing on the site limits what a developer does with inference output, and nothing expressly grants a right either: the question is contractually unanswered rather than settled in the user's favor. In practice the response arrives inside the developer's own infrastructure and goes into their own product without any permission to request from Cocoon, because no published clause says otherwise. One real constraint sits outside Cocoon: workers pull models from Hugging Face using the GPU owner's own hf_token, so each model's own license governs what may be done with what it generates, and that has to be checked model by model. On the network side, allowed model images are pinned by hash in the root contract and verified with dm-verity, which tells you which model answered, not what you are entitled to do with its output.
Data retention & training
Hosting summary
No hosting jurisdiction is announced: the site names no country and no region for where data is processed. That is consistent with the design, since computation is spread across the network's workers, on hardware brought by third parties. The intended topology is many clients, a handful of proxies (10 to 100) and a large fleet of workers (1,000+); the proxies are currently operated by the COCOON team, while each worker is run by its own owner. Data in processing stays inside the confidential virtual machine, which the site states cannot be accessed by server owners. Some state does persist worker-side: a persistent disk image per instance, with keys derived from the enclave through seal-server, an SGX enclave. One clarification matters. cocoon.org resolves to 149.154.167.99, in Amsterdam, Netherlands, on AS62041 Telegram Messenger Inc. That is where the marketing site is served from. It is not a storage location for user data and says nothing about where a given inference request is executed.
Things to keep in mind
Risks and trade-offs to weigh before adopting Cocoon.
- No legal framework at all: with no terms and no privacy policy, a user has no documented contractual recourse if anything goes wrong.
- Confidentiality rests entirely on the enclave. A flaw in Intel TDX, or a GPU left on an outdated VBIOS, moves the guarantee instead of holding it; the site also acknowledges that a malicious host can disable the GPU, even though it cannot alter the result of a computation that does complete.
- Funds are immobilized: a stake is required, recovering it can take around a day if the proxy is offline, and a badly configured proxy stake can cost a client part of its own.
- Private keys are handled by hand, with node_wallet_key sitting base64-encoded in a configuration file, so a careless copy becomes an exfiltration risk.
- Earnings and costs are denominated in Toncoin rather than in fiat currency, leaving both sides of the market exposed to volatility.
- The test image must never be exposed publicly: the site warns that it skips image hash verification and uses a constant disk key.
- Centralization is presented as transitory but is real today: the proxies and the root contract sit under the team's control, which makes them a single point of trust.
Setup & Integrations
Technical difficulty
Very high for a GPU owner: enabling Intel TDX in the BIOS, switching the NVIDIA GPU into confidential-computing mode, sometimes updating the VBIOS through NVIDIA support, on top of Linux kernel 6.16+, an H100 or newer, QEMU 10.1+, a recursive git clone, CMake and Ninja builds, a seal-server left running and worker.conf filled in by hand. The site warns that enabling TDX can be problematic on cloud provider machines. High for developers too: the client library must be embedded in a backend and a client contract funded on TON, with Docker only announced. Nothing happens without a terminal.
Deployment
Integrations
Behind Cocoon
Social
Resources
All the official URLs gathered for verification and reference.
Frequently asked questions
Who is behind Cocoon?
How are prompts kept private?
How much does it cost?
How do I earn money with my GPU?
What hardware does a worker need?
Is there an app or a web interface?
Can I check that the answer came from the right model?
Is the network really decentralized?
Are there terms of service or a privacy policy?
Where do I report a vulnerability?
Should you pick Cocoon?
Cocoon holds a genuinely uncommon position: it does not promise privacy, it engineers it. Prompts and responses are processed inside an Intel TDX enclave, the proxy's attestation is checked against a registry on TON, and the model that answered can be identified by hash. These are guarantees enforced by hardware and verified on-chain rather than asserted in a document.
Which makes the paradox hard to ignore. A product whose central argument is confidentiality ships with no terms of service, no privacy policy, no legal notice and not one mention of the GDPR. Anyone who needs a documented processing framework, a DPA or a named controller will find nothing to work with, and that is simply the state of the site rather than an omission to interpret charitably.
Maturity is mid-stage. The network is live: the worker distribution can be downloaded, mainnet settlement is documented, Telegram is announced as the first large consumer. But the proxies and the root contract remain under the team's control, so there is a single point of trust today, and the promised open proxies and DAO governance are announcements rather than features.
The real audience is narrow and clear: backend and MLOps engineers integrating inference server-side, and operators of high-end GPU servers looking to monetize them. This is not a tool for an end user, since there is no interface, no account and no application. Its structural advantage is the demand attached to the Telegram ecosystem and automatic settlement in Toncoin on TON.
Two things to keep in view before committing: no price is published, so budgeting means measuring on the network itself, and there is no service-level agreement. Quality rests on workers' on-chain reputation, which the enclave explicitly does not guarantee.
- Choosing a selection results in a full page refresh.
- Opens in a new window.