TrueOpen
Get Started
← Back to Home

Cryptographic Data Protection and Identity Privacy

Privacy protection covers payment, task identity, and inference content. Users authorize tasks with a public-key address and a digital signature, without disclosing their names or home addresses, and each task uses its own keys rather than one shared public identifier.

They can optionally encrypt inputs and inference results using AES-256-GCM authenticated encryption. Data keys are wrapped using ECIES public-key encryption and delivered to authorized recipients according to their task roles.

The project team, storage nodes, and other organizations cannot decrypt user content solely by virtue of their identity or administrative privileges.

01 / Content Encryption

Input and Output Encryption

The user’s client encrypts the input. The Worker encrypts and returns the result in chunks, which the client decrypts for display.

02 / Task Authorization

Key Delivery by Task Role

The protocol selects Workers and Verifiers using future randomness. The required keys are then delivered to the selected nodes. Workers and Verifiers need access to the plaintext relevant to their assigned computations.

03 / Ciphertext Storage

Ciphertext Storage and Forwarding

Builders store ciphertext and wrapped keys without holding the unencrypted data keys. Materials are retained for the period required by the task and any review, then deleted according to the retention rules.

Payment and Task Identity

Reducing the Public Link Between a User and a Request

A blockchain address alone does not keep a user unlinked. If an address is tied to an identity through know-your-customer checks or network information, public payments, refunds, and order signatures can still connect task records back to that user. The shielded pool and per-task keys address that link; content encryption, described above, addresses the contents.

A shielded pool hides which note funded which taskDeposits into a long-term address stay public. Inside the shared shielded pool, a zero-knowledge proof authorises spending without disclosing which note was spent. Each task carries its own key, so public records do not link the deposit address to a particular task. PUBLIC DEPOSIT SHIELDED FUNDING PUBLIC TASKS Long-term user address 0xA… Address · amount · time deposit is visible Shared shielded pool A B C D private notes in one pool ZK proof authorises spending the spent note is not disclosed Task A separate task key A no long-term address Task B separate task key B no long-term address no reused user identifier deposit Public records do not show that 0xA… paid for task A or task B The chain still checks spending authority, value conservation and double spending, then escrows the budget. Providers are paid publicly; change and refunds return to the pool as new notes. Deposit and withdrawal amounts and timing remain public and may still provide linking clues. A shielded pool hides which note funded which taskDeposits into a long-term address stay public. Inside the shared shielded pool, a zero-knowledge proof authorises spending without disclosing which note was spent. Each task carries its own key, so public records do not link the deposit address to a particular task. PUBLIC DEPOSIT Long-term user address 0xA… Address · amount · time deposit is visible deposit SHIELDED FUNDING Shared shielded pool A B C D private notes in one pool ZK proof authorises spending the spent note is not disclosed PUBLIC TASKS Task A separate task key A no long-term address Task B separate task key B no long-term address no reused user identifier Public records do not show that 0xA… paid for task A or task B The chain still checks spending authority, value conservation and double spending, then escrows the budget. Providers are paid publicly; change and refunds return to the pool as new notes. Deposit and withdrawal amounts and timing remain public and may still provide linking clues.
01 / Notes

Deposit, Then Spend Privately

Users deposit into a shared pool and receive private notes. The chain records cryptographic commitments to the notes; users keep the secrets needed to spend them. Submitting a task means proving spending authority and conservation of value in zero knowledge, without revealing which note was used. Each spend publishes a unique nullifier, which the chain uses to reject double spending.

02 / Escrow

One Atomic Step

Accepting a task consumes the input notes, moves the budget into escrow, and creates private change notes in a single state transition. Providers can confirm the budget is funded, while the spending proof does not reveal which deposit supplied it. These proofs authorize spending only — they are separate from the proofs used to verify inference.

03 / Per-Task Keys

No Shared User Identifier

The SDK derives a separate control key and encryption recipient key for each task. The control key authorizes orders, retrieval, and permitted cancellations; the recipient key receives wrapped key packages. Relayers submit the transactions, so a long-term account never signs the task, and tasks are not grouped by an on-chain user session.

04 / Refunds

Returned Without Going Back Online

At final settlement, refundable funds return to the pool as new notes under the user’s control, with no claim step required. Cancellation still requires task authorization and accounts for costs already incurred. Challenge bonds and verification budgets can also be paid from the pool, so raising a challenge does not force a user to expose a long-term account.

Accountability is unchanged. The model, task budget, actual fees, execution status, and service-node identities stay public, and Workers, Verifiers, and Builders remain answerable under their public identities. Private payment does not alter verification, settlement, or penalty rules.

What remains visible: deposit and withdrawal addresses, amounts, and times are public and may provide linking clues. What the pool hides is the direct funding link between a deposit and a task, not the deposit itself. Private mode also routes requests through relays so a direct network connection does not re-expose the association.

Status: shielded-pool payments and per-task keys are part of the Phase 2 roadmap for data availability, privacy, and smart contracts. See the development roadmap for what is planned versus available, and Section 9 of the whitepaper for the full design.

Data Availability

Storing, Verifying, and Encrypting Task Data

Verification must continue even after the Worker leaves. Multiple Builders store task materials in the data availability (DA) layer. On-chain commitments allow participants to check that retrieved materials have not been altered.

How Task Data Is Stored and Protected

Distributed Storage
Builders encode task data into fragments and distribute them across storage nodes. During the retention period, they check for and repair missing fragments so the materials remain available for verification and dispute resolution.
Recovery and Integrity Checks
Once enough fragments are retrieved, the complete materials can be reconstructed and checked against the recorded data commitments to confirm that nothing has been replaced or corrupted.
Encryption and Authorization
The user’s client encrypts the input, and the Worker encrypts the inference result before returning it. Builders store and forward ciphertext, which the user’s client decrypts for display.