You've submitted the exit. The queue is moving. You're already mentally spending that 32 ETH when, somewhere in a block three days later, a slashing proof referencing your validator lands on-chain. The exit you filed doesn't disappear. It just stops being the most urgent thing happening to your balance.
That collision, exit in progress and slash incoming, is exactly where Ethereum's consensus rules get interesting.
The queue is a one-way conveyor belt, not a panic button
When a validator submits a voluntary exit, the Beacon Chain doesn't release funds immediately. It schedules an `exit_epoch` based on how many other validators are already leaving. The churn limit governs this: at any given activation level, only a fixed number of validators can exit per epoch (roughly every 6.4 minutes). With tens of thousands of active validators, that queue can stretch across days or weeks. Once the `exit_epoch` is assigned, the validator stops earning rewards and stops having duties. The 32 ETH plus any accumulated balance sits locked until a further `withdrawable_epoch` passes, set to `exit_epoch + 256` epochs, about 27 hours under normal conditions.
Queuing up to leave doesn't protect you from what happens while you're still technically active. Full stop.
Slashing arrives before the door closes
Slashing is triggered by provable misbehavior: a surround vote, a double proposal, an equivocation the network can demonstrate on-chain. Any validator on the network can submit the proof as a `ProposerSlashing` or `AttesterSlashing` message, a packaged accusation that any block proposer can include. When that message lands in a block, the offending validator is slashed immediately, regardless of whether they already filed an exit.
Here's the concrete sequence. Validator #88,412 submits a voluntary exit on epoch 200,000. The queue is moderately busy, so the `exit_epoch` lands at 200,080. On epoch 200,040, a slashing proof referencing an earlier double-vote gets included in a block. The Beacon Chain processes it. The validator's effective balance drops by 1/32nd instantly, roughly 1 ETH on a standard 32 ETH stake. Then the `withdrawable_epoch` gets extended by an additional 8,192 epochs, about 36 days, on top of whatever remained. That extension is the correlation penalty window: the protocol holds the balance on-chain long enough to assess whether the misbehavior was isolated or part of a coordinated failure, then prices the penalty accordingly.
The validator can't un-exit. They can't re-enter the active set. They wait, with a shrinking balance, longer than they planned.
The correlation penalty is the part that bites hardest
Most explanations stop at the initial 1/32 slash. That's the floor, not the sentence.
The actual penalty scales with how many other validators were slashed in the same window. If validator #88,412 was the only one who misbehaved, the additional correlation penalty is near zero. If they were part of a group because everyone running the same misconfigured client software double-voted together, the penalty can reach the full 32 ETH, leaving the validator with effectively nothing to withdraw.
The formula runs roughly: `penalty = effective_balance (3 total_slashed_in_window) / total_active_balance`. At low total slashing, that fraction stays tiny. At high total slashing, it approaches the entire stake. This is not an accident. The protocol is explicitly designed to be lenient toward individual mistakes and brutal toward coordinated failures, and that design choice is the right one.
Consider two operators, Mara and Felix, both slashed during the same incident. Mara runs an independent setup; her client was the only one that misbehaved. Her total penalty ends up around 1.1 ETH. Felix was part of a staking pool where 2,000 validators shared a misconfigured setup and all double-voted together. His correlation penalty pushes the total close to 16 ETH. Same triggering offense, very different exit balance. The math doesn't care about intent, only about concentration of failure.
What the exit queue can't do for you
The common misread is that filing an exit before a slashing event is detected gives you a head start toward safety. It gives you nothing. Think of it like boarding a flight you've already been flagged on: the gate agent lets you through, but customs is waiting at the other end.
The withdrawal delay exists precisely to ensure the protocol can apply penalties after the fact. A validator who misbehaved, then exited, then had a slashing proof submitted three epochs later is fully exposed. The 8,192-epoch extension guarantees the balance sits on-chain long enough for the correlation math to complete.
So if you're already in the queue: your `exit_epoch` is locked, but your final withdrawal amount isn't settled until the `withdrawable_epoch` passes and every applicable penalty has been deducted. Those are two different things, and conflating them is how operators get surprised.
What's the actual takeaway here? The exit queue is an orderly checkout line. Slashing is the bill that shows up after you've handed over your card. Ethereum's design ensures you don't leave the register until both are resolved, and the protocol, not the validator, decides when that happens. Operators who understand this build their risk models around the correlation window, not the exit timestamp. The ones who don't find out the hard way that 36 days is a long time to watch a balance shrink.