EIP-8254: Cap deposit requests per block

Discussion topic for EIP-8254

EIP-8254 introduces a per-block cap of MAX_DEPOSIT_REQUESTS_PER_BLOCK = 8192 on EIP-6110 deposit requests, enforced by Execution Layer clients during both block validation and block construction. The cap matches the existing Consensus Layer SSZ list bound MAX_DEPOSIT_REQUESTS_PER_PAYLOAD exactly.

The motivation is a reachable liveness failure: at a 193–200M gas limit a block can be filled with more than 8192 deposit requests using a batching contract (~410 deposits per 10M-gas tx). The EL produces the payload, but the CL cannot SSZ-decode it (VariableList of N items exceeds maximum of 8192), the validator receives 400 Bad Request for the block request, and proposal fails. The same SSZ bound applies to every consensus client. Subsequent proposers building on the same execution head hit the same wall until the deposit backlog drains.

The cap must be enforced during block construction (not just validation): an attacker can simultaneously flood the public mempool and trigger external-builder circuit-breakers, forcing fallback to local block production where awareness of the cap is the only defence.

Spec / PR: ethereum/EIPs#11607.
Reproduction: spamoor/spammer-configs/deposit-contract-batch.yaml.

Authors: pk910 (@pk910), Barnabas Busa (@barnabasbusa).

Update Log

External Reviews

None as of 2026-05-06.

Can this be fixed in the CL?

Can this be fixed in the CL?

ssz currently has a limitation where you need to know the exact length of each value. So yeah in theory this value could just be raised to maxint-1, but that could also bring in some unpredictable behaviour (especially if the deposit count in a single slot exceeds the processing time of that slot).