Program the Future
RecordBook is an experiment in agentic verification. We're exploring what happens when you take a claim, generate a transparent verification plan for it, and let an autonomous agent resolve it with a cryptographic signature that can live onchain.
1. Make a Claim
You describe a verifiable fact in plain language. RecordBook's AI generates a Structured Claim Format (SCF) and a detailed verification runbook—a step-by-step plan specifying exactly what to check, where to check it, and what counts as success. The runbook is hash-locked at creation, so the rules can't change after the fact.
2. Verify
When it's time to resolve, a verification agent executes the runbook autonomously. It gathers evidence from the specified sources, evaluates the success conditions, and returns a structured result: YES, NO, or INCONCLUSIVE—along with its reasoning and citations. No inference, no estimation. If a check can't be completed, the agent says so.
3. Attest
The agent's output is packaged into a run artifact and dual-signed: first by the agent key (proving which model produced the result), then by an attestor key via EIP-712 typed data. The signed attestation binds a claim ID, artifact hash, outcome, and timestamp into a single cryptographic proof. Everything is stored offchain in Supabase, but the artifact hash makes it tamper-evident.
4. Save Onchain
Anyone can submit a signed attestation to the onchain registry on Base. The contract verifies the signature against an allowlist of authorized attestors, stores the record, and emits an event. This step is optional and gasless for the attestor—any third party can relay it. Once onchain, the attestation is permanent and publicly verifiable.
Trust Model
- Trusted: The attestor key signs based on agent output.
- Trustless: Signature verification, hash binding, and onchain anchoring.
- Verifiable: Anyone can re-run the runbook and compare outcomes.
FAQ
What if the AI agent gets it wrong?▾
It can. Our system is designed to be transparent and auditable but mistakes can happen. Every run produces a full evidence trail — sources checked, data found, reasoning applied. Anyone can re-run the same hash-locked runbook and compare results.
Why not just use a human oracle?▾
Humans don't scale to the long tail of claims nobody wants to manually referee. RecordBook's runbooks define exact checks against exact sources, removing interpretation. The agent follows the plan mechanically. For edge cases, INCONCLUSIVE is a valid outcome — the system never guesses. As agentic verification matures, the gap with human oracles closes.
Can the rules change after a claim is created?▾
No. The runbook is hashed at creation time and that hash is part of the claim identity. Any modification would produce a different hash, making it a different claim entirely. The rules are immutable from the moment you submit.
What happens if the data source goes down?▾
The agent returns INCONCLUSIVE. Runbooks can specify fallback sources, but if none are reachable, the system won't fabricate a result. You can re-run verification later when the source is available.
Is the attestor a single point of failure?▾
Today there's a single attestor key. The architecture already supports multiple independent attestors and threshold signatures — the contract's allowlist can require N-of-M agreement. Decentralizing the attestor set is on the roadmap as the system proves itself.
Why Base and not another chain?▾
Low gas costs, fast finality, and EVM compatibility. The contract is a simple registry — it could be deployed on any EVM chain. Base just makes it cheap enough that anchoring every attestation is practical.
What can I build on top of this?▾
Anything that needs a verified future event: prediction markets, conditional bounties, insurance triggers, SLA enforcement, escrow release conditions. The onchain attestation is a composable primitive — your contract reads the outcome and acts on it. This is an experiment in agentic verification, and we're discovering the best applications alongside early builders.