If you look up address 0x0000000000000000000000000000000000000001 on a block explorer, you'll find something odd: no deployed bytecode, no contract creation transaction, no owner — and yet contracts call it constantly, and those calls return results and cost gas. Every wallet signature check that runs through ecrecover touches this address. It behaves like a contract, but nothing was ever deployed there.
That's a precompile. A precompile (or precompiled contract) is a function built directly into Ethereum's client software, exposed at a fixed, reserved address, and callable exactly as if it were a smart contract. When a contract calls one, the client doesn't load and execute EVM bytecode — it runs native code written in the client's own language, Go in the case of Geth, Rust in others. From the caller's perspective the difference is invisible. From the network's perspective it's the difference between an operation being affordable and being impossible.
Why Precompiles Exist
The EVM is a general-purpose machine, and general-purpose machines are slow at specialized work. Heavy cryptographic operations — recovering a public key from a signature, computing an elliptic curve pairing, running a hash function the EVM wasn't designed around — would cost millions of gas if implemented as ordinary contract bytecode, assuming they could fit in the block gas limit at all.
Precompiles are the escape hatch. The operation gets implemented once in each client, natively, at native speed, and the protocol assigns it a fixed gas price that reflects the actual cost of the native execution rather than the cost of simulating it opcode by opcode. ecrecover costs a flat 3,000 gas. Implemented in pure EVM bytecode, the same signature recovery would cost orders of magnitude more.
The mechanism is simple: precompile addresses are reserved at the very bottom of the address space (0x01, 0x02, and so on), and when the EVM processes a CALL to one of those addresses, it intercepts the call and dispatches to the native implementation instead of looking up code. Inputs go in as calldata, results come back as return data, gas gets charged by a formula written into the protocol specification. That's the whole trick.
What's Actually There
The set has grown slowly, and the history is readable in the addresses.
The four originals, present since launch in 2015: ecrecover (0x01) for ECDSA signature recovery, SHA-256 (0x02) and RIPEMD-160 (0x03) — notably Bitcoin's two hash functions, included with cross-chain verification in mind — and identity (0x04), which just copies data.
The Byzantium fork in 2017 added four more, and this is the batch that aged best: modexp (0x05) for modular exponentiation, which makes RSA-style verification feasible, and three operations on the BN254 elliptic curve — point addition (0x06), scalar multiplication (0x07), and a pairing check (0x08). Those three were added to make zk-SNARK verification affordable on-chain, years before rollups existed. It's hard to overstate how consequential that decision turned out to be: essentially every Groth16 verifier contract on Ethereum — which means a large share of the ZK-rollup ecosystem — runs through those three addresses today. The infrastructure was enshrined before the industry that needed it arrived.
Not every addition worked out that way. Istanbul in 2019 added blake2f (0x09) to enable Zcash interoperability, which never materially developed. It still has to be maintained, identically, by every client team, forever — precompiles don't get removed, because deployed contracts may depend on them. That asymmetry is worth registering: a precompile is a permanent commitment made against a prediction about future demand, and the predictions are sometimes wrong.
The recent additions track the rollup roadmap. Cancun in 2024 added the KZG point evaluation precompile (0x0a), which verifies commitments to blob data and is what lets rollups prove things about blobs they posted under EIP-4844. And the Pectra upgrade in 2025 added a family of BLS12-381 operations (EIP-2537) — the same curve Ethereum's own consensus layer uses for validator signatures — after roughly five years of the proposal waiting in the queue. Five years, for a well-understood curve with an obvious use case, is a fair indication of how high the bar sits.
Where the Constraints Live
The bar is high for structural reasons, not cultural ones. Adding a precompile requires a hard fork, and it requires every client team to implement the same function natively and identically. A precompile bug isn't like a contract bug — if two clients disagree on one output for one edge-case input, they disagree on the state root, and the chain splits. The consensus-failure surface of the network grows with every precompile added, which is why client teams are the most reliable source of resistance to new ones.
Gas pricing is the other hard constraint. A precompile priced too low is a denial-of-service vector — attackers can buy more computation than they're paying for and slow the network, which is exactly what Ethereum's 2016 DoS attacks exploited in underpriced operations. Pricing has been corrected in both directions over the years (EIP-2565 cut modexp costs after the initial formula proved too conservative), and each correction is itself a fork-level change.
So the trade sits like this: precompiles buy native-speed cryptography at the cost of permanent, consensus-critical maintenance across every client. That cost is why the list has grown by roughly one batch every few years rather than continuously.
What's Changing
The interesting movement right now is happening off mainnet. Layer 2s can extend the precompile set without Ethereum's consent, and they've started doing it deliberately. The clearest example is RIP-7212 — the first "Rollup Improvement Proposal" — which adds verification for the secp256r1 curve, the one used by phone secure enclaves and passkeys. Major L2s have shipped it because it enables wallets secured by device hardware instead of seed phrases, and mainnet hasn't. Arbitrum has gone further with its own family of custom ArbOS precompiles.
This is a quiet fork in what "the EVM" means. The previous post in this series described EVM compatibility as a treadmill; custom precompiles add a second dimension, where L2s aren't just lagging the spec but extending it in different directions. A contract that depends on RIP-7212 works on Base and fails on mainnet. Whether successful L2 precompiles get pulled up into L1 — the RIP process is explicitly designed as a staging ground for that — is one of the things to watch.
The longer-horizon question is whether precompiles remain the mechanism at all. If the EVM's general execution path gets fast enough — through the ongoing work on faster clients, or the more speculative proposals to swap the VM's core for something like RISC-V — then native-speed cryptography becomes expressible as ordinary code, and the case for enshrining specific functions weakens.
What Would Confirm This Direction
L2-proven precompiles like secp256r1 verification landing on mainnet through the standard EIP process. Continued batch additions on the roughly-yearly fork cadence. Growing production usage of the BLS12-381 precompiles now that they're live.
What Would Invalidate or Change It
A consensus-splitting bug traced to a precompile implementation would harden resistance to new ones for years. In the other direction, a substantially faster general execution path would remove the reason precompiles exist — if ordinary bytecode can verify a pairing at acceptable cost, enshrinement stops paying for its maintenance burden. And if L1 and L2 precompile sets keep diverging without reconciliation, "EVM-compatible" fragments further into chain-specific dialects.
Timing Perspective
Now: The mainnet set runs from ecrecover through the BLS12-381 batch, and it's load-bearing — ZK-rollup verification traffic flows through the 2017 pairing precompiles daily. If you're reading contract code and see calls to bare low addresses, this is what you're looking at.
Next: The L2 precompile experiment is the active front. Watch whether RIP-7212 adoption converts into an L1 EIP, and whether other RIPs follow the same path.
Later: The precompiles-versus-faster-VM question is real but unscheduled. Nothing about it requires attention this year.
Boundary Statement
This post covers what precompiles are and why the set changes slowly. It isn't a Solidity tutorial on calling them, a complete gas-cost reference, or a security review of any client's implementation. And as always: this is mechanism explanation, not a recommendation to build on, use, or invest in anything described here.
