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
6247 (-15)
Cluster
mainnet-beta
Slot
443516798
Off-chain at
2026-08-25T19:38:45.178Z
Anchored at
Block time

Independent verification

1. Database (off-chain)
F6R17HRSxWkxQ7C2Mzx6SVHNdbCno7hLsj8XYMXnJh2q
2. Recomputed (your browser)
computing…
3. On-chain (Solana memo)
fetching…
Canonical bytes hashed (1824 chars)
{"actor":"judge","decided_at":"2026-08-25T19:38:45.002Z","decision":"review_revise","investigation_id":"78b38f72-39bb-4310-8c4f-1c0987620b7a","new_score":47,"page_slug":"btcpay-server-lightning-lnd-macaroon-exploit-august-2026","prev_score":62,"reason":"This page on the BTCPay Server macaroon exploit is largely accurate: 28 of 35 factual claims checked out against the vendor's own advisory and independent reporting, including the core points that the flaw belonged to BTCPay Server itself rather than LND, Lightning Labs, or the Lightning protocol (claim_findings[10]), and that the incident was actively exploited rather than merely disclosed (claim_findings[4], [5]). However, two specific claims are disputed and carry real weight rather than being minor slips. The page states twice, in two separate sections, that BTCPay-generated on-chain hot wallets were at risk and needed to be migrated (claim_findings[11], claim_findings[23]); the advisory it cites says the opposite -- that BTCPay's on-chain wallets, including hot wallets, were not affected. Telling self-hosted merchants to move funds based on a risk the vendor explicitly denies could itself cause avoidable losses during migration. Separately, the page presents a distinct, previously-patched authentication bug as the 'root cause' of the still-undisclosed exploit mechanism (claim_findings[6]), which none of its cited sources support and which one source directly contradicts. With an overall disputed/unverifiable rate near 17%, no link-rot or staleness issues, and moderate-to-high reviewer confidence (0.72), this warrants correction of those two points rather than removal or formal investigation status.","score_delta":-15,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}