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
- Sequence
- #3
- Score
- 0 → 0 (-15)
- Cluster
- mainnet-beta
- Slot
- 443523160
- Off-chain at
- 2026-08-27T03:24:24.871Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- F9KNxnD68hRQE9oHsKYEWuv5rTMkVE1nt4bCPe2Y7Ayh
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (1994 chars)
{"actor":"judge","decided_at":"2026-08-27T03:24:19.040Z","decision":"review_revise","investigation_id":"49f04edf-4c80-4118-a494-f18aa91ae323","new_score":0,"page_slug":"keyv-cacheable-npm-supply-chain-attack-teampcp-mini-shai-hulud-august-2026","prev_score":0,"reason":"The review found the page's technical account of the keyv/cacheable npm compromise itself — the maintainer account takeover, worm self-propagation mechanism, Ethereum-contract C2 infrastructure, and remediation timeline — well corroborated by vendor sources and by an independent live check of the npm registry (claim_findings[3], [5], [6], [8]-[10], [12]). However, the page's central, title-level claim that this specific incident is attributed to the 'TeamPCP' threat group, and that multiple named vendors agree on that attribution, does not hold up: only one of roughly seven vendor sources covering the incident makes an unhedged attribution, several others describe only a malware-lineage or tooling resemblance, and one of the page's own cited sources explicitly states that no actor has been established for this incident (claim_findings[0], claim_findings[1]). A related but separate problem also surfaced in the page's TeamPCP background narrative, where specific figures and a 'seventh phase' framing are not supported by the sources cited for them (claim_findings[13], [14], [18]). TeamPCP and the Mini Shai-Hulud toolkit are real, independently documented entities — the defect is overstated confidence and breadth of attribution, not invention of an actor. At 22.7% disputed claims, concentrated substantially in the page's headline claim, combined with a high-priority gap on quantified financial/on-chain impact that matters for a platform built on on-chain evidence, the page should be revised to soften its attribution framing rather than left as-is or removed.","score_delta":-15,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}