NU7 adds a term to Zcash’s supply. ZIP 259 defines the NSM reserve as “a consensus-tracked balance of ZEC/TAZ removed from circulation … not a spendable chain value pool and … not included in Issued Supply”. Zebra (ZcashFoundation/zebra#11487, #11454, #11490) and Zakura (zakura-core/zakura#1082) are each implementing it, and ZIP 259’s open issues list “Add reference implementations and test vectors for the NSM reserve”. I’ve asked the ZIP’s authors how independent vectors would fit: zcash/zips#1371.
The wider gap predates NU7: a node’s reported supply is the sum of its own pool balances, and those balances have only ever been maintained by the node that reports them. Nothing lets a third party recompute them and get the same answer byte for byte.
What’s independent, and what isn’t
Not independent: transaction parsing (Zebra since 6.4.0, Zakura and this project all use zcash_primitives), and the ZIPs themselves.
Independent: the accounting — which pool each value moves through, the issuance rules at each height, the NU7 fee removal, the reserve, and reissuance — written from the ZIPs in code shared with neither node. The transparent pool comes from its own set of unspent outputs.
Out of scope: this does not detect counterfeit shielded funds. Spending a forged note is indistinguishable from spending a real one.
Milestones (~5 months)
M1 — The NU7 window: NSM reserve reference model and test vectors (in the form agreed with the ZIP authors, or checking both implementations against theirs); the ledger core; block-by-block reconciliation of the reserve on Testnet (replayed from activation) and live across Mainnet activation, against each implementation that exposes it
M2 — Full-history recomputation, from Sprout to NU7; byte-identical across two machines and two nodes
M3 — Public report with reproduction instructions and checksums; daily verification; a proposed reconciliation step after Zebra’s own weekly Mainnet sync, which, if adopted, would keep it running without us
Budget
Startup funding: $3,000 (node infrastructure — raw blocks are the only input)
And why precisely this can’t be done by someone already in ECC/ZODL, or by a trusted node operator like our very own @emersonian ? Realistically speaking, you are the only one with the most incentive to lie here… Not a jab on you, but game theoretically speaking.
Fair question — and that’s why the design doesn’t ask anyone to trust us.
The tool is open source and deterministic: run it against any synced node and you get the per-pool balances and NSM reserve at every height, with published checksums. If our numbers were wrong, anyone re-running it would see it. @emersonian, it’d be great to have you run it independently.
Why not just a node operator? A node reports what Zebra/zcashd compute — those balances are computed once, by the same code that reports them. The point is a second, independently written accounting that checks that. Where we’re not independent we say so: transaction parsing uses zcash_primitives.
Why not ZODL or ZF? They’re implementing the code being checked (Zebra #11454, #11487, #11490); an independent check is most useful from outside that team. We’ll propose it as a step after Zebra’s weekly Mainnet full sync (an M3 deliverable); whether it lands there is the maintainers’ call, and the tool runs standalone either way.
And $47K of the $50K is paid only after each milestone is delivered; the $3K startup covers node hardware.
The design does ask people to FUND you, with a pretty penny.
Accounting that can be written in less than 30 minutes using modern AI using crates already established. Wow. What a contribution. I’d pay $50k for that, definitely.
Plus, its idiotic to spin up a node for a single task.
On the effort: summing pool balances is the easy part. The work is getting ten years of issuance rules exact at every height, then verifying that two machines reading from two different nodes produce byte-identical output. For the NSM reserve, there are no published expected values yet: ZIP 259 lists “Add reference implementations and test vectors for the NSM reserve” as an open issue. M1 delivers those, or checks both implementations against the ZIP authors’ own if they publish them first.
On the node cost: the tool reads from any synced node, and we’d welcome others running it against theirs. The $3,000 covers the Mainnet and Testnet nodes used for reconciliation over five months, including live verification across NU7 activation.
Here is the core work and our estimate, in person-weeks for a two-person team:
M1: NU7 window (weeks 1–6), ~10 person-weeks
NSM reserve reference model (ZIPs 259, 235, 237): 2–3. The specification is still moving (ZIP 237 is in review in zcash/zips#1370), so rounding and boundary cases are re-checked on each change.
Test vectors and upstream format (zcash/zips#1371): 1–2. Rounding edges, blocks either side of NU7 activation and of the reissuance start.
Issuance rules segment by segment: 4–5. Slow-start ramp over the first 20,000 blocks, Founders’ Reward to Canopy (1,046,400), the Blossom spacing change at 653,600 (which rescales both halving heights and subsidy), funding streams, the NU6 lockbox, Sprout vpub_old/vpub_new, the Ironwood turnstile. One zatoshi wrong at any height and everything after it diverges.
Transparent pool from its own unspent-output set, genesis to tip (~3.5M blocks): 2–3.
Height-by-height comparison with node-reported values, every divergence explained: 3–4. Each divergence has to be traced to either the model or the node; a node-side one goes to its security contact first.
Byte-identical reproduction on two machines against two nodes; daily incremental verification started: 1–2.
M3: Report and continuous verification (weeks 15–22), ~6 person-weeks
Public report and checksum scheme, including an independent recomputation of the range Zebra accepts through checkpoints (its Mainnet list runs to 3,485,636): 2–3.
Daily verification for ~8 weeks, divergences opened as issues: ~1.
Zebra issue and PR for a reconciliation step after its weekly Mainnet full sync: 2.
Total: ~28 person-weeks over 22 weeks. The main schedule risks are when ZIP 237 settles, the Mainnet activation date, and how many divergences the full-history comparison turns up.
My team just wrote an entire new library for light wallets in 2 days flat using a $8.64 AI. But sure. It’s too complex. Using AI isn’t bad, pretending you aren’t is. Say you do use AI and STILL take “22 person-weeks”: then you’re just incompetent at using AI, in which case you still don’t make a great case.
But what do I know. I defer the decision to the committee.