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_approve · CryptoJS Ill Bloom — Weak RNG Multi-Wallet Drain (CVE-2026-71851)
- Sequence
- #3
- Score
- 4 → 4 (0)
- Cluster
- mainnet-beta
- Slot
- 443523190
- Off-chain at
- 2026-08-27T03:34:06.869Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- DR4y5zJc5cwmmeFpUo7R5RxeoATkPxrA74gBaSjXodLX
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (1895 chars)
{"actor":"judge","decided_at":"2026-08-27T03:34:06.632Z","decision":"review_approve","investigation_id":"643728b0-3635-4fe2-98f3-9b1adc3107f5","new_score":4,"page_slug":"cryptojs-ill-bloom-weak-rng-multi-wallet-drain-cve-2026-71851","prev_score":4,"reason":"Of 30 claims checked, 27 were confirmed directly against primary sources (the GitHub Security Advisory, Coinspect's own investigation posts, and independent press), none were disputed, and only 1 was unverifiable with 2 rated partially supported. Disputed_pct is 3.3%, well within the approve band. The page's most falsifiable claim -- the CVE identifier, its CVSS score/vector, affected version range, and the 3.2.0/3.2.1-then-reverted-in-3.3.0 detail (claim_findings[1]-[4]) -- was checked against the primary advisory itself and matches precisely. The page's most alarmable claim, that this flaw caused actual multi-wallet drains rather than a merely theoretical risk (claim_findings[12]), is corroborated by matching dollar figures, wallet counts, and per-chain breakdowns across the advisory and multiple independent outlets -- it does not overstate a capability as a realized loss. The two partially_supported findings (claim_findings[10] and claim_findings[28]) concern timeline dates stated with first-of-month precision that isn't independently corroborated to the day, consistent with a known rounding artifact rather than a substantive factual error. The single unverifiable finding (claim_findings[27]) is the page generalizing a source's narrower, single-incident statement about CertiK into a broader ecosystem-risk claim -- a minor overreach in a background section, not a core allegation. Coverage gaps are all medium or low priority, so no escalation is warranted on that basis.","score_delta":0,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}