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
4537 (-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}