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 · Bonk
- Sequence
- #3
- Score
- 45 → 33 (-12)
- Cluster
- mainnet-beta
- Slot
- 443525326
- Off-chain at
- 2026-08-27T10:40:23.320Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- D2JqMyEsYEtkQhuzXyn6yoSMh6qUMj4mBQCgfF6WBR3X
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (1746 chars)
{"actor":"judge","decided_at":"2026-08-27T10:40:22.787Z","decision":"review_revise","investigation_id":"2a48b3c5-5a6f-4913-a093-0800cc23a7e9","new_score":33,"page_slug":"bonk","prev_score":45,"reason":"The numeric disputed rate (1 disputed + 0 unverifiable out of 11 claims = 9.1%) falls in the approve band on its own, but two of this run's explicit adjustment rules override a flat approval here. First, claim_findings[7] disputes the page's own summary statement that there are 'no protocol-level exploits recorded' -- the reviewer found a well-documented ~$20M BonkDAO governance-attack treasury drain (~July 2026) and a subsequent Upbit delisting citing unresolved security issues, neither mentioned on the page. This is not a peripheral fact; it directly contradicts the core safety assurance a risk-intelligence page exists to provide, on a widely-held token, so it carries more weight than an ordinary single disputed item. Second, coverage_gaps lists a high-priority gap for exactly this same missing security-incident history, and this run's rules direct that a high-priority gap should push a page toward review_revise even when the disputed percentage is low. Compounding this, claim_findings[5] shows the page presents a 1-trillion-token burn as a hypothetical future condition when the threshold was actually reached and the burn scheduled/executed roughly eight months before this review (marked stale, wrong-direction). Given these findings, together with the reviewer's moderate (0.75) confidence, a light downward revision is warranted rather than either a clean approval or a denial.","score_delta":-12,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}