> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Audits
> Third-party security review of Intention's components — what is under audit now, what is not yet, and how to read a report when it publishes.
This page is the canonical record of third-party security review against Intention's components. It states what has been audited, what is under review, and — equally important — what has not been audited yet.
## Current status
| Component | Status |
| ---------------------- | ------------------------------ |
| **Cross-chain bridge** | 🔄 **Under third-party audit** |
The [cross-chain bridge](/protocol/architecture/bridge) is the component under third-party security review. Scope covers the external-chain contracts and the signer infrastructure behind them: custody, signature verification, the two-phase withdrawal path and its dispute period, and validator set propagation across the chain boundary.
The bridge was prioritized deliberately. It is the one component whose security model is not the network's own — half of it runs on another chain, with its own validators and its own failure modes, and it is where a compromise translates most directly into lost funds. The rest of the protocol is verifiable by replaying blocks; a bridge contract on an external chain is not.
The auditor and the report will be published here on completion, with scope and findings.
This is the only third-party audit currently in scope. Other components — the execution kernel, consensus, and the clearinghouse — are covered by the internal controls described below rather than by external review. Absence of a published audit is not evidence of absence of defects. Judge accordingly, particularly before mainnet.
## How to read a report when it publishes
A useful audit answers three questions: *what was in scope*, *what did reviewers actually examine*, and *what remains open at publication*. Each report published here will make all three explicit.
* **Scope** is a commit hash plus an enumerated component list. A file or contract not listed was not audited.
* **Findings** are categorized by severity. Accepted-risk findings carry the rationale and any mitigating controls, rather than being omitted.
* **Diff since audit** is tracked separately. Any post-audit change touching audited code is flagged, so you can tell whether the published report still describes the running system.
That last item is the one most often missing elsewhere. An audit describes a specific commit. Code that has moved since is code nobody reviewed, and a report that does not say so overstates what it covers.
## Continuous review
Point-in-time audits sit on top of controls that run continuously:
* **Review gates** on every kernel, consensus, and bridge change.
* **Fuzzing and property-based testing** against the matching, risk, and settlement state machines, including determinism checks that replay committed blocks and compare results byte for byte.
* **Differential testing** across independent engine builds — a divergence is treated as a consensus bug, not a test failure.
* **Public [bug bounty](/protocol/security/bug-bounty)** for ongoing external coverage.
## Where to go next
Scope, severities, and how to report a vulnerability.
What remains exposed, stated plainly.
The component under review, and where its trust assumptions sit.
What is delivered and what is gated on the dates ahead.
Questions about audit scope or a specific finding go to `contact@intention.xyz`. Vulnerability disclosures should follow the process on the [bug bounty](/protocol/security/bug-bounty) page rather than being raised here.