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 · Trifleck
- Sequence
- #3
- Score
- 2 → 0 (-18)
- Cluster
- mainnet-beta
- Slot
- 443513059
- Off-chain at
- 2026-08-25T09:05:11.634Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- CaaaMPf78STEPdkMBQExA1uHUdACmKkJ16mJ68ut5cxS
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (2431 chars)
{"actor":"judge","decided_at":"2026-08-25T09:05:10.677Z","decision":"review_revise","investigation_id":"557dd4db-e870-418e-a663-106e68d930b0","new_score":0,"page_slug":"trifleck","prev_score":2,"reason":"This page's broad claims about the DPRK-linked 'Contagious Interview' hacking cluster -- its tactics, malware families, vendor tracking names, and prior incidents such as the Ronin, CoinsPaid, Blocknovas/Softglide, and Drift Protocol precedents -- were independently confirmed by the review. Two problems, however, stand on their own merits rather than being artifacts of one hard-to-reach source. First, the page states that the FBI's 'TraderTraitor' label applies to the same playbook described throughout the page, but CISA's own advisory (AA22-108A) tracks TraderTraitor as a distinct North Korean hacking cluster that uses a different method (fake trading apps, not fake code-review packages) -- a genuine attribution error, not a sourcing gap (claim_findings[13]). Second, nearly every fact specific to the Trifleck entity itself -- its listed address, domain-registration timeline, the named victim, the recruiter persona, employee-tenure anomalies, and the malware filename -- traces back to a single Tier-2 research blog whose article could not be directly accessed during this review; independent search corroboration supports that the source did report these details, but no second outlet confirms them, and the reviewer flagged this as a high-priority coverage gap. That is a sourcing-thinness problem rather than evidence that the entity-level narrative is false, and it should not be read as a signal that the underlying scam warning is unfounded. A citation's archival backup link is separately mismatched to an unrelated article (claim_findings[18]), a data-integrity issue independent of the source-access problem. Together these findings -- a real attribution conflation on a core claim, a high-priority single-source dependency on the entity-specific narrative, and a broken archive citation -- warrant revision (clarifying the TraderTraitor attribution and adding independent corroboration or clearer sourcing caveats) rather than outright approval or removal. The reviewer's own confidence was comparatively low, supporting a moderate rather than severe penalty.","score_delta":-18,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}