The Wall Stops Money

A governed denial before settlement can be checked offline, with no network and no trust in whoever handed you the files. Below are the bundle files, the chio proof verify command that checks them, and what each of the four negative cases prints when it refuses. The same transaction traced end to end is on Procurement Tour, and the predicate for whether a receipt represents authoritative spend at all is on Authoritative Spend.

One command, four records

The bundle is a signed, deterministic Proof Room bundle (schema chio.proof-room.bundle.v1), the same recompute-from-source format the Proof Room server verifies. The flagship script builds chio, runs the verifier over the checked-in bundle, and then reports four records in sequence.

bash

# One command walks the whole arc over the signed, offline bundle.
bash scripts/demo/flagship-wall-stops-money.sh

# The script builds the CLI (cargo build -p chio-cli --bin chio), sources the
# deterministic trusted-key block for this fixture, then runs:
source scripts/lib/chio-proof-trusted-keys.sh
BUNDLE=fixtures/proof-room/public-stages/commerce-transaction-passport/proof-room-bundle
chio proof verify "$BUNDLE" \
  --require denials --require commerce --require settlement \
  --require risk --require trust-market

The verifier writes a chio.transaction.verifier-report.v1 JSON report to stdout. Narrowed to its verdict:

chio proof verify | jq '{verdict, state, accepted, claims: (.verified_claims | length)}'·bash

{
  "verdict": "verified",
  "state": "verified",
  "accepted": true,
  "claims": 23
}

verified_claims is the list of claim names, not a count, so the filter above takes its length. Drop the length to read the names themselves.

After the report, the script prints one summary per record. The tail of its stdout:

flagship-wall-stops-money.sh stdout (tail)bash

-- MANDATE / ALLOWANCE --
mandate mandate-commerce-001: max_amount_minor=4200 max_occurrences=1 currency=USD

-- DENIED (kernel-signed terminal receipt) --
terminal_status=denied_guard_request kernel_key=e8da63a40ca6...
over-budget/over-limit corpus the verifier REJECTS (separate negative fixtures):
  commerce-payment-before-budget, commerce-mandate-occurrence-limit,
  commerce-expired-mandate, commerce-payment-amount-mismatch

-- ALLOWED (kernel-signed terminal receipt) --
terminal_status=allowed_executed kernel_key=e8da63a40ca6...
in-budget attempt authorized via x402/AP2/ACP verify-only protocol_projections

-- SETTLED (offline projection) --
schema=chio.commerce.settlement-packet.v1 status=settled

== NON-CLAIMS: offline verifier proof; no live money-stop, no fund custody, no availability claim. ==

Each --require flag gates a domain the report must cover: denials for the terminal denial, commerce for the mandate and order, settlement for the settlement packet, and risk plus trust-market for the cross-cutting risk-comptroller and trust-scorecard checks. A missing, tampered, or unsigned record fails the run closed.

rendering

One bundle, four records. The verifier checks the mandate bounds and hashes, verifies the DENIED and ALLOWED receipt signatures, and rejects the negative corpus behind the denial.

Stage 1: MANDATE

Record: mandate-allowance-ledger.json (schema chio.commerce.mandate-allowance-ledger.v1), holding the allowance mandate-commerce-001. It caps spend with max_amount_minor (4200, i.e. USD 42.00) and max_occurrences (1), and it is single_use. The commerce requirement checks the ledger schema, the allowance bounds, and that each entry in protocol_projections hashes to its payload under protocol-payloads/.

bash

chio proof verify "$BUNDLE" --require commerce
jq '{id, max_amount_minor, max_occurrences, currency}' \
  "$BUNDLE/mandate-allowance-ledger.json"

jq stdoutbash

{
  "id": "mandate-commerce-001",
  "max_amount_minor": 4200,
  "max_occurrences": 1,
  "currency": "USD"
}

The ledger record, trimmed to the fields the bounds are read from. The file also carries an issued_at, the five protocol_projections below, and one top-level digest per projected protocol:

mandate-allowance-ledger.jsonjson

{
  "schema": "chio.commerce.mandate-allowance-ledger.v1",
  "id": "mandate-commerce-001",
  "currency": "USD",
  "max_amount_minor": 4200,
  "max_occurrences": 1,
  "single_use": true,
  "used_occurrences": 1,
  "merchant_subject": "merchant:stripe:coffee-shop",
  "order_id": "order-public-settlement-valid",
  "valid_from": "2026-06-10T00:00:00Z",
  "expires_at": "2026-06-10T01:00:00Z",
  "quote_sha256": "9ead9dbbe19e0e2428a6bc6f..."
}

Stage 2: DENIED

Artifact: commerce-terminal-denial-receipt.json, a kernel-signed terminal receipt (schema chio.receipt.v1) whose terminal_status is denied_guard_request. The denials requirement checks that this receipt verifies under its kernel_key and that the receipt-coverage matrix records a runtime_terminal_denial row for it. The receipt carries a receipt_id, a policy_digest, the kernel key, and a signature, and little else: no amount, no mandate reference.

bash

chio proof verify "$BUNDLE" --require denials
jq '{terminal_status, receipt_id, kernel_key}' \
  "$BUNDLE/commerce-terminal-denial-receipt.json"

jq stdoutbash

{
  "terminal_status": "denied_guard_request",
  "receipt_id": "receipt-commerce-terminal-denial",
  "kernel_key": "e8da63a40ca687c87cfce05cb24a786c7e75cc49c70db5573f026f1c6a86ceaa"
}

The full receipt, which the denials requirement checks the signature of:

commerce-terminal-denial-receipt.jsonjson

{
  "schema": "chio.receipt.v1",
  "receipt_id": "receipt-commerce-terminal-denial",
  "terminal_status": "denied_guard_request",
  "policy_digest": "824f6c706f1092e0e84e5c9b...",
  "kernel_key": "e8da63a40ca687c87cfce05c...",
  "signature": "425dc80cbb68c93823659daa..."
}

Behind the signed denial, the same bundle ships a negative corpus the verifier must reject, one case per out-of-policy attempt. Each case is a complete bundle under negatives/catalog/ with one record tampered, so each is a bundle you can point chio proof verify at directly. Run the four commerce cases:

bash

for n in commerce-payment-before-budget commerce-mandate-occurrence-limit \
         commerce-expired-mandate commerce-payment-amount-mismatch; do
  chio proof verify "$BUNDLE/negatives/catalog/$n" --require commerce
  echo "exit $?"
done

chio proof verify stderr (error line per case)bash

error [urn:chio:error:cli:other]: proof verify: commerce replay failed: unknown commerce transition: provider_admitted -> payment_verified via verify_payment
exit 1
error [urn:chio:error:cli:other]: proof verify: commerce mandate failed: mandate occurrence limit exceeded
exit 1
error [urn:chio:error:cli:other]: proof verify: commerce mandate failed: mandate expired before payment capture
exit 1
error [urn:chio:error:cli:other]: proof verify: commerce payment failed: payment amount or currency mismatch
exit 1

Each error line above is followed on stderr by a context: line carrying the machine-readable envelope. One case, unfiltered:

chio proof verify stderr (one case, unfiltered)bash

error [urn:chio:error:cli:other]: proof verify: commerce mandate failed: mandate occurrence limit exceeded
context: {"domain":"cli","severity":"error","stability":"deprecated","string_code":"CHIO-CLI-OTHER"}
suggested fix: Preserve the original message and migrate the call site to a specific registry code when touched.

Nothing is written on stdout for a refusal. The verifier exits 1 with an empty stdout, so there is no verdict JSON and no verified claim to read.

The second case is the allowance exhausted. Its ledger sets used_occurrences to 2 against a max_occurrences of 1, on the same mandate-commerce-001 at the same 4200 minor units. That one field is the whole tamper: the case is a byte-for-byte copy of fixtures/proof-room/commerce-payments/offline-psp-valid/mandate-allowance-ledger.json with used_occurrences raised from 1 to 2, which is why its order_id and payload digests are that commerce fixture's rather than the bundle ledger's above. The mandate check refuses the whole bundle rather than the one payment, which is why a spent allowance cannot be settled around.

Each case is pinned to the record it tampers with and to the message above, in crates/products/chio-cli/tests/proof_cli_contract/fixture.rs under proof_fixture_generate_copies_runnable_negative_passport_fixtures:

Case	Tampered record	Pinned failure
`commerce-payment-before-budget`	`event-log.json`	unknown commerce transition
`commerce-mandate-occurrence-limit`	`mandate-allowance-ledger.json`	mandate occurrence limit exceeded
`commerce-expired-mandate`	`mandate-allowance-ledger.json`	mandate expired before payment capture
`commerce-payment-amount-mismatch`	`payment-lifecycle.json`	payment amount or currency mismatch

A negative case that fails to reproduce its expected code, or one that unexpectedly passes, fails the whole run. That pairing, a signed denial that verifies plus a rejection corpus that must fail, is the checkable core of the stage.

Stage 3: ALLOWED

Artifact: commerce-terminal-allow-receipt.json, a second kernel-signed terminal receipt with terminal_status allowed_executed. It is signed by the same kernel as the denial receipt (same kernel_key and policy_digest) but is an independent receipt with its own receipt_id and signature. The in-budget attempt is authorized against the mandate's verify-only protocol_projections: x402, AP2, and ACP-Commerce payloads under protocol-payloads/, each hashed and checked, none dispatched.

bash

chio proof verify "$BUNDLE" --require commerce
jq '{terminal_status, receipt_id, kernel_key}' \
  "$BUNDLE/commerce-terminal-allow-receipt.json"

jq stdoutbash

{
  "terminal_status": "allowed_executed",
  "receipt_id": "receipt-commerce-terminal-allow",
  "kernel_key": "e8da63a40ca687c87cfce05cb24a786c7e75cc49c70db5573f026f1c6a86ceaa"
}

Same kernel_key as the denial receipt, different receipt_id and terminal_status:

commerce-terminal-allow-receipt.jsonjson

{
  "schema": "chio.receipt.v1",
  "receipt_id": "receipt-commerce-terminal-allow",
  "terminal_status": "allowed_executed",
  "policy_digest": "824f6c706f1092e0e84e5c9b...",
  "kernel_key": "e8da63a40ca687c87cfce05c...",
  "signature": "7036a4e3310e43037ef358a4..."
}

The five projections the allow path is checked against, from mandate-allowance-ledger.json (each is a payload the verifier hashes, not a call it makes):

protocol_projections (excerpt)json

"protocol_projections": [
  { "protocol": "ap2", "purpose": "checkout_mandate",
    "amount_minor": 4200, "currency": "USD",
    "payload_path": "protocol-payloads/ap2-checkout-mandate.json" },
  { "protocol": "ap2", "purpose": "payment_mandate",
    "payload_path": "protocol-payloads/ap2-payment-mandate.json" },
  { "protocol": "acp-commerce", "purpose": "delegated_payment_token",
    "payload_path": "protocol-payloads/acp-commerce-delegated-payment-token.json" },
  { "protocol": "x402", "purpose": "payment_requirements",
    "payload_path": "protocol-payloads/x402-payment-requirements.json" },
  { "protocol": "chio", "purpose": "authority_projection",
    "payload_path": "protocol-payloads/chio-authority-projection.json" }
]

Stage 4: SETTLED

Artifact: settlement-packet.json (schema chio.commerce.settlement-packet.v1) with status settled. The settlement requirement checks the packet schema and its binding to the order and quote (order_id and quote_sha256 match the mandate). The packet is an offline projection: its psp is stripe-shaped-offline and its settlement_rail is offline-psp-ledger. No rail is contacted.

bash

chio proof verify "$BUNDLE" \
  --require settlement --require risk --require trust-market
jq '{schema, status, psp, settlement_rail}' "$BUNDLE/settlement-packet.json"

jq stdoutbash

{
  "schema": "chio.commerce.settlement-packet.v1",
  "status": "settled",
  "psp": "stripe-shaped-offline",
  "settlement_rail": "offline-psp-ledger"
}

The packet the verifier read those fields from:

settlement-packet.jsonjson

{
  "schema": "chio.commerce.settlement-packet.v1",
  "id": "settlement-packet-commerce-001",
  "status": "settled",
  "amount_minor": 4200,
  "currency": "USD",
  "psp": "stripe-shaped-offline",
  "settlement_rail": "offline-psp-ledger",
  "payment_intent_id": "pi_commerce_001",
  "order_id": "order-public-settlement-valid",
  "dispatch_receipt_ref": "receipt-settlement-dispatch-commerce-001",
  "reconciliation_ref": "reconciliation-commerce-001"
}

What this proof is, and is not

This is a verifier-level proof over an offline projection. chio proof verify recomputes each record from source and checks signatures; it does not touch a live rail.

The DENIED and ALLOWED records are two independent kernel-signed terminal receipts. They carry no amount and no mandate reference (only receipt_id, terminal_status, policy_digest, kernel_key, and signature), so this walkthrough does not claim they are two occurrences of one mandate.

Settlement is a verify-only x402 / AP2 / ACP-Commerce projection over an offline PSP (psp is stripe-shaped-offline, settlement_rail is offline-psp-ledger). No funds are held or moved, there is no live money-stop, and no public availability is asserted.

One command, four records

Stage 1: MANDATE

Stage 2: DENIED

Stage 3: ALLOWED

Stage 4: SETTLED

See also