The receipt is public.
The machinery is not the promise.

Start with what CAT can actually prove.

CAT means Court Attestation & Transparency. CAT v1 is a strict, content-addressed receipt for one opted-in JudgeCat case. It lets a verifier determine whether the presented record matches the signed record and whether the signer was trusted for that record at the relevant time.

Four layers. One honest answer.

A receipt moves through four conceptual layers. Keeping them separate prevents a polished case card from being mistaken for cryptographic proof, or a working signature from being mistaken for official trust.

1. Presentation

   Case card

   The readable JudgeCat verdict. Its design can change without changing the receipt beneath it.

2. Record

   Canonical receipt

   A closed, versioned JSON object containing the exact public facts and consent scope being filed.

3. Proof

   Domain-bound signature

   A detached signature over the canonical receipt under the CAT receipt-signing domain.

4. Trust

   Registry plus transparency state

   Public history establishes whether the signer was authorised and the exact issuance was committed at the required time.

The signed object is deliberately small.

CAT v1 accepts a closed behavioural-receipt shape. Unknown fields are not silently accepted. A separate proof object transports the signature without rewriting the immutable receipt.

{
  "receipt": {
    "protocol": { "name": "CAT", "version": "1.0.0" },
    "case": { "caseId": "…", "verdict": "…" },
    "subject": { "wallet": "…", "network": "solana" },
    "evidence": { "digest": "sha256:…" },
    "consent": { "scope": ["public_case_receipt"] },
    "validity": { "issuedAt": "…", "expiresAt": "…" },
    "receiptId": "cat:…"
  },
  "proof": {
    "algorithm": "Ed25519",
    "issuerKeyId": "cat-key:…",
    "digest": "sha256:…",
    "signature": "…"
  }
}

Verify the record, then verify the authority.

An independent verifier should follow the public contract in order and stop on failure. It must never replace a precise failure with a reassuring green tick.

1. 1

   Parse under strict limits

   Accept the documented envelope shape only. Reject malformed input, unsupported versions and unknown receipt fields.

2. 2

   Validate the schema

   Check required fields, formats, enumerations and closed-object rules against the exact versioned schema.

3. 3

   Recreate the canonical receipt

   Apply the documented canonical JSON rules so every conforming implementation reaches the same bytes.

4. 4

   Recompute identifiers

   Recreate the content-derived receipt ID and SHA-256 digest, then compare both without substitution.

5. 5

   Verify the domain-bound signature

   Verify the detached Ed25519 proof over the CAT-specific signing message—not a screenshot, rendered card or bare digest.

6. 6

   Resolve trust and lifecycle

   Check the public issuer history, validity window, transparency commitment, withdrawal and supersession state.

7. 7

   Return the exact result

   Display verified, historical, draft, unknown, invalid or another documented state without collapsing them together.

assert schema(envelope.receipt, version = "1.0.0")
canonical = canonicalise(envelope.receipt)
assert deriveReceiptId(canonical without receiptId) == receipt.receiptId
assert sha256(canonical) == proof.digest
assert verifyDomainSignature(canonical, proof)

trust = resolveIssuerHistory(proof.issuerKeyId, receipt.validity)
log   = locateExactIssuance(receipt.receiptId, proof.digest)
state = combine(trust, log, expiry, withdrawal, supersession)

return exactState(state)

The reference verifier is available at /cat-protocol#verifyReceipt. Canonicalisation rules and interoperability vectors remain part of the versioned public protocol contract; this handbook does not publish an operator runbook.

“Signature works” is only one check.

CAT exposes distinct states so downstream software can describe what it actually knows. Integrators should preserve these labels and explanations.

Receipts are immutable. Their status can change.

A signed receipt is never rewritten in place. Corrections create a new receipt; public lifecycle information explains what happened to the old one.

1. Opt in

   The wallet holder is shown the public nature and scope before filing.

2. File

   Strict receipt fields produce one content-derived identifier.

3. Issue

   An authorized issuer may attach the domain-bound proof only when production gates are open.

4. Verify

   Anyone can independently recompute the public checks.

5. Withdraw

   The application records a withdrawn presentation state; copies already held by others cannot be erased.

6. Supersede

   A correction creates a new receipt that names the earlier receipt it replaces.

7. Expire

   The record remains historical, but the verifier stops describing it as currently valid.

CAT Authority records two wallets approving the same public proposal.

CAT Authority is a separate v2-draft pilot. Wallet A signs a role-bound message for one immutable proposal. Wallet B reviews that same proposal and countersigns under a separate counterparty role. The public docket can then show whether both proofs match the exact filed proposal.

Schemas and state are inspectable at stable public paths.

These interfaces form the public integration surface. API responses remain the source of current machine-readable state; this handbook explains how to interpret them.

const response = await fetch("https://judgecat.app/api/cat-protocol/verify", {
  method: "POST",
  headers: { "content-type": "application/json" },
  body: JSON.stringify({ envelope })
});

const result = await response.json();
if (!response.ok) throw new Error(result.error || "Verification failed");

renderExactState(result.status, result.checks);

Treat public endpoints as rate-limited internet services: validate inputs locally where practical, handle non-success responses, cache only public schemas appropriately and never treat network failure as verification success.

Public receipts require public-eyed consent.

CAT minimises the signed record, but it cannot make public information private. A user should understand exactly what will be published before signing or opting in.

Ship the verifier, not a trust shortcut.

A conforming integration should be conservative: accept only versions it understands, preserve exact states and make the limits visible beside the result.

Frequently entered into evidence.