Babylon Bug Bounty Program

Babylon introduces a new major utility for Bitcoin: trustless and self-custodial staking. The Babylon Bitcoin staking protocol turns Bitcoin into a stakable and slashable asset for any Proof-of-Stake system. This allows Bitcoin HODLERs to hold their Bitcoins while earning staking rewards from the PoS systems for the slashable security they provide, in the same way as how native PoS token staking works.

Severity and Rewards

Vulnerabilities are classified using two factors: Impact and Conditions. The combination of these factors determines the severity and guides the reward amount.

Severity Levels

Vulnerabilities in the Blockchain/DLT part will be classified according to the following severity levels:

• Critical
  • Direct loss of funds
  • Permanent freezing of user funds
  • Retrieve the private key of a covenant committee member
  • Leakage of EOTS private keys without the holder double-signing
• High
  • Preventing a covenant signer from activating staking requests indefinitely.
  • Causing the Bitcoin light client tracked by Babylon Genesis to diverge from the canonical Bitcoin chain by more than 100 Bitcoin (BTC) blocks under normal network throughput and capacity conditions.
  • Generation of invalid EOTS keys
  • Generation of invalid EOTS key signatures/ Invalid verification of EOTS key signatures
  • Temporary freezing of funds for more than the staking timelock for a staking transaction or more than the unbonding timelock for an unbonding transaction.
  • Avoiding slashing despite malicious behavior
  • Chain halt
  • Permanently halting the Bitcoin Staking finalization of blocks.
  • Babylon node recognizes Bitcoin Staking protocol transactions and/or signatures as valid when they are invalid.
• Medium
  • Preventing honest relayers from submitting Bitcoin headers or Bitcoin checkpoints to the Babylon Genesis chain indefinitely.
  • Inability to process or activate new valid staking registrations under normal network throughput and capacity conditions.
  • Generation of staking transactions that cannot be confirmed by the Bitcoin ledger
  • Temporary denial of service of Babylon Genesis chain, lasting more than 24 hours, achievable at no economic cost to the attacker.
  • Babylon node recognizes Bitcoin Staking protocol transactions and/or signatures as invalid when they are valid.
• Low/Informational
  • Causing temporary, minor or easily recoverable disruptions to normal Babylon Genesis chain operations

Vulnerabilities in the Web & App part will be classified according to the following severity levels:

• Critical
  • Execute arbitrary system commands
  • Retrieve sensitive data/files from a running server, such as: database passwords, blockchain keys, etc. This does not include non-sensitive environment variables, open source code, or usernames etc with no operational impact.
  • Taking state-modifying authenticated actions (with or without blockchain state interaction) on behalf of other users without any interaction by that user, such as: Making trades
  • Subdomain takeover with already-connected wallet interaction
  • Direct theft of user funds or causing their freezing
  • Malicious interactions with an already-connected wallet without user interaction, such as: Modifying transaction arguments or parameters, submitting malicious transactions
• High
  • Taking down the API/website
  • Injecting/modifying the static content on the target application without JavaScript (persistent), such as: HTML injection without JavaScript Replacing existing text with arbitrary text Arbitrary file uploads, etc
  • Subdomain takeover without already-connected wallet interaction
• Medium
  • Changing non-sensitive details of other users (including modifying browser local storage) without already-connected wallet interaction and with up to one click of user interaction, such as their stored pending transactions.
  • Injecting/modifying the static content on the target application without JavaScript (reflected), such as: Reflected HTML injection Loading external site data
  • Redirecting users to malicious websites (open redirect)
  • Circumventing access restrictions on Web without using special tools

Impact Assessment

The severity level of a vulnerability will be determined based on both its impact and conditions:

• Impact Factors
  • Amount of funds at risk
  • Number of users affected
  • Duration of the vulnerability's effect
  • Complexity of exploitation
  • Requirement for privileged access
• Conditional Factors
  • Technical complexity of the exploit
  • Required preconditions for exploitation
  • Opportunity window for exploitation

Reward Structure

Reward Amounts

Rewards will be paid according to the following structure:

Blockchain/DLT:

Severity Level	Reward Range
Critical	20,000 USD - 500,000 USD
High	5,000 USD - 15,000 USD
Medium	1,000 USD - 3,000 USD
Low	flat 1,000 USD

• Reward Calculation for Critical Vulnerabilities
  • For critical vulnerabilities, the reward amount will be calculated as 10% of the funds directly affected, up to a maximum of 500,000 USD. The calculation of the amount of funds at risk will be based on the time and date the bug report is submitted.
  • A minimum reward of 20,000 USD will be awarded for critical vulnerabilities to incentivize security researchers against withholding bug reports.
• Reward Calculation for High Severity Vulnerabilities
  • For high-severity vulnerabilities, rewards will be capped at up to 100% of the funds affected, with a maximum of 15,000 USD. If the vulnerability can be demonstrated to cause temporary freezing (without actually being exploited) as defined in the impacts table, the reward doubles from the full frozen value for every additional 24h that the funds are temporarily frozen, up to a max cap of the High reward. This is because as the duration of the freezing lengthens, the potential for greater damage and subsequent reputational harm intensifies. Thus, by increasing the reward proportionally with the frozen duration, the project ensures stronger incentives for bug disclosure of this nature.
  • A minimum reward of 5,000 USD will be awarded for high-severity vulnerabilities to incentivize security researchers against withholding bug reports.
• Reward Calculation for Medium Severity Vulnerabilities
  • For medium-severity vulnerabilities, rewards will be capped at up to 100% of the funds affected, with a maximum of 3,000 USD.
  • A minimum reward of 1,000 USD will be awarded for medium-severity vulnerabilities to incentivize security researchers against withholding bug reports.

Web & App:

Severity Level	Reward Range
Critical	10,000 USD - 70,000 USD
High	up to 7,500 USD
Medium	flat 3,000 USD

For critical web/apps bug reports, rewards will be awarded with USD 70 000, only if the impact leads to:

• A loss of funds involving an attack that does not require any user action
• Users' funds being permanently inaccessible involving an attack that does not require any user action
• Unauthorised access to user funds due to a cryptographic or key management vulnerability

All other impacts that would be classified as Critical would be rewarded with a minimum of USD 10 000.

The rest of the severity levels are paid out according to the Web & App reward table above.

Reward Payment Terms

Payouts are handled by the Babylon Labs team directly and are denominated in USD. However, payments are done in USDC on Ethereum, BABY on Babylon Genesis or a mix as determined by Babylon Labs in its sole discretion. If payment or part of the payment is in BABY tokens the conversion price for the purposes of calculation shall be determined based on the arithmetic average of the daily closing prices of the BABY token over the immediately preceding fourteen (14) calendar days before the date of payment. The daily closing price for each day during the calculation period shall be obtained from the publicly available data published on Coingecko (https://www.coingecko.com/en/coins/babylon/historical_data). Babylon Labs shall perform the calculation in its sole but reasonable discretion.

General Notes

• Sherlock's Criteria for Issue Validity guide can be a helpful resource for more context on out-of-scope issues, etc., but nothing in the guide should overrule the definitions above
• A coded Proof of Concept (POC) with instructions to run the POC is required
• If the protocol team has the ability to take measures (upgrade the contract, pause the contract, etc.) against an exploit, the potential damage is limited to a 1-hour exploit period before it is assumed that the protocol team takes measures to prevent further damage

Platform Rules

Please review the Sherlock Bug Bounty Platform Rules before submitting any vulnerability.

Out of scope

Specific to Blockchain/DLT:

• Impacts involving centralization risks
• Impacts involving Bitcoin not being live or safe.
• Impacts involving the Babylon validator set not being live or safe.
• Impacts involving the temporary downtime of relayers between Babylon and Bitcoin.
• Impacts involving the submission of a large number of transactions to the Bitcoin ledger and their delayed inclusion.
• Impacts involving >=⅓ malicious finality voting power.
• Impacts involving >= ⅓ malicious CometBFT voting power.
• Impacts involving a quorum of the covenant committee being malicious.
• Impacts preventing a quorum of the covenant committee to be reached due to a full quorum not being live.
• Impacts involving the confirmation depth and finalization timeout parameters being set to an improperly low value.
• Impacts involving a user’s staking transaction being included in a Bitcoin block in which different Bitcoin staking parameters than the ones the user used apply.

Specific to Web & App:

• Theoretical impacts without any proof or demonstration
• Impacts involving attacks requiring physical access to the victim device
• Impacts involving attacks requiring access to the local network of the victim
• Reflected plain text injection (e.g. url parameters, path, etc.)
  • This does not exclude reflected HTML injection with or without JavaScript
  • This does not exclude persistent plain text injection
• Any impacts involving self-XSS
• Captcha bypass using OCR without impact demonstration
• CSRF with no state modifying security impact (e.g. logout CSRF)
• Impacts related to missing HTTP Security Headers (such as X-FRAME-OPTIONS) or cookie security flags (such as “httponly”) without demonstration of impact
• Server-side non-confidential information disclosure, such as IPs, server names, and most stack traces
• Impacts causing only the enumeration or confirmation of the existence of users or tenants
• Impacts caused by vulnerabilities requiring un-prompted, in-app user actions that are not part of the normal app workflows
• Lack of SSL/TLS best practices
• Impacts that only require DDoS
• UX and UI impacts that do not materially disrupt use of the platform
• Impacts primarily caused by browser/plugin defects
• Leakage of non sensitive API keys (e.g. Etherscan, Infura, Alchemy, etc.)
• Any vulnerability exploit requiring browser bugs for exploitation (e.g. CSP bypass)
• SPF/DMARC misconfigured records
• Missing HTTP Headers without demonstrated impact
• Automated scanner reports without demonstrated impact
• UI/UX best practice recommendations
• Non-future-proof NFT rendering

All categories

• Impacts requiring attacks that the reporter has already exploited themselves, leading to damage

• Impacts caused by attacks requiring access to leaked keys/credentials

• Impacts caused by attacks requiring access to privileged addresses (including, but not limited to: governance and strategist contracts) without additional modifications to the privileges attributed

• Impacts relying on attacks involving the depegging of an external stablecoin where the attacker does not directly cause the depegging due to a bug in code

• Mentions of secrets, access tokens, API keys, private keys, etc. in Github will be considered out of scope without proof that they are in-use in production

• Best practice recommendations

• Feature requests

• Impacts on test files and configuration files unless stated otherwise in the bug bounty program

• Impacts requiring phishing or other social engineering attacks against project's employees and/or customers

Disclosure Policy

All vulnerabilities must be reported exclusively through the Sherlock platform and must not be disclosed publicly until:

1. The vulnerability has been verified by the protocol team
2. A fix has been implemented and deployed
3. The protocol team has granted explicit permission for public disclosure
   Premature public disclosure can result in disqualification from the reward.

Testing

When testing for vulnerabilities:

• Do not test on public mainnet deployments
• Use local test environments or local forks for all testing
• Do not attempt to access or modify other users' data
• Do not perform any actions that could disrupt the normal operation of the protocol
• Do not use automated scanning tools without manual verification

Prohibited actions

The following actions are strictly prohibited:

• Attempting to access private user data
• Social engineering or phishing attacks
• Physical or electronic attempts to access protocol's infrastructure
• Any testing that violates applicable laws or regulations
• Threatening or harassing behavior
• Any testing on mainnet or public testnet deployed code; all testing should be done on local-forks of either public testnet or mainnet
• Any testing with pricing oracles or third-party smart contracts
• Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
• Any denial of service attacks that are executed against project assets
• Automated testing of services that generates significant amounts of traffic
• Public disclosure of an unpatched vulnerability in an embargoed bounty

Additional terms

As a condition of your participation in Babylon Labs Bug Bounty Programs, including the submission of bug reports, you agree to be bound by the following terms and conditions in addition to any other terms and conditions that govern your participation. If you do not agree to these terms and conditions, you should not submit any bug report.

1. Babylon Labs will determine the severity level and impact for each submission, whether any submission is within scope and eligible for a reward, and the amount of a reward within a stated range, in its reasonable discretion.

2. Babylon Labs is not liable or responsible for any costs, fees, or expenses incurred by you in connection with this Bug Bounty Program. You acknowledge and agree that you shall be solely and exclusively responsible for the payment of any and all taxes, levies, duties, or similar governmental charges (collectively, "Taxes") that may arise in connection with any reward payments made to you. However, Babylon Labs may be required by applicable law to withhold or deduct any Taxes from payments.

3. Babylon Labs is an express third-party beneficiary of the Security Researchers Terms & Conditions between you and Sherlock, and entitled to enforce the terms and conditions therein as if it were an original contracting party. Babylon Labs is the party designated to be the transferee of intellectual property rights.

4. Babylon Labs, its affiliates and licensors, and their respective directors, officers, and employees (collectively, “Babylon Parties”) will have no liability arising from or relating to your use of, or conduct in connection with this Bug Bounty Program or the sherlock platform, other than Babylon Labs’ potential obligations to pay you a reward. To the fullest extent permitted by applicable law, under no circumstances will any Babylon Parties be responsible or liable under any theory of liability, whether based in tort, contract, negligence, strict liability, warranty, or otherwise: (a) for any direct, indirect, exemplary, special, punitive, incidental, or consequential losses or damages of any kind, including without limitation, loss of profits arising from or relating to the bug bounty program or your use of the Sherlock platform. The foregoing limitations apply even if Babylon Parties were advised of or should have known of the possibility of such losses or damages and notwithstanding any failure of essential purpose of any limited remedy. The foregoing limitations will apply even if the above stated remedy fails of its essential purpose. Some jurisdictions do not allow the limitation or exclusion of certain liabilities, and damages. Accordingly, some of the disclaimers and limitations set forth in this Agreement may not apply in full to you, but will apply to the fullest extent as permitted by applicable law.

Protocol Resources

• Website
• Previous Audits
• Babylon Docs