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 (Risk Disclaimer).

2. Public methodology

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

3. Reports

4. Bug bounty and responsible disclosure

4.1. Scope

4.1.1. In scope

• BTR smart contracts at the canonical addresses in 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).
• 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), 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.

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, 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 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 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;
• the researcher’s preferred payout destination and contact details.

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.