Bitcoin ETF

Rocket

Rocket Pool

Ethereum

<div style="margin: 28px 0; padding: 18px 22px; border: 1px solid rgba(139,92,246,0.5); border-top: 4px solid #8b5cf6; border-radius: 8px;">
 <p style="margin: 0 0 10px; font-size: 13px; font-weight: bold; letter-spacing: 1px; text-transform: uppercase; color: #8b5cf6;">Key Takeaways</p>
 <ul style="margin: 0; padding-left: 20px;">
  <li style="margin-bottom: 6px;">Validator deposits can no longer fund same-key builders</li>
  <li style="margin-bottom: 6px;">Only deposits queued at the <a rel="noopener noreferrer nofollow">fork</a> faced risk</li>
  <li style="margin-bottom: 6px;">Hoodi testnet delay revived a rejected fix</li>
  <li>Teku and Lodestar still need matching code</li>
 </ul>
</div>
<p>The <a href="https://github.com/ethereum/consensus-specs/pull/5736" rel="noopener noreferrer nofollow">specification change was merged on October 26</a>, two weeks after the flaw was <a href="https://github.com/ethereum/consensus-specs/issues/5735" rel="noopener noreferrer nofollow">reported on GitHub</a>.</p>
<h2 id="how-an-operator-could-have-taken-a-staker-s-deposit">How an operator could have taken a staker’s deposit</h2>
<p>Pooled staking protocols commonly split the work of running a validator. The protocol puts up the ETH, and an outside node operator holds the validator’s signing key. Ethereum keeps <a href="https://ethereum.org/developers/docs/consensus-mechanisms/pos/keys/" rel="noopener noreferrer nofollow">signing and withdrawals separate</a>, so the operator can run the validator without being able to withdraw the protocol’s stake.</p>
<p>Glamsterdam pairs execution-layer changes with a consensus-layer upgrade called Gloas, and adds builders as a new kind of participant under <a href="https://eips.ethereum.org/EIPS/eip-7732" rel="noopener noreferrer nofollow">enshrined proposer-builder separation</a>. Builders assemble the transaction-carrying part of each block and hold their own balances. At the fork, Ethereum converts qualifying deposits still waiting in the queue into builder accounts.</p>
<p>That conversion is where the flaw sat. Under the old rule, once a pending deposit registered a builder for a key, every later deposit for that key topped up the builder, regardless of where its withdrawal credentials pointed. An operator could queue a builder deposit for a fresh key from an address they controlled. If the staking protocol then funded a validator deposit for the same key, and both were still pending at the fork, the protocol’s ETH would be credited to the operator’s builder balance, which the operator could then withdraw.</p>
<p>No validator would be created either. Some protocols release the rest of a stake only after proving that a new validator carries their withdrawal credentials, and that proof would never arrive.</p>
<p>In a follow-up comment, the issue’s author listed designs the bug could disrupt, Lido’s predeposit guarantee, Origin’s OETH and Rocket Pool’s Saturn, while flagging the list as quick AI-assisted research that may contain errors. In each case the exposure is a first deposit, 1 ETH in the Lido and Rocket Pool examples, with the rest of the stake left locked until recovery steps run. The author described these as conditional code findings, not live exploits.</p>
<p>Only deposits still queued when the fork activates could be misrouted, and because Glamsterdam has not reached mainnet, no funds have been lost.</p>
<div class="read-more pb-3 pt-3 pt-md-2 px-3 my-4 border bg-light">
 <h5 class="text-uppercase border-bottom mb-3 pb-1 d-none d-md-block">READ MORE:</h5><a href="https://coindoo.com/swiss-regulator-clears-first-retail-bitcoin-etf/" rel="noopener noreferrer nofollow">
  <div class="contentRight col-4"><span><img src="https://coindoo.com/wp-content/uploads/2025/04/swiss-bitcoin-btc.jpg"></span>
  </div>
  <div class="contentLeft col-8">
   <h4 class="title mb-0">Swiss Regulator Clears First Retail Bitcoin ETF</h4>
  </div></a>
</div>
<h2 id="rejected-on-october-19-merged-a-week-later">Rejected on October 19, merged a week later</h2>
<p>The fix was proposed on October 12. After discussion on two core developer calls, it was closed on October 19 for lack of client support, and the <a href="https://github.com/ethereum/pm/issues/2271" rel="noopener noreferrer nofollow">testing call</a> floated prototyping it after the Hoodi testnet upgrade rather than disrupting the schedule.</p>
<p>Three days later, the Ethereum Foundation <a href="https://blog.ethereum.org/2026/10/22/glamsterdam-hoodi-delay" rel="noopener noreferrer nofollow">postponed Glamsterdam’s activation on Hoodi</a> to investigate how EIP-8037 interacts with existing smart contracts, a problem unrelated to deposits (<a href="https://coindoo.com/ethereum-pauses-glamsterdam-test-some-contracts-at-risk/" rel="noopener noreferrer nofollow">we covered the pause here</a>). The extra time reopened the debate. An October 23 comment on the <a href="https://github.com/ethereum/pm/issues/2281" rel="noopener noreferrer nofollow">next testing call’s agenda</a> tied the deposit change to the revised timeline, the author added deposit-ordering tests the same day, and the change was merged on October 26.</p>
<h2 id="what-the-new-rule-does">What the new rule does</h2>
<p>After the fork, builder and validator deposits already travel separate paths under <a href="https://eips.ethereum.org/EIPS/eip-8282" rel="noopener noreferrer nofollow">EIP-8282</a>. The fix applies the same logic to the queue at the fork: withdrawal credentials, not the public key, decide where each pending deposit goes.</p>
<div style="margin: 24px 0; overflow-x: auto;">
 <table style="width: 100%; border-collapse: collapse; text-align: left;">
  <thead>
   <tr style="border-bottom: 2px solid #8b5cf6;">
    <th style="padding: 10px 12px;" scope="col">Pending deposit at the fork</th>
    <th style="padding: 10px 12px;" scope="col">Old rule</th>
    <th style="padding: 10px 12px;" scope="col">New rule</th>
   </tr>
  </thead>
  <tbody>
   <tr style="border-bottom: 1px solid rgba(139,92,246,0.25);">
    <td style="padding: 10px 12px;">Validator deposit, same key as a builder</td>
    <td style="padding: 10px 12px;">Credited to the builder</td>
    <td style="padding: 10px 12px;">Stays in the validator queue</td>
   </tr>
   <tr style="border-bottom: 1px solid rgba(139,92,246,0.25);">
    <td style="padding: 10px 12px;">Valid builder deposit, same key as a validator</td>
    <td style="padding: 10px 12px;">Blocked from registering</td>
    <td style="padding: 10px 12px;">Registers the builder</td>
   </tr>
   <tr>
    <td style="padding: 10px 12px;">Invalid builder deposit, existing validator</td>
    <td style="padding: 10px 12px;">Kept for the validator</td>
    <td style="padding: 10px 12px;">Kept for the validator</td>
   </tr>
  </tbody>
 </table>
</div>
<p>Reusing one key for a validator and a builder is still allowed; the purpose stated in each deposit now decides which account it funds.</p>
<h2 id="what-still-has-to-happen-before-the-fork">What still has to happen before the fork</h2>
<p>Client teams now have to ship the same rule. A <a href="https://github.com/Consensys-Incorporated/teku/pull/11582" rel="noopener noreferrer nofollow">Teku change opened on October 27</a> was still under review, and <a href="https://github.com/ChainSafe/lodestar/pull/10428" rel="noopener noreferrer nofollow">Lodestar’s</a> remained open.</p>
<p>A late change also has to land identically in every client. Older reference tests encode the previous routing, so a client following the new rule fails them. Teku’s author reports passing the tests generated from the updated specification, which has not yet been packaged in a specification release. If clients reached the fork applying different rules to the same queue, they would compute different balances and disagree on the chain’s state.</p>
<p>The Foundation has not set a new Hoodi date or a Glamsterdam mainnet date. Staking protocols that rely on deposit proofs also have their own line of defense: according to the issue’s author, pre-deposit checks that reject a key already carrying a builder deposit can prevent this scenario.</p>
<p>The post <a href="https://coindoo.com/ethereum-nearly-let-node-operators-grab-staked-eth/" rel="noopener noreferrer nofollow">Ethereum Nearly Let Node Operators Grab Staked ETH</a> appeared first on <a href="https://coindoo.com" rel="noopener noreferrer nofollow">Coindoo</a>.</p>

Ethereum Nearly Let Node Operators Grab Staked ETH

Table of Contents

Coindoo.com

Other articles published on Oct 27, 2026

Join our free newsletter for daily crypto updates!