
Wormhole
Wormhole is a generic cross-chain messaging protocol that allows smart contracts on various blockchains to communicate with each other. Messages are routed from chain to chain by a decentralised group of guardian nodes who sign attestations of the on-chain state.
PoC required
KYC required
Rewards
Rewards by Threat Level
Please note that for any valid Critical severity reports, the maximum reward will be up to $5,000,000 USD, paid in W token, with the following tiers:
- Tier 1: Ability to Extract the TVL of all chains: Up to $5,000,000 in W
- Tier 2: Ability to Extract the TVL of a single chain: Up to $2,500,000 in W
- Tier 3: Ability to permanently deny access to the TVL of one or many chains: Up to $1,250,000 in W
All rewards are decided on a case-by-case basis, taking into account the bug's exploitability, the feasibility of the exploit scenario, the impact it causes, and the likelihood of the vulnerability presenting itself, particularly if it is nondeterministic or some of the conditions are not present at the time.
Because of the governor, rewards for critical vulnerabilities are further capped at 10% of extractable value during a 24-hour period. The Governor (https://github.com/wormhole-foundation/wormhole/tree/main/node/pkg/governor) is designed to limit the value that can be transferred out of one chain over time. Rewards for vulnerabilities resulting in the perpetual locking of funds are further capped at the lesser of 1% of destroyable value or $1,250,000 in W. Rewards for critical vulnerabilities relating to NFTs are further capped at $20,000 in W.
Value is calculated based on the current market value and available liquidity for widely used tokens in the Portal Token Bridge, such as ETH and SOL.
In cases where the report achieves more than one of the above objectives, rewards will be tiered to the higher of the two objectives and will not be aggregated (e.g., if you can extract and brick a complete TVL for a chain, you will be awarded a bounty as if you could only extract the complete TVL for that chain).
Rewards for bugs in dependencies and third-party code are at the discretion of the Wormhole team and will be based on the impact demonstrated on Wormhole. If the dependency has its own bug bounty program, your reward for submitting this vulnerability to Wormhole will be lowered by the expected payout of that other program. If the vulnerability is in a connected blockchain rather than the Wormhole code, the locked and wrapped assets on that chain are not included in the impact calculation.
Vulnerabilities known to the Wormhole team at the time of reporting are ineligible for reward. This includes external audit reports, vulnerabilities in Wormhole's dependencies that have been disclosed publicly, and internal company communications. If necessary, the program will provide proof of prior knowledge about the issue.
Wormhole Foundation will maintain full discretion on vulnerability payouts. We encourage bug reporters to submit issues outside of the above-mentioned payout structure, though we want to be clear that we’ll exercise discretion on a case-by-case basis regarding whether an issue warrants a payout and what that ultimate payout would be.
Program Overview
Wormhole is a generic cross-chain messaging protocol that allows smart contracts on various blockchains to communicate with each other. Messages are routed from chain to chain by a decentralised group of guardian nodes who sign attestations of the on-chain state.
For more information about Wormhole, please visit https://wormhole.com/.
This bug bounty program is focused on preventing negative impacts on Wormhole and the Portal Token Bridge. It currently covers their smart contracts, guardian nodes, and Wormhole integrations with blockchains.
Submission Requirements
All reports must include sufficient explanation and data to reproduce the bug easily, e.g., through a proof-of-concept code.
We require the bug reporter to comply with our KYC requirements before we pay for a bug report.
This includes the following:
- Wallet address where you’ll receive payment.
- Proof of address (either a redacted bank statement with your address or a recent utility bill with your name, address, and issuer of the bill).
- A copy of your passport will be required.
- W rewards are limited to those persons who are (a) not U.S. Person as defined in Rule 902(k) of Regulation S under the United States Securities Act of 1933, as amended (“Regulation S”) (b) is not domiciled in or has their principal place of business in the United States; (y) will conduct all transactions with the Tokens outside the United States and solely with non-US persons; and (z) is not acquiring the Tokens for the account or benefit of any U.S. Person and will not engage in any directed selling efforts in the United States.
- Any W to which you are entitled to receive as a reward will only be granted and delivered to you upon the execution by you of a Restricted Token Grant Agreement in the form required by Wormhole Foundation and subject to the terms and conditions set forth therein, including a lock-up on the W token as set forth therein.
- You shall be responsible for reporting and paying any current and future taxes that it may incur resulting from the grant or delivery of any W or cash compensation.
- If you report a critical bounty with a reward denominated in W, you may be entitled to receive the reward in USDC if you are unable to receive the reward in W.
These details will only be required upon determining that a bug report will be rewarded. They will remain strictly confidential among need-to-know individuals (basically, only individuals must verify KYC and process the payment).
KYC required
The submission of KYC information is a requirement for payout processing.
Proof of Concept
Proof of concept is always required for all severities.
Responsible Publication
Category 3: Approval Required
Prohibited Activities
- 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
- Attempting phishing or other social engineering attacks against our 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 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
- Any other actions prohibited by the Immunefi Rules
Feasibility Limitations
The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug's severity.
Therefore, Immunefi has developed a set of feasibility limitation standards which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.