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 · Solidity Pro VSCode Extension (Malicious)
- 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}