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 · Coreum XRPL Bridge Exploit (August 2026)
- Sequence
- #3
- Score
- 12 → 6 (-6)
- Cluster
- mainnet-beta
- Slot
- 443514916
- Off-chain at
- 2026-08-25T13:52:01.640Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- 2hUVn87oR6dR5h5i4wC3J1YakSy5UoTyVxS4KRogCk4r
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (1749 chars)
{"actor":"judge","decided_at":"2026-08-25T13:52:01.134Z","decision":"review_revise","investigation_id":"913c528b-8895-480e-9a55-348543b6fcca","new_score":6,"page_slug":"coreum-xrpl-bridge-exploit-august-2026","prev_score":12,"reason":"Of the 52 claims checked, 42 were confirmed and only 2 were disputed, putting the raw disputed rate at about 6% — within approval range by itself. But the page's central loss figure, 199,916.3 XRP, is repeated seven times throughout the page (claim_findings[1],[18],[20],[21],[40],[43],[47]) without noting that tx's own technical lead publicly confirmed a different total, 198,715.88 XRP, a roughly 1,200 XRP gap the reviewer could not resolve and flagged as a high-priority coverage gap rather than a disputed claim. Paired with a second high-priority gap — the page cites no wallet addresses or transaction hashes at all for a fully public, independently verifiable on-chain event — this is enough to warrant a revision request, even though the technical narrative of the exploit (the deposit-verification flaw, the 17-of-28 relayer quorum, the 94-transaction/97-minute timeline, and the correct, repeated finding that the XRP Ledger itself and Ripple Labs were unaffected) is well corroborated by multiple independent outlets and tx's own statements. A separate, minor error — the claim that August 11 was XRP's 'first sub-$1 level since January 2024,' contradicted by other reporting pointing to November 2024 (claim_findings[32] and [50], same underlying error counted once) — is background market color, not a core allegation, and carries little weight on its own.","score_delta":-6,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}