The standard

The receipt, in brief

Every event in a payment's life is one receipt: sequence, event type, actor, payload, and a hash over RFC 8785 canonical JSON that binds the previous receipt. Amounts travel as fixed-point strings, never JSON numbers, so canonicalisation is exact by construction. Receipts are append only; a correction is a new receipt. A payment that violates its mandate or policy is refused before construction, and the attempt itself is receipted.

The division of proof is deliberate. Cartulary records the authority and reasoning it says it applied, and the receipt chain makes that disclosed record internally checkable; it does not independently prove the authority existed or that the reasoning was followed. The ledger proves what authorised parties executed and what state changed. The receipt chain references the prepared transaction hash and the ledger's own identifiers; it never duplicates transaction detail that the ledger deliberately partitions.

What verification proves, exactly: recomputing every hash proves no disclosed receipt was altered, reordered, or removed from the interior of the chain, relative to the hashes in hand. Three limitations are stated rather than hidden. Self-consistency is not authorship: without a signed head or an external anchor, a holder of the whole chain could rewrite an event and every subsequent hash, and the result would still verify. Truncation at the tail and whole-chain omission are invisible to recomputation. Organisation-level anchoring, on the roadmap, closes both. And partial disclosure verifies less, and says so: disclosed receipts verify by recomputation, withheld receipts are opaque commitments verified by linkage alone. The repository ships a dependency-free verifier and adversarial test vectors that run on every change.

What each protocol supplies, and what it does not

These efforts are not equivalents and should not be flattened into a slogan. This table records, per protocol: the authority object it supplies, what it does not supply, how Cartulary normalises it, what is verified cryptographically, and what remains a policy assertion. Each external row links to that protocol's own specification and is maintained against it. The last row is our own design fixture and has no specification, which its heading says.

The Verified column describes what each protocol makes cryptographically verifiable, not what Cartulary currently verifies. The protocol adapters are not built, so nothing in that column is running here.

Adapter note: settling on a shared ledger

Institutional settlement networks such as Canton permit compliance checks inside multi-step transfers, and support preparing a transaction for inspection before an external party signs it. That gives a decision layer two distinct gates. Gate one, before preparation: may this action be attempted at all, under this agent's mandate, the organisation's policy, and screening? Gate two, after preparation and before signature: is this prepared transaction exactly the one that was approved, with the sender, receiver, instrument, and amount matching the approved intent and the transaction hash independently recomputed? The external signature commits to the prepared transaction hash, and to nothing else; off-ledger metadata is not covered merely by appearing in a receipt. The adapter therefore has a design requirement: the prepared transaction must contain or reference the mandate identifier, the policy version, and the rules hash, so that the signature binds them to the resulting ledger action. Signing keys stay with the wallet or custodian; Cartulary authorises and verifies, and is never a custodian.