VEIL / privacy protocol · draft v0.1.0
Private inference
you can verify.
Four questions.
- Q1Which model and which software produced this answer?
- Q2Who was able to read the prompt while it was being processed?
- Q3Can the payment be separated from the request it paid for?
- Q4Can the result be checked without revealing the request?
The name spells the four parts: Verified sidecar, Encrypted relay, Independent (blind) credits and a Ledger of receipts. A fifth part, measured policy, describes any filtering in a form a verifier can inspect. The aim is not to ask anyone to accept a privacy statement. It is to give builders a way to check one.
Why open models need this
Open weights mean choice: the same model can run at many hosts, in many regions. That choice also spreads a prompt across systems run by different people. A prompt can hold unreleased code, research, trading logic or customer records, and the usual arrangement asks you to trust each host with it while it is in use. VEIL replaces that trust with evidence you can check before you send anything.
The design in one request.
A VEIL request is a chain of steps that can each be checked on their own. It starts with the client choosing the privacy floor it needs:
Lane
standard
Path
TLS to the router, then to any bonded provider
Who can serve it
Any bonded provider
Payment
Key, USDG balance or per-call payment
Lane
attested
Path
TLS to the router, then to an enclave whose quote the router verified minutes ago
Who can serve it
Attested hosts only
Payment
Key, USDG balance, per-call payment or blind credit
Lane
blind
Path
Oblivious relay run by an independent party, then to an attested enclave
Who can serve it
Attested hosts only
Payment
Blind credits only; keys and wallets are refused
A lane is a floor, not a wish. When the router cannot meet it, the request is refused with the reason, rather than being served below the level the client asked for.
01 /
Served inside an enclave.
The request reaches a confidential VM, optionally with a confidential GPU. The sidecar in front of the model server hashed the weights at boot, generated its keys in memory and asked the hardware for a quote that commits to those keys and hashes. A client can compare that quote to the published measurements.
02 /
Encrypted to the enclave.
The prompt is sealed to the enclave's key before it leaves the client. The router can still route and bill the call, but it forwards ciphertext it cannot read. On the blind lane an independent relay also hides the client's network address from the router.
03 /
Paid without a name.
Blind credits are bought with USDG and signed blindly by the router. When one is spent, the router can tell it is genuine and unspent, but not which wallet or purchase it came from.
04 /
A receipt to check.
The enclave and the router each sign a receipt holding hashes of the request and the response, the model digest and the attestation hash. Hourly roots are anchored on Robinhood Chain, so the record cannot be rewritten later.
V · A verified sidecar.
The sidecar sits in front of an OpenAI-compatible model server inside the enclave. At boot it hashes every weight file, checks the digest against the allowed list, generates a TLS key and a receipt-signing key in memory, and binds all of them into the hardware quote.
- The quote proves which image and which weights are running, and that the keys never left the enclave.
- The router re-checks each host's quote on a short interval. A stale quote removes the host from attested lanes.
- Every change of image or weights produces a new measurement, recorded in the public registry.
Details: 0001 Attestation.
E · An encrypted relay.
Clients encrypt the request body to the enclave's public key with HPKE. The router sees the routing fields it needs (model, lane, size) and forwards the sealed body. On the blind lane, the request first passes an oblivious HTTP relay operated by a party independent of the router, so the router never learns the client's IP address, and the relay never learns the content.
Details: 0002 Transport.
I · Independent, blind credits.
A wallet buys credits with USDG. The router signs each credit blindly, so the signature is valid but the router never sees the value it signed. Spending a credit proves it is genuine and unspent without revealing where it came from. The purchase itself is public on Robinhood Chain; which prompts the credits paid for is not.
Details: 0003 Credits and the blind credits page.
L · A ledger of receipts.
Two signatures cover each answer: the enclave signs what it computed, and the router signs what it routed and charged. Both receipts hold hashes, never text. The router batches receipts into an hourly Merkle tree and anchors the root on Robinhood Chain, so a receipt can later be proven to have existed at that time and not changed since.
Details: 0004 Receipts.
Measured policy, not hidden filters.
If an enclave applies any content policy, that policy is part of its measured image. Its rules are published, the outcome of a refusal is recorded in the receipt, and a verifier can see which policy version was in force. Filtering that cannot be inspected has no place in a private lane.
Details: 0005 Measured policy.
Who learns what.
| Party | Learns | Does not learn |
|---|---|---|
| Relay | Client network address, message sizes | Prompt, answer, which model |
| Router | Model, lane, size, cost, credit validity | Prompt and answer (sealed), client address on the blind lane |
| Enclave host | That a request arrived | Anything inside the enclave, if the hardware holds |
| Enclave | Prompt and answer, in memory only | Who paid, when blind credits are used |
| Chain | Hourly receipt roots, USDG purchases | Individual prompts or which credit paid for them |
Honest limits.
- Confidential computing depends on the hardware vendor's design and keys. A flaw there weakens every attested lane.
- An attestation says what code runs. It does not say that the code is free of bugs.
- Timing and size can still link requests on the blind lane, especially at low traffic.
- The text of a request is read inside the enclave; privacy covers who else can read it, not the model itself.
Design targets.
| Target | Meaning |
|---|---|
| T1 · Measured serving | Every attested answer is traceable to a published image and weight digest. |
| T2 · Sealed content | No party outside the enclave can read prompts on attested lanes. |
| T3 · Unlinked payment | Blind-lane payments cannot be tied to a wallet. |
| T4 · Fail closed | Missing or stale evidence refuses the call; it never downgrades it. |
| T5 · Checkable record | Receipts verify offline with published keys and on-chain anchors. |
What exists, and what is planned.
Status
Draft · not deployedVEIL is a public draft. No attested lane, relay or blind credit is served by Verify Route today. The specification is published so that it can be reviewed before it is built, and every part will be marked here when it goes live. Machine-readable status: /veil/status.json.Open models should not mean open prompts.
A public specification lets any host implement the same guarantees and lets any client check them the same way. That is the point of VEIL: privacy that is a property of the system you can verify, not a line in someone's terms.