Notes / Audits and snapshots

Zcash native oracle, whole set: ARO2 anchored on Testnet, 2026-09-19

Audits and snapshots2026-09-19Chain: Zcash

Source: chains/zcash/data/testnet_oracle_batch_2026-09-19.md in the repository, rendered here without changes. Source file

Extends data/testnet_oracle_poc_2026-09-19.md (ARO1: one score, Zcash L1) to every target chains/zcash/scorers.py score_all() returns, in ONE on-chain commitment. The format was already built and unit-tested, but never broadcast, by commit 7833263 (scripts/attest_scores.py, METHODOLOGY.md 9.5). This run adds the ECDSA signature over the set, a broadcast script (scripts/publish_batch.py) and the real Testnet transaction. The ARO1 attestation and its transaction are untouched.

Design and what it proves: METHODOLOGY.md 9.6. This file is the evidence trail for the run: every number below was read live, not carried over.

Constraints respected: Zcash TESTNET only (testnet.zec.rocks, consensus branch 0x37A5165B); the existing zero-value Testnet publisher key, loaded from outside the repo and never printed; no faucet, no funding request (the funds were the ARO1 change output already at the publisher address); no Mainnet write.

1. What was anchored (7 targets)#

Re-derived from a FRESH live score_all() run immediately before signing, under the methodology hash pinned in the batch header. The run aborts on any drift.

Same values as data/scored_targets_2026-09-19.md. Merkle root a323d59c09351e9cda29f27cab34ad2078568995b7e911bc40f1c0e3012c3c93, commitment 74f6ba041e253bb75e523e1b0d00422e44221c7a0240757cd1a40ad15d513662, methodology pin 8a3a1042690bfda50555667496ab9510bc86fd2d250cdb6a56334600996f4bb5.

2. Preconditions, checked before broadcasting#

3. The transaction#

Three independent confirmations, none of them this project's own parser alone:

1. SendTransaction returned errorCode 0 with the predicted txid as its message.
2. A separate lightwalletd GetTaddressTxids read returned raw bytes identical to what was signed, at height 4,368,539.
3. api.testnet.cipherscan.app (third party, Zebra-backed) lists the transaction in block 4,368,539, version 6, 255 bytes, fee 15000 zat, and its /raw hex is identical to the bytes signed.

4. Verify without trusting this project's code#

# 1. read the OP_RETURN from the chain (any lightwalletd or explorer): expect 41524f32 + the commitment
curl -s https://api.testnet.cipherscan.app/api/tx/18791a4cdaa00b5d0aefc1dcce5576c6e43ea9e203db03b0d973772dfe32cc37/raw
# 2. recompute leaves -> Merkle root -> commitment from the file's records, verify every inclusion proof
python3 chains/zcash/scripts/attest_scores.py verify chains/zcash/data/testnet_attestation_v2_2026-09-19.json
# 3. same, and additionally re-derive from a fresh live score_all() (scores may have moved since: DRIFT lines say which)
python3 chains/zcash/scripts/attest_scores.py verify chains/zcash/data/testnet_attestation_v2_2026-09-19.json --live
# 4. unit tests pinned to the real transaction bytes
python3 -m unittest scripts.lib.tests.test_zcash_batch_anchor -v

The dashboard's Zcash tab does step 1 and 2 in the browser (BLAKE2b-256 in JS) and prints MATCH or MISMATCH. The methodology pin is checked with git show 783326342d5bbc05c07cd43f649e8878a78353d6:chains/zcash/METHODOLOGY.md | sha256sum.

5. Publisher key state, stated plainly#

The key's private half was committed in clear in 40ca1a4 and stays readable in the private repo's history (data/publisher_key_exposure_2026-09-19.md). At the time of this run the out-of-repo key file carried a send_guard_lifted record: dated 2026-09-19, by the maintainer, an explicit decision recorded in the chat, risk accepted ("anyone who reads the private repo's history can forge an ARO batch from this address; a signature by it proves 'someone with access to the repo', not a specific publisher"), with the flag exposed_in_git_history set to false only so that send does not refuse and was_exposed_in_git_history kept true. This run used that state as found. The decision itself was made in a chat this run did not see: what is checked here is the file's record, not the conversation.

Consequence for what the anchor proves: see METHODOLOGY.md 9.6 "does NOT prove". publish_batch.py send still refuses any key file marked exposed (unit-tested).

6. Not verified / open#

• The scores are what this project's own scorer computed from public reads; the anchor does not make them true (METHODOLOGY.md 9.6).
• Nothing on Zcash consumes the commitment. There is no on-chain check of the ECDSA signature (transparent scripts cannot verify it): the chain stores only the hash.
• The set is the 7 targets score_all() returned at that moment. The two Maya Asgard vaults are the currently active ones and can change, which changes the set and needs a new batch.
• No automation: this is a second manual run. publish_batch.py send makes it repeatable, not scheduled.
• Remaining publisher balance was 9,965,000 zat at the time of this run (since swept, see section 7); nothing else has been funded or requested.
• The Zcash phase in the docs is not advanced by this run (a phase transition is a maker-checker decision, the project's review rules).

7. Update 2026-09-20: the same commitment re-anchored from a rotated key#

The publisher key used in this run was later rotated (data/publisher_key_exposure_2026-09-19.md, METHODOLOGY.md 9.7). Its remaining 9,965,000 zat went to a new address in one sweep (d2b5a319..., block 4,368,630), and the identical ARO2 commitment was anchored again from that address, signed by the new key: txid eeaa894c3c46814f7228a7ecf2be84c0006c1154b5101688dd413d9a419689c0, block 4,368,633 (2026-09-19T23:15:28Z), file data/testnet_attestation_v2_reanchor_2026-09-20.json. This run's own record above is unchanged: it was made by the exposed key and still proves integrity and timing only.

Not an audit, not investment advice. All notes · Back to the dashboard.