# consensus-specs PR 5736: where the clients stand (checked 2026-10-27)

PR: https://github.com/ethereum/consensus-specs/pull/5736, "Separate builder and validator deposits at the Gloas fork". It was merged 2026-10-26T19:16:28Z as `8b374fa81b0918b84fe0063a56b4a482e1fa2c6f` (source: https://api.github.com/repos/ethereum/consensus-specs/pulls/5736).

## What the PR changes
Source: https://github.com/ethereum/consensus-specs/pull/5736.diff, `specs/gloas/fork.md`, `onboard_builders_from_pending_deposits`.
- **Old** first check: `if deposit.pubkey in validator_pubkeys: pending_deposits.append(deposit); continue`. Credentials (`is_builder_withdrawal_credential`) and `is_pending_validator` were checked only for deposits whose pubkey is not already a builder.
- **New** first check: `if not is_builder_withdrawal_credential(deposit.withdrawal_credentials): pending_deposits.append(deposit); continue`. Two consequences follow:
  - A builder-credential deposit whose pubkey belongs to an existing validator can now create a builder.
  - A builder-credential deposit with an invalid signature is kept only if the pubkey is a validator or a pending validator. Otherwise it is dropped.
- The new spec text adds: "Only deposits with builder withdrawal credentials can fund builders… Other deposits stay queued, even if a builder uses the same public key… A valid builder registration can use a validator's public key."

## Spec release status
- Newest consensus-specs release: **v1.7.0-beta.4, published 2026-10-08**. There is **no v1.7.0-beta.5 or later**, and no release notes mention 5736 (source: https://api.github.com/repos/ethereum/consensus-specs/releases).
- Because 5736 was merged on 10-26, no released spec and no released test vectors contain it yet.
- https://api.github.com/repos/ethereum/consensus-spec-tests/releases stops at v1.6.0-beta.0 (2025-09-24). No consensus-spec-tests release covers the new routing in its gloas/fork vectors. The PR does add pyspec tests (`test_process_pending_deposits.py` in the diff), but only on `dev`.

## Clients
Branch heads come from `git ls-remote` on 2026-10-27. Files were read through raw.githubusercontent.com at those commits. "Old" means the existing-validator check comes before the credential check.

| Client / branch | Head commit | Routing at head | First routing check (quoted) | 5736 PR / issue |
|---|---|---|---|---|
| Lighthouse stable | a376defa30470923556d91bdeb15a802e297f31f (same as the brief's pin) | **old** | `consensus/state_processing/src/upgrade/gloas.rs`: `// Deposits for existing validators stay in the pending queue.` / `if state.get_validator_index(&deposit.pubkey)?.is_some() {` | none found (search "5736" returns only unrelated #5736; "onboard builders" returns #9943 open, a cache issue, not 5736) |
| Lighthouse unstable | 301f3bf2323cd2b3f946ceed026be8075d24e1c3 | **old** (same code, lines ~259-263) | same as stable | none found |
| Prysm develop | eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a (= pin) | **old** | `beacon-chain/state/state-native/setters_gloas.go`: `if _, ok := b.validatorIndexByPubkey(pubkey); ok { newPendingDeposits = append(...)` (around L810) | none found ("5736", "onboard builders", "builder deposits fork" return only older perf PRs like #17440 and #17387) |
| Teku master | 2c35574b3373cbe8ad121a768d98f066aec05b73 (= pin) | **old** | `GloasStateUpgrade.java`: `// Deposits for existing validators stay in the pending queue` / `if (validatorsUtil.getValidatorIndex(state, pubkey).isPresent()) {` (around L224) | **PR #11582 "Route pending deposits by credentials at Gloas builder onboarding", open**, created 2026-10-27, body says "Implements consensus-specs#5736". Tracking issue #11510 "look into consensus specs -builder deposits at upgrade" closed 2026-10-19. https://github.com/Consensys-Incorporated/teku/pull/11582 |
| Nimbus stable | 0abc0dd0fc0750a8875c49089d074f7d7197b62c (= pin) | **old** | `beacon_chain/spec/beaconstate.nim`: `# Deposits for existing validators stay in the pending queue` / `if findValidatorIndex(state.validators.asSeq, bucket_sorted_validators[], deposit.pubkey).isSome:` | none found ("5736" returns only unrelated #5736; "onboard builders" returns #8686 and #7926, both older) |
| Nimbus unstable | 5babd698516450d8b8e60c2af610a5853baaa9a9 | **old** (same code, around L2360) | same | none found |
| Lodestar unstable | e4b4f615e68c1a4ea7c57632e6ed8d824624573f (= pin) | **old** | `packages/state-transition/src/slot/upgradeStateToGloas.ts`: `// Deposits for existing validators stay in the pending queue` / `if (isValidatorKnown(state, validatorIndex)) {` | **PR #10428 "fix: route pending deposits by withdrawal credentials at the gloas fork", open**, created 2026-10-17, not merged. https://github.com/ChainSafe/lodestar/pull/10428 |
| Grandine develop | 52cd677117b5d93bf477fe4843148070b0303444 (= pin) | **old** | `helper_functions/src/fork.rs` (~L1051-1059): the builder-index top-up comes first, then `if is_for_validator[index] { pending_deposits.push(*deposit); continue; }`, and only after that `if !predicates::is_builder_withdrawal_credential(...)` | none found ("5736" and "onboard builders" return 0 or only #860 and #575, both older). The "builder deposits" search hit the API rate limit. |

Notes:
- Prysm and Lodestar top up an existing builder before the credential check. That order still matches the old spec, because existing validators are excluded first.
- Grandine checks the builder index before `is_for_validator`. The new spec forbids exactly that pattern for a non-B0 deposit whose key belongs to both a builder and a validator. Under the old spec it was unreachable at the fork, because builders and validators could not share a key.
- Some API searches were rate-limited: nimbus "builder deposits fork", grandine "builder deposits fork", and "beta.5" for every client except Lighthouse. Lighthouse "beta.5" returned 70 unrelated hits, none about 5736. Those searches are **not completed**.

## Devnets and testnets
- **glamsterdam-devnet-11** targets consensus-specs **v1.7.0-beta.0** (756f49cf, 09-04). Genesis was 2026-09-14 and Gloas activated at epoch 450 on 2026-09-16 (https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-11).
- No newer devnet note was found: `@ethpandaops/glamsterdam-devnet-12` and `-13` return 404. ACDT #101 does mention a live devnet-12 (https://github.com/ethereum/pm/issues/2271), but its spec version could not be determined.
- **Sepolia: "forked Oct 6"** (ACDT #101, https://github.com/ethereum/pm/issues/2271). That was before 5736 was merged and before beta.4 (10-08), so Sepolia's fork-time onboarding already happened once, with the **old** routing. It cannot be re-run. The epoch (353024) comes from the brief and was not checked independently here.
- **Hoodi**: was scheduled for 2026-10-26 17:42:48 UTC (epoch 132352) and has been **postponed with no new date**. The replacement schedule "will be announced at a later date" (https://blog.ethereum.org/2026/10/22/glamsterdam-hoodi-delay). The fork has therefore **not** happened, and Hoodi's onboarding is still in the future.
- **Plan for 5736** (ACDT #101 agenda, and the comment by jtraglia, 2026-10-16, https://github.com/ethereum/pm/issues/2271#issuecomment-6223076039):
  - Not for Hoodi.
  - Clients prototype the change.
  - Merge and make a release after Hoodi upgrades.
  - Test on a short-lived devnet "like devnet-12".
  - Do not delay mainnet.

  The PR was merged before Hoodi forked, because Hoodi was postponed.
- ACDE #248 (https://github.com/ethereum/pm/issues/2267) says to "aim to set the date [mainnet] on ACDC next week, if Hoodi goes smoothly".
- ACDC #190 (2026-10-29, https://github.com/ethereum/pm/issues/2276) had no agenda lines about 5736, beta, or Hoodi when read.
- ACDC #189 (https://github.com/ethereum/pm/issues/2247) lists a "builder onboarding" item linking consensus-specs issue #5735.

## Verdict
**Transient lag, not yet fixed on any client's default branch.** Every network that has already forked did so on the old routing:
- devnet-11 used v1.7.0-beta.0.
- Sepolia forked on Oct 6.

For those networks the old routing is the correct consensus rule and fork onboarding is a past, one-time event. No released spec (latest v1.7.0-beta.4) and no test release contains 5736 yet.

All six clients run the same old order at their newest default-branch commits, so they do not currently diverge from each other. The gap is between all clients together and spec `dev`.

The risk is in the future and conditional. Hoodi's (postponed) fork and mainnet are planned to run the new routing. If clients ship it unevenly, and a pending deposit with builder credentials uses an existing validator's pubkey, or an invalid one targets a validator or pending validator, then states would diverge at the fork.

Mitigations seen so far:
- Teku #11582 and Lodestar #10428 are open.
- No PR was found for Lighthouse, Prysm, Nimbus, or Grandine (some searches were incomplete because of rate limits).
- The agreed plan is a beta release followed by a short devnet before Hoodi or mainnet.

Until a release contains 5736 and Hoodi has a new date, this should be reported as **transient lag to be tracked**, and as a **live divergence risk for the rescheduled Hoodi fork** if releases arrive unevenly. Which spec version Hoodi will target cannot be determined from public pages yet.