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_approve · Solana
- Sequence
- #2
- Score
- 35 → 35 (0)
- Cluster
- mainnet-beta
- Slot
- 418314626
- Off-chain at
- 2026-05-08T03:18:50.894Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- 77vKDgXdCXNUEW9H3rt8WbWWuG812Ljf8PSjyAkQ8Vq9
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (965 chars)
{"actor":"judge","decided_at":"2026-05-08T03:18:50.659Z","decision":"review_approve","investigation_id":"37f76c43-1a2b-430c-bcec-29da838671b3","new_score":35,"page_slug":"solana","prev_score":35,"reason":"Reviewer confirmed 16 of 23 claims outright and found zero disputed claims, yielding a 4% disputed rate well within the approve threshold. The five partially-supported claims involve minor numerical discrepancies (wallet hack amount, SOL price drop percentage), a misattributed source ($500M figure), and editorial opinion presented as fact (compliance toxicity from a tier-3 Medium post). One stale claim (262-day uptime counter) is factually correct at time of writing but should be updated. Coverage gaps around the dropped SEC case and network improvements are noted but do not undermine existing content accuracy.","score_delta":0,"sequence_num":2,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}