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 · Unidentified Crypto Whale — $25.6M Repeated Phishing Drain
- Sequence
- #3
- Score
- 0 → 0 (-12)
- Cluster
- mainnet-beta
- Slot
- 443514940
- Off-chain at
- 2026-08-25T13:59:41.724Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- 6w2oXEgS3foDh5YLSQszQUwZZp6H4LSqeqfQVVtBdsWp
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (1934 chars)
{"actor":"judge","decided_at":"2026-08-25T13:59:41.071Z","decision":"review_revise","investigation_id":"fee02041-4d9a-4f8c-873d-070c0eb8c403","new_score":0,"page_slug":"unidentified-crypto-whale-25-6m-repeated-phishing-drain","prev_score":0,"reason":"Fact-checking confirmed most of this page: the core incident (date, dollar amount, mechanism), the full stolen-asset breakdown, the 2023 prior incident and its figures, the 90% fund-return history, and the broader 2026 crypto-loss statistics all held up against independently fetched sources (claim_findings[0,2,3,4,6,10,11,12,13,14,15,16,17,18,19,20,22,23,24,25]). Two problems stood out. First, the page identifies address 0x8fEB...F95Ae as the attacker's, but a directly fetched CryptoRank article describes that same address as the victim's own targeted wallet -- a genuine, unresolved contradiction between sources on who the attacker actually is (claim_findings[5]). Second, the page credits AMBCrypto with a set of Blockaid statistics ($1.1B / 212 incidents / $790M) that AMBCrypto's actual article does not contain; the figures themselves are accurate and correctly cited to a different source elsewhere on the same page, making this a misattributed citation rather than a fabricated number (claim_findings[9]). Two additional claims -- the carried-forward victim wallet prefix and an 'largest incident of the month' superlative -- could not be verified either way (claim_findings[1,8]). Together these push disputed_pct to about 15%, within the minor-issues band. Separately, the reviewer found this page duplicates another AVOID.NET entry describing the identical incident; that is a platform indexing problem, not a defect in this page's content, so it is noted but not scored here to avoid double-penalizing one incident twice.","score_delta":-12,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}