​
Receipts

Signed inference receipts as the network’s proof primitive.
Each completion a Malibu provider serves normally ends with a signed receipt: an Ed25519 signature over a canonical tuple that binds the request, the output, the provider and the provider’s reported model hash. Receipts let the coordinator settle a request by checking the provider’s signature instead of taking its word. For the buyer-facing guide, see Guides → Signed receipts.

​
Two receipt profiles

Both profiles are signed the same way:
JCS is RFC 8785 JSON canonicalization, so key order comes from JCS rather than the order in the tables below.

​
The v0.4 settlement tuple

Twenty-three signed fields: usage holds five integers: observed_input_tokens, observed_output_tokens, billable_input_tokens, billable_output_tokens and delivered_output_bytes.

​
The v0.3 legacy tuple

Nine fields: model_hash, model_id, output_hash, prompt_hash, provider_pubkey, receipt_version ("3"), tokens_out, ttft_ms and unix_ts. model_hash may be null.

​
Getting a receipt as a buyer

  • Response header: on some non-streaming responses. Some non-streaming responses carry a v0.3 receipt in X-MacProvider-Receipt (currently roughly a quarter to a third); streams never do. For the rest, use /v1/receipts. The header is set only when the serving provider has a registered receipt key and the request was dispatched without a settlement snapshot, so the provider signed a v0.3 receipt. Replayed responses and guard-modified bodies never carry it, and v0.4 settlement receipts are never put in it. For a request that carries the header, the metadata endpoint returns attempts: []: the two are complementary.
  • Receipt metadata. GET https://api.malibu.tech/v1/receipts/{request_id} returns a metadata-only view of each settlement attempt for your own request. It needs the bearer API key of the account that made the request. The view includes the settlement outcome, receipt result, prompt and output hashes, model id and hash, catalog id and receipt key fingerprint. It never includes raw prompts, outputs or signatures.

​
Trust source

The coordinator keeps each provider’s current Ed25519 receipt public key. After a key rotation, the previous key stays valid for 7 days. The coordinator’s receipt-key lookup is not exposed on api.malibu.tech. The released verifier’s built-in key-lookup default is no longer valid, so do not rely on default key lookup. Offline verification of current receipts is pending a verifier update.

​
Verifier compatibility

The open-source verifier is macprovider-verify, published under release tags verify-v<version> (latest verify-v1.1.0). Offline verification of current receipts is pending a verifier update.

​
Where receipts get used

  • Verified model settlement. The coordinator’s verdict on the receipt decides whether the buyer is debited and the provider is credited. Missing, invalid or late receipts pay the provider nothing and release the buyer’s reservation. See Operations → Verified model settlement.
  • Buyer audit trails. Use the receipt metadata endpoint when resolving disputes. Keep any v0.3 header you receive, with the raw request and response bodies, for verification once the updated verifier ships.
  • Public stats. The per-provider routability snapshot reports whether a receipt key is present (present, pending_rotation or missing). It does not report a receipt validity rate. See Reputation.

​
What a valid receipt proves

A valid receipt proves that a holder of the provider’s receipt key signed the canonical tuple, and that the key was the one the coordinator had on record. It does not prove: honest computation (the model hash is provider-reported), hardware or binary integrity, timestamp honesty, privacy, or independence from the coordinator. Full text: Security & trust model.