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.

Decision
review_revise · Trifleck
View on Solana ↗
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}