CLZ Opcode

Adds a new CLZ opcode that counts the number of leading zero bits in a 256-bit word, returning 256 if the input is zero.

Engine API Usage

At and after Azul activation, block production and import use the following Engine API methods: engine_forkchoiceUpdatedV3 for starting block builds and forkchoice synchronization. engine_getPayloadV5 for fetching built payloads. engine_newPayloadV4 for importing payloads into the execution engine. engine_getPayloadV5 returns a V5 envelope, but the contained execution payload is still V4-shaped. As a result, payload insertion continues through engine_newPayloadV4 (there is no engine_newPayloadV5 path used by Base Azul clients).Azul constraints for this flow: Blob-related Engine API inputs are constrained to empty values: expectedBlobVersionedHashes MUST be an empty array. blobsBundle in engine_getPayloadV5 responses is expected to be empty. executionRequests in engine_newPayloadV4 MUST be an empty array.

eth_config RPC Method

Introduces the eth_config JSON-RPC method, which returns chain configuration parameters such as fork activation timestamps.

eth/69

Updates the Ethereum wire protocol to version 69, removing legacy fields from the Status message and simplifying the handshake.

MODEXP Gas Cost Increase

Raises the MODEXP precompile minimum gas cost from 200 to 500 and triples the general cost calculation.

Multiproofs

Proof System Introduces a multi-proof system for L2 checkpoints, where AggregateVerifier can verify one or two proofs for the same proposal before withdrawals rely on it. New/Changed Onchain Components Adds AggregateVerifier plus proof-specific verifier contracts, reduces DelayedWETH to a 1-day withdrawal delay, and moves legacy finality timing out of OptimismPortal2 and AnchorStateRegistry. Proposer Turns safe or finalized Base L2 checkpoints into L1 AggregateVerifier games by requesting TEE proofs, verifying output roots, and submitting proposals with the required bond. Challenger Checks in-progress AggregateVerifier games against canonical L2 state and disputes incorrect claims through the permissionless ZK proof challenge path. TEE Provers Adds AWS Nitro Enclave-backed TEE provers for the common proposal path. The enclave re-executes requested L2 block ranges and signs resulting checkpoint outputs. ZK Provers Adds permissionless ZK provers for dispute verification, especially to challenge invalid TEE-backed proposals or invalidate bad ZK claims. Prover Registrar Keeps the onchain TEEProverRegistry in sync with the live set of Nitro prover signers, attesting active signer identities and removing orphaned signers.

Remove Account Balances & Receipts

Simplifies the FlashblocksMetadata payload by removing new_account_balances and receipts from the Flashblocks WebSocket format.

secp256r1 Precompile

Specifies the secp256r1 precompile at address 0x100. From Azul, the gas cost increases to 6,900 to match the L1 gas cost specified in EIP-7951.

Transaction Gas Limit Cap

Introduces a protocol-level maximum gas limit of 16,777,216 (2^24) per transaction. Transactions above this cap are rejected during validation, and Base adopts the same cap as L1 to maximize Ethereum equivalence. Deposit transactions will be exempt from the transaction gas limit cap. They are already limited to 20,000,000 gas as that is the most gas that can be included in an L1 block.

Upper-Bound MODEXP

Caps MODEXP precompile inputs to a maximum of 1024 bytes per field. Calls with larger inputs are rejected.

Use basev0 protocol ID for discv5

Updates execution-layer discovery to use basev0 as the protocol ID so Base nodes can find each other more quickly, especially on smaller networks like Sepolia.

B20

B20 implements the ERC-20 specification, making it interoperable with all existing systems built on ERC-20 like wallets, exchanges, data indexers, and onchain protocols. What's different is how it runs. Rather than a conventional smart contract, a B20 is a precompiled contract: its logic runs natively in the node software, written in Rust and executed directly instead of as onchain EVM bytecode. Issuers can deploy and configure tokens of all kinds: stablecoins, real-world assets, and onchain-native tokens. When deploying new tokens, we've consistently seen issuers rebuild compliance features from scratch, slowing their speed to market and introducing the risk of missteps. To accelerate issuing new high-quality assets, B20 comes with an Issuer Toolkit purpose-built for teams facing these requirements.

Reducing Canonical Withdrawal Delay

The single-proof dispute game finalization window is reduced from 7 days to 5 days. The dual-proof fast path (TEE + ZK) introduced in Azul remains at 1 day. Shortening the single-proof window frees capital for fast-bridge liquidity providers sooner, reducing fees and improving reliability for users who bridge through third-party partners.

Reth V2

Ships Reth V2 as the reference execution client for Base nodes, delivering significant sync speed and throughput improvements.

B20 Improvements (Cobalt)

Cobalt will bring the following improvements to the B20 token standard: Pay transaction fees in B20s: as part of our rollout of EIP-8130, users will be able to pay transaction fees in B20s. Schedule Multiplier Updates: allows issuers to schedule (and optionally cancel) a multiplier to tokens. This allows for onchain representation of splits, without needing to mint or burn tokens. Only available on the Asset variant of B20. Transfer blocked: simplifies the current freeze and seize model by reducing the burnBlocked + mint steps into a new transferFromBlocked action. New Policies - Union (||) & Intersect (&&): the Union policy allows asset issuers managing many tokens the ability to share policies by default with the ability to enable overrides per token. The Intersect policy allows asset issuers the ability to compose allowlist behaviors with commonly-needed blocklists.

Dynamic Upgrades

Dynamic Upgrades introduces an Ethereum smart contract that stores upgrade timestamps for Base nodes, allowing nodes to query the contract and apply changes live. The EL and CL each run an upgrade-signal poller that reads the contract over L1 RPC, saves the schedule into the client's activation overrides, and applies them wherever the schedule is used. Forks activate at the scheduled time with no restart. We expect the decoupling of node releases and upgrade timestamps to reduce the number of node releases operators need to run. NOTE: This change will be rolled out in metrics-only mode for Cobalt, as we collect data to validate that the upgrades work smoothly.

Native Account Abstraction

EIP-8130 will bring Native Account Abstraction to Base and allow us to keep transactions opinionated and optimizable. Compared to the previous generation of Smart Accounts, we’ve been able to dramatically reduce the per transaction cost to end users by over 2x, while not compromising on our scaling goals. Native Account Abstraction makes the following features native to the chain: Batch calls: Group multiple actions into a single transaction Sponsorship: Applications can pay for their users’ gas fees or allow them to pay in any token. Portability: Use the same account on any chain, even those that don’t support Native AA. Quantum Ready: Key rotation and multiple authentication schemes allow users to upgrade to post quantum authentication. High-throughput: Parallel nonces and large sender limits unlock high levels of concurrency. Session keys: Applications can act on your behalf with bounded and revocable permissions or create Sub-accounts: Fully isolated account owned by you and controllable by an application. Metadata: Add memos and attributions to your transactions.