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_with_notes · BONK.fun
- Sequence
- #3
- Score
- 42 → 58 (+16)
- Cluster
- mainnet-beta
- Slot
- 443508741
- Off-chain at
- 2026-08-18T20:40:47.546Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- C2sBsKZmBe4eAXb5wwnHjAW7zbpJRhUAF7EoxgMqrMZu
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (2149 chars)
{"actor":"judge","decided_at":"2026-08-18T20:40:47.420Z","decision":"review_approve_with_notes","investigation_id":"4e806f2b-5b8e-47a3-b0ec-336c97b71675","new_score":58,"page_slug":"bonk-fun","prev_score":42,"reason":"This is a calibration adjudication: content accuracy and score are judged separately. On content, the page's core narrative — a March 2026 domain-registrar social-engineering hijack (not a protocol exploit), ~$30,000 in confirmed losses, the registrar's acknowledgment of fault, and a 110% refund relaunch — is confirmed by tier-1/tier-2 sources (claim_findings[5]-[8]). The only disputed item, claim_findings[3] (the 2025-09-01 timeline entry citing an 81% Pump.fun share), is a citation-source mismatch on a secondary competitive-dynamics fact; the underlying directional claim is independently corroborated, so it does not change what a reader concludes about the entity's risk. On score, the current 42 (WARNING) reflects the incident's severity label rather than BONK.fun's own culpability. Per the rubric's fraud-likelihood semantics, a verified third-party 'suffered' attack (category b) — with the registrar itself accepting fault, no smart-contract compromise, prompt disclosure, and above-cost refunds — caps at CAUTIONARY, not WARNING. I agree with the reviewer's calibration_assessment and adopt its recommended score of 58. Notes: (Reconcile the 82% (sections[0]) vs 84% (sections[5]) peak market-share figures to one number; independent verification puts it at ~82.7%.) (Fix the 2025-09-01 timeline entry: the cited Cryptopolitan article does not support an 81% Pump.fun figure and in fact documents the opposite trend at a different date; cite a source that supports the specific figure or soften to the directionally-corroborated claim.) (Consider a follow-up on whether the 110% refunds were actually paid out, given the review date is ~5 months post-incident.) (The 0.9% BONK price-decline figure (sections[5]) could not be traced to any cited source; verify or remove.)","score_delta":16,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}