Base Chain is a fast, low-cost, decentralized network that delivers sub-second, sub-cent global transactions. It is the foundation for a new economy where anyone, anywhere can participate.
Live
Runnable PoC Required
KYC required
Select the category you'd like to explore
Assets in Scope
Impacts in Scope
Proof of Concept (PoC) Requirements
Proof of Concept (PoC) Requirements A runnable PoC, demonstrating the bug's impact, is required for this program and has to comply with the Immunefi PoC Guidelines and Rules.
Optional Project Info
Where might Security Researchers confuse out-of-scope code to be in-scope?
Given our previous status as an OP Stack chain, participants may confuse OP Stack components (op-node, op-geth, op-batcher) as in scope. Only Base-native code in the Assets in Scope section (EL, CL, Batcher, TEE/ZK components, etc.) is in scope. Additionally, any Optimism audit reports (listed in this competition) represent out-of-scope code. The ZK prover and its associated circuits are also out of scope. The core Op-Succinct program is out-of-scope, but changes we have made to it are in-scope.
For base/base, following folders are considered to be out-of-scope:
- https://github.com/base/base/tree/main/actions
- https://github.com/base/base/tree/main/devnet
- https://github.com/base/base/tree/main/baseup
- https://github.com/base/base/tree/main/etc
Is this an upgrade of an existing system? If so, which? And what are the main differences?
Yes. Base Azul is Base's first independent upgrade after transitioning from the OP Stack. Main differences:
- Client consolidation – migrating from op-geth/op-node to base-reth-node (EL) and base-consensus (CL);
- Proof system migration – replacing Optimistic fault proofs (Cannon) with a dual-proof system (TEE + ZK) for faster finality;
- Custom features – Fusaka EIP support and future protocol innovations. See: https://specs.base.org/upgrades/azul/overview for more details.
Where do you suspect there may be bugs and/or what attack vectors are you most concerned about?
Primary concerns:
- Offchain consensus/execution logic – state root derivation bugs in base-consensus and base-reth-node.
- Proof system integration – TEE/ZK dispute game submission logic, verifier contract bugs, and soundness issues in ZK recursion;
- Protocol transitions – incorrect hardfork activation logic, backwards compatibility breaks, and edge cases in EIP-1559 fee calculation;
- Multi-client discrepancies – execution differences between CL and EL that cause chain forks.
What emergency actions may you want to use as a reason to downgrade an otherwise valid bug report?
- Downgrade valid reports if the attack requires compromising Base-operated infrastructure (not discoverable via code review alone).
- Any report that assumes we will not dispute/blacklist/retire an invalid proposal within the proof system, unless it can be shown that such an action cannot be taken.
- Any report relying on an invalid TEE or ZK proof will be downgraded, especially TEE proofs unless it can be shown that a key compromise is unnecessary.
- Any report that assumes a service/program will not be manually restarted with possibly different configurations will be downgraded
What addresses would you consider any bug report requiring their involvement to be out of scope, as long as they operate within the privileges attributed to them?
- TEE Proposer/Registrar signers (AWS Nitro, Intel TDX enclaves) – if operating within attestation-backed signature authority;
- Security Council multisig (governance-controlled upgrades) – if approving changes within their mandate;
- Sequencer – if transaction ordering is within normal MEV parameters.
What addresses would you consider any bug report requiring their involvement be out of scope, even if they exceed the privileges attributed to them?
- L1 Ethereum validators and stakers – not relevant to Base consensus;
- Third-party bridge validators (Relay, Across, Axelar, etc.) – outside Base's control;
- Base corporate infrastructure – non-protocol (KMS, deployment pipelines, etc.).
Which chains and/or networks will the code in scope be deployed to?
- Base Sepolia testnet (post-April 20 Azul activation) – competition environment.
- Base mainnet (planned May 13, 2026) – target deployment. Base mainnet is not considered to be in scope for the purpose of this competition.
What external dependencies are there?
- Ethereum mainnet (L1) – state root anchoring, EIP-4844 blob data availability, gas price feeds;
- RiscZero SP1 ZK prover – v6.0.2+ (soundness fix required);
- AWS Nitro Enclaves – TEE attestation infrastructure;
- Optimism upstream libraries (op-batcher, optimism/contracts) – for bridge and withdrawal logic. No modifications to these libraries are in scope.
- https://github.com/base/node/tree/main/reth
Are there any unusual points about your protocol that may confuse Security Researchers?
- Single-proof finality model – a TEE or ZK proof is needed to finalize. A ZK proof can be used to challenge a TEE proof, but not vice-versa
- Intermediate output roots – proofs cover block ranges and include commitments to intermediary roots within a proposal to allow disputes to cover a much smaller range of blocks;
- Soundness alert mechanism – if two different state roots both have valid proofs of the same type (i.e. both are TEE or both are ZK), the game can be automatically nullified;
- Private vs. public known issues – some Kona bugs are private (not yet disclosed publicly) but valid for reward.
What are the most valuable educational resources already available? (Ie. Documentation, Explainer videos or articles, etc)
- https://specs.base.org/upgrades/v1/overview – full V1 (Base Azul) specification;
- https://docs.base.org/base-chain/node-operators/base-v1-upgrade – operator migration guide;
- http://github.com/base/base – open-source code with README and architecture docs;
- https://blog.base.dev – technical blog posts on proofs and stack migration.
Public Disclosure of Known Issues
Known Vulnerabilities in Base Azul
Bug reports for publicly disclosed bugs are not eligible for a reward.
Private Known Issues Reward Policy
We are aware of an issue in this codebase that has not yet been publicly disclosed. The Base team has provided a Hash Variant as evidence of pre-existing knowledge concerning this specific vulnerability. Researchers will not receive credit for its discovery. Should this issue become public knowledge during the competition, this section will be updated accordingly.
Previous Audits
Base’s completed audit reports can be found at the links provided below. Unfixed vulnerabilities mentioned in these reports are not eligible for a reward.
Audits for multiproof smart contracts:
- Multiproof contracts audit 1: https://cantina.xyz/portfolio/25ba64ea-d6f3-411e-8338-419ffc385ba6
- Multiproof contracts audit 2: https://cantina.xyz/portfolio/b72c7078-f6da-4074-a3bd-4f938f469fb7
- TEE contracts audit 1: https://cantina.xyz/portfolio/423a9f33-b710-4445-a125-950b0a7771d7
- TEE contracts audit 2: https://cantina.xyz/portfolio/a4f952cf-1c5b-4e3c-8153-c3adff899613
Audit reports for Optimism smart contracts and components (includes Kona): https://github.com/ethereum-optimism/optimism/tree/develop/docs/security-reviews#security-reviews
Network not being able to confirm new transactions (total network shutdown)
Unintended permanent chain split requiring hard fork (network partition requiring hard fork)
Permanent freezing of funds (fix requires hardfork)
Direct loss to Base or users ≥ 10% of funds held within Bridge.
Forging or bypassing TEE or ZK proof verification in AggregateVerifier to finalize an invalid state root on L1
Draining or stealing funds from the L1 bridge portal through invalid withdrawal proofs constructed against a forged finalized state
Circumventing the dispute/challenge mechanism to prevent correction of an invalid proposal before finalization
Direct theft of any user funds, whether at-rest or in-motion
Unauthorized upgrade or replacement of verifier contract implementations (AggregateVerifier, TEEVerifier, or dispute game implementations via DisputeGameFactory)
Permanent freezing of funds in the bridge or in dispute game bonds with no available recovery path
Unintended chain split (network partition)
Temporary freezing of network transactions by delaying one block by 500% or more of the average block time of the preceding 24 hours beyond standard difficulty adjustments
Out of scope
Following folders for base/base are considere to be out-of-scope:
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