A payment, end to end

Send one Test USD and watch it arrive

This 36.288-second cut contains only real Bob and Carol Signal simulator footage. One-screen moments pair the real interface with a side explanation; the handoff uses synchronized two-screen footage. Dead pauses are removed while retained application action stays at normal speed. The moving dot is editorial motion explaining the encrypted consignment path—not Signal UI or packet-capture evidence. No application or transaction state was reconstructed. The underlying two-hop receipt confirmed at signet heights 316765 and 316766. Test USD has no monetary or redemption value.

The issuer mints 100 Test USD

A mint is public: asset and amount go into the anchor, so anyone can audit supply. In proof lineage v3, the coin proof itself proves knowledge of the issuer seed bound by genesis. New anchors use the unspendable marker OP_0 ∥ sha256(OP_RETURN); the historical capture below predates that live-found migration.

The payment arrives as a Signal message

The consignment — coin openings plus a history-independent recursive proof of the coin's entire history — travels off-chain, end-to-end encrypted, as an ordinary Signal attachment. Signal transport carries ciphertext; after normal message decryption, the local OpenCSV wallet verifies the attachment.

The phone verifies locally

The recipient's phone verifies the recursive proof, syncs compact block filters (kilobytes), finds the anchor block via the marker, and checks locally that the coin was never spent before. No RPC, no indexer, no trusted server. The recorded build below waited for six confirmations and correctly failed closed at insufficient depth. The current draft adds a narrower provisional capability: after full proof, ownership, binding, exact-transaction, layout, and confirmed-prefix exclusion checks, it can expose the coins as available before settlement while naming replacement risk. Download alone is never enough.

Earlier 10 Test USD acceptance receipt

Bob's recipient key prefills from the Signal chat. The v4 one-input/payment-plus-change path spent the received 25 Test USD coin into 10 for Carol and 15 change. The live simulator generated the proof locally in 6.237 seconds, then signed and persisted the exact Bitcoin transaction in 42 ms. The complete instrumented operation took 5m28s because chain verification ran for 77.861s before proving and 93.163s before signing, with backup/recovery scheduling between phases. That is an acceptance-harness receipt, not a consumer-latency claim. Rust—not Swift or an anchor server—reserves Bitcoin fees, derives change, fixes the context, persists signed bytes, and relays. A child may spend a verified unconfirmed coin, but Rust re-observes the exact parent after selection and again before signing; disappearance or replacement freezes the child. The separate Bitcoin performance explainer shows why this asset dependency does not spend the parent's Bitcoin UTXO and therefore is not an ordinary Bitcoin ancestor chain. Return transaction a3a3f4b1…12dc0a later confirmed at height 316620.

A later acceptance rerun closed the stronger gate: parent 2c3bc97c…f4786 was still unconfirmed when Bob spent its exact Test USD coin into child f77ff986…24554. Both pinned providers matched both raw transactions, and Signal exposed each receipt as available before confirmation with replacement risk.

Two later gates exercised different Bitcoin mechanics. Carol sent 5 Test USD to Bob and 5 to Note to Self in shared transaction 771aefc6…03c4c3, confirmed at height 316687. A separate 1 Test USD Bob→Carol payment was safely fee-bumped from 2 to 5 sat/vB as 4ae0f1c6…cbd7f7. The replacement preserved the protocol layout and logical payment identity: Carol credited once and Signal displays one payment while both exact attachments remain available as receipts. Both public observers report the replacement confirmed at signet height 316803.

The CLI verifies Bob's transfer

On the other side, the text wallet runs the same verification: proof, anchor position, local exclusion check. VERIFIED — two independent clients accept the same consignment with no shared server.

A double-spend is rejected; the supply audit balances

Re-spending the same coin produces a conflicting anchor — the first-occurrence rule rejects it at a real block location (NullifierConflict). The public mint/redeem stream sums the supply, and anyone can recompute it.