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 · dTRINITY dLEND
- Sequence
- #4
- Score
- 52 → 52 (0)
- Cluster
- mainnet-beta
- Slot
- 443512488
- Off-chain at
- 2026-08-25T07:44:56.281Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- Brgmgvs18UYu3TJ5mL71FupRduXD4PQXS9dtEJanty3j
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (1341 chars)
{"actor":"reviewer","decided_at":"2026-08-25T07:44:56.088Z","decision":"review","investigation_id":"32a844a0-4b60-4c3c-9c8c-06ae37b7387e","new_score":52,"page_slug":"dtrinity-dlend","prev_score":52,"reason":"The large majority of factual claims on this page — including both security-incident narratives, TVL/peg figures, and protocol overview details — are well-supported by their cited sources and corroborated independently. However, the review found a clear, cited-source contradiction on the Cyberscope 'audit' claim (Cyberscope's own page says no formal audit was completed, only an automated scan), a factual date error on the Hats Finance audit competition (the cited primary source gives June–July 2025, not August 2025 as stated twice on the page), and an internally inconsistent claim that the audit competition occurred 'after' the September 2025 exploit when it in fact preceded it under any of the dates involved. Several other claims involve minor overstatements of architectural parity across chains (Katana) or rely on weak/self-reported sourcing (regulatory-absence claims sourced only to the company's own website; several audits sourced only to the protocol's own documentation).","score_delta":0,"sequence_num":4,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}