Skip to main content
AVOID.NET
← avoid.net

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

  1. 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.
  2. 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.
  3. 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 · AscendEX (BitMax)
View on Solana ↗
Sequence
#3
Score
12 → 0 (-12)
Cluster
mainnet-beta
Slot
443515302
Off-chain at
2026-08-25T14:25:29.958Z
Anchored at
—
Block time
—

Independent verification

1. Database (off-chain)
5aqQ66vSdgCVR8ySxZ7AkY8ZABFAaAmTKaazWmnn9x3h
2. Recomputed (your browser)
computing…
3. On-chain (Solana memo)
fetching…
Canonical bytes hashed (2282 chars)
{"actor":"judge","decided_at":"2026-08-25T14:25:29.078Z","decision":"review_revise","investigation_id":"a2376978-bfce-4a51-9673-406ac00d7f5d","new_score":0,"page_slug":"ascendex-bitmax","prev_score":12,"reason":"The reviewer verified 33 claims and found a disputed_pct of about 15% (3 disputed + 2 unverifiable of 33), which falls in the minor-issues band, but the composition of the disputed items pulls the penalty toward the upper end of that band. Two of the three disputed findings (claim_findings[21] and [29]) are the same defect appearing twice on this page: the page states as established fact that 'multiple on-chain security agencies' attributed the December 2021 hack to North Korea's Lazarus Group, but none of the four sources the page cites for that claim make the attribution, and a dedicated incident tracker (rekt.news) records the attacker as unidentified. Naming a specific state-linked actor without support is a meaningful accuracy problem in a section heading and body text, not a minor detail. The third disputed item, claim_findings[11], is lower severity: the RootData '46% C-level transparency' figure is real and appears in a source cited elsewhere on the page (ChainCatcher), it is simply misattributed to three sources that do not contain it -- a provenance error, not a false fact. Separately, claim_findings[20] shows the page records AscendEX's 2021 reimbursement pledge without noting independent reporting indicates it was fulfilled, which leaves an unfairly unresolved impression on a fact favorable to the company. The two unverifiable findings (claim_findings[12], [16]) trace to ascendex.com returning HTTP 403 to the reviewer, a source-access limitation rather than a page defect, and the two stale findings (claim_findings[3], [13]) reflect that the page's 'no public statement' framing was accurate on June 26, 2026 but was overtaken days later by AscendEX's operational shutdown -- also not a defect at time of writing. Reviewer confidence of 0.72 and the mixed severity of the disputed items support a mid-range penalty within the minor-issues band rather than escalation to significant-issues.","score_delta":-12,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}