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.

Decision
review_revise · ShipMonk
View on Solana ↗
Sequence
#3
Score
28 → 16 (-12)
Cluster
mainnet-beta
Slot
443515080
Off-chain at
2026-08-25T14:05:38.454Z
Anchored at
—
Block time
—

Independent verification

1. Database (off-chain)
7URqywFj1r9Dg917tFyuuiASxor6SUKQ7hCe34w3ZW7H
2. Recomputed (your browser)
computing…
3. On-chain (Solana memo)
fetching…
Canonical bytes hashed (2065 chars)
{"actor":"judge","decided_at":"2026-08-25T14:05:37.763Z","decision":"review_revise","investigation_id":"930d9ec3-3b01-456d-b86e-c788baabbe19","new_score":16,"page_slug":"shipmonk","prev_score":28,"reason":"The reviewer confirmed 20 of 24 claims outright and found only 1 disputed and 1 unverifiable, putting disputed_pct at 8.3% — mathematically inside the approve range, and the breach's core facts (the CVE, the 13,689-customer scope, the 90-day retention mitigation, and the parallel Framework/Tally/n8n/Kilo Code disclosures) are solidly confirmed against Trezor's own blog and multiple Tier-1 outlets. Two problems keep this out of approval anyway. First, the page's summary — its most-read line — says ShipMonk 'disclosed' the breach, which claim_findings[1] shows is false and contradicted by the page's own body sections and by Tier-1 sources: only Trezor ever made a public statement. A citation for the founding year (claim_findings[0]) also points to a CBInsights page that states a different year than the one claimed. Second, and more consequential, the reviewer flagged a high-priority coverage gap: ShipMonk is a non-crypto logistics company caught up in a broad, unrelated Metabase zero-day that hit several other unrelated companies too, and no source establishes any fault or misconduct on ShipMonk's part, yet the page's 'vendor risk management' section (claim_findings[22]) frames open questions in a way that risks implying an unproven governance failure. That is an aggregate framing problem, not a false-statement problem, and it is not something a disputed-claims percentage can measure — it requires the page to add plain, prominent context that ShipMonk itself is not a crypto business and is included solely as a third-party vendor, not because any source found it at fault. This revision request addresses correctable defects; it is not a judgment on whether ShipMonk should be indexed at all.","score_delta":-12,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}