Merlin Chain Bug Bounty Program

Merlin is a Bitcoin Layer 2 that integrates ZK-Rollup network, decentralized oracle network, and on-chain BTC fraud proof modules. Merlin Chain is committed to empowering Bitcoin's native assets, protocols, and products on Layer 1 through its Layer 2 network, to Make Bitcoin Fun Again.

Rewards

Critical vulnerabilities are further capped at 10% of economic damage, with the main consideration being the funds affected in addition to PR and brand considerations, at the discretion of the team. However, there is a minimum of USD 75,000 for Critical bug reports.

Rewards will be provided according to the rules of this bug bounty program as outlined above. At the discretion of Merlin, quality, creativity, or novelty of submissions may modify payouts within a given range. In case of multiple reports about the same issue, Merlin will reward the earliest submission, regardless of how the issue was reported.

Known Issues (Out of Scope)

The following known issues are considered to be out of scope of this bug bounty program:

Smart Contracts:

• The management permission and upgrade permission in the contract are multi-sign account management, ensuring that it is a multi-person approval operation.
• Bridge contract mint permission is an mpc account co-managed with a third party Cobo, which also ensures mint functions processing by multiple parties.
• Because the NFT receiving address of merlin-chain is an AA address, the mint function is used for NFT receiving.
• Enter the btc address for Layer 2 currency withdrawal. Ensure that the address is correct.

Scope

In Scope Assets

Impact in Scope & Rewards

Blockchain/DLT

Web (*.merlinchain.io)

Smart Contracts

Out of Scope & Exclusions

The following vulnerabilities are excluded from the rewards for this bug bounty program:

• Attacks that the reporter has already exploited themselves, leading to damage
• Attacks requiring access to leaked keys/credentials
• Attacks requiring access to privileged addresses (governance, strategist)

Smart Contracts and Blockchain

• Incorrect data supplied by third party oracles (Note: oracle manipulation/flash loan attacks are NOT excluded)
• Basic economic governance attacks (e.g. 51% attack)
• Vulnerabilities in the implementation of 'custom token bridges' which are written by third parties for bridging tokens to their network
• Lack of liquidity
• Best practice critiques
• Sybil attacks
• Centralization risks

Third Party References

Since Merlin uses a fork of Polygon CDK, any questions about Polygon CDK should be directed to Polygon: https://github.com/0xPolygon/cdk-validium-node?tab=security-ov-file

Prohibited Activities

The following activities are prohibited by this bug bounty program:

• Any testing with mainnet or public testnet contracts; all testing should be done on private testnets
• Any testing with pricing oracles or third party smart contracts
• Attempting phishing or other social engineering attacks against employees and/or customers
• 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
• Automated testing of services that generates significant amounts of traffic
• Public disclosure of an unpatched vulnerability in an embargoed bounty

Reporting Rules

• For Web vulnerabilities, the Merlin Team reserves the final right of interpretation regarding the final determination.
• Rewards or recognition require that the Merlin security team can reproduce and verify an issue and that the security impact is clear.
• Reproduction steps need to be clear, and may include screenshots, videos, scripts, etc.
• Do not conduct social engineering and phishing attacks against people.
• Do not leak the details of the vulnerability.
• Do not use a scanner for large-scale scanning. If the business system or network becomes unavailable, it will be handled according to relevant laws.
• Those who test the vulnerability should try to avoid modifying the page directly, continuously popping up message boxes (log is recommended for XSS verification), stealing Cookies, and obtaining aggressive payloads such as user information (for blind XSS testing, please use DNSLog). If you accidentally used a more aggressive payload, please delete it in time.
• Vulnerability testing is only limited to PoC (proof of concept), and destructive testing is strictly prohibited. If harms are caused inadvertently during testing, they should be reported in time. Sensitive operations performed in tests, such as deletion and modification, are required to be explained in the report.