Receipts and verification

This is a working draft of VEIL and not a standards-track document. It describes the receipt format, signatures and anchoring as designed for Verify Route. None of it is deployed yet; when a part ships, this section will say which, and the changelog will record it.

Every call yields a router receipt signed with Ed25519, and on attested lanes also a node receipt signed by the enclave. Receipts carry hashes and counts, never text. Hourly Merkle roots of all receipts are anchored on Robinhood Chain.

The words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY are used as in RFC 2119 and RFC 8174 when written in capitals. Terms used across the documents:

• Router: the Verify Route service that routes, prices and signs calls.
• Enclave: a confidential VM, optionally with a confidential GPU, running the sidecar and a model server.
• Sidecar: the process in the enclave that measures weights, holds keys and signs node receipts.
• Quote: hardware-signed evidence of what was measured into the enclave.
• Lane: the privacy floor of a request, one of standard, attested or blind.

• generation, model, provider, lane
• usage (prompt and completion tokens) and cost_usdg
• request_sha256 and response_sha256 over the exact bytes exchanged
• attestation_sha256 on attested lanes, bond and canary status at routing time
• issued_at, key_id and sig

The signature covers the canonical JSON of all other claims (keys sorted, no whitespace). Public keys are published at /.well-known/vr-receipt-keys.json with their validity windows. For streamed answers, each chunk extends a hash chain and the final receipt signs the head of that chain.

Once an hour the router builds a Merkle tree of the receipts it issued and writes the root to a contract on Robinhood Chain. A receipt can then be shown with its Merkle path, proving it existed at that hour and has not changed.

1. Canonicalize the claims and check the Ed25519 signature against the published key for its window.
2. If you hold the request, hash it and compare with request_sha256.
3. If a Merkle path is present, recompute the root and compare it with the anchored value on-chain.
4. On attested lanes, compare attestation_sha256 with the registry entry for that host.

A hash does not reveal text, but anyone holding an exact guess of a request can confirm it. Receipts are therefore only returned to the caller, and the anchored roots reveal nothing about individual calls.