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 · Phala Cloud (June 2026 API Breach)
- Sequence
- #2
- Score
- 52 → 52 (0)
- Cluster
- mainnet-beta
- Slot
- 443523440
- Off-chain at
- 2026-08-27T03:57:08.319Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- EeXxc5UShEsFoCgPRkUK2zZVm5twqFNsx5Ko1WbnLrEu
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (1573 chars)
{"actor":"reviewer","decided_at":"2026-08-27T03:57:08.164Z","decision":"review","investigation_id":"26425c6f-e476-4181-87a2-e94d3148db6b","new_score":52,"page_slug":"phala-cloud-june-2026-api-breach","prev_score":52,"reason":"The page's core factual account of the June 2026 Phala Cloud API incident — timestamps, the Offchain-vs-Onchain KMS scope distinction, encryption architecture, and remediation steps — is accurately and precisely sourced to Phala's own incident notice and documentation, and background/audit claims independently check out. The principal defect is in the 'Severity Context' section, which states as fact that an attacker 'was able to exfiltrate' secrets and 'bypass' TEE protection, whereas Phala's own disclosure only says a script 'may have accessed' decrypted variables and frames the flaw as an API authorization issue rather than a TEE/attestation failure — a claim the page's own Limitations section elsewhere correctly hedges, creating an internal inconsistency. A secondary issue is one timeline date (zkSecurity audit 'completion' pinned to June 1, 2025) that conflicts with the audit's own documented May 26-June 13, 2025 window, consistent with the corpus's known default-to-first-of-month artifact. One community-sentiment claim lacks any source that is actually about this incident, and one audit citation (TrustBlock) is dead, though the underlying fact was independently confirmed elsewhere.","score_delta":0,"sequence_num":2,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}