Open specification docket · v1.0.0 Public issuance off

Don’t trust the cat.
Verify the receipt.

CAT means Court Attestation & Transparency: a strict, open receipt for one opted-in JudgeCat case. It binds the charge, evidence digest, consent and validity window into a filing anyone can check.

Inspect a draft receipt Read the architecture
Attests
One satirical case filing
Does not attest
Identity, safety or creditworthiness
Building next · v2 design Bilateral authority receipts Two wallets authorize the same canonical terms
CAT RECEIPT / EXHIBIT 001

Behavioural verdict

DRAFT
Subject
1111…1111
Case
#421
Ruling
Guilty
Consent
Wallet submitted
Lead charge Aggravated Top Buying 3 public-history exhibits entered into the digest.
SHA-256 Waiting for clerk…

This sample begins unsigned. CAT calls it a draft, because the court has standards about imaginary cryptography.

What the protocol changes

The roast stays ridiculous.
The record stops being vague.

WITHOUT CAT

“The court definitely said this.”

A screenshot, a crop and the defendant’s extremely selective memory.
WITH CAT

“This exact filing produced this exact digest.”

Schema, evidence hash, consent, expiry and an issuer signature that can be checked independently.
Chain of custody

One receipt. Six honest states.

No green tick appears merely because a JSON object exists.

  1. Opt inThe wallet is submitted or its controller elects to publish an existing case.
  2. FileStrict fields produce a content-derived receipt ID.
  3. DigestCanonical UTF-8 JSON is hashed with SHA-256.
  4. SignAn external Ed25519 signer may attest. No key means draft.
  5. VerifySchema, ID, digest, signer, expiry and registry state are checked.
  6. ReplaceCorrections supersede; withdrawals and expiry remain visible as states.
Authority Layer · actively building · v2 design

Two wallets.
One exact docket.

Design, not live No production signatures
No on-chain anchoring

The next CAT layer is a bilateral receipt: Wallet A proposes canonical terms and signs those bytes; Wallet B countersigns the same bytes. The useful authority comes from both controlling wallets authorizing one shared record—not from JudgeCat declaring itself emperor of contract law.

BILATERAL RECEIPT / DESIGN EXHIBIT CAT://AUTHORITY/V2-DRAFT
Canonical terms digest sha256: one proposal · one byte order · two detached signatures
Proposer · Wallet A 7vHm3…oP8s
SignsExact proposal bytes

Signature not collected

Counterparty · Wallet B 9pLz7…aW7c
CountersignsExact proposal bytes

Signature not collected

NON-TRANSACTING DESIGN PREVIEWThis exhibit requests no wallet connection, creates no signature and moves no funds.
  1. 01ProposeCanonical terms, roles, expiry and fulfilment evidence are fixed.
  2. 02Wallet A signsThe proposer authorizes that exact payload with a detached signature.
  3. 03Wallet B countersignsThe counterparty signs the identical payload—never a server-rewritten copy.
  4. 04Perform or cancelFulfilment evidence or a mutually signed cancellation updates registry state.
  5. 05Supersede or disputeCorrections create a new receipt; disagreement is recorded, not magically arbitrated.
Possible dockets

Small agreements that deserve better receipts.

  • Bounties
  • Commissions
  • Donation pledges
  • DAO work
  • Referral terms
  • Wallet challenges
First application docket · CAT Exchange

Payment matched.
Dispatch authorised.

Currently building · non-custodial · not live

The proposed portal gives a buyer and seller one signed order record, then checks a separate on-chain payment before the seller dispatches. CAT verifies the trail; it never holds the money or pretends that a receipt can force a parcel to arrive.

  1. 01File itemSeller fixes item hash, price, accepted asset, payment wallet, expiry and dispatch terms.
  2. 02Both signBuyer and seller authorize the identical canonical order bytes.
  3. 03Pay directBuyer pays the seller wallet with the CAT receipt ID as the settlement reference.
  4. 04Match chainBuyer, recipient, mint, amount, reference, time and confirmations must all match.
  5. 05DispatchOnly a verified payment opens dispatch; private delivery data stays off the public receipt.
  6. 06Close docketReceipt, refund, cancellation or dispute becomes a linked signed state—not a rewritten order.
What this improvesShared terms · exact-payment proof · dispatch timing · append-only statusWhat it cannot guaranteeIdentity · item quality · delivery · refunds · legal enforcement
Protocol anatomy

Three layers. No mystery meat.

03
Presentation

Case card

The funny human-readable verdict. It can be redesigned without changing the signed receipt beneath it.

HTML / image
02
Proof

Detached envelope

Receipt digest, issuer public key and Ed25519 signature—or an explicit unsigned draft state.

Publicly verifiable
01
Record

Canonical receipt

Closed JSON schema containing only the case, behavioural evidence digest, opt-in scope and lifecycle.

Content-addressed
Open format · JSON Schema 2020-12

Read the filing, not the marketing.

Every object is closed. Unknown fields fail. Changing a plea, timestamp or charge changes the content ID and breaks the old signature.

  • No universal score. CAT files one case at a time.
  • No identity claim. A public key is a subject, not a named person.
  • No eternal green tick. Expiry and supersession are first-class checks.
  • No secret-key theatre. The web app never invents a signing key.
Loading evidence…
RESEARCH
DOCKET
Possible future rail · not live

A measured path to Solana attestations.

Solana Attestation Service supports credential authorities, schemas, authorized signers, unique nonces and expiry. CAT could eventually anchor a small receipt digest through that system—after devnet testing, an explicit wallet opt-in and published program addresses.

Official SAS site Create-attestation docs Foundation source
  1. NowOpen CAT schema + local primitivesNo production issuer. No on-chain claim.
  2. NextSigned off-chain receipt pilotExternal signer, owner opt-in, public verifier.
  3. ResearchSAS devnet compatibilitySchema and expiry mapping tested in public.
  4. Only thenOptional mainnet anchorSeparate consent and transparent transaction cost.
The court’s technical opinion

Useful protocols make fewer promises and better receipts.

Open My Casebook