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 on-chain state.
PoC required
KYC required
Rewards
Rewards by Threat Level
Reward amount is % of the funds directly affected, capped at the maximum critical reward of:
$20,000,000Mainnet assets:
Reward amount is % of the funds directly affected up to a maximum of:
$10,000,000- Tier 1: Ability to Extract the TVL of all chains: Up to 20,000,000 W
- Tier 2: Ability to Extract the TVL of a single chain: Up to 10,000,000 W
- Tier 3: Ability to permanently deny access to the TVL of one or many chains: Up to 5,000,000 W
All rewards are decided on a case-by-case basis, taking into account the exploitability of the bug, the impact it causes, and the likelihood of the vulnerability presenting itself if it is nondeterministic or some of the conditions are not present at the time. The rewards presented in the payout structure above are the maximum rewards and there are no minimum rewards.
Rewards for critical vulnerabilities are further capped at 10% of extractable value during a 24h period (see Governor mechanism: https://github.com/wormhole-foundation/wormhole/blob/main/whitepapers/0007_governor.md). Rewards for vulnerabilities resulting in the indefinite locking of funds are further capped at 1% of destroyable value. Rewards for critical vulnerabilities relating to NFTs are further capped at 80,000 W.
Value is calculated based on the current market value and available liquidity for widely-used tokens in the Portal Token Bridge, e.g. 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 (eg. if you have the ability to extract and brick a complete TVL for a chain, you will be awarded a bounty as if you were able to 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 itself rather than the Wormhole code, the locked and wrapped assets on that chain are not included in the impact calculation.
Wormhole Foundation will maintain full discretion on the payouts for vulnerabilities. We do 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 -- 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 on-chain state.
For more information about Wormhole, please visit https://wormhole.com/.
This bug bounty program is focused on the prevention of negative impacts to Wormhole and the Portal Token Bridge, which currently covers their smart contracts, guardian nodes, and Wormhole integrations with blockchains.
Submission Requirements All reports must come with sufficient explanation and data to easily reproduce the bug, e.g. through a proof-of-concept code.
For a bug report to be paid, we do require the bug reporter to comply with our KYC requirements.
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)
- 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 and all W to which you are entitled to receive as 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 that has a reward denominated in W you may be entitled to receive the reward in USDC at 25% of the reward value if you are unable to receive the reward in W.
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.
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.