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 · Hyperbridge (Polkadot-Ethereum Bridge) — April 2026 Exploit
- Sequence
- #3
- Score
- 32 → 24 (-8)
- Cluster
- mainnet-beta
- Slot
- 443521480
- Off-chain at
- 2026-08-26T15:13:38.514Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- AiSPQorEz1SnfKTC1pLHyRbcywChdrsrQ1bPmj4LfFZ8
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (2089 chars)
{"actor":"judge","decided_at":"2026-08-26T15:13:38.251Z","decision":"review_revise","investigation_id":"5f3c2907-8e30-4d82-a4a7-875cd9bc7d2c","new_score":24,"page_slug":"hyperbridge-polkadot-ethereum-bridge-april-2026-exploit","prev_score":32,"reason":"I checked the reviewer's arithmetic: 26 confirmed, 7 partially_supported, 1 disputed, 2 unverifiable, 0 stale, 0 link_rot across 36 claims gives disputed_pct = (1+2)/36 = 8.3%, matching the reviewer's own figure and the reviewer.md formula (partially_supported excluded from the numerator). On the raw table this sits inside the 0-10% approve band, and the page's central facts hold up well: the exploit date, target, root cause, and the loss revision from $237,000 to $2.5 million were all confirmed by directly fetching Hyperbridge's own post-mortem (claim_findings[1], [3], [7], [15]). I am escalating one band anyway, on a single named mechanism: coverage_gaps[0] (priority: high) is not an ordinary expansion suggestion but a structural omission directly tied to claim_findings[27] — Hyperbridge's own April 23, 2026 'First Returns' post documents a partial voluntary fund recovery that the page's Recovery Efforts section omits entirely, leaving that section reading as more unresolved than the record supports. That, combined with a compounding misattribution to named security firms (claim_findings[9]: CertiK is credited with confirming mechanics it only confirmed occurred, and 'Blocksec Falcon' appears to be a garbled, superseded-theory rendering of BlockSec Phalcon) in a section the page marks critical severity, is enough to warrant a light, unbannered-status revision rather than a bare approval. None of the remaining partially_supported findings (slug simplification, bio citation mismatches, Hypernative mischaracterization, Q1 figure sourcing) rise to the level of factual inaccuracy — they are citation-hygiene and precision issues on facts independently verified as true.","score_delta":-8,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}