Validator consolidations

A consolidation moves the effective balance of one or more source validators onto a single target validator, then exits the sources. It's the EIP-7251 mechanism introduced with the Pectra hard fork.

What Pectra changed

Before Pectra, every validator was pinned to a 32 ETH effective balance and the only way to grow stake was to spin up more validators. EIP-7251 raises that ceiling to 2048 ETH for validators that opt into the new 0x02 compounding withdrawal credentials, and adds a beacon-chain primitive (the consolidation request) that moves balance between two validators sharing the same withdrawal credentials.

In Lido v3, and on the SVM by extension, validators are created with 0x02 credentials by default.

How a consolidation works

A consolidation request is an EIP-7002-style transaction sent from the withdrawal address of the source validator to the consolidation predeploy contract on the execution layer (EIP-7251). The beacon chain picks it up, drains the source's balance onto the target, and exits the source.

Three things must hold for a request to land:

• Source and target are both active .
• The transaction is signed by the wallet that controls the source's withdrawal credentials.
• The target's projected balance after consolidation stays ≤ 2048 ETH.

ℹ️

One transaction per pair: each source/target pair is a separate on-chain request. A 5-into-1 consolidation is five signed transactions, not one.

How consolidations can be used in Lido v3

Though Lido v3 does not support consolidations from validators whose withdrawal credentials are stVaults, it does support consolidations from external validators. This provides an alternative to stakers that want to migrate their stake from externally owned validators to a stVaults without missing out on the yield or without being subject to entry queue.

Source / target pairing

Northstake models consolidations as two parallel arrays of public keys: sourcePubKeys and targetPubKeys. Index i in one maps to index i in the other.

The two arrays must be the same length. Duplicate sources are rejected; multiple sources can share a target as long as the combined projected balance fits under 2048 ETH.

Pre-flight validation

Before producing transactions, Northstake exposes a validation endpoint that resolves each pair against on-chain state and returns:

• The current balance of each source and target (in wei).
• The projected target balance after the consolidation lands.
• The signing wallet: the address that controls the source's withdrawal credentials and must sign the request.
• A totalConsolidationBalance summing all source balances.

The UI uses this to populate the review screen and to catch three classes of error early: invalid validator public keys, target overshooting 2048 ETH, and a connected wallet that doesn't match the signing wallet.

🖱️

to validate before signing in the UI: the Configure pairs → Next transition calls the validation endpoint automatically. Failures are surfaced inline against the offending pair; a wallet mismatch is shown as a non-blocking warning on the review step.

</> to validate via the API: see validateConsolidationRequests. Returns per-pair balances, the projected target balance, and the signing wallet.

Submitting the consolidation

Once validated, the consolidate endpoint returns one partial transaction per pair, each addressed to the consolidation predeploy and ready to be signed by the source's withdrawal-address wallet. The signer steps through them sequentially.

🖱️

to consolidate validators in the UI: from a vault page, open Consolidate, pick the vault (preselected when launched from the vault row), then for each row paste a source BLS public key and pick a target validator from the searchable dropdown. The review step shows current → projected balances per target and flags any wallet mismatch. Signing produces N transactions for N pairs.

</> to consolidate validators via the API: see consolidateValidators. Pass sourcePubKeys and targetPubKeys as same-length arrays; the response contains a transactions array of partial transactions to sign and broadcast in order.

Constraints at a glance

After the consolidation lands

The beacon chain processes the consolidation request, moves the balance, and exits the source. The source transitions active → exited → withdrawn on the standard exit timeline (see Staking and the PDG flow → After activation). The target's effective balance is updated on the next epoch boundary.

There's no separate withdrawal claim for the consolidated balance: it lives on the target validator, not in the vault's withdrawal queue. The exited source's principal and pending rewards, however, do sweep into the vault's withdrawal queue and are claimable through the usual Withdrawals flow.

Related

• Staking and the PDG flow: validator lifecycle and where consolidation sits among staking operations
• Consolidate validators into a stVault: walkthrough
• Withdrawals: claiming the swept principal of exited source validators