I’ve been following this discussion and keep coming back to whether we’re using the right lever here.
I understand the concern behind 8363. If staking keeps growing and more of that ETH ends up concentrated through LSTs, custodians and large institutional operators, that creates a real problem.
What I’m less convinced of is that reducing the return on all staked ETH is the best way to address it. Total stake and stake composition are related, but they aren’t the same thing. Changing issuance acts directly on the first and only indirectly on the second.
If the concern is intermediation and where delegated consensus weight ends up, native delegation seems like a more direct place to intervene.
What if delegation itself became native to Ethereum?
An ETH holder could place ETH into a protocol-level delegation system without transferring control of that ETH to a staking operator. Existing providers could still offer LSTs, liquidity, insurance, interfaces, institutional products, custody, tax reporting and other services.
But I’ve changed my view on one important part of the design.
I no longer think the delegator, or the commercial provider they use, should necessarily choose the validator that receives the underlying native delegated consensus weight.
The structure I’m exploring now looks more like:
ETH holder -> native delegation pool -> protocol-routed validators
A user could still choose Lido, Coinbase, Chorus One, a wallet or another service at the application layer, but that commercial choice would not automatically route the native delegated stake back to that provider’s validators.
The reason for this change is the identity problem.
My earlier approach tried to make increasingly concentrated operators progressively more expensive. I explored declining reward curves, bond-backed capacity, operator families and concentration reserves.
I no longer think that is the cleanest direction.
Any nonlinear rule applied independently to pseudonymous validator identities risks becoming a game about how the same underlying actor partitions itself. Ethereum cannot reliably know that ten apparently independent validators or operators are actually controlled by one entity.
So instead of trying to identify concentrated hidden owners, the current construction tries to make identity splitting irrelevant to the allocation rule itself.
For validator i, let:
V_i = ordinary native effective balance
If the validator is NED-enabled:
B_i = V_i
otherwise:
B_i = 0
B_i is deliberately not “operator-owned stake.” Ethereum can observe validator credentials and effective balance, but it cannot reliably observe beneficial ownership.
Let:
D_i = protocol-assigned NED delegated principal
The balanced routing target is:
D_i = u * B_i
where u is a common delegation ratio.
The important part is that the allocation is linear.
If one hidden actor divides the same eligible base stake across any number of validator identities:
B_A = B_1 + B_2 + ... + B_n
then its total target delegation remains:
D_A = D_1 + D_2 + ... + D_n = u * B_A
Splitting into more identities creates no additional target allocation.
More generally, if an allocation rule g(B) is required to be exactly neutral to arbitrary splitting, it needs to satisfy:
g(B_1 + B_2) = g(B_1) + g(B_2)
Under ordinary continuity or monotonicity assumptions, that leads to a linear rule.
So rather than asking Ethereum to distinguish “real small operators” from fake ones, the protocol makes subdivision irrelevant to the routing rule.
There is still another problem though.
If only a concentrated subset of validators participates in NED, even proportional routing within that subset can increase its consensus share relative to validators outside it.
The current construction handles that with a full-network concentration bound.
Let:
S = total ordinary active base stake
E = total NED-eligible base stake
D = total assigned NED delegated principal
and:
e = E / S
d = D / S
Now normalize each NED validator:
b_i = B_i / S
y_i = D_i / S
For an eligible-base mass m, define a Delegation Concentration Envelope:
C(m) = maximum delegated principal that can fit inside any eligible-base slice of size m
Operationally, this is a fractional-knapsack bound: sort eligible validators by D_i / B_i, highest first, and ask how much delegated principal can actually be packed into m units of eligible base stake.
This replaces an earlier version that used only the single highest local leverage ratio. The DCE is tighter because a tiny high-leverage validator contributes only the delegated principal it can actually carry instead of its ratio being multiplied across unrelated stake.
Let κ < 1/3 represent the largest pre-NED base-stake coalition the mechanism is required to prevent from being pushed across one third solely because of NED amplification.
Define:
m = min(κ, e)
NED also has an exceptional global effective-weight multiplier γ, normally:
γ = 1
Effective delegated consensus weight is:
Q_i = γ * D_i
The full-network constraint is then:
κ + γ * C(m) <= (1/3) * (1 + γ * d)
The reasoning is fairly direct.
Any hidden coalition with ordinary base share at most κ can have at most m of its base stake inside the eligible set.
By construction of C(m), the delegated principal assigned to any such eligible slice cannot exceed C(m).
So its post-NED consensus share is bounded by:
q <= (κ + γ * C(m)) / (1 + γ * d)
and the constraint above guarantees:
q <= 1/3
without requiring Ethereum to know which validator identities belong to the same hidden owner.
That is the part of the idea I find most interesting now.
It turns the problem from:
How do we identify and punish a large hidden operator?
into:
How much delegated consensus weight can the protocol safely add while guaranteeing that delegation itself cannot push a protected sub-threshold hidden coalition across a critical consensus threshold?
The construction also gives an interesting scaling property.
In the balanced state:
D_i = u * B_i
so:
C(m) = u * m
and:
d = u * e
The amount of delegation NED can safely support therefore grows with eligible validator coverage.
For an illustrative protected threshold of κ = 32%, the concentration-only capacity is approximately:
| NED-eligible coverage |
Maximum D / S from concentration |
| 40% |
2.86% |
| 60% |
6.67% |
| 80% |
20% |
| 88.89% |
50% |
| 90% |
60% |
| 92% |
92% |
So if participation is narrow, NED is deliberately small.
If participation becomes broad, the protocol can safely support much more delegated capital.
At universal proportional participation, relative amplification tends to zero because the delegated allocation increasingly resembles the validator set itself.
The shorthand I’ve been using for this is:
Flanders earns scale by earning coverage.
I also no longer think concentration, local delegation leverage and total NED size should all be controlled by one parameter.
The current construction separates them.
The DCE constraint handles hidden-coalition concentration.
A separate local limit:
D_i <= ℓ * B_i
bounds the delegated principal attached to any one unit of eligible native stake.
And a global limit:
D / S <= Λ
can bound total NED exposure even when near-universal participation makes the concentration constraint very permissive.
The broader framing has changed as a result.
This is no longer really an attempt to force large staking businesses to decentralize themselves.
A provider could become commercially very large.
What it would not receive automatically is an equivalent share of native delegated consensus weight simply because a large number of users chose its product.
In other words:
commercial staking share != native delegated consensus allocation share
A provider that wants more NED allocation still needs more NED-eligible native base stake, and the resulting delegated distribution remains subject to the network-wide concentration envelope.
There are obviously substantial implementation questions.
NED would need separate accounting for ordinary effective balance and delegated principal, lifecycle rules for activation and retirement, a bounded-cost implementation of the DCE, rewards and penalties across the two capital sources, historical slashing exposure, pooled withdrawals, churn limits and exceptional safety handling.
The current design also uses a global effective-weight multiplier γ as a last-resort safety mechanism. If an involuntary state change makes the active NED distribution violate the concentration bound, γ can fall below 1 so that some assigned delegated principal temporarily stops contributing full consensus weight. Increasing γ again would be activation-like and should consume churn.
I have also moved away from the attestation-only version I briefly explored.
The current reference direction treats:
W_i = V_i + γ * D_i
as the validator’s NED-weighted consensus balance for the stake-weighted roles NED participates in, including FFG, LMD-GHOST and proposer sampling.
That avoids maintaining two fundamentally different stake distributions for finality and proposal probability, although it reintroduces the economic issue that execution-layer proposer revenue cannot all be forced back into the NED pool.
The current approach is to leave that execution-layer revenue with the operator as an explicit operator rent rather than pretending the protocol can reliably measure and redistribute all MEV.
That means NED yield may be lower than the full economic return of direct validation or some LSTs. I think that is an adoption question that needs to be modeled rather than hidden with a subsidy.
Slashing and withdrawal accounting are also more complicated than I originally appreciated.
Ethereum can receive valid slashing evidence well after the underlying message was signed, which means pooled delegation cannot simultaneously provide unbounded historical delegated liability, finite final withdrawals with no clawback, and exact assignment of every arbitrarily late loss to the users who were present at the time.
The current reference design therefore gives the delegated component a finite NED slashing claim window while leaving ordinary Ethereum validator slashing unchanged.
The initial reference window is:
W_NED = 8192 epochs
A timely NED slashing notice keeps the relevant pool liability open. A withdrawal cannot settle until its delegated exposure has retired, the NED claim window has passed, and timely pending notices have resolved.
Historical NED exposure can in principle be proven against historical BeaconState commitments rather than requiring a permanent dense delegator-to-validator graph.
There is still a lot of consensus-layer work before I would consider this EIP-ready.
In particular, the remaining blockers include parameter selection, Pyspec lifecycle/accounting, a full audit of consensus uses of effective balance, accountable-safety analysis for exceptional γ reduction, sync-committee semantics, delegated slashing penalties, historical proof cost, state-processing cost and adoption/issuance modeling.
I also don’t think this solves every form of staking concentration.
Ethereum still cannot determine the beneficial ownership of ordinary validator stake. A custodian can still stake customer ETH outside NED. LSTs and staking providers can remain commercially concentrated. And NED does not make the existing validator set more decentralized by itself.
The narrower claim is that native delegated capital does not have to make commercial delegation concentration automatically become additional consensus concentration.
I’ve substantially rewritten the separate NED thread around this construction:
[IDEA] Native Ethereum Delegation (NED) - Protocol-Routed Delegation With Split-Neutral Allocation and Coverage-Bounded Consensus Amplification
It is still an idea-stage mechanism rather than an EIP, and I’m especially interested in corrections where the economic model collides with consensus-layer realities I’m missing.
But I think the broader question remains:
If the concern is staking composition and intermediation, should we be looking harder at mechanisms that operate directly on delegated consensus weight before using aggregate staking yield as the primary lever?