EIP-8012: Generalized consolidation requests
Reutilizes the consolidation request contract to pass general messages from the EL to the CL.
| Authors | Potuz (@potuz) |
|---|---|
| Created | 2025-08-22 |
| Discussion Link | https://ethereum-magicians.org/t/eip-8012-generalized-consolidation-requests/25264 |
Table of Contents
Abstract
This EIP redefines the field target_pubkey from consolidations requests into a general array of 48 bytes that can be interpreted separately by the consensus layer.
Motivation
The current contract to send consolidation requests is not optimized in that the exact same contract, with the exact same calldata and engine API, can be used to transmit more general messages from the EL to the CL without changes on the EL side. In particular, avoiding any cross layer coordination in the event of an CL hard fork.
As a possible application, we could use the same contract to allow any existing validator to become a builder as in EIP-7732.
Specification
Constants
Consensus Layer
| NAME | Value | Comment |
|---|---|---|
MAGIC_PREFIX |
0xEF0A11 |
3 byte prefix to all generalized consolidation requests |
Execution Layer
No changes are expected
Consensus Layer
This EIP does not establish any changes on the consensus layer, but rather standardizes how consolidation requests are to be treated in the future. When receiving a ConsolidationRequest type object on the consensus layer, the target_pubkey field is to be treated differently. If it coincides with the BLS publick key of an existing active validator in the beacon chain, then it is to be interpreted as such. Otherwise, the 48 bytes are to be interpreted as a concatenation of the following fields
|MAGIC_PREFIX | CALL_TYPE | ARG_NUMBER | ARG1 | ARG2 | ARG3 | ARG4 | ARG5 |
Where MAGIC_PREFIX is the 3 byte constant that prefixes all generalized consolidation requests. CALL_TYPE are 4 bytes to be interpretted as a little Endian uint32 and identifies the function type. ARG_NUMBER is a 1 byte to be interpretted as a uint8 that encodes the number of arguments that are being passed to the generalized consolidation request handler. And each ARG1, ARG2, ARG3, ARG4, ARG5 are all interpretted as little Endian uint64.
For each addition of a new CALL_TYPE, the consensus layer must add a handler appropriately called from within process_consolidation_requests.
Engine API
No changes needed.
Rationale
The proposed reinterpretation of the existing contract enables new implementations in the consensus layer without requireing a hard fork in the execution layer.
Backwards Compatibility
This EIP is fully backwards compatible.
Security Considerations
No known security impacts.
Copyright
Copyright and related rights waived via CC0.
Citation
Please cite this document as:
Potuz (@potuz), "EIP-8012: Generalized consolidation requests [DRAFT]," Ethereum Improvement Proposals, no. 8012, August 2025. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-8012.