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 · Bond Protocol
- Sequence
- #3
- Score
- 42 → 58 (+16)
- Cluster
- mainnet-beta
- Slot
- 443509084
- Off-chain at
- 2026-08-19T01:41:36.902Z
- Anchored at
- —
- Block time
- —
Independent verification
- 1. Database (off-chain)
- yET9eijV36HKSPat3u2UB21jU8WJ58GwBTXafhzjTxn
- 2. Recomputed (your browser)
- computing…
- 3. On-chain (Solana memo)
- fetching…
Canonical bytes hashed (2243 chars)
{"actor":"judge","decided_at":"2026-08-19T01:41:36.746Z","decision":"review_approve_with_notes","investigation_id":"d9137293-15db-46cf-b00d-94ca66903d90","new_score":58,"page_slug":"bond-protocol","prev_score":42,"reason":"This is a calibration correction, not a content dispute: every material factual claim on the page is independently corroborated (claim_findings[0]-[6]) and disputed_pct is 0.18 with zero disputed findings, so the page's substance is not in question. The current score of 42 (WARNING) reflects treatment appropriate to own-fraud or negligence conduct, but the entity's only incident is a suffered smart-contract exploit (calibration_assessment.incident_attributions[0], attribution 'b') with same-day full fund recovery, a transparent public postmortem, and a substantive multi-audit remediation program — no own-fraud, exit-scam, or misappropriation finding exists anywhere in the review. Per the rubric's fraud-likelihood semantics, a 'suffered' incident with no fraud finding caps severity at CAUTIONARY (50-69); 58 places the entity in the lower-middle of that band, reflecting both the exculpatory recovery/remediation record and the residual concerns (bug missed by multiple prior audits, near-zero current TVL and thin team) that argue against a higher placement. Notes: (Add the November 2022 Sherlock audit contest (sherlock-audit/2022-11-bond-judging) to the timeline — the Feb 2023 contest was not the first post-incident audit, and the omission currently understates how quickly the team responded.) (Confirm the 'Bondly Finance Hack Explained (July 2021)' Halborn citation is clearly labeled as an unrelated, similarly-named project and not presented in a way a skimming reader could conflate with Bond Protocol.) (Verify the ZachXBT citations (zachxbt.mirror.xyz, paragraph.com/@investigations) are entity-specific reporting on Bond Protocol; if they are only general archive landing pages, remove them or label as general context.) (Add coverage of current operational thinness (third-party data showing headcount near 1) alongside the existing TVL-decline note.)","score_delta":16,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}