Verify a decision
Every moderation decision on AVOID.NET is anchored to the Solana blockchain. You don't have to trust us — you can verify cryptographically that we committed to a verdict at a specific moment and have not rewritten it.
How verification works
- We commit. When a moderator accepts/rejects a submission, we serialize the decision into deterministic UTF-8 bytes (
payload_canonical_string), hash it with SHA-256, encode the digest as base58, and write it to Solana inside an SPL Memo v2 transaction. - We store the bytes. The exact bytes we hashed are stored alongside the decision in our database. Anyone can read them and recompute the hash in any language.
- You compare three values. Database hash, your independently-recomputed hash, and the hash inside the on-chain memo. If all three match, the decision is authentic and timestamped.
The on-chain memo format is
AVOID.NET|v1|h:<b58-sha256>|d:<id>|t:<iso>Find a signature on any investigation page's decision log, or run python -m src.verify_decision --signature <sig> for a CLI check.
Decision
review_revise · Zcash Orchard Pool Counterfeiting Vulnerability
- Sequence
- #3
- Score
- 52 → 40 (-12)
- Cluster
- mainnet-beta
- Slot
- 443524820
- Off-chain at
- 2026-08-27T08:08:53.037Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- HJTR8KUGJwDtsBZPZEUS1XgBLmxBtrEFyfqphQvWeGNw
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (2598 chars)
{"actor":"judge","decided_at":"2026-08-27T08:08:52.725Z","decision":"review_revise","investigation_id":"c2e1e834-593f-44ff-8d7f-fda4a68fcbc3","new_score":40,"page_slug":"zcash-orchard-pool-counterfeiting-vulnerability","prev_score":52,"reason":"This is one of the most thoroughly checked pages in the run (44 claims), with disputed_pct of 0.25 ((6 disputed + 5 unverifiable) / 44), placing it in the 10-30% revise band. On the question that matters most for this subject -- did the page falsely claim the vulnerability was proven not to have been exploited -- the page gets it right almost everywhere, correctly distinguishing this incident from the unrelated 2018/2019 Sprout vulnerability and matching Shielded Labs' own carefully hedged 'no way to cryptographically prove' language in its exploitation-status discussion (claim_findings[18]). That said, one earlier section overstates what the cross-pool turnstile mechanism proves, asserting the ZEC supply cap was 'verifiably intact' (claim_findings[8]) in a way that contradicts both Shielded Labs' own advisory and the page's own more careful hedging later on -- an internal inconsistency on the page's central epistemic claim, which we weight more heavily than an isolated factual slip because of what it concerns, even though the page corrects itself elsewhere. Separately, the page misdates public disclosure as June 5, 2026 rather than June 4, 2026 (per Shielded Labs' own advisory and two independent outlets); this is a single underlying error that recurs in four places (claim_findings[4, 16, 32, 41]), so we treat it as one dated fact copied across the page rather than four independent failures, which tempers its weight relative to the raw count. A separate, unrelated 30-day date error places Orchard/NU5 activation on 2022-05-01 instead of the actual May 31, 2022 (claim_findings[34]). The five unverifiable findings (a zebrad version cutoff, a $330 stabilization price, a hiring announcement, and a private-coordination start date cited in two places) are minor supporting details, not core allegations, and count against the page mainly as unresolved specifics rather than as substantive errors. A high-priority coverage gap -- the page's evidence set predates public reporting on the Ironwood upgrade that appears to implement the incident's proposed remediation -- confirms revision rather than approval is warranted even though the disputed share is at the lower end of concerning.","score_delta":-12,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}