> For the complete documentation index, see [llms.txt](https://docs.brain.fi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.brain.fi/concepts/proof.md). # Proof Why every claim Brain makes is verifiable. Every meaningful event Brain records is hashed and chained. Production tenant roots are periodically anchored on Base Sepolia; demo and sandbox tenants keep an append-only database hash chain and are not published on-chain. Brain's API and off-chain services are production available. The on-chain contract is unaudited, Base Sepolia only, and not deployed on Base mainnet. A counterparty, auditor, or end user can verify that a specific production-tenant event happened, at a specific time, with a specific decision, **without trusting Brain**. ### Two Layers of Proof | Layer | What it proves | | ------------------ | ------------------------------------------------------------------------------------- | | **Citations** | The data behind any answer or decision (transactions, invoices, evidence) | | **Merkle anchors** | That the event itself happened, in the order Brain says, with the metadata Brain says | Citations make claims traceable inside Brain. Anchors make Brain's claims independently verifiable outside Brain. ### What Gets Logged Every material state change emits an audit event: | Type | When | | --------------------- | ------------------------------------- | | `source.connected` | A source connected for the tenant | | `transaction.created` | A new transaction landed | | `wiki.query` | A natural-language question was asked | | `policy.evaluated` | A policy decision was rendered | | `action.proposed` | An agent proposed an action | | `action.approved` | A human signed approval | | `action.executed` | An action settled on its rail | | `audit.anchored` | A Merkle root was anchored on Base | Read endpoints (Wiki queries, Ledger reads) also land in the log. Anyone reviewing the trail can see exactly what was read, by whom, when. ### Tamper-Evidence Each event is hashed deterministically. Each event references the previous event's hash. The result is a per-tenant hash chain. ``` event_n.prev_hash = hash(event_{n-1}) ``` To rewrite history, you'd have to regenerate every subsequent hash. And you'd still have to fool the Merkle anchor on Base. ### On-Chain Anchors Brain batches audit events into a Merkle tree per tenant and submits up to 50 eligible tenant roots in one publisher cycle. A cycle closes when it reaches that root count or one hour of waiting, whichever comes first. An event is anchored only when its audit status records a confirmed on-chain transaction. There is no severity-accelerated anchoring path. Once published, a tenant-root pair cannot be published again. Demo and sandbox tenant roots remain database-only and are excluded from those cycles. Database-linked Base Sepolia production receipts measured on 2026-08-11 across 36 transactions and 189 roots ranged from 47,325 to 73,620 gas per tenant root, with a weighted average of 51,474. This is an observed operational measurement, not a fixed gas or cost guarantee. It does not represent a full publisher-wallet cost guarantee while wallet-to-anchor reconciliation remains under investigation. ```typescript const proof = await brain.proof(actionId); proof.merklePath; // sibling hashes from leaf to root proof.anchorRoot; // the Merkle root anchored on Base proof.anchorTx; // the transaction that anchored it ``` A counterparty verifies on-chain by checking `BrainAuditAnchor.isPublished(tenantId, root)` and calling `BrainAuditAnchor.verifyInclusion(root, leaf, proof)`. `latestAnchor(tenantId)` returns the most recently published root for a tenant. They do not need a Brain account, an API key, or access to the underlying data. ### What's on-Chain vs Off-Chain | On-chain | Off-chain | | ------------------------------ | ----------------------------------- | | Hashed `tenant_id` | Tenant's actual id | | Merkle roots | Individual events | | Published roots and block data | Event content, citations, decisions | | Publisher transaction address | Audit event signatures | The on-chain footprint is intentionally minimal. The hash commits to history without revealing anything. ### Privacy Properties | Concern | How Brain handles | | ----------------------------------- | -------------------------------------------------------------------------- | | Counterparty learns tenant identity | Tenant ID is hashed before storage | | Counterparty learns event content | Events are off-chain; only hashes anchor | | Anchor publisher compromise | Only the configured publisher can write; root uniqueness prevents replay | | Reorg drops an anchor | Pending anchors are retried; off-chain status is canonical until confirmed | ### Why "Anchored on-Chain" Matters Most audit logs in fintech are SOC 2 documents and SQL exports. They prove that the vendor cared. They don't prove that the events happened as described. An on-chain anchor is the difference between **trust** and **verify**. Even if Brain disappeared tomorrow, the on-chain record would still be queryable on Base, and any party with a Merkle proof could prove what happened. ### Where This Lives in the Protocol The proof story is the Audit layer (Layer 6) plus the six deployed protocol contracts: | Contract | Job | | ------------------------- | -------------------------------------------------------------------- | | `BrainAuditAnchor` | Anchors Merkle roots per tenant | | `BrainPolicyRegistry` | Anchors policy version hashes per tenant | | `BrainSmartAccount` | Directly called session-key account enforcing scope, caps, and nonce | | `BrainMCPAgentRegistry` | Anchors external-agent scope and behavior hashes | | `BrainEscrow` | Testnet conditional escrow locks | | `BrainReputationRegistry` | Publishes reputation roots; scoring remains placeholder | [**→ Smart contracts overview**](/smart-contracts/overview.md) ### Related | Concept | Page | | ----------------------------------- | ------------------------- | | The data that backs every answer | Memory | | The decisions captured in the trail | Policy | | Who acts and gets logged | Agents | | Deep dive | Protocol: Audit and Proof | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.brain.fi/concepts/proof.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.