# Ethereum staking entry wait stands at 25 days

<https://kriptometa.com/en/ethereum-staking-entry-queue-25-day-wait>

Author: KriptoMeta Editorial Team
Language: English

Published: 2026-10-05T13:35:05+03:00

Updated: 2026-10-05T13:35:05+03:00

![Queued optical connectors on either side of an Ethereum-marked network assembly](https://kriptometa.com/uploads/ethereum-da-staking-icin-gunluk-bekleyis-fee04762558f_article.webp)

## Key takeaways

- An October 5 morning snapshot puts the entry queue at 1,457,964 ETH, with an estimated wait of 25 days and seven hours.
- The roughly 14-day exit estimate is not a guaranteed date for receiving ETH in a wallet.
- Lido contributors propose stopping new stake allocations to MetaMask operators; the proposal is not an implemented decision.

New stake and departing validators are waiting in different Ethereum queues. As MetaMask’s precautionary exits continue, Lido contributors have proposed a further restriction on new allocations.

About 1.46 million ETH was waiting to enter Ethereum [staking](https://kriptometa.com/en/glossary/staking) in an October 5 morning snapshot. [Validator Queue](https://www.validatorqueue.com/), which uses beaconcha.in data, estimated an entry wait of 25 days and seven hours. The same snapshot showed 786,275 ETH in the exit queue, with an estimated wait of 13 days and 16 hours.

The figures describe two different requests: bringing new validators online and allowing existing ones to leave. ETH in the entry queue has not yet begun earning rewards as an active validator. Balances waiting to exit have not necessarily been sent to an exchange or sold, either. Queue data alone does not establish a direction for the price.

## Leaving the queue is not the same as receiving the funds

Ethereum limits the pace of entries and exits to protect network security against sudden changes in stake. Requests above that processing rate build up in a queue. The balance waiting and the estimated delay can change as new requests arrive and earlier ones are processed.

[Ethereum’s withdrawal documentation](https://ethereum.org/en/staking/withdrawals#validator-sweeping) distinguishes a validator ending its duties from the transfer of its balance to a wallet. Once it has completed its exit, a validator no longer earns rewards. Eligible funds still await the network’s automatic sweep through accounts. The withdrawal process also depends on the [staking method](https://kriptometa.com/en/liquid-vs-solo-staking) and how the provider operates.

**Fourteen days is not a guaranteed payment date.** A withdrawal delay may follow the exit queue. These figures describe an October 5 morning snapshot, rather than a promise that every customer of a staking service will receive funds within the same period.



## Lido contributors propose halting new MetaMask allocations

A separate step emerged at liquid staking protocol [Lido](https://kriptometa.com/en/lido-review) on the same day. An October 5 [forum proposal](https://research.lido.fi/t/security-disclosure-metamask-staking-precautionary-out-of-order-exits/11961/2) seeks to stop new stake allocations to MetaMask Staking operators in the two relevant validator modules. Contributors plan to include the change in the next on-chain vote; it has not been announced as an approved decision.

> “no new deposits will be allocated”

Lido contributors’ October 5 proposal, describing the restriction that would apply if adopted.

The proposal follows MetaMask’s [precautionary validator exits](https://kriptometa.com/en/metamask-lido-security-validator-exits) initiated last week. In its [October 1 update](https://metamask.io/en-GB/news/user-update), MetaMask said it was working with partners on those exits after an incident affecting part of its infrastructure. Based on its investigation at that point, the company reported no indication that wallets or customer funds had been affected.

The entry and exit queues cover the entire network. Their total ETH balances cannot be attributed to the MetaMask incident alone. The new allocation proposal also makes no promise about when the existing queue will clear.
