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_revise · Amir Hossein Rad
- Sequence
- #3
- Score
- 2 → 0 (-12)
- Cluster
- mainnet-beta
- Slot
- 443519322
- Off-chain at
- 2026-08-26T05:06:20.497Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- 4fmXiY9NZEYwmLmPtjLNgjGeSZPotrvzDfVwsctK5wBG
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (2768 chars)
{"actor":"judge","decided_at":"2026-08-26T05:06:20.271Z","decision":"review_revise","investigation_id":"e8d3f545-e0ed-42f0-8fa0-79ef47f530fc","new_score":0,"page_slug":"amir-hossein-rad","prev_score":2,"reason":"Of 23 factual claims checked against the page's cited sources, 17 were confirmed, 5 were partially supported, and 1 was disputed, for a raw disputed rate of 4.3% (claim_findings index 17). On the standard metric alone that rate would round to a clean approval. But the one disputed finding is a fabrication, not an overstatement: the page states that TRM Labs documented a named Nobitex co-founder authoring and updating the exchange's address-validation software 17 times between 2022 and 2024, and attributes this to a specific TRM Labs report. A full-text check of that report found no mention of code authorship, commit counts, or any individual developer at all -- the claim has no basis in the cited source, and it appears twice on the page (once in prose, once in the timeline). That is a different and more serious defect than a dropped hedge or a rounded-off qualifier; it is an invented, specific detail attached to a real research firm's name. The five partially-supported findings are lower-severity sourcing-precision problems: a 'largest ... to date' superlative wrongly attributed directly to Treasury when it actually comes from a compliance blog's own analysis (claim_findings index 4); a 'material support for a designated entity' framing that overstates precision, since the entity in question was not yet designated at the time of the conduct described (index 9); a $2.3 billion figure that is accurate but does not appear in any of the four sources the page cites for it (index 11); and two timeline entries with invented day-level precision where the underlying sources give only a month (indices 19-20). None of this touches the page's core, well-supported findings: the designation date, the legal authorities (E.O. 13224 and 13902), the scale and nature of the allegations against Nobitex, and Rad's role at the exchange are all confirmed by Treasury's own release and corroborated independently, the page correctly keeps Rad separate from the unrelated Kharrazi family, and the designation remains active as of today. Because this page names a living individual under active sanction, a specific fabricated attribution to a named research firm is treated as a correction-worthy defect rather than being absorbed into a clean pass by the disputed-claim percentage alone; the page should have the code-authorship claim removed or properly sourced before this is reconsidered for approval.","score_delta":-12,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}