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
- Sequence
- #4
- Score
- 37 → 37 (0)
- Cluster
- mainnet-beta
- Slot
- 457462720
- Off-chain at
- 2026-10-16T01:59:45.505Z
- Anchored at
- 2026-10-16T01:59:57.481Z
- Block time
- —
Independent verification
- 1. Database (off-chain)
- 44NPkxXoGZo4Xm1sRwoRJcc5n81noT5f4LZgzzhiR4Rq
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (1642 chars)
{"actor":"reviewer","artifact_identity":"e28ba2250306d975afb7b21686a8ba71","decided_at":"2026-10-16T01:59:45.284Z","decision":"review","disputed_pct":0.1429,"findings_hash":"78R5FJrqc71eqkv8GkUz5LDi7eUtxJvrmTUEzPjtB1E6","investigation_id":"b49b74f3-c3d5-4876-8cfd-a60919377829","mode":"findings_only","new_score":37,"page_content_hash":"4e03003d796db68b11b350f2a57c4acfaa3b01c70aaffae455516713f49b4697","page_slug":"0x62d5a59e0d67c0381aad53b201b4a1b8dcd2c833","prev_score":37,"reason":"The page's core on-chain claims are well supported: live verification confirmed the EOA classification, zero balance, exact transaction count, block numbers, dates, sender address, absence of ENS, and absence of any Etherscan label. One factual overstatement was found: the page claims the full sender address 'could not be verified through open-web sources,' but Etherscan — the page's own cited source — displays the complete untruncated address directly; this should be corrected rather than left as an unresolved gap. The ChainAbuse 'no reports' claim could not be independently rendered/confirmed due to the site's JavaScript dependency, making it unverifiable rather than confirmed or disputed. A notable omission is that the page does not flag the sender address's own dust-token-farming activity or the deceptive ERC-20-approve-selector calldata embedded in one of the two funding transactions, both of which are consistent with address-poisoning-style behavior and would be relevant to the risk narrative.","score_delta":0,"sequence_num":4,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}