Privacy
A request sent to a Neuronet passes through several hands: the gateway that routes it, the mesh peers it travels over, the miner process that runs the model, and the operator who controls that machine. The privacy level of a task describes how much of the request content each of them is supposed to see. This page describes the privacy model of the protocol, the assumptions behind it, and where the code has not caught up with the design.
Privacy is a per-task setting, chosen by the Owner alongside the model and the verification tier. See Task Configuration for where it sits among the other task settings.
What Cannot Be Hidden
Model inference needs the input in plaintext inside GPU memory. The forward pass operates on real token values, not on ciphertext. Anyone with full control of the machine and enough motivation can read that memory, and no amount of software encryption changes it. This is the fixed constraint the whole model is built around.
Cryptographic alternatives that would remove the constraint are not practical for production inference. Fully homomorphic encryption multiplies the cost of matrix multiplication by several orders of magnitude, and secure multi-party computation both multiplies the cost and requires several miners per query. Neither is usable at the throughput a serving network needs.
What remains is a ladder: each level narrows who can see the request, and the top of the ladder needs hardware support.
The Levels
P0: Transport Encryption
Traffic is encrypted in transit on every hop: TLS between the consumer and the gateway, and libp2p Noise between the gateway and the miner. Plaintext never crosses the network, even at the baseline level. What P0 does not do is hide anything from the parties the request passes through: the gateway, the miner process, and the operator of the mining machine all see the prompt and the answer.
P0 is the baseline for open models and public data. Cost: none, since both encryption layers are already part of the transport.
P1: Sealed for the Miner
The prompt is sealed for the specific miner that will run it, using X25519 key agreement plus AES-256-GCM against the 32-byte public key that miner published on chain. Only that miner can open it. A miner without a registered encryption key is skipped rather than sent plaintext, and the sealed payload is what travels the mesh, so no intermediate peer on the route sees the request.
One caveat matters, and the design intent and the current implementation differ on it. The intent is that the consumer seals the prompt itself, which would take the Owner out of the set of parties holding request content entirely. In the gateway as it is built today, the gateway performs the sealing: it receives the prompt in the clear and seals it per miner immediately before dispatch. So P1 today protects the request from everyone on the mesh route, but not from the gateway itself. If your threat model includes the party running the gateway, that gap is real and P1 does not close it yet.
P1 does not blind the miner either. The miner process decrypts the prompt to run the model, and the operator of that machine can inspect the process. Cost is negligible: the key agreement and symmetric encryption take well under a millisecond, against inference times measured in hundreds of milliseconds.
P2: Process Isolation
P2 adds host-level hardening around the inference process on top of P1: a container with a read-only root filesystem, a seccomp profile that blocks the system calls used to attach a debugger or read another process's memory, encrypted swap so that memory pages do not reach disk in the clear, and temporary files kept in memory rather than on persistent storage.
This raises the effort required to read a prompt off a mining machine. It does not put the prompt out of reach. An operator with root can load a kernel module or read GPU memory through the device nodes, and nothing at this layer stops that. P2 is defence in depth against casual inspection, not a guarantee against a determined operator. The overhead is on the order of one percent.
P3: Confidential Computing
P3 is the only level that is meant to hold against the operator of the machine. It relies on hardware: a GPU running in confidential computing mode (H100 generation and later) together with a CPU trusted execution environment, so that the prompt is decrypted inside the enclave and never appears in plaintext outside it. The miner attests to its hardware state, and the attestation report is checked against the task requirements before the miner is treated as confidential.
Attestation also covers what is loaded, which closes a gap that verification handles statistically at lower levels: a substituted model shows up directly in the report rather than only through re-checks. The reported throughput cost of confidential mode on current hardware is 4 to 8 percent.
Summary
| Level | Mechanism | Mesh route | Gateway | Miner process | Miner operator | Overhead |
|---|---|---|---|---|---|---|
| P0 | TLS plus libp2p Noise | blind | sees prompt | sees prompt | sees prompt | none |
| P1 | X25519 + AES-256-GCM seal | blind | sees prompt today, by design should not | sees prompt | can inspect | under 0.01% |
| P2 | P1 plus container, seccomp, encrypted swap | blind | as P1 | sees prompt | hard, not impossible | around 1% |
| P3 | Confidential computing with attestation | blind | as P1 | inside the enclave | blind | 4 to 8% |
| P4 | Onion routing | blind, plus who-talks-to-whom | as P1 | as P3 | as P3 | not measured |
P4 targets metadata rather than content: it hides which consumer talks to which miner, which the levels below leave visible. It is a design placeholder, not shipped code.
Choosing a Level
The question that decides the level is who you need to be blind, not how sensitive the data feels.
- If the concern is the network path, P0 covers it.
- If the concern is other peers on the mesh route, P1 covers it. If the concern is the party running the gateway, P1 is aimed at that but does not yet reach it, since the gateway does the sealing.
- If the concern is someone poking around on a mining host without much effort, P2 raises the bar.
- If the concern is the operator of the machine acting deliberately against you, P3 is the only honest answer, and it restricts the task to attested hardware.
- If the concern is traffic analysis rather than content, that is P4, and it does not exist yet.
Higher levels narrow the pool of miners that can serve the task, which affects capacity and price. That trade is the real cost of the upper levels, more than the percentages in the table.
Privacy and Verification
Verification re-runs work on a second miner, which means a verifier needs the same input the executor had. Sealing the prompt for one miner is at odds with handing it to another one later. In the current implementation this is not a problem, because the gateway holds the prompt and seals it again for whichever miner is asked to replay.
It becomes a problem in the design where the consumer seals and the gateway holds only ciphertext. Two ways out are on the table. A replay envelope has the consumer seal the prompt separately for each miner in the task pool at request time; the gateway stores all the envelopes without being able to open any, and hands over the right one if the request is sampled. For a pool of 5 to 20 miners this adds a few hundred bytes per request, and the consumer does not need to be online later. The alternative asks the consumer to seal again for the chosen verifier at re-check time, which avoids the upfront cost but requires the consumer to be reachable. See Inference Verification for how the re-check itself works.
The artifact hashes are never encrypted. Verification compares hashes, and those need to be readable on chain by anyone.
What the Chain Stores
The chain holds hashes, attestation reports, and the miner encryption keys used to address a request. Prompts, answers, and artifacts stay off chain. No AI request is written to the blockchain at any privacy level, including P0.