Learnings — Client-Data / Stateless ZK Rollups
This cluster holds the nearest non-Bitcoin relatives of Shielded CSV: systems where the client holds the transaction data and the chain holds only a commitment. That is mechanically the same split zkCoins lives with — off-chain plaintext coins/balances, on-chain opaque commitment — so their hard-won answers to data availability, recovery, and proof/signature aggregation transfer more directly than anything from chains that publish full data. The recurring lesson across all of them is blunt: in a client-data design, lost data equals lost funds, and "an honest network will hand it back" is a precondition that must be engineered, not an assumption that can be wished into place. One source even files zkCoins' own model ("Intmax2, Shielded CSV") in the same row — off-chain storage, high privacy, not-yet-deployed (eprint 2025/569, summarized in the CAAW'26 slides, slide 16).
Intmax2 (stateless ZK-rollup, client-side DA)
How it works — Intmax2 is a ZK-rollup whose block producers do almost nothing: they "periodically generate a commitment to a set of transactions, distribute inclusion proofs to each sender, and collect and aggregate signatures by the senders" — they "remain unaware of the contents of each transaction or its validity" (Intmax statelessness deep-dive). All transaction data and computation are pushed to the client. Each user keeps a self-custodied balance proof — "each user needs to keep track of all merkle proofs they have received from aggregators and other users", and this collection is what is submitted to the L1 contract to withdraw (web search summary, L2BEAT/INTMAX). On-chain footprint is tiny — roughly 4–5 bytes per transaction sender — because senders are batched and signatures are BLS-aggregated; the deep-dive notes "the 4 to 6-byte DA cost is divided among a large number of users, such as 1000, reducing it to a completely negligible level" (deep-dive). L2BEAT categorises its DA as "self-custodied", and states plainly: "Funds can be lost if users lose the self-custodied data required to prove their balance." (L2BEAT INTMAX). Exit is autonomous: a user submits a ZK balance proof to the L1 liquidity/exit contract.
This is the closest living analogue to zkCoins: the same off-chain-data + on-chain-commitment split, the same "your data is your money" custody property (zkCoins' own docs state "the bundle is custody"), and the same recursive-proof spine. The differences are the anchor (Ethereum/Scroll vs Bitcoin) and the privacy goal (Intmax2 minimises footprint but is not anonymity-set-shielded the way zkCoins is). What it does not solve — recovery of lost client data — is exactly zkCoins' Recovery gap, so Intmax2 is most useful as a confirmation of the failure mode and a source of two concrete primitives (signature/transfer aggregation; balance-proof-to-contract exit), not as a recovery blueprint.
Adoptable for zkCoins
| Element | What it is | Why it fits zkCoins | Gap addressed | Fit | Effort |
|---|---|---|---|---|---|
| Signature/transfer aggregation at the publishing step | Aggregator collects many senders' commitments, BLS-aggregates their signatures, and anchors one batched commitment — amortising the on-chain cost to ~4–5 bytes/sender | zkCoins anchors a full ~177 B commitment per transaction today; a batching/aggregation layer is exactly the half-aggregated-nullifier / batched-publishing direction the Shielded CSV paper already points at | Aggregation / S2 | Med | High |
| "Stateless producer" role separation | The block producer only commits + distributes inclusion proofs + aggregates sigs; it never validates content | Cleanly matches zkCoins' two-key split — the operational/node side does publishing+inclusion, the wallet side holds spend authority; gives a principled boundary for what a batching publisher may do | S5 / Aggregation | Med | Med |
| Balance-proof → contract exit as a verifier-queryable settlement check | Withdrawal forces the user to present a self-contained proof that a global verifier (the L1 contract) checks | zkCoins' S1/S2 want a verifier-queryable check on receipt rather than trusting the source; the "present a constant-size proof to a neutral verifier" shape is reusable even though zkCoins' verifier is a node-against-Bitcoin, not a contract | S1 / S2 | Med | Research |
| Explicit "self-custodied DA" framing + 24h-timelocked exit path | Naming data-loss-as-fund-loss as a first-class risk class, plus a delayed, challengeable exit lane | zkCoins should adopt the same honesty in docs and a graceful-degradation exit story; the timelock pattern is a cheap hedge against a withholding window | Recovery / Data-availability | High | Low |
Doesn't transfer
- The L1 smart-contract escrow / exit contract has no Bitcoin equivalent — Bitcoin can't run the balance-proof verifier on-chain. zkCoins must keep "verify against your own node + Bitcoin," not "verify in a contract."
- Intmax2's aggregator-distributes-inclusion-proofs model assumes a semi-live aggregator service; zkCoins' node-is-relay model already self-hosts this, so don't import the centralised-aggregator dependency.
- Intmax2 is footprint-optimised, not anonymity-set-shielded — its privacy is "minimal data," not zkCoins' global ZK unlinkability. Borrow the aggregation, not the privacy posture.
- A real balance-proof circuit vulnerability forced Intmax to suspend legacy withdrawals — a caution that the "exit via proof" lane is only as safe as its circuit; doesn't change the design but argues for conservative, well-audited verification.
ePrint 2025/569 — UTxO Binding (Liu, Wang, Zhang)
How it works — This paper names the four structural limitations of any Bitcoin CSV protocol and is the single most on-point external source for zkCoins' recovery gap. Its taxonomy of CSV limitations is: Data Availability ("Users maintain their full TX history — data loss = token loss"), Client Coherence ("participants must apply exactly the same validation rules"), Peer Discovery ("transmitting transaction-history data to the recipient"), and State Integrity ("the full token ledger is not stored on-chain") (eprint 2025/569 slides, slide 10). Its fix is UTxO binding: each Bitcoin token-binding UTXO is uniquely bound (via a commitment hashed into an OP_RETURN) to a "shadow UTXO" on an auxiliary chain ("AuxChain", implemented on Nervos CKB) that stores the token data and rules. The AuxChain runs a Bitcoin light client, so "token transaction verification can be performed autonomously on the AuxChain" and the shadow UTXO's "locking script is conditioned on the spending status of its bitcoin UTxO." Claimed properties: Exclusive Binding, Unforgeability, and Public Verifiability — "anyone who has access to Bitcoin and AuxChain can detect double-spending or over-issuing" (slides 12–14). The authors are explicit it is "not a side chain or bridge of Bitcoin." The headline cost: each Bitcoin token-binding UTXO must carry the 546-sat dust limit (~0.4 USD), Bitcoin fees dominate, and latency is ~Bitcoin block time (slide 15).
The transferable insight is the diagnosis, not the prescription. The four-limitation taxonomy is a ready-made audit checklist for zkCoins; "Data Availability + State Integrity" is precisely zkCoins' Recovery/DA cluster, and "Peer Discovery" is its delivery/transport gap. The prescription — store the data on a second chain — is exactly what zkCoins must not do, since it abandons the no-own-chain / Bitcoin-only principle and inherits a second chain's consensus and DA assumptions. zkCoins' bet is that seed + Bitcoin + an honest, replicated network can supply availability without an AuxChain; this paper is the strongest argument that the "honest network" half is the load-bearing risk, and that public-verifiability of the spent set (its closest analogue to zkCoins' S2 accumulator) is achievable when someone holds queryable state.
Adoptable for zkCoins
| Element | What it is | Why it fits zkCoins | Gap addressed | Fit | Effort |
|---|---|---|---|---|---|
| The four-limitation CSV taxonomy as an audit lens | DA, Client Coherence, Peer Discovery, State Integrity — the structural failure classes of any CSV system | Gives zkCoins a rigorous, externally-sourced checklist; "Client Coherence" (everyone runs identical validation rules) is an under-discussed gap given zkCoins' recursive-proof versioning | Data-availability / Recovery / S1 | High | Low |
| Public Verifiability as the design target for S2 | "Anyone with Bitcoin + the state store can detect double-spend / over-issue" | This is the explicit goal of zkCoins' S2 (verifier-queryable nullifier accumulator); the paper shows it is reachable once some always-available store holds the spent set keyed to Bitcoin | S2 | Med | Research |
| "Conditioned on the spending status of its Bitcoin UTXO" linkage | The off-chain object's validity is mechanically tied to a Bitcoin spend event a light client can check | Reinforces zkCoins' "authenticate every returned blob against Bitcoin" recovery rule — the chain is the integrity anchor, the store is untrusted | Recovery / Data-availability | High | Low |
| Dust-funded data anchor as an economic baseline | 546 sat per binding UTXO ≈ 0.4 USD, fees dominate | A concrete cost yardstick for zkCoins' own per-commitment economics and anti-spam pricing | Economics | Med | Low |
Doesn't transfer
- The AuxChain / second-chain itself is a hard no. Storing data on Nervos CKB (or any AuxChain) abandons Bitcoin-anchoring / no-own-chain and imports a second chain's consensus, DA, and liveness assumptions. zkCoins' whole differentiator is not doing this.
- The "shadow UTXO" on-chain global state trivially solves DA precisely because the second chain is a global, replicated ledger — which is the cost zkCoins refuses to pay. Take the diagnosis, reject the cure.
- Public, non-shielded data model — UTxO binding is transparent ("public" privacy in the paper's own comparison); zkCoins keeps amounts/identities off-chain and shielded. Their DA solution leaks what zkCoins hides.
- The paper's authors leave privacy-enhancing binding and recovery details as open questions — so it offers no off-the-shelf private-recovery construction; zkCoins' Nostr-relay-mesh + seed-bound pull tags remain the bespoke answer.
Plasma & the general DA problem (the cautionary cluster)
How it works — Plasma kept state off-chain on a child chain and committed only Merkle roots to Ethereum, relying on fraud proofs and exit games for safety. Its fatal flaw is the data-withholding attack: a malicious operator "can commit a Merkle root that encodes a fraudulent state, then withhold the transaction data so users cannot prove the exit is invalid because they don't have the data" (Onther / Tokamak: Plasma DA problem; ethereum.org Plasma). Worse, withholding is indistinguishable from network latency — "a block is reached to validators at different times in asynchronous environment" — so honest and malicious operators cannot be told apart from the outside. The defensive primitive is the mass exit: when misbehaviour is suspected, everyone races to withdraw, which slows the attacker but "still needs a way to verify the validity of withdrawal requests during a mass exit." The precondition that makes any exit safe is brutal and direct: users must independently hold their own data — Plasma MVP's confirmation signatures force users to verify inclusion themselves before signing (Onther/Tokamak).
Plasma offers no element to adopt — it offers the failure mode to design against, and it maps with uncomfortable precision onto zkCoins' "honest cooperating network" recovery assumption. zkCoins is materially safer than Plasma in one respect: its commitments are authenticated against Bitcoin, so a withholding party "can only withhold, never forge" (zkCoins docs) — a node cannot push fraudulent state the way a Plasma operator could. But on availability the analogy holds exactly: if every relay drops a bundle before the recipient fetches it (and the sender has discarded its copy), the coin is unrecoverable — zkCoins' docs already flag this as "custody-adjacent." Plasma's history says the mitigation cannot be "assume honesty"; it must be replication + a forced-availability fallback + the user holding their own data.
Adoptable for zkCoins
| Element | What it is | Why it fits zkCoins | Gap addressed | Fit | Effort |
|---|---|---|---|---|---|
| Replication as a hard precondition, not best-effort | Plasma proved that off-chain data on a single operator is a single point of theft-by-withholding; safety requires the data to live in ≥k places | Directly hardens zkCoins' stated "honest + replicated ⇒ recovery" — turn "mirror to a few relays" from advice into an enforced replication factor with acknowledgements | Recovery / Data-availability | High | Med |
| "Hold your own data" default | Plasma MVP forced users to self-verify inclusion before signing; the user's own copy is the last line of defence | zkCoins should keep the wallet/sender retaining the bundle until a verified recipient ACK, and let the user's own node be an authoritative replica — never rely solely on foreign relays | Recovery / Delivery | High | Low |
| Withholding ≠ latency → need an availability challenge/timeout | You cannot distinguish malice from lag, so you need an explicit timeout + escalation (re-pull from more peers, alert) rather than a binary trust decision | Gives zkCoins' recovery-pull a concrete liveness protocol: deterministic retry across the relay mesh with a bounded window before flagging a coin at-risk | Recovery / Delivery | Med | Med |
| Mass-exit thinking → graceful degradation plan | A pre-agreed escape hatch when the network turns adversarial | zkCoins has no "what if the relay mesh goes hostile" story; even a documented degraded mode (fall back to user-held bundle + Bitcoin) reduces systemic risk | Recovery / Economics | Med | Research |
Doesn't transfer
- Fraud proofs / challenge games are the wrong tool — zkCoins uses validity proofs (ZK), so it never needs an interactive fraud-proof window or a watchtower. The Plasma exit-game machinery is obsolete here.
- The on-chain exit contract / bonded withdrawal has no Bitcoin analogue and assumes a programmable L1; not portable.
- Plasma's withholding lets an operator forge invalid state; zkCoins' Bitcoin-anchored commitments prevent forgery outright, so only the availability lesson transfers, not the validity lesson.
- Modern rollups "solved" this by posting full data on-chain — the one escape hatch zkCoins explicitly rejects (it would destroy shielding and the constant on-chain footprint). zkCoins must solve DA without on-chain data, which is the harder path.
Top candidates from this cluster
- Replication-as-precondition + sender-holds-until-ACK (Plasma lesson, reinforced by Intmax2's "data loss = fund loss") — Recovery / Data-availability — Fit High / Effort Med. The single highest-value takeaway: make zkCoins' "honest + replicated" recovery property real by enforcing a replication factor and verified acknowledgements, not leaving it as advice.
- The four-limitation CSV audit taxonomy (ePrint 2025/569) — Data-availability / Recovery / S1 / Client-coherence — Fit High / Effort Low. A free, rigorous checklist; surfaces the under-discussed "Client Coherence" (identical validation rules / proof versioning) gap.
- Signature/transfer aggregation at publishing (Intmax2 BLS + mass transfers) — Aggregation / S2 — Fit Med / Effort High. The clearest concrete path toward zkCoins' batched-publishing and half-aggregated-nullifier roadmap, amortising the ~177 B per-commitment cost across many senders.
- Public-verifiability as the explicit S2 target + Bitcoin-conditioned validity linkage (ePrint 2025/569) — S2 / Recovery — Fit Med / Effort Research. Confirms a verifier-queryable spent-set is achievable when an always-available store holds state keyed to Bitcoin, and reinforces "authenticate every blob against Bitcoin."