What Are Precompiled Contracts on Ethereum?

A precompiled contract on Ethereum is a piece of functionality that lives at a specific, reserved contract address but is implemented directly in the client software's native code rather than as EVM bytecode, giving it dramatically better performance and lower gas costs than an equivalent operation written in Solidity or another smart contract language. Precompiles exist for a small, fixed set of operations — mostly cryptographic ones — that would be prohibitively expensive to run as ordinary interpreted smart contract code.

Why precompiles exist

The Ethereum Virtual Machine executes smart contract bytecode by interpreting it instruction by instruction, which is flexible but relatively slow compared to running equivalent logic as compiled, native code. For certain operations — particularly cryptographic primitives like hashing algorithms and signature verification — this interpretation overhead would make routine operations, like verifying a signature, so expensive in gas that many practical use cases (multi-signature wallets, privacy-preserving proofs, cross-chain verification) would become impractical or prohibitively costly.

Precompiles solve this by reserving a small set of low-numbered contract addresses (starting at 0x01) for operations that are implemented as native code within the client itself — written in the same language as the client (like Go, for Geth), compiled and optimized like any other software function, rather than interpreted as EVM bytecode. When a contract calls one of these addresses, the client recognizes it and executes the native implementation directly, charging a fixed, much lower gas cost that reflects the operation's actual computational cost rather than the overhead of bytecode interpretation.

What precompiles currently exist

Ethereum's precompile set has grown gradually over the years, each addition requiring its own EIP and network upgrade, since adding a precompile is a protocol-level change, not something a developer can do unilaterally. Some of the long-standing ones include:

Address	Function	Common use case
0x01	ECRECOVER — recovers a signer's address from an ECDSA signature	Verifying signatures, including meta-transactions
0x02	SHA-256 hashing	Interoperability with systems (like Bitcoin) that use SHA-256
0x03	RIPEMD-160 hashing	Interoperability with certain address formats
0x04	Identity — simply copies input to output	Efficient data copying within contract logic
0x05	Modular exponentiation	RSA-style cryptography, some ZK-related computations
0x06–0x08	Elliptic curve operations (alt_bn128)	Verifying zero-knowledge proofs efficiently
0x09	Blake2 compression function	Cross-chain and specific hashing needs

Newer precompiles have continued to be proposed and added as needs evolve — particularly around zero-knowledge proof verification, given how central ZK-rollups and other layer 2 designs have become to Ethereum's scaling roadmap.

Why this matters for developers and, indirectly, for users

If you're building or auditing smart contracts, precompiles are the reason certain operations — verifying a signature, checking a ZK proof, hashing data compatible with another chain's format — are practical to do on-chain at all. Writing full elliptic curve pairing operations in raw EVM bytecode would be so gas-expensive that many zero-knowledge applications simply wouldn't be economically viable without a dedicated precompile handling the heavy cryptographic lifting natively.

For everyday users, precompiles are invisible — you'll never call one directly — but they're quietly responsible for making certain features affordable. Signature-based account abstraction schemes, ZK-rollup proof verification happening on mainnet, and various cross-chain and privacy-preserving applications all lean on specific precompiles to keep gas costs from becoming a hard blocker.

Precompiles versus regular smart contracts

The key distinction is that a regular smart contract's logic is fully visible as EVM bytecode, deployed and stored like any other contract, and executed by the EVM's interpreter. A precompile's logic isn't deployed at all in the usual sense — it's built directly into the client software itself, at a reserved address, and every full node's client must implement it identically for consensus to hold. This also means adding a new precompile is a hard-fork-level protocol change requiring broad client and network consensus, unlike deploying an ordinary contract, which anyone can do permissionlessly at any time.

How a new precompile gets added

Adding a precompile isn't something any individual developer can do — it requires a formal EIP proposal, review and rough consensus among client teams and researchers, implementation across every major execution client (Geth, Nethermind, Besu, Erigon, and others), thorough testing on public testnets, and eventual inclusion in a scheduled network upgrade. This high bar exists because every full node on the network must implement any given precompile identically for consensus to hold — a single client with a subtly different implementation of a precompile's logic could cause that client to disagree with the rest of the network about a transaction's validity, a serious bug class known as a consensus failure. This is quite different from deploying an ordinary smart contract, which any developer can do permissionlessly at any time without needing anyone else's approval.

Gas costs are fixed, not measured dynamically

Another distinguishing feature of precompiles is how their gas costs are determined. Ordinary EVM bytecode is priced instruction by instruction as it executes, with costs reflecting the interpreter's actual per-opcode overhead. Precompiles, by contrast, are typically assigned a gas cost formula directly in their specifying EIP, calibrated by benchmarking the native implementation's real-world performance across representative inputs. This means precompile gas costs can, in principle, need occasional recalibration if underlying hardware or software improvements change the actual cost of running the native operation relative to the rest of the EVM's pricing — a rare but real category of proposed protocol adjustment.

Bottom line

Precompiled contracts are Ethereum's way of making a small set of computationally expensive but broadly useful operations — mostly cryptographic hashing and signature verification — affordable to use on-chain, by implementing them as native client code at reserved addresses rather than as interpreted EVM bytecode. They're invisible in everyday use but foundational to features like efficient signature verification and zero-knowledge proof checking, and expanding the precompile set is a deliberate, infrequent protocol-level decision rather than something added casually.