Documentation

A short, plainly-worded guide. What HULDR is, who it's for, and what a receipt actually contains. No code where prose will do.

What HULDR is

HULDR is a receipt format. When an AI provider runs a model for you and you pay them, HULDR mints a small cryptographic record that says: this prompt was paid for, this output is bound to it, and the compute happened inside an attested secure enclave. The record is portable. Anyone can verify it offline. Nobody (including us) ever sees the prompt or the response.

Think of it as the wax seal on a sealed envelope. The seal proves the envelope was made by the right hand, on the right day, for the right person. It doesn't open the envelope.

Who it's for

AI inference providers who run models inside trusted execution environments (TEEs) and want to attach a verifiable receipt to every paid request.
Callers and agent frameworks who want proof — for audit, billing, or downstream pipelines — that a private inference actually ran and was paid for, without leaking what was asked.
Auditors and regulators who need an audit trail that doesn't compromise user privacy. The receipt is a redacted, cryptographic log.

The three actors

1. The caller

The party making the request. Usually a user, an agent, or a downstream service. The caller pays per request via the HTTP-402 protocol and receives both the response and a receipt.

2. The provider

The party running the model. Runs inside a TEE (Atoma, Marlin Oyster, or Phala dstack are the supported flavors). On every request the provider commits to the input, runs the model, commits to the output, and signs a receipt with their stake-bonded key.

3. The verifier

Anyone who later inspects the receipt. Could be the caller themselves, a regulator, an aggregator, or an on-chain contract. Verification is offline and takes a few milliseconds.

What's inside a receipt

A HULDR receipt is six fields and a signature. Nothing more. None of them carry the prompt, the response, or who you are.

providerThe provider's wallet address. Their public identity. They've staked $HUL against this address; if they forge a receipt, that stake is at risk.

paidHow much was paid for this single request, and the x402 payment reference. Settled before the model even ran.

inputA commitment to your prompt — basically a one-way hash. Lets a verifier check "yes, this receipt is for that exact prompt" without ever revealing the prompt itself.

outputA commitment to the response. Same idea: proves the response is the one bound to this receipt, but the response itself stays with you.

quoteA hash of the TEE attestation — the certificate the secure enclave produced saying "I am running this exact model, on this exact hardware, sealed against tampering."

sigA BLS12-381 signature over everything above, signed by the provider's bonded key. This is the wax seal.

How a receipt is minted, step by step

Your client sends a request to the provider's endpoint.
The provider replies 402 Payment Required with a price quote.
Your client settles via x402. The settlement reference comes back to the provider.
The provider hashes your prompt (this is the input commitment), runs the model inside the TEE, hashes the output, fetches the enclave's attestation quote, and signs a receipt over all of it.
You receive the response + the receipt in the same HTTP body.
(Optional) The provider — or an aggregator — can later anchor the receipt's hash on-chain so there's a public audit trail without publishing the receipt itself.

How verification works

Anyone holding a receipt can verify it without talking to a server, without hitting a chain, and without seeing the prompt or response:

huldr verify rcpt.json

The verifier checks four things:

The signature is valid for the provider's known public key.
The attestation quote matches an accepted TEE profile (Atoma, Marlin, Phala).
The payment reference resolves to a settled x402 transaction.
The provider was bonded and active at the receipt's timestamp.

If all four hold, the receipt is good. If you also possess the original prompt and response, you can recompute the input/output commitments locally to confirm they match.

Frequently asked

Does HULDR see my prompt?

No. HULDR has no server in the path. Only commitments and quote hashes ever cross the network. The provider sees the prompt because they have to run the model on it — but they run it inside a TEE, and the receipt proves it.

What if the provider is dishonest?

Providers stake $HUL when they register. If anyone can prove a quote was forged, or a payment was double-claimed, the slasher contract takes a slice of the stake and rewards the challenger. The economics are: it's cheaper to be honest.

Why BLS12-381 signatures?

Two reasons. First, since Pectra (EIP-2537), Ethereum has a precompile that verifies BLS signatures cheaply on-chain (~131k gas). Second, BLS lets you aggregate many signatures into one — a pipeline of agent calls can produce a single combined proof that all of them happened, paid, and were attested.

Is HULDR a chain?

No. HULDR is a receipt format and a small set of stateless verifier contracts. The receipt verifier on Base is a pure function. The optional anchor relay just publishes a Merkle root per epoch.

Can I use this in production today?

Not yet. HULDR is in Phase 1 — sepolia smoke is green, the SDK skeleton works, but mainnet contracts and provider integrations aren't shipped. See the disclaimer.

Where can I read the protocol spec?

The receipt schema is being drafted as an EIP. Until that's submitted, the source-of-truth is contracts/src/HuldrVerifier.sol and the eip/eip-huldr.md draft in the project repository.

← back to surface