Optimism
Optimism is a blockchain infrastructure provider that enables developers and enterprises to launch scalable, secure and customizable networks and applications. The company serves fintechs, payment providers, institutions and crypto companies creating the next generation of onchain products. Optimism's open-source OP Stack delivers Ethereum-grade security, nearly-free transactions, and the flexibility to meet complex business needs at scale.
Triaged by Immunefi
PoC Required
KYC required
Select the category you'd like to explore
Assets in Scope
Impacts in Scope
Unauthorized access to, modification of, or destruction of production user or tenant data, where a single exploitation affects multiple users or tenants, as distinct from an attack that must be repeated for each additional victim
Taking or modifying authenticated actions on behalf of other users, where the action results in direct theft of funds or execution of an unauthorized onchain transaction
Retrieve sensitive data/files from a running server, such as server configuration, credentials, or source code (excluding production user or tenant data)
Retrieve sensitive data/files from a running server, such as:
- /etc/shadow
- database passwords
- blockchain keys (this does not include non-sensitive environment variables, open source code, or usernames)
Subdomain takeover with already-connected wallet interaction
Direct theft of user funds
Malicious interactions with an already-connected wallet, such as:
- Modifying transaction arguments or parameters
- Substituting contract addresses
- Submitting malicious transactions
Injection of malicious HTML or XSS through metadata
Protocol insolvency, not including proposer/challenger bonds or fee vaults
Loss of user funds by direct theft, not including proposer/challenger bonds or fee vaults
Direct loss of funds, not including proposer/challenger bonds or fee vaults
Permanent freezing of funds, not including proposer/challenger bonds or fee vaults
Out of scope
Chains:
- When assessing impact for a bug, it will be primarily assessed against the impact it has on the following live chains: OP, Ink, Soneium, and Unichain. Each chain is identified by their entries in the superchain-registry (https://github.com/ethereum-optimism/superchain-registry/).
- A feature actively in use on at least one of these chains, or planned to be in use according to a governance proposal, is eligible for the highest tier impacts. A feature not actively in use on these chains will have its impact downgraded by one level.
The following are considered out-of-scope for the bug bounty:
Blockchain / DLT:
- Vulnerabilities requiring the user to have publicly exposed an API, such as JSON-RPC or the Beacon API
- Vulnerabilities requiring the chain operator to violate recommended best practices as described on our docs website, for example around network topology, proxy configuration and so on. See here https://docs.optimism.io/chain-operators/reference/architecture#network-design-example
- The Alt-DA feature of op-node and op-batcher.
- All execution layer clients which have reached end-of-service (e.g. op-geth).
- op-reth depends on several crates sourced from https://github.com/paradigmxyz/reth/. Issues which are responsibly disclosed to the upstream reth team or the Ethereum Foundation Bug Bounty Program (https://bbp-form.ethereum.org/) cannot be "replayed" against Optimism’s bug bounty program if the vulnerability has already been made public. If the vulnerability is disclosed to Optimism at the same time as upstream, the vulnerability is eligible for the bug bounty program.
- All currently known issues with devp2p here: https://github.com/ethereum/devp2p/blob/master/rlpx.md#known-issues-in-the-current-version
- There are scenarios where, if an attacker can predict an L1 reorg, they could exploit it to reorder dispute game transactions in a way that causes the honest challenger to respond incorrectly and therefore lose its bond — although the dispute game itself will still resolve correctly.
Smart Contracts:
- Vulnerabilities in the implementation of ‘custom token bridges’ which are written by third parties for bridging tokens to their network
- Bugs in op-challenger or other off-chain components that result in "Incorrectly resolved dispute game, detected by op-dispute-mon".
- Proof of whale based attacks on Fault Proofs.
- There appears to be an obvious bug which would allow an attacker to withdraw a fake ERC20 token from L2 in exchange for a real ERC20 (such as WBTC) token on L1. There is no check in the L2StandardBridge, however the withdrawal is prevented from finalizing by a check in the L1StandardBridge. Naturally if you do find a way to circumvent our protections, then we would reward you.
- A bug in ResolvedDelegateProxy.sol which could result in a storage slot key collision overwriting the address of the implementation. This bug is dependent on the layout of the implementation contract, and Optimism is not affected.
- There is an edge case in which ETH deposited to the OptimismPortal by a contract can be irrecoverably stranded:
- When a deposit transaction fails to execute, the sender’s account balance is still credited with the mint value. However, if the deposit’s L1 sender is a contract, the tx.origin on L2 will be aliased, and this aliased address will receive the minted on L2. In general the contract on L1 will not be able to recover these funds. We have documented this risk and encourage users to take advantage of our CrossDomainMessenger contracts which provide additional safety measures.
- Sending cross-chain messages with very large amounts of data, or very specific amounts of gas can open up griefing attacks causing the sender’s funds to be stuck and requiring an upgrade to release them.
- Deposit transactions can be griefed at a cost to the attacker, by filling up the MAX_RESOURCE_LIMIT. This issue is mitigated by PR 5064, which does not completely resolve the issue but does increase the cost of a sustained griefing attack. A more complete fix will require architectural changes.
- There are various ‘foot guns’ in the bridge which may arise from misconfiguration of a token. To minimize complexity our bridge design does not try to prevent all forms of developer and user error. Examples of such foot guns include:
- Having both (or neither of) the local and remote tokens be OptimismMintable.
- Tokens which dynamically alter the amount of a token held by an account, such as fee-on-transfer and rebasing tokens.
Web & App:
-
explorer.optimism.io
-
testnet-explorer.optimism.io
-
retrofunding.optimism.io
-
public-grafana.optimism.io
-
discord.optimism.io
-
kyc.optimism.io
-
kyb.optimism.io
-
raas.optimism.io
-
contribute.optimism.io
-
superfest.optimism.io
-
welovetheart.optimism.io
-
support.enterprise.optimism.io
-
login.enterprise.optimism.io, the Auth0-hosted login page for enterprise.optimism.io. The page itself is operated by Auth0 and is out of scope. Optimism's own Auth0 tenant configuration remains in scope, including allowed callback URLs, allowed web origins, connection settings, actions and rules, and any custom login page template, as does any vulnerability that results in unauthorized access to enterprise.optimism.io.
-
Abuse of testnet faucet allocations on console.optimism.io, including bypassing or spoofing drip eligibility criteria. Testnet funds have no market value, so this is not treated as theft of user funds. Genuine authentication flaws in the faucet's identity flow remain in scope at the applicable severity.
-
Additionally, any other asset belonging to Optimism but not under Optimism’s control will also be out of scope.
The following domains, operated by Agora:
- vote.optimism.io
- atlas.optimism.io
Security researchers who discover vulnerabilities on these domains are encouraged to report them directly to Agora at security@voteagora.com. However, if a vulnerability on these domains leads to a direct financial impact on the OP Stack or the Optimism protocol itself, the impact remains in scope under the Primacy of Impact and should be submitted through this bug bounty program.
Blockchain/DLT specific
- Incorrect data supplied by third party oracles
- Not to exclude oracle manipulation/flash loan attacks
- Impacts requiring basic economic and governance attacks (e.g. 51% attack)
- Lack of liquidity impacts
- Impacts from Sybil attacks
- Impacts involving centralization risks
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