EIP-8200 Moving precompiles to the EVM (EVMification)
Hegota Declined for Inclusion · EVM & execution · EIP status Draft · created 2026-03-21
Replaces three precompiles, RIPEMD-160 (0x03), MODEXP (0x05), and BLAKE2f (0x09), with ordinary EVM bytecode that does the same job. Addresses and functionality stay the same; only the internal implementation changes.
Why it is needed
Ethereum has special contracts called precompiles, implemented separately inside client software so that certain operations run quickly. Every client team must implement and maintain them on its own, so there is an ongoing maintenance cost, and if implementations diverge, it can lead to consensus bugs. The burden is greater for zkEVMs, which verify EVM execution with zero-knowledge proofs, because each precompile needs a separate optimized non-EVM implementation. Yet these three precompiles are hardly used in practice. RIPEMD-160 has very little onchain usage. 99.99% of MODEXP usage is 256-bit moduli for SNARK verification, and BLAKE2f is in practice used by a single contract. This EIP replaces the three precompiles, which are little used or can be replaced at low cost, with ordinary EVM code, reducing the number of special implementations every client must maintain and simplifying the protocol.
What changes
Today
- RIPEMD-160 (0x03), MODEXP (0x05), and BLAKE2f (0x09) run as precompiles that each client implements separately
- Gas costs are computed with a dedicated formula for each precompile
- A zkEVM must build a separate optimized implementation for each precompile
After EIP-8200
- At the start of the block in which the fork activates, equivalent EVM bytecode is deployed at the three addresses
- From that block on, the three addresses are no longer treated as precompiles
- Gas costs are computed as the sum of the costs of the EVM instructions actually executed
- Existing contracts keep working by calling the same addresses in the same way
Who is affected
- Client teams: Three fewer special precompile implementations need to be maintained, and the risk of consensus bugs from implementation differences goes down. The barrier to entry for new clients is also lower.
- zkEVM·L2: Fewer precompiles need to be implemented as separate circuits. According to the call records, this reduces the ZKVM circuit and audit scope.
- Contract developer: Existing contracts that call the three addresses keep working, but gas costs change. A contract that calls with a fixed amount of gas can revert if the new cost is higher.
In depth
Why these were chosen for replacement: actual usage of the three precompiles
The targets are RIPEMD160_ADDRESS (0x03), MODEXP_ADDRESS (0x05), and BLAKE2F_ADDRESS (0x09). RIPEMD-160 has very little onchain usage, and its main historical use, Bitcoin-style address derivation, is uncommon in Ethereum contracts. In the proposer's analysis, 99.99% of MODEXP usage was 256-bit moduli for SNARK verification, and the rare RSA moduli made up the rest. BLAKE2f is currently used predominantly by a single contract. The selection criterion is that usage is low or that the precompile can be moved to the EVM at low cost.
Deployment method: install code at the start of the fork block
At the start of execution of the block in which this change activates, for each of the three addresses above, (1) the code at that address MUST be set to EVM bytecode functionally equivalent to the replaced precompile, and (2) from that block onward (including that block), the address MUST no longer be treated as a precompile. This is the same approach as EIP-7666, which moves the identity precompile (0x04) to the EVM. However, the exact bytecode to deploy at each address is not yet specified.
Gas cost: from dedicated formulas to a sum of instruction costs
After activation, calls to the three addresses are charged the standard EVM execution cost instead of the precompile-specific gas formulas. Currently the RIPEMD-160 precompile charges 600 + 120 * ceil(len(data) / 32) gas, and BLAKE2f charges gas equal to the number of rounds specified in the input (rounds). MODEXP uses a complex formula based on the base, exponent, and modulus lengths and an iteration count derived from the exponent. Because the EVM implementation charges the sum of the costs of executed instructions, costs are expected to change. In particular, modular exponentiation is complex on the EVM, so MODEXP is expected to cost more for large inputs. The specific gas comparison table for each precompile is left as a TODO in the source.
Design choice: deploy at the same address, give up replicating the gas formulas
It does not try to reproduce the original precompile gas formulas exactly, and instead accepts the natural gas cost of EVM execution. The rationale is that gas repricing has been done many times in the Ethereum ecosystem and its effects are well understood. Even so, an impact analysis for each precompile will be carried out. The alternative of removing the precompiles and having callers use library contracts at other addresses was rejected because it would break backward compatibility for already deployed contracts. If bytecode is deployed directly at the existing addresses, every existing contract that calls those addresses keeps working through the same interface without modification.
Backward compatibility and security considerations
The functionality at each address is preserved, but gas costs change, so contracts that depend on precise gas calculation when calling may be affected. In particular, a contract that calls with a fixed amount of gas can revert if the EVM implementation costs more than the existing precompile. The source states that precompile gas costs have changed in the past and that relying on hardcoded gas costs has been regarded as bad practice. On implementation correctness, the deployed bytecode must be thoroughly tested and audited to confirm that it produces the same output as the original precompile for all valid inputs and handles invalid inputs the same way.
Status: Draft, excluded from the Hegotá fork
This EIP is in Draft status, and its content may change, for example the bytecode to deploy and the test cases are not yet specified. In the core developer calls, it was accepted as a Hegotá fork candidate (PFI) at 07.30 ACDE #242, citing the reduced ZKVM circuit and audit scope, but at 09.10 ACDE #245 its inclusion in Hegotá was withdrawn (DFI). Everyone agreed the direction was good, but the judgment was that it was premature because performance benchmarks of the replacement bytecode were not yet mature.