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_approve_with_notes · ThalaSwap
- Sequence
- #3
- Score
- 42 → 62 (+20)
- Cluster
- mainnet-beta
- Slot
- 443509197
- Off-chain at
- 2026-08-19T04:00:06.842Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- D3SExuLJdW5KkuZWNsjuEkBPyULhCAW4QwRQvQ2MJpq6
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (2392 chars)
{"actor":"judge","decided_at":"2026-08-19T04:00:06.482Z","decision":"review_approve_with_notes","investigation_id":"9ef17dd6-b7aa-4c1a-ae5c-c52a6a15cc62","new_score":62,"page_slug":"thalaswap","prev_score":42,"reason":"This is a calibration-only adjudication; the content review found no disputed claims (claim_findings show 10 confirmed, 2 partially_supported, 1 unverifiable, 0 disputed, disputed_pct 0.08), so the page's factual accuracy is not in question. The score is the problem: the incident is a suffered exploit (attribution 'b' per calibration_assessment.incident_attributions[0]) with an engineering-process failure as root cause, no evidence of insider misconduct, same-day full recovery of all $25.5M, a transparent public post-mortem, an OtterSec re-audit, and structural remediation (withdrawal rate limits). Per the rubric, a 'suffered' attribution caps the entity at CAUTIONARY (50-69), not WARNING (20-49); the current score of 42 (WARNING) misclassifies a well-handled, fully-recovered exploit as if it carried an own-conduct penalty. I agree with the reviewer's recommended band (CAUTIONARY) and score (62), which reflects strong incident response and remediation offset by the process failure that allowed an unreviewed patch to ship and by currently volatile, declining TVL. Notes: (Reconcile the Nov 16 post-mortem publication date in timeline[7] with the Medium article's own displayed byline of Nov 26, 2024; consider splitting into a Nov 16 announcement/tweet event and a separate Nov 26 detailed post-mortem event.) (Reframe the 'mid-2026 $2.23M TVL' figure in timeline[8] to note TVL volatility (ranged ~$5.3M-$2.2M within May 2026 alone, ~$613K on the v1/v2 listing as of review date) rather than presenting a single day's snapshot as a stable current state.) (Populate the blank section `content` and `heading` fields — the supplied page input had empty prose for every section, so editorial-language and causal-framing auditing could not be performed against actual reader-facing text.) (Consider adding coverage of: whether Thala's founders are publicly identified, whether a bug-bounty program (e.g., Immunefi) was established post-incident, and any MOD stablecoin peg-stability history independent of the exploit.)","score_delta":20,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}