This page will be expanded once audits complete. The rows below are placeholders.
Audit history
| Auditor | Scope | Date | Report |
|---|---|---|---|
| TBD | IntentionKernel execution semantics and deterministic replay | TBD | TBD |
| TBD | IntentionBFT consensus, leader election, quorum certification | TBD | TBD |
| TBD | Cross-chain bridge contracts and signer infrastructure | TBD | TBD |
How to read an audit
A good audit answers three questions: what was in scope, what did the reviewers actually look at, and what are the open findings at release time. When we publish a report, each of those will be explicit so you can judge the signal for yourself.- Scope is expressed as a commit hash plus a list of components. If a file or contract was not audited, it will not be listed.
- Findings are categorized by severity. Accepted-risk findings are flagged with the rationale and any mitigating controls.
- Diff since audit is tracked separately — any post-audit change that affects audited code is highlighted so you know whether the published report still describes the running system.
Continuous review
In addition to point-in-time engagements, the protocol relies on:- Internal review gates on every kernel, consensus, and bridge change.
- Fuzzing and property-based testing on matching, risk, and settlement state machines.
- Formal specification for the core financial primitives where practical.
- Public bug bounty for ongoing external coverage.
Questions about the audit scope or a specific finding should go to
security@intention.xyz. Security disclosures should follow the process described on the bug bounty page.