---
title: "Audits"
description: "Assurance model, audit methodology, published reports, bug bounty and responsible disclosure."
audience: both
type: reference
status: live
lang: en
updated: "2026-09-17"
publish: true
aliases: [3-7-bug-bounty]
---
# Audits

How the contracts are reviewed and how to report what the review missed: internal and external audits, humans and AI, perpetual auditing, and the disclosure channel.

## 1. Assurance model

Third-party audits are pending. Reports will be linked here when they land; there is no placeholder page in the meantime.

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

- Independent reviewers work the same scope in parallel, then argue their findings to convergence, rather than one pass signing off.
- Rounds are economic-risk first: undercoverage and contagion before oracle, governance and code.
- A scope closes only after two consecutive rounds return nothing.
- A closed scope re-opens whenever a new heuristic or a new class of reviewer arrives, so nothing is clean by seniority.

An internal programme is not an independent opinion. Until third-party reports are published, treat the contracts as experimental: the assurance behind them is that programme, the test suite and the invariant proofs described in the [Security overview](/docs/3-overview) ([Risk Disclaimer](/docs/risk-disclaimer)).

## 2. Public methodology

The public audit methodology repository is [https://github.com/btr-protocol/audits](https://github.com/btr-protocol/audits).

## 3. Reports

| Report | Scope |
|---|---|
| [Internal Audit 2026-09](/docs/3-4-1-internal-audit-2026-09) | Public subset of the September 2026 pre-launch internal round, with the findings it closed and the positions it accepted |

## 4. Bug bounty and responsible disclosure

### 4.1. Scope

#### 4.1.1. In scope

- BTR smart contracts at the canonical addresses in [Contract Addresses](/docs/2-1-contract-addresses):
  - Pool / PoolFactory (the beacon) / Pool implementation
  - Admin, Flash (UUPS singletons behind ERC-1967 proxies)
  - ExternalOracle
  - AccessControl
  - LPToken (per-leg ERC-20 receipt clone; the pool's sole share ledger for that leg)
  - Yield hooks (`YieldHook` and its venue adapters)
- Pre-launch, testnet deployments are in scope for triage; rewards are discretionary until mainnet.
- 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 (see [§1](#1-assurance-model)).
- 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

Third-party audit is pending and the protocol is not yet on mainnet ([§1](#1-assurance-model)), so this is an indicative pre-mainnet schedule, not a funded commitment. Sizing follows severity, exploitability and user impact; final classification rests with BTR security.

| Severity | Description                                                                 | Reward range (indicative)             |
|---|---|---|
| Critical | Direct, unauthorized loss of user or protocol funds; permanent freeze       | Up to USD 250,000                     |
| High     | Significant fund loss requiring non-trivial preconditions; long freeze      | USD 25,000 - 100,000                  |
| Medium   | Limited fund loss; governance bypass; oracle / accounting deviation         | USD 5,000 - 25,000                    |
| Low      | Griefing; minor accounting drift; DoS without fund loss                     | USD 500 - 5,000                       |

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](#44-responsible-disclosure-process).

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, which today is a pre-mainnet one. The schedule above is what the work is worth
to us; what lands in your wallet is what the treasury can cover at the time. Publishing a headline
figure we cannot honour would be worth nothing to whoever earned it.

That does not change what to do with a finding. Bring an exploitable bug to us whatever you think the
balance is. Reporting starts the safe harbour in [§4.3](#43-safe-harbor) and commits you to nothing: we
say what we can do before you decide. There is room on timing, structure, scope, and on a public
credit or a private resolution. If the treasury cannot meet what a finding is worth, tell us what
would work.

An exploit is not a payout. It is an illiquid position in a traceable asset, with every analytics
firm on it and a permanent record attached to whoever moves it. If you already have more than you
meant to, come to us first: the range of outcomes is wider before than after.
`security@btr.markets` is answered by engineers, not a ticket queue, and the response times in
[§4.5](#45-sla) 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](/docs/terms-of-service#3-eligibility-and-restricted-access))
- 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](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;
- the researcher's preferred payout destination and contact details.

### 4.5. SLA

| Stage                              | Target                              |
|---|---|
| Initial acknowledgement            | 2 business days                     |
| Triage and severity classification | 5 business days                     |
| Remediation plan                   | 10 business days for Critical/High  |
| Bounty decision                    | 30 business days post-remediation   |

### 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](#1-assurance-model).