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 Counterfeit Vulnerability
- Sequence
- #3
- Score
- 38 → 28 (-10)
- Cluster
- mainnet-beta
- Slot
- 443526124
- Off-chain at
- 2026-08-27T13:12:03.319Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- GJ5MaAGMWZEpQjZp4HzawY4objM4UNuyL9K5geknYP3f
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (2170 chars)
{"actor":"judge","decided_at":"2026-08-27T13:12:03.038Z","decision":"review_revise","investigation_id":"f187a829-54e4-4673-b2b7-6c4dea8103c9","new_score":28,"page_slug":"zcash-orchard-counterfeit-vulnerability","prev_score":38,"reason":"Disputed_pct is (4 disputed + 1 unverifiable) / 41 claims = 12.2%, placing this page in the 10-30% band, which calls for a moderate revision rather than approval or denial. Three of the four disputed findings (claim_findings[0], [13], [40]) trace back to a single underlying error -- the page says the vulnerability was publicly disclosed on June 5, 2026, when the primary source and Bloomberg's reporting both point to June 4 -- so this is one factual mistake repeated in three places, not three independent ones. A second, more consequential error credits zcashd v6.12.5 with fixing the vulnerability (claim_findings[17]), when the Zcash Foundation's own release notes show v6.12.5 only disabled Orchard as a stopgap and the actual circuit fix shipped in v6.20.0 with the NU6.2 hard fork; on a page about a cryptographic soundness bug, misidentifying which release fixed it is a substantive error. The remaining disputed item (claim_findings[18], an unverifiable fork/orphan-block count) and a stale-but-excluded finding about the Ironwood upgrade already having launched are minor by comparison. Weighing against these errors, the reviewer found that the page gets the single hardest and most consequential judgment call right: it correctly frames exploitation as 'cannot be ruled out' rather than 'ruled out,' matching the primary source precisely where several secondary rewrites overstated certainty (claim_findings[22]-[23]). Reviewer confidence was solid (0.78), the highest in this review batch, supporting a routine revise rather than a harsher or softer call. A high-priority coverage gap (coverage_gaps[0], noting Ironwood has since launched and taken in over $1B in migrated ZEC) further supports revision to keep the page current, independent of the disputed_pct calculation.","score_delta":-10,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}