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 · Coldcard / Coinkite Hardware Wallet Firmware Exploit
- Sequence
- #3
- Score
- 18 → 6 (-12)
- Cluster
- mainnet-beta
- Slot
- 443521505
- Off-chain at
- 2026-08-26T15:26:41.490Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- 98bvA685d8XSsCwE7aXKVb2XZCH6QbLBctET5mbdKtUq
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (1836 chars)
{"actor":"judge","decided_at":"2026-08-26T15:26:41.043Z","decision":"review_revise","investigation_id":"2166bf7d-c5c4-4a44-a9a8-fbed8b9d3827","new_score":6,"page_slug":"coldcard-coinkite-hardware-wallet-firmware-exploit","prev_score":18,"reason":"The page's core narrative holds up: 25 of 39 extracted claims are confirmed, and disputed_pct comes to 15% (1 disputed + 5 unverifiable of 39), which falls inside the range calling for revision rather than approval or removal. The review found one materially disputed point — the page's description of the specific code change behind the flaw does not match the most detailed independent technical post-mortem, which attributes the bug to a different mechanism (a build/linker failure rather than a source-code function swap); this is one atomic claim under the reviewer's methodology, but it concerns the page's central technical explanation, not a peripheral detail, so it is weighted accordingly. Two figures were accurate when published but were quickly overtaken: the page's ~$70M 'Total Scope' loss figure was superseded within days by ~$89M and then ~$116M with signs of multiple attackers, and its 'no legal action' note predates a reported suspension of customer-data deletion in anticipation of litigation about a week later — both understate rather than overstate the incident's severity. Separately, the review surfaced that this page overlaps substantially with several other index pages describing the same underlying incident with inconsistent loss totals and no cross-references between them; that is a real index-quality problem, but it is a finding this page-level verdict records rather than one it has a mechanism to resolve.","score_delta":-12,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}