Everything you need to implement against us.
Including the things vendors usually bury: rate limits, versioning, the conformance vectors, and what happens when we are down.
Protocol
Receipt format
The wire format and its constraints. draft-manav-receipt
Statement rules
R1–R6 and how stmt_hash is computed. draft-manav-statement
Verification algorithm
Step by step, including every reject code. Run the vectors
Signature suites
Hybrid Ed25519 + ML-DSA-87 (FIPS 204), pure mode, empty context.
Versioning & deprecations
The receipt wire format is versioned in the signed bytes themselves: the type tag is inside M, so a lease signature can never be presented as a receipt signature. We will name and date each format version and ship an upgrade guide per version.
A written deprecation policy, with a notice period and a support window per version, is not published yet. Until it is, format changes are recorded in the changelog.
Rate limits
| What | Limit |
|---|---|
| Passkey registrations | 30 per IP per hour |
| Statements | 120 per IP per hour |
| Agent grant actions | 300 per IP per hour |
| Host lease seeds | 12 per host per hour |
| Key set, revocation list, verification | Cache them; offline checks are unlimited |
Over the limit, the API answers 429 with { ok: false, error: "rate_limited" }.
What happens when we are down
Verification does not depend on us. A verifier with a cached key set and a cached revocation list returns the same answer whether or not the issuer is reachable. Issuing new receipts does require the issuer.
Design for it: cache the JWKS, cache the revocation list, and treat an unverifiable revocation list as a reject rather than a pass.
Raw artifacts
- Specification drafts
- Action schemas — nine published JSON schemas
- Key set (JWKS)
- Conformance vectors
- OpenAPI description: not published yet
- Source repository: not public yet; shared with evaluating customers
Start with the quickstart
Three calls to a human-signed receipt.