A signed request format, published for any wallet.

Validation runs in one fixed order, and the first failing stage decides the outcome — a wallet does not keep checking after the first failure, and two conforming implementations cannot disagree about which stage a bad request fails at.

1. Local policy first

   Before reading the request at all, the wallet checks its own configuration is sane: the current time, its issuer allowlist, the expected network and token mint, and its own ceilings for amount size, validity duration, clock skew and metadata cache age. A caller may tighten these ceilings; it may never loosen them.

2. Wire and shape

   The raw bytes must be at most 4,096 bytes of strict UTF-8, nested at most four levels deep, with no duplicate top-level JSON name — checked before the bytes are even parsed as JSON.

3. Parse and canonicalize

   The bytes parse as one JSON object, and re-canonicalizing that object must reproduce the exact input bytes. Outer whitespace is therefore a rejection, not something a scanner or a deep link may trim.

4. Field shape

   Unknown fields are rejected, then missing fields, then fields of the wrong type. Only then are the sixteen permitted fields validated by their individual rules — issuer format, ID patterns, timestamp format, amount digits, and so on.

5. Claim semantics

   Version is supported, issuer matches an exact allowlisted HTTPS identity, network and token mint match the wallet's own configuration, the amount is a valid positive integer within the digit ceiling, and the validity window is well-formed, not expired, not yet future-dated beyond the allowed skew, and not longer than the ceiling.

6. Issuer metadata and key

   The wallet validates the issuer's published key set against its own bounded shape, requires an exact issuer match and a fresh cache, finds exactly one key matching the request's key_id, and refuses a revoked key immediately even if the signature below would otherwise verify.

7. Signature

   The Ed25519 signature is verified over the canonical bytes of the other fifteen claims, using the exact public key published for that key_id.

8. Replay reservation

   request_id, payment_reference and nonce are reserved atomically, all three, for the life of the request. A duplicate of any one of them fails closed, and an otherwise-invalid request must never consume a reservation.

9. Display and approval

   Only after every prior stage passes does the wallet display the critical fields to the customer and require a separate, explicit approval. Nothing prior to this step can approve or submit a transfer by itself.

This page publishes version 1 of the protocol. The version is a field in every envelope, not an assumption: a wallet that does not implement the version named in a request rejects it rather than guessing at a best-effort interpretation. Within v1, a verifier may tighten its own ceilings — a shorter validity window, a smaller amount limit, a shorter metadata cache — but may never loosen any ceiling this specification sets. A future version, if published, would be a new document at a new path, verified independently; it does not silently change what a v1 verifier accepts.