Blind credits

This is a working draft of VEIL and not a standards-track document. It describes how blind credits are issued, held and spent 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.

A wallet pays USDG on Robinhood Chain and receives credits signed with blind RSA (RFC 9474). The router never sees the credit it signs, so a spent credit cannot be matched to its purchase.

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.

A one-time key created in the client receives the USDG payment. The client blinds a batch of random credit values, the router signs the blinded values against the paid amount, and the client unblinds them. Credits come in fixed denominations so that value does not become an identifier.

A credit is presented as Authorization: BlindCredit token=<token> on the blind lane. The router checks the signature and a spent-set, records the credit's hash, and serves the call up to the credit's value. The unused part of a credit is not refunded.

• The USDG purchase is public on-chain: that a wallet bought credits, and how many.
• Buying and spending close together in time can link them; clients SHOULD wait.
• Which prompts a credit paid for is not linkable to the purchase.

Each signing key has a published validity window; credits signed with it expire with it. Keys are listed at a well-known URL and rotated on a fixed schedule so that a key change cannot be used to tag a single buyer.