Ethereum Precompiles Explained: Built-In Contracts, Addresses, and Gas

A contract calls a tiny address, finds no ordinary bytecode there, and still gets a cryptographic result. If that sounds contradictory, blockchain infrastructure has led you to one of the Ethereum Virtual Machine's most useful exceptions: precompiled contracts, usually shortened to precompiles.

Precompiles let the protocol perform expensive, standardized operations—signature recovery, hashing, modular arithmetic, elliptic-curve math, and proof verification—without interpreting a long Solidity implementation opcode by opcode. They are efficient, but they are not magical safety wrappers. A caller must use the correct address, exact byte encoding, sufficient gas, and fork-aware return checks.

This guide describes Ethereum mainnet after the Fusaka/Osaka upgrade. Other EVM-compatible networks can expose a different precompile set or price the same operation differently. It is educational, not financial advice (NFA); verify the specification and target chain before relying on any low-level call.

What Is an Ethereum Precompile?

Think of the EVM as a workshop. Ordinary smart contracts bring instruction sheets—their deployed bytecode—and the workshop executes each instruction. A precompile is more like a certified machine already bolted to the floor. You send a precisely shaped input to its fixed address, and the execution client runs a native protocol function.

From a contract's perspective, the interaction still resembles a message call. You can use CALL or, for read-only work, STATICCALL, supply calldata and gas, then inspect success and return data. Under the hood, every conforming execution client must produce the same result because the function is part of Ethereum's consensus rules rather than code stored in the account.

That distinction creates three practical consequences:

• eth_getCode can return 0x even though the address performs useful work.
• The input and output follow the precompile's protocol specification, not Solidity's usual function-selector ABI unless a wrapper deliberately adds one.
• Adding or changing a precompile requires a network upgrade because all execution clients must agree on its behavior and gas schedule.

The Ethereum Yellow Paper formally describes the original execution exceptions, while the current execution specifications track their behavior across forks.

The Current Ethereum Precompile Map

Ethereum mainnet's live set grew in stages. The compact map below reflects the protocol after Pectra added BLS12-381 operations and Fusaka added P-256 verification.

The first nine are summarized in the Yellow Paper. EIP-4844 assigns the KZG point-evaluation precompile to 0x0a. EIP-2537 defines seven BLS12-381 addresses from 0x0b through 0x11; Ethereum's execution specification records their Pectra activation on mainnet on May 7, 2025.

The newest entry is deliberately outside that contiguous run. EIP-7951 defines P256VERIFY at 0x100, with a 160-byte input and a 32-byte success value. The Ethereum Foundation's Fusaka mainnet announcement records activation on December 3, 2025. It also confirms the related MODEXP changes: EIP-7823 bounds each input number at 8192 bits, while EIP-7883 updates gas pricing to better match execution cost.

How a Precompile Call Actually Works

The flow is closer to a binary protocol request than a normal Solidity method call:

1. Encode the exact byte sequence required by the relevant EIP.
2. Call the fixed address, commonly with staticcall when no value or state change is needed.
3. Check the EVM call's success flag.
4. Check the exact return-data length and value defined by the specification.
5. Treat malformed input, empty output, and unsupported-chain behavior explicitly.

For example, EIP-7951 expects five 32-byte values in this order: message hash, signature r, signature s, public-key x, and public-key y. A minimal wrapper can look like this:

library P256Verifier {
    address internal constant P256 = address(0x100);
 
    function verify(
        bytes32 messageHash,
        bytes32 r,
        bytes32 s,
        bytes32 x,
        bytes32 y
    ) internal view returns (bool) {
        bytes memory input = abi.encodePacked(messageHash, r, s, x, y);
        (bool ok, bytes memory output) = P256.staticcall(input);
 
        return ok
            && output.length == 32
            && abi.decode(output, (uint256)) == 1;
    }
}

The length check matters. Calling an ordinary address with no code can succeed while returning empty bytes. Checking only ok could therefore mistake “nothing executed” for valid verification on a chain that has not activated 0x100. EIP-7951 also returns empty data for an invalid signature, so the wrapper must distinguish the specified 32-byte success result from every empty-output path.

Production code should use a well-reviewed library, test official vectors, and pin supported chain and fork assumptions. The snippet illustrates return handling; it is not a complete authentication system.

Why Ethereum Uses Precompiles

Native execution makes specialized math practical

Some cryptographic operations are possible in EVM bytecode but far too costly for routine use. Precompiles give clients optimized implementations with a consensus-defined gas charge. BN254 pairing operations, for example, made succinct proof verification practical within block limits; the relationship is explained further in the zero-knowledge proofs guide.

Standard addresses improve interoperability

Every mainnet contract can target the same address and encoding. The caller does not need to deploy a fresh SHA-256 or elliptic-curve implementation. This shared interface is especially useful for proof systems, bridges, signature schemes, and wallet contracts.

New primitives can unlock better user experience

P-256 is widely supported by phones, security keys, secure enclaves, and WebAuthn ecosystems. Making its signature verification native gives account systems a more direct route to device-backed credentials. That does not make every passkey crypto wallet safe; recovery policy, transaction intent, and smart-account code still matter.

Precompiles, Opcodes, and System Contracts Are Different

These mechanisms can all expose protocol capabilities, but they live at different boundaries.

The labels matter when debugging. A block explorer may show no verified source for a precompile because there is no ordinary runtime bytecode to verify. Conversely, a fixed-address system contract can have code and storage even though the protocol writes to it. Do not infer behavior from the address shape alone.

Gas Accounting Is Part of the Interface

A precompile is efficient, not free. A caller pays message-call overhead, memory expansion and copying where applicable, plus the precompile's own cost formula. Some have fixed charges; others scale with input length or the number of curve points.

Gas schedules can change at a hard fork when benchmarks reveal that an operation is underpriced or overpriced. Fusaka's MODEXP repricing is the clearest recent example. That is why hardcoding a historical estimate is risky. Use the current target-fork rules, estimate the complete transaction, and compare the receipt's actual gasUsed. The gas fees guide explains how gas units become an ETH-denominated fee.

Risks and Limits

Encoding mistakes can fail silently at the wrong layer

Field elements, curve points, scalars, and signatures have exact byte order, length, and range rules. abi.encode and abi.encodePacked are not interchangeable. A wrapper can compile cleanly while producing bytes the precompile rejects.

EVM-compatible does not mean precompile-identical

Layer 2s and alternative EVM chains may activate a primitive earlier, place custom precompiles at other addresses, or use different gas schedules. RIP-7212 deployments helped establish the P-256 interface before Ethereum L1 adopted EIP-7951, but support still must be checked per chain.

Native code expands the consensus surface

Every client must agree on edge cases. Invalid-point handling, input padding, and gas calculation are consensus-sensitive. That is why precompile proposals need specifications, test vectors, benchmarks, and coordinated activation.

Cryptographic verification proves only the stated relation

A valid signature does not prove that the user understood a transaction. A valid pairing does not prove that an application chose a sound proof system or trusted setup. Precompiles accelerate primitives; application security remains the caller's responsibility.

Future forks can change cost or availability assumptions

Ethereum can reprice, replace, add, or potentially “EVMify” functions through later upgrades. Infrastructure should identify the active chain configuration rather than assuming a static list forever.

Developer Checklist

• Confirm the precompile is active on the exact chain and fork.
• Read the final EIP and current execution specification.
• Validate input length, byte order, ranges, and curve membership requirements.
• Check both call success and exact return-data semantics.
• Cap gas and bound user-controlled input.
• Test valid, invalid, truncated, oversized, and empty inputs.
• Run official test vectors across every supported execution client or test environment.
• Re-estimate after network upgrades instead of reusing historical gas constants.
• Document what the primitive proves—and what the surrounding application still trusts.

FAQ

Are precompiles normal smart contracts?

No. They are called through addresses like contracts, but their behavior is implemented by execution clients under consensus rules rather than ordinary bytecode stored at those accounts.

Why does eth_getCode return 0x for a working precompile?

Because there is no deployed runtime bytecode to return. The client recognizes the address during message execution and dispatches the native function.

Can I send ETH to a precompile address?

An address can receive value, but that does not turn the transfer into a useful operation or provide a recovery path. Do not send funds to a precompile. Call it only through a wrapper designed for its specified input and output.

Is 0x100 available on every EVM chain?

No. It is live on Ethereum mainnet after Fusaka, but other networks have their own upgrade schedules and custom address maps. Detect or configure support per chain.

Are precompiles always cheaper than Solidity?

They are intended for operations that benefit from native execution, but total cost includes call overhead, memory, input size, and the current fork's schedule. Measure the complete call rather than assuming every use is cheaper.

Primary Sources

• Ethereum Yellow Paper
• Ethereum execution specifications
• EIP-196: BN254 addition and multiplication
• EIP-198: Modular exponentiation
• EIP-152: BLAKE2 compression function
• EIP-4844: KZG point evaluation
• EIP-2537: BLS12-381 operations
• EIP-7951: P-256 signature verification
• Ethereum Foundation: Fusaka mainnet announcement

The Bottom Line

Ethereum precompiles are protocol-native machines behind contract-shaped doors. They make standardized cryptography practical, but the fixed address is only the beginning of the interface. Safe integration requires exact encoding, fork-aware gas assumptions, strict output checks, and a clear understanding of what the primitive does not guarantee.

Treat the specification as executable security documentation. Test on the target chain, use reviewed wrappers, and re-check assumptions after each upgrade. This article is educational and not financial advice (NFA). Crypto applications and smart contracts can fail or lose funds; test cautiously, use only value you can afford to lose, and always do your own research (DYOR).