A One-Time Deposit Crossover
Glamsterdam brings proposer-builder separation into Ethereum’s consensus rules. Builders assemble the transaction payloads that block proposers use; the upgrade introduces staked builder accounts within the protocol.
The issue describes an operator first queuing a valid builder deposit for a new public key, with withdrawals directed to the operator’s own address. A staking protocol then funds a validator deposit for that same key using its intended validator withdrawal credentials, such as `0x02`. If both deposits remain pending at the fork, the onboarding logic credits both amounts to the builder. The operator can then withdraw the protocol’s funds, according to the report.
No validator is created in that scenario. A protocol that requires proof of a validator’s withdrawal credentials before releasing more funds may therefore be unable to obtain that proof. Depending on its design, accounting, staged funds or recovery procedures could be disrupted, the issue says.
The current fork specification keeps deposits for already-registered validators in the validator queue. The described exposure is to pending deposits for new keys with the operator’s builder deposit ahead of them, not existing validator balances.
After the fork, EIP-8282 routes builder deposits through a separate contract. It retains the one-time onboarding of builder-credentialed deposits from the old queue so builders can exist from the upgrade’s first slot. That transition is where the two deposit types can cross over.
Checks Before Funding
The GitHub report identifies pre-deposit checks that reject an earlier builder deposit as a way to prevent the scenario. Gusakov urged delegated-staking developers to review the details and prepare mitigation measures.
Glamsterdam activated on Sepolia on Oct. 6. Ethereum’s deployment tracker proposes Hoodi activation on Oct. 26 and still lists mainnet timing as TBD.
