OpenCSV

Issuer-backed assets verified by the parties to a payment, not by a consensus network. Shielded transfers, auditable supply, and Bitcoin ordering — no fork, new chain, or anchor server.

Watch the prototype lineage end to end

Eighty seconds: mint, anchor, off-chain transport, scan-first verification, batching — and what you trust. The animation predates the safe-marker, co-funded-v2, production-proof, and Rust account-wallet changes documented below.

Rendered with Remotion from web/animation.

What is real, what is under review, what comes last

OpenCSV publishes receipts at the boundary between those three states. A prototype result is evidence, not a production claim; a green local branch is not a merge.

On the reference main line

Proof lineage v3 + co-funded batching

Issuer authorization and predecessor keys are bound in-circuit. The 94-bit-floor proof profile, C1 co-funded transactions, and C2 two-round peer gossip have reproducible Rust receipts. The separate translated-Rust kernel refinement has 15 audited declarations on formal-aeneas/main.

Now on opencsv-rs/main

Verified kernel, accept boundary, readiness, wallet

A4/A5 adoption, dated signet/readiness evidence, C2 adversarial fixes, and the Rust-owned Signal account-wallet foundation are merged. The independent adversarial re-review was deferred by the owner, not represented as completed.

Final codebase

Signal-iOS migration

The physical-phone prototype proved encrypted delivery, native rendering, and local scanning. The final Rust custody, backup, device-binding, and crash-safe send design is not yet integrated into Signal-iOS.

Bitcoin is protocol gas, not a second payment product. The target Signal wallet exposes fee reserve, UTXOs, confirmations, and evidence, but Bitcoin can be spent only by an OpenCSV mint, transfer, or protocol-safe fee bump. There is no general BTC send or bespoke OpenCSV anchor server. Follow the exact gates in issue #1 and the Signal architecture in issue #3.

How it works

Bitcoin provides ordering and availability. Everything else — amounts, coins, validity proofs — moves directly between sender and recipient, and the recipient verifies it client-side.

01 — Mint

Issuer creates supply

A v3 mint proves knowledge of the issuer seed committed by genesis and binds the exact statement in-circuit. MINT ∥ asset_id ∥ V remains public for supply audit; new coin openings remain private.

02 — Send

Pay like sending a message

The Rust wallet reserves Bitcoin fees, fixes input zero, and anchors a 64-byte context-bound record. Raw nullifiers, coin openings, and the recursive proof travel only in the consignment, e.g. over Signal.

03 — Verify

Recipient checks, chain sleeps

The recipient verifies one history-independent proof and one Bitcoin anchor, then evaluates first occurrence from its own header/filter/block view. Explorer data may accelerate discovery; it cannot decide acceptance.

See it working

The real CLI against a real bitcoind (regtest): every anchor is a broadcast Bitcoin transaction carrying a 64-byte OP_RETURN record and a compact-filter marker — no demo chain, no mocked chain. These captures show the historical feasibility profile; current production-profile measurements are below.

captured 2026-08-03 08:53 UTC · regtest · opencsv-rs@b64bdf4

Issuer initializes a USD asset and mints 100 to Bob; the anchor transaction is broadcast and confirmed on regtest
The issuer creates a USD asset and mints 100 to Bob — the anchor is a real transaction, confirmed on-chain (gettransaction shows 6 confirmations).
Bob verifies the mint consignment: VERIFIED 100, coins stored, balance 100
Bob verifies the consignment — constant-size proof plus the on-chain anchor — and his wallet credits the coins.
Bob sends 60+40 back to the issuer (VERIFIED); a double-spend of the same coins is REJECTED by the first-occurrence rule; the supply audit reads 100 from chain data
Bob sends 60+40 back (VERIFIED); re-anchoring the same nullifiers loses to first occurrence (REJECTED); the public supply audit sums mints − redeems from chain data.

Properties

OpenCSV extends Shielded CSV's client-side validation with the predicates an RWA actually needs.

Frozen proof-lineage-v3 release measurements. The August 1 ~0.55 s phone result used the retired test profile.
ProofM4 prove (warm)VerifySizeiPhone 16e prove (cold)
Genesis mint102 ms14.8 ms535,705 B181 ms
Transfer / mint predecessors7.77 s22.2 ms854,105 B11.25 s
Transfer / node predecessors9.76 s21.4 ms841,464 B14.47 s
Redeem4.71 s19.9 ms778,466 B7.28 s

Comparison

Where OpenCSV sits among RWA and client-side-validation designs.

Client-side validationShielded transfersAuditable supplyIssuer-gated issuanceTrustless light verificationFork-free on Bitcoin
ERC-20 (Ethereum)nonoyesyestrusted RPCn/a
RGByespartialper-contractyesfull history rescanyes
Taproot Assetsyespartialissuer proofsyesissuer proofsyes
Zcashno (own chain)yesnonolightwalletd (trusted)no
Shielded CSVyesyesnonofull scan or trusted indexeryes
OpenCSVyesyesyesyescompact filters + PoW, on-deviceyes

The last two columns are where OpenCSV earns its keep. Issuer-gated issuance and auditable supply make it an RWA scheme rather than a bearer asset. The deeper one is light verification: in plain Shielded CSV, checking a double-spend means scanning every nullifier the chain has ever carried (or trusting someone who did) — fine on a desktop, impossible on a phone. OpenCSV's marker output makes anchor blocks discoverable through the same compact block filters light wallets already sync, so a phone proves "this coin was never spent before" with proof-of-work and a few kilobytes per block — no trusted server, no full scan. That's the difference between client-side validation as a theory and client-side validation that runs in your pocket.

Roadmap

From paper to a payment that arrives like a text message.

  1. Paper & site — done

    Scheme specification, security analysis, comparison. You are here.

  2. Rust core — real PCD, working

    opencsv-core + opencsv-pcd: Poseidon2 commitments and nullifiers over BabyBear, mint/transfer/redeem predicates as hand-written AIR, in-circuit FRI recursion. V3 transfers verify two predecessor proofs in-circuit: 0.84–0.85 MB proofs, ~21–22 ms verification, and history-independent size/work (7.77–9.76 s warm proving on M4). The full flow — mint → shielded transfer → double-spend rejected → redeem → public supply audit — passes end to end.

  3. Formal ledgers — machine checked

    Twenty-nine Lean specification theorems are sorry-free and CI-audited. A separate 15-declaration Aeneas audit connects the pure Rust kernel to the model without pretending the two counts are one.

  4. Signal prototype — live-tested

    Both directions worked over production Signal on a physical iPhone using the feasibility proof profile. This is preserved as prototype evidence; the final serverless Rust account wallet and v3 proof profile have not yet been integrated into Signal-iOS.

  5. Scan-first indexing — working

    A protocol-constant marker output makes anchor blocks discoverable via compact filters. A real consignment was verified with no RPC and no indexer — 320 filter bytes + 1,140 block bytes for the window — and an anchor hand-crafted with raw bitcoin-cli from the spec was discovered by the scan engine purely via the filter walk. Two implementations, one protocol, zero coordination.

  6. Production prover & batching v2 — reference stack

    Frozen proof parameters, in-circuit issuer authorization and predecessor keys, co-funded batches, authenticated gossip, durable reservations, and real multi-party regtest receipts.

  7. Finish readiness, then iOS last

    The kernel/readiness/wallet descendants are on the reference main line. The corrected C3 model is now on the formal main line; finish signet acceptance and release evidence, then migrate Signal-iOS in place and run physical crash/recovery acceptance. No mainnet or release action is implied.