Raise PeerDAS Custody Threshold

Draft · 14 September 2026 · Download Markdown source

Abstract

Raise BALANCE_PER_ADDITIONAL_CUSTODY_GROUP from 32 ETH to 256 ETH, increasing the total effective balance that requires a validating node to custody all 128 groups from 4,096 ETH to 32,768 ETH.

Motivation

The existing 4,096 ETH threshold can impose full custody on home operators with delegated stake, for example through Lido CSM or Rocket Pool. High-bandwidth residential connections may be unavailable locally even when an operator can afford better hardware. As blob throughput grows, this requirement risks reducing geographic diversity, as well as becoming a further constraint on blob scaling. Raising the threshold allows more home operators to benefit from partial custody as blob throughput increases.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Parameters

Set BALANCE_PER_ADDITIONAL_CUSTODY_GROUP to 256 ETH:

Name	Type	Value
`BALANCE_PER_ADDITIONAL_CUSTODY_GROUP`	`Gwei`	`Gwei(256 * 10**9)`

The following parameters are unchanged:

Name	Mainnet value
`NUMBER_OF_CUSTODY_GROUPS`	`128`
`SAMPLES_PER_SLOT`	`8`
`CUSTODY_REQUIREMENT`	`4`
`VALIDATOR_CUSTODY_REQUIREMENT`	`8`

Custody requirement

The custody formula is unchanged. For total effective balance B in ETH, taken from the latest finalized state across all validators attached to the node, the required group count is:

min(max(floor(B / 256), 8), 128)

The requirement first exceeds eight groups at 2,304 ETH and reaches all 128 groups at 32,768 ETH. Operators MAY custody more than the required count.

The existing retention rule is unchanged: when a requirement decreases, a node SHOULD continue to custody, advertise, and serve its previous highest custody_group_count, persisting that count across restarts.

The baseline for this EIP is the PeerDAS validator custody specification and networking specification.

Rationale

The 256 ETH increment is chosen to substantially reduce the custody burden on operators with delegated stake: at 4,096 ETH, the requirement falls from 128 groups to 16. The reconstruction capacity retained at the resulting full-custody threshold is assessed in Security Considerations.

Backwards Compatibility

The change is backwards compatible.

Test Cases

The following cases use exact total effective balances, VALIDATOR_CUSTODY_REQUIREMENT = 8, and NUMBER_OF_CUSTODY_GROUPS = 128:

Effective balance	Groups at 32 ETH	Groups at 256 ETH
0 ETH	8	8
32 ETH	8	8
287 ETH	8	8
288 ETH	9	8
2,047 ETH	63	8
2,048 ETH	64	8
2,303 ETH	71	8
2,304 ETH	72	9
4,096 ETH	128	16
32,767 ETH	128	127
32,768 ETH	128	128
65,536 ETH	128	128

An empty validator list returns eight. Equal total effective balances MUST produce equal requirements: one 2,048 ETH validator and 64 validators of 32 ETH each both return eight groups; validators of 2,048 ETH and 256 ETH together return nine.

Security Considerations

PeerDAS relies on full-custody nodes to reconstruct and redistribute missing data, as described in the PeerDAS networking specification. Validator custody provides assurance that such nodes exist by requiring nodes with sufficiently large attached effective balances to custody all columns. One honest full-custody node can reconstruct the complete data after receiving at least half of the columns and redistribute it to the network; additional nodes provide redundancy. Raising the full-custody threshold to 32,768 ETH retains this role for large staking nodes.

Previous measurements provide an empirical basis for expecting a substantial population of these nodes. Reading Figure 10 of Heimbach, Vonlanthen et al. gives approximately 1.6% of measured validator-hosting peers above 1,024 validators, or roughly 35–40 peers in the sample.¹ At 32 ETH per validator, this corresponds to the proposed 32,768 ETH threshold. Extrapolating that fraction to an assumed population of 5,000–6,000 validator-hosting nodes gives approximately 80–100 full-custody nodes. This is an estimate based on the May 2024 distribution.

Illustrative power-law distributions give the same order of magnitude. Allocating one million 32-ETH-equivalent validators across 5,000–6,000 nodes with rank-size allocations v_r = C r^(-s), normalized to that total, yields 85–108 nodes above the threshold for s = 0.8, 1.0 (Zipf), or 1.2. Capping allocations at 20,000 validators per node and renormalizing yields 106–132. Together with the observed distribution, they support expecting on the order of one hundred full-custody nodes, providing substantial redundancy beyond the small number required for reconstruction.

The minimum validator custody requirement and the sampling, commitment, and reconstruction mechanisms are unchanged. Consolidating validators without changing their total attached effective balance does not change the custody requirement. Voluntary full custody and retention of previously advertised custody can provide additional capacity. Reducing the bandwidth burden on home operators also supports geographic diversity and reduces pressure to move staking into hosted infrastructure.

Reference

¹ Lioba Heimbach, Yann Vonlanthen, Juan Villacis, Lucianna Kiffer, Roger Wattenhofer. Deanonymizing Ethereum Validators: The P2P Network Has a Privacy Issue. DOI: 10.48550/arXiv.2409.04366.