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
#3
Score
0 → 0 (-5)
Cluster
mainnet-beta
Slot
443510613
Off-chain at
2026-08-25T02:59:32.344Z
Anchored at
—
Block time
—

Independent verification

1. Database (off-chain)
C9mdj8CJtejvoWbi7JkYepGYJma9mLGhHA3wBZQkUnLZ
2. Recomputed (your browser)
computing…
3. On-chain (Solana memo)
fetching…
Canonical bytes hashed (2180 chars)
{"actor":"judge","decided_at":"2026-08-25T02:59:32.097Z","decision":"review_revise","investigation_id":"26dc07e2-5780-4704-aa90-143adfe70acb","new_score":0,"page_slug":"solidity-pro-vscode-extension-malicious","prev_score":0,"reason":"The reviewer found zero disputed claims across 39 checked statements, and the page's core narrative -- two malicious Solidity Pro extensions harvesting crypto and cloud credentials, removed from Open VSX on August 6-7, 2026, and tentatively linked to the WhiteCobra threat cluster -- is confirmed by multiple independent sources with exact IOC and date matches (e.g. claim_findings[0], [3], [11], [17], [19]). The page technically crosses the approve threshold (10.26% vs 10%) only because of 4 'unverifiable' findings, none of which reflect a factual problem with the page: claim_findings[22] is an inherently unfalsifiable negative claim ('no charges reported'); claim_findings[28] is a single IOC hash not found in an incomplete source fetch; and claim_findings[30] and [31] are remediation-guidance citations that the reviewer could not access due to fetch/blocking failures, not because the underlying advice was contradicted. We weighted these as tooling limitations rather than evidentiary weaknesses. Separately, coverage_gaps flags one high-priority item -- the page lacks confirmed install/victim counts specific to this campaign (as opposed to prior, distinct WhiteCobra incidents) -- which on its own is grounds to route to revision rather than a clean approval, per policy that high-priority gaps push toward revise even when disputed_pct is low. Combining a technical (if narrow) breach of the approve threshold with a substantive high-priority gap, and weighing against the fact that nothing was actually disputed and reviewer confidence was reasonably high (0.78), we issue a light revise: request that the page attempt to source install/download figures and clarify the fetch-blocked remediation citations, while leaving the score impact minimal since the underlying reporting held up.","score_delta":-5,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}