Overview
Precompiled contracts exist on Base at predefined addresses. They are similar to predeploys but are implemented as native code in the EVM as opposed to bytecode. Precompiles are used for computationally expensive operations, that would be cost prohibitive to implement in Solidity. Where possible predeploys are preferred, as precompiles must be implemented in every execution client. Base contains the standard Ethereum precompiles as well as Base-specific precompiles. The table below lists P256VERIFY, including its introduction version and current gas cost. B20’s singleton precompiles are documented separately in the B20 section.P256VERIFY
TheP256VERIFY precompile performs signature verification for the secp256r1 elliptic curve. This curve has widespread
adoption. It’s used by Passkeys, Apple Secure Enclave and many other systems.
It is specified as part of RIP-7212 and was added to
the Base protocol in the Fjord release with a gas cost of 3,450.
With the Azul hardfork, the gas cost was updated to 6,900 to match EIP-7951 and maintain strict equivalence with L1 precompile pricing.
Address: 0x0000000000000000000000000000000000000100
Standard Ethereum Precompile Modifications (Azul)
The Azul hardfork introduced changes to two standard Ethereum precompiles:MODEXP (Address 0x05)
- EIP-7823 — input fields are capped at 1,024 bytes each. Calls with larger inputs are rejected.
- EIP-7883 — minimum gas cost raised from 200 to 500; the general cost formula is tripled.
B20
B20 is Base’s native token standard for programmable assets. Its shared token logic runs as precompiles in the Base node rather than as per-token Solidity code. B20 assets expose an ERC-20-compatible interface with additional roles, policies, and supply controls. Each B20 asset has its own address, created through the Factory; the addresses below are shared system entry points, not token addresses.
For an overview of B20’s design and capabilities, see the B20 introduction. See
B20 constants for the canonical address list.