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.
- Sequence
- #4
- Score
- 47 → 47 (0)
- Cluster
- mainnet-beta
- Slot
- 457554073
- Off-chain at
- 2026-10-16T07:28:21.637Z
- Anchored at
- 2026-10-16T07:28:39.618Z
- Block time
- —
Independent verification
- 1. Database (off-chain)
- JA2a3TJjJY8U2Df5tRHmA2UcE9Q9CEmfVr4fb2QnwCnp
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (2187 chars)
{"actor":"reviewer","artifact_identity":"4cd762eac0b3fbd8e6ed16aca6955577","decided_at":"2026-10-16T07:28:21.402Z","decision":"review","disputed_pct":0.3,"findings_hash":"G5491ocPjmdUWPa9tbBPmSXe8s2MNuifTyfmJMPvkNMP","investigation_id":"78b38f72-39bb-4310-8c4f-1c0987620b7a","mode":"findings_only","new_score":47,"page_content_hash":"0ff3f3f5d42ffcdfd8e42ba8136cf1deaf98dfb6ab7b9ca1cb235390d25100bd","page_slug":"btcpay-server-lightning-lnd-macaroon-exploit-august-2026","prev_score":47,"reason":"The page's core narrative -- an unauthenticated attacker obtaining LND macaroon files from pre-2.4.2 BTCPay Server deployments, active exploitation confirmed by BTCPay on August 7, 2026, confirmed victims Foundation and Citadel21, and the three-part remediation (patch, rotate macaroons, migrate hot wallet funds) -- is well supported by the official BTCPay Server advisory, GitHub release notes, and multiple independent news outlets (CoinDesk, Blockonomi, CryptoTimes). Two defects stand out: (1) the page asserts, in its own prose, both that the TOTP/FIDO2 authentication bypass caused the macaroon exposure and, two sentences later, that developers said the two issues are distinct -- an internal contradiction not resolved by any of the four sources cited for that section, one of which (TFTC, citing Cryptonomist) actually supports the 'distinct' reading over the causal one; and (2) two timeline/date issues tied to the CoinTelegraph article, which published August 9, 2026 rather than August 8 as implied by two timeline entries. Additionally, two archive_url fields in sources_used point to completely unrelated Blockonomi articles (an AMD stock piece and a DAO treasury piece), indicating an archiving mix-up; one of these has a locatable correct replacement, the other currently has no valid Wayback snapshot at all. The Bitcoin Red Team disclosure-credit claim (four named individuals) is well corroborated by contemporaneous reporting, though the official blog post, in its current post-edit state, now credits only two of those names.","score_delta":0,"sequence_num":4,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}