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
00 (-14)
Cluster
mainnet-beta
Slot
443513902
Off-chain at
2026-08-25T12:55:30.514Z
Anchored at
Block time

Independent verification

1. Database (off-chain)
7TJn9cRsvThRaiWhzHBLSwdk9MEA1UC2JT33A5PV7GEy
2. Recomputed (your browser)
computing…
3. On-chain (Solana memo)
fetching…
Canonical bytes hashed (2294 chars)
{"actor":"judge","decided_at":"2026-08-25T12:55:30.316Z","decision":"review_revise","investigation_id":"10622728-729b-44eb-90d4-6ea9f25dae1a","new_score":0,"page_slug":"node-gyp-npm-supply-chain-compromise-june-2026","prev_score":0,"reason":"The page's core scaffolding -- campaign scale, the Phantom Gyp/binding.gyp mechanism, the Wave 1/Wave 2 timeline, and exact package and version figures -- is confirmed with high precision against multiple independently fetched vendor sources (claim_findings[0], [3], [6], [18]), and the raw disputed-plus-unverifiable rate is a low 12.5% (4 of 32 claims). However, two issues push this above a clean approval. First, nine of 32 findings are only 'partially_supported,' and several of them are not benign imprecision: claim_findings[7] shows the page's four-stage payload description conflicts with a materially different architecture in one of its own cited sources (ReversingLabs) without flagging the disagreement, and claim_findings[15] and [16] present specific persistence-mechanism names, timers, and AI-assistant file paths that could not be traced to the sources cited for them. Claim_findings[29] is an outright disputed timeline entry: the page's own cited source was published three days before the date the timeline attributes its reporting to. Second, and more consequential, the review identifies a high-priority coverage gap: while the body text correctly states that the genuine node-gyp package and its maintainers were not backdoored (claim_findings[5]), the page's title, slug, and entity name ('node-gyp npm Supply Chain Compromise') can be read as implying the legitimate, widely-depended-upon node-gyp tool itself was compromised. That framing risk is invisible to the disputed_pct metric, which only scores body-text claims, not title/entity naming. A second high-priority gap notes a possible unreported Microsoft/GitHub impact. Together these findings warrant revision -- clarifying the entity framing and resolving the timeline date and payload-description discrepancies -- rather than a clean approval or a denial, given that the substantive factual record otherwise holds up well.","score_delta":-14,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}