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 · 0x62d5a59e0d67c0381aad53b201b4a1b8dcd2c833
- Sequence
- #3
- Score
- 45 → 37 (-8)
- Cluster
- mainnet-beta
- Slot
- 443525516
- Off-chain at
- 2026-08-27T10:52:34.295Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- BRWkRMFJGF3bqEaaqvXyWbMJJQNA2gQZbsanLxyLN86C
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (2264 chars)
{"actor":"judge","decided_at":"2026-08-27T10:52:33.653Z","decision":"review_revise","investigation_id":"b49b74f3-c3d5-4876-8cfd-a60919377829","new_score":37,"page_slug":"0x62d5a59e0d67c0381aad53b201b4a1b8dcd2c833","prev_score":45,"reason":"The review's own summary block was miscomputed and is superseded here: of 21 checked claims, 0 were disputed, 15 confirmed, 1 partially supported, and 5 unverifiable, giving a disputed_pct of (0+5)/21 = 23.8% under the spec's formula, which places the page in the 10-30% revise band. Every checkable factual claim about the address's on-chain history -- its EOA status, zero balance, the two zero-value transfers with exact block numbers, absence of an ENS name, and no further activity -- was independently confirmed via Blockscout and Ethplorer and still held true on a live recheck ten weeks after the page's stated investigation date (claim_findings[0], [4], [13]). The five unverifiable items driving the disputed_pct are not contradictions: two are the result of blocked or unrendered pages (ChainAbuse, Etherscan's comment section) that the reviewer could not load, not evidence the underlying claims are wrong (claim_findings[7], [9]), and two more are inherently unconfirmable negative or interpretive statements checked only by general web search (claim_findings[12], [16]). Given the absence of any actual dispute and reviewer confidence of 0.70, we apply a penalty toward the lower end of the band rather than the band's upper range. The reviewer's high-priority coverage gap -- that the page's trust score of 45 has no stated rubric connecting it to an otherwise near-blank evidentiary record (claim_findings[18], coverage_gaps[3]) -- reinforces staying in review_revise rather than approve, but is not grounds to escalate to the 30%+ band's under_investigation status, since the band table gates that status strictly to disputed_pct of 30% or more and this page sits at 23.8%; that gap is a question about the index's own scoring methodology, not a factual defect in the page, and no combination of score delta, banner, or status change in this schema can resolve it.","score_delta":-8,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}