Audits

How the contracts are reviewed and how to report a vulnerability: internal audits, human and AI reviewers, perpetual auditing, and the disclosure channel.

1. Assurance model

Assurance today is the internal audit programme below, with its methodology public in the audits repository. Third-party reports are linked here as they land; there is no placeholder page in the meantime. Third-party review is scoped to the launch-code heads the internal campaigns closed on.

Scope is split by what a reader can verify. On-chain contracts (verified source) and the oracle and keeper behaviour observable on chain are public, with the method, the severity doctrine and the finding template. The off-chain price source, its signing and keeper internals and the infrastructure are reviewed under a private scope; their findings are published at summary level once fixed and deployed. An end-to-end review programme started on 2026-10-19: the chain of trust from the price source through signing, keepers, the on-chain oracle, pool pricing and pool contracts to governance. A reviewed build counts only if the deployed bytecode or image matches the audited commit.

Internal auditing started pre-launch and continues, run as perpetual auditing:

• Independent reviewers work the same scope in parallel, then reconcile their findings to convergence.
• Rounds are economic-risk first: undercoverage and contagion before oracle, governance and code.
• A campaign closes only after six successive cohorts return nothing, alternating three that read the whole system and three that read a fixed scope, all after the last fix, with every reviewer’s target set enumerated and marked.
• A closed scope re-opens whenever a new heuristic or a new class of reviewer arrives.

As of 2026-09-27, the date of the public report, the launch code had been through six campaigns and a dedicated pass on the cooperative-arbitrage stack (2026-09-26 to 09-27). The six campaigns used 492 finders and filed 111 rows, 121 findings counting 10 aliases merged in campaign D: 18 Medium, 82 Low, 21 Informational, no High or Critical. The cooperative-arbitrage pass filed 16 more (1 Medium, 13 Low, 2 Informational). Two campaigns reached the stop rule on 2026-09-27: D on the launch code, and F, a delta over the last pre-launch changes, after 38 cohorts. The first campaign’s clean streak was voided: its finders were too shallow to call a cohort clean, and its fixes were audited again. Across the whole programme, 946 findings had been filed; 555 are real at the launch code, 440 root causes after merging (Internal Audit 2026-09).

The public report is as of 2026-09-27. Findings filed against later code, including the end-to-end review that started on 2026-10-19, are published under the disclosure policy once fixed and deployed, and are not in these counts. Methodology v1.2 (2026-10-19) governs the programme from that date.

An internal programme is not an independent opinion. Until third-party reports are published, the assurance behind the contracts is that programme, the test suite and the invariant proofs described in the Security overview (Risk Disclaimer).

2. Public methodology

The public audit methodology repository is https://github.com/btr-protocol/audits: the methodology (v1.2, 2026-10-19) and the finding template.

3. Reports

The report is published from the audits repository and mirrored here: the markdown at github.com/btr-protocol/audits is the source of truth; the docs page mirrors it with a status note as of 2026-09-27.

4. Bug bounty and responsible disclosure

4.1. Scope

4.1.1. In scope

• BTR smart contracts at the canonical addresses in Contract Addresses:
  • PoolProxy / PoolFactory / Pool implementation
  • The mark store (MarkStoreP8), run by the Pool implementation
  • Admin, Flash (UUPS singletons behind ERC-1967 proxies)
  • CoopArb
  • AccessControl
  • LPToken (per-leg ERC-20 receipt clone; the pool’s sole share ledger for that leg)
  • Router (the multi-hop execution singleton)
  • The deployed linked libraries (PricingLib, PoolConfigLib, PoolLiquidityLib, NUQuarticLib, AdminParamsLib), which run in their caller’s storage
  • Yield hooks: YieldHook and its AaveV3YieldHook, CompoundV2YieldHook, ERC4626YieldHook and MorphoBlueYieldHook adapters
• Testnet deployments are in scope for triage; rewards there are discretionary.
• BTR keeper bots and operator infrastructure (including the oracle mark-pushing keeper) to the extent that a vulnerability leads to direct user loss or protocol compromise.
• BTR front-end to the extent that a vulnerability leads to user-fund loss, transaction tampering, or credential theft.

4.1.2. Out of scope

• Third-party smart contracts that BTR integrates with (e.g. yield venues a YieldHook adapter deploys into).
• Incumbent benchmark venues (Curve / UniV2 / UniV4) used for comparison: not BTR protocol.
• Forks of BTR contracts deployed by third parties.
• Theoretical attacks without a demonstrable path on deployed or production-bound code.
• Issues already publicly disclosed or known to BTR, including every finding and every accepted position in the published reports.
• Accepted risk positions stated in the docs: a parameter the protocol leaves untimelocked, or a trust assumption named in Security, is a design decision, not a bounty submission.
• Automated scanner output with no exploit path, and load or denial-of-service testing against public RPCs, explorers or third-party infrastructure.
• Social engineering, phishing or physical attacks against BTR contributors.
• UI bugs that do not lead to fund loss or transaction tampering.
• Best-practice or styling concerns absent a security impact.
• Vulnerabilities requiring physical access to a user’s device or privileged compromise of a user’s wallet.

4.2. Reward tiers

This is an indicative schedule, not a funded commitment: payouts depend on the treasury (§4.2.1). Sizing follows severity, exploitability and user impact; final classification rests with BTR security.

Rewards are paid in stablecoin or BTR-treasury-approved assets at BTR’s discretion, and are conditional on the report meeting the requirements in §4.4.

If BTR lists this program on a third-party platform (e.g., Immunefi), the platform-published schedule controls and supersedes the ranges above.

4.2.1. What the ranges are bounded by

The protocol treasury. The schedule above is the target; the payout is what the treasury can cover at the time.

Report an exploitable bug regardless of the treasury balance. Reporting starts the safe harbour in §4.3 and commits you to nothing: we state what we can pay before you decide. Timing, structure, scope, and public credit or private resolution are negotiable. If the treasury cannot meet what a finding is worth, propose terms.

Exploited funds are traceable on chain and hard to liquidate. If you have already extracted funds, contact us before moving them. security@btr.markets is read by engineers, and the response times in §4.5 are commitments.

4.3. Safe harbor

To the maximum extent permitted by applicable law, BTR Foundation grants safe-harbor to good-faith security researchers conducting research within the scope of this Bug Bounty. Specifically:

• United States - Computer Fraud and Abuse Act (CFAA, 18 U.S.C. § 1030): No civil action will be brought against in-scope, good-faith research.
• United States - DMCA § 1201: Reverse-engineering of BTR smart contracts and front-end JavaScript for security-research purposes is authorized.
• United Kingdom - Computer Misuse Act 1990: No civil action will be brought against in-scope, good-faith research, and BTR will not report such research to a prosecuting authority.
• European Union - NIS2 Directive (2022/2555): Security research conducted under this policy qualifies as “coordinated vulnerability disclosure” for NIS2 purposes.
• European Union - Cyber Resilience Act: Reporting conducted under this policy meets responsible-disclosure standards.

Safe harbor is conditional on the researcher:

• making a good-faith effort to avoid privacy violations, service degradation, or destruction of data;
• not exploiting the vulnerability beyond what is necessary to demonstrate impact;
• not extracting more value than the minimum required to prove the bug;
• withholding public disclosure until BTR has remediated the issue or 90 days have elapsed, whichever is earlier (extendable by mutual agreement; researcher and BTR co-publish post-remediation);
• complying with all applicable laws.

We adopt the Immunefi v2.3 disclosure template for non-listed researchers; Immunefi-listed researchers follow Immunefi’s standard procedures.

4.3.1. Exclusions from safe harbor

Safe harbor does NOT extend to:

• Researchers resident in sanctioned jurisdictions (see ToS §3)
• Researchers extorting BTR or third parties under threat of disclosure
• Public disclosure prior to remediation, outside the 90-day window above
• Activity exceeding the minimum necessary for proof-of-concept
• Testing of third-party systems, which BTR cannot authorize, and any out-of-scope asset

4.4. Responsible disclosure process

Submit reports to security@btr.markets encrypted with the BTR security PGP key (fingerprint published at https://btr.markets/.well-known/security.txt when available; otherwise request the key at the same address).

Reports should include:

• a clear technical description of the vulnerability;
• step-by-step reproduction (preferably with a forking-test or Foundry PoC);
• a proposed severity assessment against the table in §4.2;
• the affected chain and address, since the same code runs at different addresses per chain;
• the researcher’s preferred payout destination and contact details.

Do not open an issue, a pull request or a public post before the window in §4.3 closes: a public report forfeits safe harbour.

4.5. SLA

4.6. Duplicates and attribution

The first researcher to report a previously-unknown vulnerability with sufficient detail to reproduce is eligible for the bounty. Duplicate reports may receive partial credit at BTR’s discretion. With consent, BTR will publicly credit researchers under §1.