# Prysm process_pending_deposits does not comply with beacon chain specs, leading to chain split

Prysm's batch signature verification skips a second same-slot deposit for a new validator with an invalid signature, diverging from spec and risking a chain split.

- Payout: Contest reward
- Severity: high
- Program: Ethereum Pectra Prysm
- Credited: zigtur
- Disclosed: 2025-07-21
- Write-up quality: 8/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_ethereum_pectra_prysm.pdf#3.1.1
- Library page: https://bugbountylibrary.com/r/cantina%3Aethereum_pectra_prysm%3A3.1.1
- Tags: domain:web3 impact:dos impact:integrity kind:contest platform:cantina sev:high tech:go technique:incomplete-fix technique:source-review vuln:business-logic vuln:signature-replay

**Target:** beacon-chain electra process_pending_deposits / batchProcessNewPendingDeposits
**Root cause:** Prysm batches signature verification for new-validator pending deposits and drops any deposit with an invalid signature, even when the validator was already registered by an earlier deposit in the same slot; the spec only verifies the first deposit's signature.
**Steps:**
1. Read spec process_pending_deposits/apply_pending_deposit: signature checked only if pubkey not in registry.
2. Note Prysm collects new-pubkey deposits into pendingDepositsToBatchVerify and verifies each signature individually.
3. Craft two pending deposits for the same fresh pubkey in one slot: first valid, second with zeroed 96-byte signature.
4. Run `go test -run ^TestBatchProcessNewPendingDepositsZigtur` against electra.BatchProcessNewPendingDeposits.
5. Observe balance is 32 ETH instead of 64 ETH — second deposit silently dropped.
**How found:** Code review of Prysm's batch-verification optimization against the spec's apply_pending_deposit logic; noticed the `if validSignature` gate wraps the already-known-validator balance increase, contradicting the spec's rule that only the first deposit's signature matters.
**Exploitation:** Any validator can submit two deposit transactions in the same block for a new pubkey where the second has an invalid signature; Prysm nodes drop the second deposit while spec-compliant clients apply it, causing state divergence and a chain split.
**Escalation:** Combined with a Besu EIP-7702 v-parity bug, split validator percentage reaches the 33% consensus-failure threshold.
**Insight:** When a client batches an operation for performance, check whether the batch gate (e.g. signature validity) is applied to items that the spec would process unconditionally — consensus clients diverge exactly at these optimization boundaries.