Bug Bounty

1. Scope

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.

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 Audit Status).
• 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.

2. Reward tiers

The protocol is pending third-party audit and is not yet on mainnet (Audit Status), so the table below is an indicative pre-mainnet schedule, not a funded commitment. Reward sizing follows severity, exploitability and impact on users; 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.

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

2.1. What the ranges are bounded by

They are bounded by the protocol treasury, and we would rather say so than publish a number we cannot honour. A headline figure a project cannot actually pay is worth nothing to the person who earned it, and every researcher who has been through that once can tell the difference. So: the schedule above is what the work is worth to us, and what lands in your wallet is what the treasury can cover at the time, which today is a pre-mainnet treasury and will not always be.

None of that changes what to do if you find something. If you are holding a finding that leads to an exploit, bring it to us regardless of what you think the balance is. We will tell you what we can do before you decide anything, and we would rather negotiate a number with you than read about it on chain. That conversation has no downside for you: reporting starts the safe harbour in §3, and nothing about opening it commits you to accepting what is offered.

We are aware of the arithmetic that competes with this. 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. What we are offering instead is a counterparty who wants to pay you, will say honestly what it can raise, and can find room: timing, structure, scope, a public credit if you want one, a private resolution if you do not. If the treasury genuinely cannot meet what a finding is worth, tell us what would work; more of those conversations end well than people expect.

If you already have more than you meant to, that is still a conversation and not a verdict. Come to us first and the range of outcomes is wide. Come to us after and it narrows for everyone, including you. security@btr.markets is monitored, answered by engineers rather than a ticket queue, and the response times in §5 are ours to keep, not aspirations.

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.

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. 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.

5. SLA

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 Audit Status.