Proof-Carrying Cashier
Connecting T1 / Non-custodial

ZeroClaw × Solana Pay / T1 merchant workflow

Proof-Carrying Cashier

Settlement evidence, not payment claims. A cafe owner can charge table 4 through ZeroClaw without handing the agent a wallet key. Every offer and receipt carries evidence another machine can verify.

Start 5-minute review Inspect proof ledger
26 TypeScript tests 6 Rust verifier tests 0 production vulnerabilities Human wallet signs
  1. 01OfferCanonical terms
  2. 02PaymentWallet execution
  3. 03WitnessRPC observation
  4. 04ProofOffline verification
00

Judge review pack

See the product, inspect the proof, verify it yourself.

Strong submissions make the trust path obvious. This route takes roughly five minutes and separates recorded evidence, public proof, and reproducible verification.

01 / Real browser + terminal recording Watch the deployed product and verifier run. Cloudflare site walkthrough plus a real independent verifier command. Signed payment evidence is clearly labeled localnet. Open MP4 ↗
  1. 01
    Watch the real product recording Deployed browser UI, proof tabs, raw bundle, and an actual verifier terminal run.
  2. 02
    Inspect one accepted proof Open the offer, settlement, witness, and raw bundle in the public console.
  3. 03
    Verify outside the website The command ignores the hosted verdict and recomputes hashes and signatures locally.
  4. 04
    Audit the implementation Read the ZeroClaw skill, SOPs, threat model, tests, and permission-free WASM verifier.
Public evidence Inspect accepted proof Offer + settlement + witness + raw JSON Source Open GitHub repository Skill, SOPs, TypeScript core, and Rust verifier Release Download verifier assets WASM component, fixture, checksums Submission Read the bounty post Product narrative and security update
Independent verification npm ci && npm run verify:public-proof
32
Automated tests
26 TypeScript + 6 Rust
14
Public proof checks
Ledger links + cryptographic validity
0
Keys held by agent
No signing or autonomous refunds
2
Public-network witnesses
Distinct HTTPS RPC endpoints

Evidence boundary: the published signed payment is a real Agave local-validator transaction, not public devnet. Public devnet and mainnet receipts require two distinct HTTPS RPC witnesses.

Ledger entries 0 Immutable invoice records
Settled volume 0 SOL Across paid invoices
Proof coverage 0 / 0 Paid receipts with bundles
Open invoices 0 Awaiting settlement
Attention queue 0 Fail-closed exceptions
01

Operations

Settlement ledger

Scan invoice state, proof coverage, network evidence, and exceptions from one operational surface.

Settlement invoices with state, amount, network, evidence, and update time
Order State Amount Network Evidence Updated
0 records Click a row to inspect its portable evidence.
02

Proof atlas

Evidence in physical form.

GPT Image 2 studies translate the cashier's custody boundary, witness quorum, and portable receipt into inspectable visual artifacts.

Editorial proof-carrying cashier poster showing a terminal, receipt, and evidence chain
01 / Settlement evidence Proof leaves the operator's machine.
A receipt and payment terminal study for the non-custodial cashier
02 / Merchant receipt Terms exist before funds move.
Independent blockchain witness nodes converging on a portable proof artifact
03 / Witness topology Chain state is observed, not claimed.
03

System model

Proof before credit.

The product is positioned as merchant reconciliation infrastructure, not another QR generator or autonomous payment agent.

  1. 01 / Immutable offer

    Terms exist before funds move.

    Payment ID, recipient, amount, memo, reference, expiry, offer hash, and issuer attestation.

  2. 02 / Independent witness

    Chain state is observed, not claimed.

    Recipient, amount, mint, memo, reference, slot, and transaction result are checked by RPC witnesses.

  3. 03 / Portable proof

    Evidence leaves the operator's machine.

    Offer and settlement hashes carry Ed25519 attestations and can be verified without local state.

  4. 04 / Human boundary

    Exceptions fail closed.

    Late, duplicate, invalid, disputed, or mismatched payments enter an attention queue. Refunds need approval.