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
#2
Score
0 → 0 (0)
Cluster
mainnet-beta
Slot
443562316
Off-chain at
2026-09-02T00:42:01.471Z
Anchored at
—
Block time
—

Independent verification

1. Database (off-chain)
DRXeH4gNA6zAntZbLR74p3SiRYRxkH5e4rTJyPKeRQk4
2. Recomputed (your browser)
computing…
3. On-chain (Solana memo)
fetching…
Canonical bytes hashed (1226 chars)
{"actor":"reviewer","artifact_identity":"be4ff1d2cd2e0c1e0eec814989ab79ca","decided_at":"2026-09-02T00:42:01.377Z","decision":"review","disputed_pct":0.1765,"investigation_id":"5caaf7ce-4d97-4ee9-bd46-ceeaa5d70a7d","new_score":0,"page_slug":"lazarus-group-mach-o-man-clickfix-macos-campaign","prev_score":0,"reason":"The technical core of the page (SHA-256 hashes, C2 infrastructure, persistence mechanism, exfiltration chain, and opsec-failure narrative) is verified almost verbatim against the primary ANY.RUN source, and the broader Drift/KelpDAO context is well corroborated by independent outlets. However, the page's account of disclosure chronology and the origin of the 'North Korea's Safari' name is inaccurate — the malware was first publicly named and detailed on April 13, 2026 by the same primary researcher, eight days before the date and attribution the page presents as the first disclosure — and the MITRE ATT&CK mapping includes two technique IDs not found in either cited source while omitting the exfiltration technique that is central to the page's own narrative.","score_delta":0,"sequence_num":2,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}