Alert Source Discuss
⚠️ Draft Standards Track: Core

EIP-7266: Remove BLAKE2 compression precompile

Remove the blake2f (0x09) precompile by changing the precompile behaviour to result in an exceptional abort

Authors Pascal Caversaccio (@pcaversaccio)
Created 2023-07-03
Discussion Link


This EIP removes the blake2f (0x09) precompile by changing the precompile behaviour to result in an exceptional abort.


EIP-152 has never capitalised on a real-world use case. This fact is clearly reflected in the number of times the address 0x09 has been invoked (numbers from the date this EIP was created):

  • The most recent call took place on 6 October 2022.
  • Since its gone live as part of the Istanbul network upgrade on December 7 2019 (block number 9,069,000), 0x09 has been called only 22,131 times.

One of the reasons why EIP-152 has failed is that the envisioned use cases were not validated before inclusion.


The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

All CALL, CALLCODE, DELEGATECALL, and STATICCALL invocations to the blake2f precompile address 0x09 MUST result in an exceptional abort.


The EVM should be optimised for simplicity and future-proofness. The original Yellow Paper states: these are so-called ‘precompiled’ contracts, meant as a preliminary piece of architecture that may later become native extensions. Considering that no use cases have been realised in the last 3.5 years, we can conclude that the precompile blake2f (0x09) will never transition into a native opcode. In that sense, the precompile blake2f (0x09) is an obsolete carry-along with no real-world traction and thus should be removed. This removal will simplify the EVM to the extent that it only consists of clear instructions with real-world use cases. Eventually, the precompile blake2f (0x09) can be safely used as a test run for the phase-out and removal of EVM functions.

Backwards Compatibility

This EIP requires a hard fork as it modifies the consensus rules. Note that very few applications are affected by this change and a lead time of 6-12 months can be considered sufficient.

Security Considerations

There are no known additional security considerations introduced by this change.

Copyright and related rights waived via CC0.


Please cite this document as:

Pascal Caversaccio (@pcaversaccio), "EIP-7266: Remove BLAKE2 compression precompile [DRAFT]," Ethereum Improvement Proposals, no. 7266, July 2023. [Online serial]. Available: