Inference Delivery Receipt — Format Specification (v1)

Status: Published 2026-08-11 · schema 1
Purpose: A vendor-neutral, definitional specification of a content-bound, dual-signed inference delivery receipt for implementers, auditors, and agent tooling.

Non-goals: Marketing copy, pricing, marketplace listing text, SDK packaging.

1. Abstract

An inference delivery receipt is a small, offline-verifiable cryptographic object that attests:

At time T, under environment E, for tenant N, an issuer with key id K asserts that
a specific input (by hash), output (by hash), model weights (by digest), and
runtime measurement (e.g. enclave PCR) participated in one inference event,
identified by receipt_id.

It is not:

• Proof of training-data provenance or dataset copyright
• Proof that a human authorized a payment (that is payment-mandate / agent-identity territory)
• A substitute for an independent third-party auditor unless the verifier independently holds the hashed material and trusts the key distribution

Payment binding (optional) lives outside this format — e.g. in an HTTP 402 / x402 extension envelope that references receipt_id and may add settlement identifiers and HTTP entity digests. See §7.

1.1 Sibling products (non-confusion) — MUST

This document defines only the inference delivery receipt.

Other dual-signed receipt products — including attestation / policy-verify receipts returned by document-verify APIs — use a different domain-separation context and different body fields (e.g. verdict, doc_sha256, measurements). Those products:

• MAY share the same envelope/crypto stack (Ed25519 + ML-DSA-44, kid, offline verify), and
• do not conform to §4, and
• MUST NOT be described as inference delivery receipts under this specification.

Implementers MUST NOT treat every dual-signed wire blob as §4-conformant.
§4 fields (enclave_measurement, input_hash, output_hash, weights_digest, …) apply only where an issuer mints an inference delivery body.

2. Conformance classes

A verifier that requires full MUST reject classical-only envelopes.

3. Identifiers and domain separation

4. Signed body (schema 1)

All multi-byte cryptographic fields below are raw 32-byte digests unless noted; on the wire they MAY be hex- or base64url-encoded so long as the canonical preimage for signing is defined and fixed (see §5).

4.1 Weights preimage (normative)

weights_digest = SHA-256(W)

• If a single file or single contiguous blob is loaded: W is those exact bytes.
• If multiple files: for each relative path in lexicographic UTF-8 order, append
  uint64_be(len(path_utf8)) || path_utf8 || uint64_be(len(content)) || content.
• W MUST NOT include archive headers, compression wrappers, timestamps, or host metadata.

4.2 Input / output preimages

Issuers MUST document how input_hash and output_hash are formed for their product.
When the delivery channel is HTTP, a separate payment-layer digest MAY bind the decoded HTTP entity body (after Content-Encoding removal); that digest is not a field of this body unless the product defines output_hash to be exactly that preimage.

5. Envelope and signatures

5.1 Logical envelope

An issued receipt is an envelope containing:

1. The canonical body (encoding fixed per implementation; CBOR or JSON with a frozen canonicalization rule — both MUST be versioned and test-vectored)
2. Key id kid (32 bytes recommended) identifying the verifying public keys
3. Ed25519 signature (64 bytes)
4. ML-DSA-44 signature (2420 bytes) for class full

Informative arity: five-element envelope (version, body, kid, ed25519_sig, ml_dsa_sig) has been used in production implementations; the normative requirement is dual-sig full class completeness, not a specific CBOR tag layout.

5.2 Verification (full class)

1. Parse envelope; reject malformed arity / lengths.
2. Resolve kid against a caller-supplied keyset (or a pinned HTTPS keyset URL the verifier trusts).
3. Recompute the body preimage under the fixed domain context.
4. Verify Ed25519 and ML-DSA-44; both MUST succeed for full.
5. Check schema / alg supported.
6. Apply verifier policy on ts, env, and key status (active / retired / revoked).

Offline-by-default: verification MUST NOT require a network call when the keyset and receipt bytes are already local. Network is only for optional key fetch or optional public-ledger inclusion (§7).

5.3 Exit / result codes (CLI-oriented, informative)

6. What the receipt does not claim

Normative non-claims (product language MUST respect these):

1. Not training provenance. No statement about datasets, copyright, or training runs.
2. Not payment authority. Does not prove a human or agent was authorized to spend.
3. Not global delivery proof alone. A hash without the corresponding bytes held by the verifier is not delivery proof to that verifier.
4. Not a substitute for key trust. Verifiers must obtain authentic public keys out of band or via a pinned key distribution channel.

7. Optional: public day inclusion

A receipt MAY be included in a daily Merkle ledger under:

Inclusion proofs (event path + tenant path + checkpoint package + anchors) are orthogonal to dual-sign verify. A verifier MAY:

1. Verify the receipt offline (§5), then
2. Verify inclusion against a caller-supplied checkpoint and anchors (zero phone-home if all files local).

8. Optional: payment binding (x402 and similar)

Payment protocols (e.g. x402) MAY attach a receipt by reference, not by rewriting §4:

Rules of composition:

• Frozen body fields MUST NOT be redefined by the payment envelope.
• If both a payment-layer contentHash and output_hash exist, the product MUST document whether they share a preimage.
• Batch settlement schemes MUST use a commitment identifier, not a fake transaction hash.

A separate draft extension key (a product-specific extension key) and an upstream offer-receipt v2 delta are product / standards tracks, not required to implement this format.

9. Test vectors

A conforming implementation MUST ship:

1. At least one valid dual-sign vector (golden body + signatures + keys)
2. At least one invalid signature vector
3. Boundary tests for weights multi-file preimage ordering

Vector format SHOULD be language-neutral JSON (hex fields) so independent implementations can assert the same intermediates.

Reference vectors (this repository): inference-receipt-vectors-v1.json
(schema freeze companion; dual-sign golden + invalid cases).

10. Versioning

11. Security considerations (summary)

Full threat models for payment binding and gateway emission live in separate design documents.

12. References (informative)

• FIPS 204 (ML-DSA)
• Ed25519
• x402 specifications (payment extensions; settlement schemes including batch-settlement)