Azul Execution Engine

Azul layers a batch of Osaka-era execution rules onto Base while keeping the chain in lockstep with L1 pricing and behavior. The changes fall into three buckets: EVM-level adjustments (a per-transaction gas cap, MODEXP limits, a new opcode, and precompile repricing), networking updates (the eth/69 wire protocol and a leaner Flashblocks message), and RPC additions (a fixed Engine API method set and the new eth_config endpoint).

EVM Changes

Transaction Gas Limit Cap

EIP-7825 sets a protocol-enforced ceiling of 16,777,216 (2^24) gas on any single transaction. Anything asking for more than that is turned away at validation time. Base matches the L1 ceiling so the two layers stay equivalent.

Note

Deposit transactions are exempt from the cap. They are already bounded to 20,000,000 gas, which is the most gas an L1 block can carry for them.

Upper-Bound MODEXP

EIP-7823 limits each MODEXP precompile input field to at most 1024 bytes; calls that exceed that size are rejected.

MODEXP Gas Cost Increase

EIP-7883 lifts the MODEXP precompile floor from 200 to 500 gas and triples the result of the general cost formula.

CLZ Opcode

EIP-7939 adds the CLZ opcode, which counts the leading zero bits in a 256-bit word and returns 256 when the input is zero.

secp256r1 Precompile Gas Cost

EIP-7951 places the secp256r1 precompile at address 0x100 with a gas cost of 3,450.

Base has shipped this functionality since Fjord, where the p256Verify precompile was added at the same 0x100 address via RIP-7212, also priced at 3,450 gas. Starting with Azul the cost rises to 6,900 to match the L1 figure in EIP-7951, keeping Base’s precompile pricing strictly aligned with Ethereum.

Networking Changes

eth/69

EIP-7642 bumps the Ethereum wire protocol to version 69. It strips legacy fields out of the Status message and streamlines the handshake.

Discovery protocol now uses basev0 protocol ID

The execution-layer discovery protocol now advertises basev0 as its protocol ID. Scoping discovery this way lets Base nodes locate one another faster, which matters most on smaller networks such as Sepolia where peers are scarcer.

Remove Account Balances & Receipts

Azul trims the FlashblocksMetadata payload sent over the Flashblocks WebSocket. The new_account_balances and receipts fields are dropped. The access_list field stays in the schema but is left unpopulated in Azul.

Before:

{
  "block_number": 43403718,
  "new_account_balances": {
    "0x4200000000000000000000000000000000000006": "0x35277a9715c6df1c99de"
  },
  "receipts": {
    "0x1ef9be45b3f7d44de9d98767ddb7c0e330b21777b67a3c79d469be9ffab091dd": {
      "cumulativeGasUsed": "0x177d7bd",
      "logs": [],
      "status": "0x1",
      "type": "0x2"
    }
  },
  "access_list": null
}

After:

{
  "block_number": 43403718,
  "access_list": null
}

RPC Changes

Engine API Usage

From Azul activation onward, block production and import flow through a fixed set of Engine API methods:

• engine_forkchoiceUpdatedV3 to kick off block builds and synchronize forkchoice.
• engine_getPayloadV5 to retrieve built payloads.
• engine_newPayloadV4 to import payloads into the execution engine.

engine_getPayloadV5 hands back a V5 envelope, but the execution payload inside it keeps its V4 shape. Because of that, payloads are still inserted through engine_newPayloadV4 — Base Azul clients never use an engine_newPayloadV5 path.

The flow operates under these Azul constraints:

• Blob-related Engine API inputs are pinned 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

EIP-7910 adds the eth_config JSON-RPC method, a way to surface a chain’s configuration — fork activation timestamps among other parameters. Base Azul answers eth_config calls with the standard EIP-7910 response schema, subject to a few Base-specific details:

• blobSchedule always comes back with current, next, and last zeroed out. Since Base carries no native blob transactions, it deliberately avoids reporting Ethereum’s synthetic blob-schedule defaults.
• precompiles lists the active EVM precompile set for that fork — the standard Ethereum precompiles plus any Base-specific additions.
• systemContracts only contains entries representable under EIP-7910. On Base that means:
  • BEACON_ROOTS_ADDRESS appears once Ecotone is active.
  • HISTORY_STORAGE_ADDRESS appears once Isthmus is active.
  • DEPOSIT_CONTRACT_ADDRESS, CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, and WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS are omitted.

Base-specific predeploys and the other OP Stack system contracts are not serialized into eth_config unless the EIP-7910 schema covers them.