Wormhole-logo

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.

Algorand
Aptos
Arbitrum
Aurora
Avalanche
BSC
Base
Celestia
Celo
Dymension
ETH
Evmos
Fantom
Gnosis
Injective
Klaytn
Kujira
Mantle
Moonbeam
Near
Maximum Bounty
$5,000,000
Live Since
11 February 2022
Last Updated
08 April 2024
  • PoC required

  • KYC required

Rewards by Threat Level

Blockchain/DLT
Critical
Up to 20,000,000 W
High
Up to $100,000 USDC
Medium
Up to $10,000 USDC
Low
Up to $2,000 USDC
Smart Contract
Critical
Up to 10,000,000 W
High
Up to $100,000 USDC
Medium
Up to $10,000 USDC
Low
Up to $2,000 USDC
  • 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.

KYC required

The submission of KYC information is a requirement for payout processing.

Prohibited Activities

Default 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.