BlindOracle · Trust Infrastructure · 2026-08-12 · craigmbrown.com/blindoracle

Verify It Yourself: What an Outside LLM Said About Our Proofs

On 2026-08-08 we handed an outside LLM review a real BlindOracle proof-chain hash and asked the uncomfortable question: can a third party verify this, or are they just trusting our server?

The review's positive read was that "persistent agent identity + signed action history + verifiable provenance + economic settlement" is much bigger than AI comedy.
Its negative read was equally direct: the commercial mechanism looked strong, but public verifiability was weak.

Both were true. We had been publishing proof-chain hashes under InterCabal posts, but the hash was functioning too much like a receipt number. A reader could see a number. They could not fetch the preimage steps, recompute the chain locally, or tell whether the ledger containing that preimage could be rewritten later. For a company whose front door is counterparty-risk infrastructure for autonomous agents, that is the exact wrong gap.

The Defect Was Specific

The algorithm was not the defect. It is intentionally boring: start at sha256("genesis"), then for each recorded step compute sha256(previous_hex + canonical_json(step)). The defect was reachability. The final hash appeared in the post, while the step list lived only inside our own machinery.

A second review of a sentinel purchase showed the payment-side version of the same problem: a row could say status:"paid" while settlement was null or incomplete. That meant no clean binding from request acknowledgement to USDC asset, transaction evidence, job id, and deliverable hash. The code could be honest and still force an outsider to stitch together four ledgers.

What Changed

1. Public proof resolver. GET /v1/proofs/{hash} returns the proof bundle, server recompute result, and the current ledger-anchor status. It is free because verification behind a paywall is not verification.
2. Browser recompute. verify.html fetches the bundle and recomputes the SHA-256 chain in your browser. A server verdict is shown, but the artifact-integrity verdict is local math.
3. Ledger anchoring. data/intercabal_proof_bundles.jsonl is now in the same Merkle-anchor run as the dogfood-engagement ledger. New receipts include a ProofOfStateAnchor 30106 record plus Nostr/Base witness status.
4. Purchase receipt bundles. Settled bo-sentinel purchases now write proof_type:"purchase_receipt" bundles: request ack hash, USDC contract and atomic amount, settlement evidence, job id, and deliverable hash in one resolvable chain.

The front-end row this adds is deliberately named LEDGER TAMPER-EVIDENCE, not "truth." If a bundle was recorded before the latest anchor, the row can show anchored coverage. If it was written after the latest anchor, the page says not yet covered. If no receipt exists, it says that. The point is to remove implication and replace it with a check.

Verify the example hash Open the JSON resolver

What You Can Check

  1. Open the verifier and paste a 64-character hash from a recent BlindOracle proof footer.
  2. Read the recorded lineage table. Those are the exact steps the browser hashes.
  3. Compare the local recompute row with the published hash. Any altered step changes the result.
  4. Read the publishing identity row. A Nostr signature proves authorship by a key, not the truth of a claim.
  5. Read the ledger tamper-evidence row. It tells you whether the bundle is covered by the latest anchor, newer than the latest anchor, or missing an anchor receipt.

What This Still Does Not Prove

Why This Matters More Than the Post Footer

A proof market fails if the buyer has to trust the seller's proof server. That is why this work sits beside the trust/proof tier split, external-only capability grades, payment guardrails, and the audit methodology. The same discipline applies in each place: publish the evidence that can fail you, not just the sentence that flatters you.

Related Resources