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
228 (-14)
Cluster
mainnet-beta
Slot
443521278
Off-chain at
2026-08-26T14:09:30.074Z
Anchored at
Block time

Independent verification

1. Database (off-chain)
7QdSvejCBC9ZprkLgoEoZEfF4exa9T9uxXsTuyTwck6a
2. Recomputed (your browser)
computing…
3. On-chain (Solana memo)
fetching…
Canonical bytes hashed (2467 chars)
{"actor":"judge","decided_at":"2026-08-26T14:09:29.800Z","decision":"review_revise","investigation_id":"b67351d6-4938-413c-aa54-0ba5284676b1","new_score":8,"page_slug":"ostium-protocol-oracle-signer-key-compromise-july-2026","prev_score":22,"reason":"Independently re-tallying the review's own claim_findings array (74 entries, not the summary block's stated 75) gives 53 confirmed, 5 partially_supported, 6 disputed, 10 unverifiable, 0 stale/link_rot -- a disputed_pct of (6+10)/74 = 21.6%, versus the reviewer's reported 21.3% (16/75). Both figures fall inside the 10-30% band, so the discrepancy does not change the outcome, but it is the review's own internal arithmetic that is unreliable here, on top of what it found on the page. The bulk of the page -- the loss amount, on-chain addresses and transaction hashes, response timeline, and audit-history quotes -- is solidly corroborated (claim_findings[0], [17]-[19], [26], [28], [30]-[32], [37]-[41], [49], [51]-[53]). Set against that, the page overstates its own primary source on the incident's defining technical claim: Ostium's own post-mortem language, as quoted by The Block, describes only an 'off-chain infrastructure' compromise and explicitly rules out smart-contract or multisig causes, but never confirms that a signer private key specifically -- as opposed to a forwarder or other off-chain component -- was stolen; two independent technical outlets say the exact mechanism remains officially unconfirmed even after the post-mortem (claim_findings[1], [10], [24], [42], [73]). The page also contains a recurring arithmetic slip (10,540/12,084 ETH is ~87%, not the ~83% stated in two places), a residual-funds figure that does not reconcile with the page's own numbers, an uncited and incorrect 'second-largest exploit of July 2026' superlative, a headline statistic ($790M/74%) that could not be matched to any source, and an attribution to 'Galaxy Research' that could not be located anywhere. None of this rises to core-allegation fabrication or systemic sourcing failure, and reviewer confidence (0.72) is moderate rather than low, so denial or delisting is not warranted; but the accumulation of a load-bearing overstatement plus several distinct, concrete inaccuracies supports a revision at the higher end of this band rather than a token penalty.","score_delta":-14,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}