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 · debank.auction
- Sequence
- #3
- Score
- 2 → 0 (-12)
- Cluster
- mainnet-beta
- Slot
- 443514672
- Off-chain at
- 2026-08-25T13:41:22.703Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- 5goxQQq73kVPzUGjNJAxpWhKbc2p6DW49MoVhv68mYRs
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (1751 chars)
{"actor":"judge","decided_at":"2026-08-25T13:41:22.070Z","decision":"review_revise","investigation_id":"027efe27-8bb6-4acc-8596-12b3ac306d6a","new_score":0,"page_slug":"debank-auction","prev_score":2,"reason":"An independent fact-check disputed or could not verify 9 of 36 claims on this page (25%), but none of those items touch the page's central allegation — that debank.auction is a malicious typosquatting domain using hidden, AI-targeted prompt injection — which remains fully confirmed against the primary Zscaler research (claim_findings[12], [13], [16], [17], [20]). Instead, the disputed claims cluster around a recurring sourcing problem: a Hacker News article cited as coverage of this campaign that actually predates it and covers an unrelated topic (claim_findings[27], [31]), a Group-IB source cited to support a DeBank-specific claim it never makes (claim_findings[24]), and an 'updated August 5' date that appears to conflate an archive snapshot with an actual editorial revision (claim_findings[22], [35]), which also leaves a related claim unverifiable (claim_findings[29]). One minor background fact — DeBank supporting '100+' chains versus independently reported '~70+' — is also disputed (claim_findings[4]). These are citation-hygiene failures layered on top of solid core reporting, not evidence the underlying threat account is wrong. Combined with two high-priority coverage gaps (independent verification of the domain's current status, and re-verification of the mismatched citations), this warrants a moderate score reduction and a revision cycle rather than approval or denial.","score_delta":-12,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}