Cocoon
A TON-based compute network where GPU owners execute model requests inside confidential workers.
INPUT / OUTPUT PRIVACY
Stage 1Partial proof
ASSESSED DEPLOYMENT
Backend client to attested network
Verification labels describe capabilities established by the cited sources. This review did not perform live cryptographic attestation, reproduce production builds or complete an independent security audit.
Who actually runs the models?
GPU owners run model workers using Cocoon software. Proxies select those workers and settle payments on TON; they route within a model-execution network rather than reselling unrelated inference APIs.
Deployment and TEE coverage
The documented client library runs on the application backend. The guarantee begins there; a Telegram or other application's front-end/backend path and its own data retention are outside this record.
Production proxies and workers use Intel TDX. Workers verify GPU confidential-compute state at boot. Remote parties verify the measured VM transitively; they do not directly verify a separate GPU report.
Why Stage 1?
Stage requirementsAt least one content layer has independently checkable technical evidence, including partial proof within a layer. The full privacy boundary is incomplete. The stage tooltip distinguishes partial findings from fully met requirements for Stage 2.
STEPS FOR STAGE 2
2 of 3 requirements for Stage 2 met. Missing proof: Logs & storage.
- Request pathMet
Private inputs and outputs across the request path, with E2EE or an equivalent attested channel that protects against intermediaries and binds keys to the accepted workload.
Technically verifiable. Backend → proxy → worker
- Inference executionMet
Protected inference with a verifiable workload identity and protection covering the CPU, GPU and every place content is processed.
Technically verifiable. Registry + boot-time GPU check
- Logs & storageNot established
No content logging, persistent storage, human review or training. Any temporary content-derived cache must have verifiable isolation and enforced removal.
Unknown. No complete lifecycle found
Identity and operational metadata are assessed separately below. They do not set the content stage; prompt or response content in telemetry remains part of the content-retention assessment.
Request path
Technically verifiableRA-TLS chain. RA-TLS binds the certificate key to a TDX quote. The backend client verifies the proxy, and the proxy verifies the worker. Production policy must constrain accepted image measurements; testing policies and empty allowlists provide weaker checks.
Inference execution
Technically verifiableAttested worker. Worker image and supported model hashes are checked using the TON registry. GPU verification runs inside the VM before it starts. The registry's update governance and current proxies are managed by the Cocoon team, so distributed workers do not imply fully decentralized control.
Logs & storage
UnknownRetention gap. The reviewed architecture establishes protected execution and channels. It does not establish a complete content-retention lifecycle covering logs, traces, caches, backups and the integrating application's storage. TEE operation is not a zero-retention guarantee.
Identity & metadata
Documented onlyTON payment records. The network uses wallet-linked payment contracts and records payment state. Encryption does not hide traffic or settlement metadata. The reviewed sources do not establish a complete linkage and deletion policy for off-chain operational data.
Remaining trust assumptions
- Intel TDX and NVIDIA confidential-computing isolation and verification.
- Measured proxy/worker code, strict RA-TLS policies and model hashes in the registry.
- Cocoon's current registry governance and the integrating application's backend.
Limits of this assessment
- Distributed GPU workers coexist with team-operated proxies and centralized registry updates.
- The application backend is a trusted client; this is not automatically device-to-model privacy.
- TON settlement and network metadata are outside content encryption.
Primary-source record
4 sources · reviewed 2026-10-06
Sources reviewed 2026-10-06
