The Wall Stops Money

Use this page when

You want a runnable, offline check of a signed governed denial before settlement, together with the exact bundle files and the chio proof verify command that checks them. Don't use this if you want the full procurement transaction traced end to end (see Procurement Tour) or the machine-checkable predicate for whether a receipt represents authoritative, real-money spend at all (see 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), then runs:
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

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"

mandate-allowance-ledger.json

{
  "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"

commerce-terminal-denial-receipt.json

{
  "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 is replayed against a temporary copy of the bundle and pinned to its own expected failure code:

commerce-payment-before-budget
commerce-mandate-occurrence-limit
commerce-expired-mandate
commerce-payment-amount-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"

commerce-terminal-allow-receipt.json

{
  "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)

"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"

settlement-packet.json

{
  "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