Skip to main content
AVOID.NET
← avoid.net

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

  1. 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.
  2. 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.
  3. 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.

Sequence
#3
Score
00 (0)
Cluster
mainnet-beta
Slot
443519851
Off-chain at
2026-08-26T09:05:17.721Z
Anchored at
Block time

Independent verification

1. Database (off-chain)
FrJxu1vsSAFQPbfB8TonzvXMfxv4rAaYjH6pszC6G5u1
2. Recomputed (your browser)
computing…
3. On-chain (Solana memo)
fetching…
Canonical bytes hashed (2259 chars)
{"actor":"judge","decided_at":"2026-08-26T09:05:17.561Z","decision":"review_approve","investigation_id":"5502f2b2-6209-4f96-9683-1ddd6fb3c973","new_score":0,"page_slug":"sector-drainer-daas-wallet-drainer-with-phantom-0-day-bypass","prev_score":0,"reason":"Of 44 claims checked, 41 traced cleanly to their cited sources, 1 was an unverifiable metadata date, 2 were partially supported, and none were disputed (claim_findings[0-23,26-41,43 minus the two below]). Disputed_pct works out to (0 disputed + 1 unverifiable) / 44 = 2.3%, well inside the 0-10% approve band, and the reviewer's own confidence (0.82) supports treating this as a solid pass. The dollar figures, victim counts, drainer lineage, and law-enforcement context all held up against independent sources. The one issue needing direct judgment is claim_findings[43]: the page's title and slug state 'Phantom 0-Day Bypass' without the hedge ('alleged', 'claimed') that the body text applies consistently and correctly throughout. That mismatch is real and matters more here than in a typical novelty-claim case, because it names a specific, uninvolved third-party wallet vendor in connection with an unconfirmed security flaw -- a reader who only sees the title or a search snippet could walk away thinking Phantom has a confirmed exploited bug, which the body explicitly says is not the case. However, this is a title/metadata framing issue, not a disputed factual claim, and it was logged as a medium-priority coverage gap, not a high-priority one. The scoring framework here has no lever that reaches slug/title wording directly -- disputed_pct, source-quality penalties, and the high-priority-gap override all operate on claim content, and this finding doesn't trigger any of them. Consistent with how a prior review of a different page's slug-wording mismatch was handled, I'm naming that gap plainly rather than stretching a claim-level disputed_pct or gap-severity value to manufacture a penalty it wasn't designed to carry. The fix that actually addresses the concern is editorial (retitle/re-slug with a hedge word), not a score or status action.","score_delta":0,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}