Bron never holds or controls user private keys, funds, or assets. All transactions are user-initiated and executed directly with third-party smart-contract protocols. Swap and staking functions are performed via independent third-party APIs. Bron only provides technical access and does not pool, intermediate, or custody user assets.
Reward Assessment
Smart contract vulnerabilities are assessed individually as CVSS scoring is not directly applicable to blockchain smart contracts. Our security team evaluates the impact based on:
- Potential fund loss or theft
- Contract functionality disruption (DoS, freezing)
- Exploitation feasibility and complexity
- Business impact and affected user base
Reward amounts follow similar ranges based on severity assessment:
Every accepted bounty submission entitles the researcher to a non-transferable Bron NFT in addition to the monetary reward listed below. The NFT grants a complimentary Basic tier subscription for 2026 (or an upgrade to the next tier if Basic is already active, capped at Enterprise). To receive any reward, a Bron wallet is required — bounty payments are distributed in stablecoins to the researcher's Bron wallet address.
| Severity Level | Impact Description | Reward Range (USD) |
|---|---|---|
| Low | Minor issues with no direct impact on funds or functionality | $50 — $250 |
| Medium | Issues affecting contract behavior but not leading to direct fund loss | $250 — $2,500 |
| High | Issues that could lead to limited fund loss or significant disruption | $2,500 — $5,000 |
| Critical | Issues leading to significant fund theft, loss, or contract compromise | $5,000 — $12,500 |
| Exceptional | Complete contract compromise or mass fund drainage | more than $12,500 |
The final reward is determined by our security committee based on the demonstrated impact, exploit complexity, and the quality of the report. High-quality reports with detailed impact analysis and working PoC may receive increased rewards.
All bounty payments are made in USD-denominated stablecoins to the researcher's Bron wallet address and are subject to sanctions screening and anti-money-laundering controls consistent with Bron's compliance policy. Rewards cannot be paid to individuals or entities on applicable sanctions lists.
Smart Contracts in Scope
The Bug Bounty program covers the following on-chain components deployed by Bron on Ethereum Mainnet, Optimism, and associated public test networks (Sepolia, Holesky). Testing must not involve contracts or systems operated by third parties.
Descriptions below are provided solely to define the testing scope. They do not constitute marketing of financial products or an offer of investment in any token or protocol.
1. Bron Token and Cross-Chain Bridge
Smart-contract set implementing the BRON utility token and cross-network transfer mechanism. Includes contracts enabling token issuance, locking, and authorized cross-chain messaging via LayerZero. Fee-handling components manage on-chain collection and allocation between networks under multi-signature governance. All operations are non-custodial and executed by user transactions.
Networks: Ethereum (primary), Optimism (secondary).
2. Intent Protocol Contracts
Smart-contract framework supporting intent-based transaction requests and decentralized quote matching. Core modules handle order registration, solver participation, and oracle-based verification of completed transactions. Contracts do not provide custody or execute trades on behalf of users; they process on-chain data signed by participants.
Networks: Ethereum, Optimism.
3. Loyalty and Rewards Contracts
On-chain reward logic enabling users to record token-locking commitments and receive protocol-defined allocations from designated fee pools. All reward calculations and distributions occur automatically by smart contract according to transparent parameters. Bron does not hold participant assets, manage funds, or guarantee returns.
Networks: Ethereum, Optimism.
Impacts in Scope
The following impact scenarios are considered critical vulnerabilities and are within the scope of our Bug Bounty program:
Critical
- Exploits resulting in the permanent locking or theft of user funds
- Permanent DoS attacks (excluding volumetric attacks)
- Total supply manipulation across chains
- Unauthorized upgrades or access control bypass
High
- Any governance voting result manipulation
- Solver or oracle collateral theft
- Reward distribution calculation errors leading to fund loss
- Cross-chain bridge exploits (mint/burn manipulation)
Medium
- Griefing attacks (no profit motive for attacker, but damage to users or protocol)
- Liquidation mechanism exploits
- Fee calculation or collection vulnerabilities
- Unbonding period gaming
Low
- All above impacts for OApp, OFT & ONFT related contracts
- Precision loss in reward calculations (within acceptable bounds)
- Gas optimization issues without security impact
Prohibited Activities
The following activities are strictly prohibited when testing smart contracts:
- Mainnet/Testnet testing: All testing must be done on local forks of mainnet or testnet. Any testing on production deployed code is forbidden
- Pricing oracle manipulation: Testing with pricing oracles or third-party smart contracts is prohibited
- Social engineering: Phishing or social engineering attacks against our employees and/or customers
- Third-party systems testing: Testing with third-party systems and applications (e.g., browser extensions, SSO providers, advertising networks)
- Denial of Service attacks: Any DoS attacks executed against project assets
- High-volume automated testing: Automated testing of services that generates significant amounts of traffic
- Public disclosure: Public disclosure of an unpatched vulnerability during embargo period
Required: Use local forks (Hardhat, Foundry, Ganache) of mainnet/testnet for all testing. We recommend using mainnet forks with recent block snapshots to ensure realistic testing conditions.
Feasibility Limitations
Bug reports must demonstrate realistic attack scenarios. The following limitations apply when assessing vulnerability feasibility and severity:
Accepted Attack Scenarios
- Vulnerabilities must demonstrate actual funds or assets that can be compromised
- Exploitation must be feasible under current network conditions and contract states
- Attack must show clear negative consequences for users or protocol
Not Accepted as Severity Justification
- Assumptions that blockchain will rollback to prevent exploit are not valid
- Assumptions that team will detect and prevent attack before execution
- Attacks requiring unrealistic capital investment (e.g., >$100M to exploit $10K) will be downgraded
- If the attacker must risk significant funds with high probability of loss, this may downgrade severity
- Attacks with no profit motive and minimal user impact may be classified as griefing (Medium/Low severity)
Example 1: An attack requiring $100M capital to steal $100K would be downgraded from Critical to Low due to unrealistic economics.
Example 2: An attack that temporarily inconveniences users but causes no fund loss and has no profit motive would be classified as Griefing (Medium) rather than High severity.
Out of Scope — Smart Contract Specific
The following types of issues are not considered exploitable vulnerabilities in Bron's smart contracts:
Third-Party Oracle Data Issues
- Incorrect data supplied by third-party oracles — Data errors from external oracle services are not related to Bron contract code and are not considered a vulnerability
- Note: Oracle manipulation and flash-loan attacks are NOT excluded from the program scope if they exploit vulnerabilities in contract logic that enable such attacks
Economic and Governance-Level Attacks
- Impacts requiring economic or governance-level attacks (e.g., 51% attack, lack of liquidity) — Such issues depend on market conditions or network control and are not considered exploitable vulnerabilities. A 51% attack involves an attacker controlling over 50% of a blockchain network's computing power to manipulate transactions, which is a network-level issue, not a contract defect
- Lack of liquidity — Low pool liquidity or market volatility is a business risk, not a technical vulnerability
Protocol-Level Design Issues
- Sybil attacks — Manipulation through multiple fake identities or nodes is considered a protocol-level or economic design issue (e.g., absence of staking requirements, quorum, or KYC), not a smart contract vulnerability. Such attacks are nearly impossible to reproduce in a test environment
- Centralization risks — Impacts involving trust in administrators, multisig wallets, or owner privileges are accepted design choices, not vulnerabilities. These are operational security measures, not contract defects