We propose reducing the ValidatorsExitBusOracle (VEBO) reporting frame from 75 epochs (8 hours) to 45 epochs (~4.8 hours), increasing reporting frequency from 3 to 5 times per day.
The change improves exit request latency and distributes validator exit batches more evenly throughout the day.
Motivation
Faster withdrawal processing under load
Each VEBO report can request exits up to the maxBalanceExitRequestedPerReportInEth sanity limit. With 8h frames, exit demand accumulates over a longer window before a report is submitted. Smaller frames mean exits are requested sooner after the withdrawal demand is identified, reducing the end-to-end latency from “withdrawal request submitted” to “validator exit initiated.”
More granular exit pacing
With 3 reports per day, exit bursts are large and concentrated. 5 reports per day distributes exit requests more evenly, reducing the impact on node operators who must process exit messages.
Preserved daily anchor
45 divides 225 exactly (225 = 5 × 45), so the new frame grid aligns perfectly with the 24-hour epoch cycle. Executing the transaction between 12:00 UTC and 20:00 UTC (during the VEBO frame that starts at 12:00 UTC) ensures initialEpoch is anchored to noon — the same daily anchor as today.
What Changes
Parameter
Current
Proposed
epochPerFrame
75 (~8h)
45 (~4.8h)
fastLaneLengthSlots
100
100
Reports per day
3
5
Daily frame times
4:00 / 12:00 / 20:00 UTC
02:24 / 07:12 / 12:00 / 16:48 / 21:36 UTC
Proposed vote items:
Give MANAGE_FRAME_CONFIG_ROLE role to agent
Set new frame configs - setFrameConfig(45, 100)
Revoke MANAGE_FRAME_CONFIG_ROLE
Limit enact time from 12.00 UTC to 20.00 UTC
The vote should be executed between 12:00 UTC and 20:00 UTC to preserve the noon epoch anchor.
Feedback welcome before moving to an on-chain vote!
I think the proposal sounds. During the periods of a high withdrawal demand like we see now extra VEBO reports will facilitate faster withdrawals and decrease market pressure on stETH. During calm periods it would indeed spread validator exits more evenly throughout the day.
I fully support the proposal and think that the change should be made in the next on-chain voting slot in May 2026.
Has the churn impact been modelled? Shorter frames mean less time for deposits to refill the buffer between reports, so during demand spikes the protocol commits to more exits before incoming stake can cover the gap.
Rough example: 10k ETH withdrawal, buffer at 5k, deposit inflow ~1k/h.
8h frame, avg report at h4: deficit 1k, exit 1k
4.8h frame, avg report at h2.4: deficit 2.6k, exit 2.6k
The extra 1.6k gets committed to exit even though the buffer would have caught up anyway. Recovered ETH then has to redeposit, and with the current beacon entry queue at multiple weeks that capital sits idle. Rewards drag on both sides.
Net trade: faster withdrawal latency (good for stETH peg under stress) vs more churn during spikes. With the entry queue this long, the cost side is heavier than usual.
Does VEBO smooth across recent frames or factor in pending deposits, or is each report a pure snapshot? And has anyone simulated total exit volume against historical bursty periods?
Thanks, support this idea since the gas spending only decreases, while granular reports offer less time drag over withdrawals demand and their distribution.
—
On gas estimation: assuming roughly ~600 K gas/cycle and 1,095 cycles/year (current 8 h frame, ~3/day):
Annual gas: ~657 M gas
At 25 gwei: ~16.4 ETH/yr (~$54 K at $3,300/ETH) — what 2024 likely cost
At 8 gwei: ~5.3 ETH/yr (~$15 K)
At 2 gwei: ~1.31 ETH/yr (~$3,300 at $2,500/ETH) — typical 2025
At 0.6 gwei: ~0.39 ETH/yr (~$900 at $2,280/ETH) — current run-rate
With this proposal:
Net effect on annual gas: +~1.5–1.6×, i.e., ~330 M extra gas/year added on top of the current ~657 M.
In current gas conditions (~0.6 gwei, $2,280 ETH), this means going from ~$900/yr to ~$1,400–1,500/yr in raw oracle-tx fees — clearly tractable.
Thanks, good question, and a fair concern to clarify.
VEBO does not calculate exits as a simple unfinalized withdrawals - current buffer snapshot.
For each frame it takes the WQ demand at the reference slot, then estimates how much ETH will be available by the time the requested validators would actually become withdrawable and swept. This includes the current buffer / withdrawal reserve / vault balances, expected rewards and withdrawals, and validators that were already requested to exit but are not yet on exit. VEBO then adds validators to the report one by one only while that predicted available ETH is still below the WQ demand.
So reducing the frame from 75 to 45 epochs should not make VEBO repeatedly request exits for the same demand. Previously requested / on-exit validators are accounted for, and each new report recalculates from fresh state.
Deposits are handled through the actual state at the new reference slot: if deposits have arrived and increased the buffer before the report, VEBO sees that and may request fewer exits or none. What VEBO does not do, same as today, is assume future deposit inflow that has not happened yet.
So the main effect of shorter frames is fresher recalculation and faster reaction to WQ demand, not a change in the exit calculation model.
I propose adjusting the enactment time (4) from the current range of 12:00–20:00 UTC to 13:00–16:30 UTC.
Within this window, we should already have received the previous report, and immediately after enactment, we’ll be ready for the next report scheduled at 16:48 UTC.