# Lighthouse might not accurately update effective balances

Lighthouse updates validator effective balances twice per epoch (post-deposits and post-consolidations), breaking hysteresis and producing a 63 vs 64 ETH divergence that can chain-split.

- Payout: Contest reward
- Severity: high
- Program: Ethereum Pectra Lighthouse
- Credited: alexfilippov314
- Disclosed: 2025-07-21
- Write-up quality: 8/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_ethereum_pectra_lighthouse.pdf#3.1.1
- Library page: https://bugbountylibrary.com/r/cantina%3Aethereum_pectra_lighthouse%3A3.1.1
- Tags: domain:web3 impact:dos impact:integrity kind:contest platform:cantina sev:high tech:rust technique:regression technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Ethereum consensus client epoch processing (single_pass.rs)
**Root cause:** Effective balance updates are applied both after pending deposits and after consolidation requests, whereas the spec applies them once after consolidations; hysteresis makes two updates non-equivalent to one.
**Steps:**
1. Set validator A balance 31.9 ETH, validator B balance 64 ETH with effective_balance 64 ETH.
2. B submits partial withdrawal of 32 ETH; A submits consolidation A->B (allowed since process_consolidation_request doesn't check target's pending withdrawals).
3. Both process in same epoch: B's balance drops to 32 ETH, effective_balance still 64 ETH.
4. Lighthouse updates B's effective_balance to 32 ETH after deposits, then to 63 ETH after consolidation (63.9 ETH balance fails upward threshold).
5. Spec-correct single update keeps effective_balance at 64 ETH (net -0.1 ETH below DOWNWARD_THRESHOLD).
6. Divergent effective balances across clients cause chain split.
**How found:** Code-reading of single_pass.rs against the Electra spec's process_epoch ordering; noticed effective balance updated at L320-L330 and again at L1101-L1111, then reasoned about hysteresis non-commutativity.
**Escalation:** Divergence between Lighthouse and spec-compliant clients leads to consensus/chain split.
**Insight:** When a client reorders spec steps for single-pass optimization, check stateful functions with hysteresis/thresholds (effective balance, caches) for idempotency—two partial updates can differ from one combined update.