Documentation Index
Fetch the complete documentation index at: https://base-a060aa97-roethke-refactor-docs-icp.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
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 a small number of additional precompiles. The following table lists each of the additional precompiles. The system version indicates when the precompile was introduced.| Name | Address | Introduced |
|---|---|---|
| P256VERIFY | 0x0000000000000000000000000000000000000100 | Fjord |
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. The op-geth implementation is
here.
Address: 0x0000000000000000000000000000000000000100
Opcode Differences
Base uses the standard Ethereum opcode set with the following modifications:| Opcode | Hex | Behavior on Base |
|---|---|---|
ORIGIN | 0x32 | For L1→L2 deposits from contracts, returns the aliased L1 address. For EOA-initiated deposits, returns the actual origin. |
CALLER | 0x33 | For L1→L2 deposits initiated by contracts, returns the aliased L1 contract address. |
COINBASE | 0x41 | Returns the SequencerFeeVault address (0x4200000000000000000000000000000000000011). |
DIFFICULTY / PREVRANDAO | 0x44 | Returns the prevrandao value from the L1 origin block, per EIP-4399. |
BASEFEE | 0x48 | Returns the current L2 base fee. |
BLOBBASEFEE | 0x4A | Always returns 1. EIP-4844 blob transactions are disabled on L2; Base does not process blobs. |
Address Aliasing
When a contract on L1 calls a contract on L2 (via theL1CrossDomainMessenger or directly through a deposit transaction), the L1 sender address is aliased on L2 to prevent address collisions between identically-addressed contracts on L1 and L2.
The alias is computed by adding a fixed offset to the L1 address:
CALLER and ORIGIN within the context of those L1-initiated transactions. Externally owned accounts (EOAs) are not aliased — aliasing only applies to contract callers.
To recover the original L1 address from an aliased address, subtract the same offset: