---
eip: 8012
title: Generalized consolidation requests
description: Reutilizes the consolidation request contract to pass general messages from the EL to the CL.
author: Potuz (@potuz)
discussions-to: https://ethereum-magicians.org/t/eip-8012-generalized-consolidation-requests/25264
status: Draft
type: Standards Track
category: Core
created: 2025-08-22
---

## 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](./eip-7732.md).

## 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](../LICENSE.md).