Native Ethereum Delegation (NED): Protocol-Routed Delegation With Split-Neutral Allocation and Bounded Consensus Amplification

squijello · August 13, 2026, 12:39am

Abstract

Ethereum already has delegation economically, but the protocol does not provide a neutral native delegation primitive. Capital therefore tends to reach consensus through staking providers, LST protocols, custodians and other intermediaries that also influence validator selection.

This post explores a different native-delegation architecture.

Rather than allowing a delegator’s choice of commercial staking provider to determine which validator receives the delegated consensus weight, native delegated ETH enters a protocol-level pool and is routed algorithmically across eligible validators.

The allocation rule is deliberately linear in each operator’s own slashable native stake:

D_i=uB_i.

Here, B_i is validator i's operator-owned eligible effective balance and D_i is its active protocol-routed delegated balance.

The motivation for linearity is not simply proportional fairness. Exact neutrality to arbitrary identity splitting requires an additive allocation rule. Under standard regularity assumptions, additivity implies linearity.

A second mechanism bounds the amount by which NED may amplify consensus concentration relative to the entire pre-existing validator set. For the current state variables defined below, NED requires:

3\left(\kappa+r\min(\kappa,e)\right)\leq1+d.

This guarantees that any hidden coalition controlling at most \kappa of pre-NED base stake cannot be pushed above one third of resulting consensus weight solely through NED, without requiring the protocol to identify the coalition.

The intended property is therefore not “large operators become small.” It is:

\text{commercial delegation concentration}\not\Rightarrow\text{automatic consensus-control concentration}.

This is an idea-stage mechanism rather than an EIP.

1. Motivation

Ethereum currently has a practical separation between capital providers and operators, but that separation is mostly mediated above the protocol.

A user may interact with an exchange, staking service, LST or custodian, and that intermediary typically determines where the user’s stake ultimately operates.

This creates an important coupling:

\text{user demand for provider }P\longrightarrow\text{additional stake controlled by }P.

The problem is not necessarily that a staking company becomes commercially large.

The protocol-level concern is that commercial aggregation can mechanically become consensus aggregation.

The question explored here is:

Can Ethereum expose a native delegation primitive in which commercial provider choice and consensus-weight allocation are deliberately separated?

Conceptually:

\text{ETH holder}\rightarrow\text{native NED pool}\rightarrow\text{protocol-routed validators}.

Existing providers could continue competing on custody, liquidity, LST wrappers, insurance, tax reporting, institutional services, compliance, analytics and UX.

Their customers’ use of those services would not itself instruct NED to route consensus weight back to the same provider.

2. Why I moved away from identity-local concentration penalties

An earlier version of this idea attempted to impose progressively increasing costs on concentrated operator identities.

That approach runs into a structural problem.

Let f(B) be any strictly convex cost applied independently to protocol-visible identities, with f(0)=0.

If one owner divides a position B equally among n identities, convexity gives:

n f\left(\frac{B}{n}\right)<f(B).

So a strictly convex identity-local rule inherently makes identity subdivision cheaper.

A linear function is split-neutral but does not penalize scale. A concave function can make subdivision unattractive but creates economies of scale.

Without another observable notion of common ownership, changing the convex curve does not solve this.

This motivated a different objective: make allocation itself neutral to identity splitting.

3. State model

For each NED validator i, define:

B_i=\text{operator-owned native effective balance},

and:

D_i=\text{active NED delegated effective balance}.

The validator’s consensus weight is:

W_i=B_i+D_i.

The two balances have different ownership semantics.

B_i remains ordinary validator-owned stake governed by the validator’s withdrawal credentials.

D_i is an accounting claim of the NED pool. The operator can exercise consensus duties over that weight while assigned, but cannot withdraw the delegated principal.

This likely requires consensus to distinguish two concepts that are frequently represented today by one effective_balance:

native/operator-owned effective balance, and
consensus effective balance.

Stake-weighted protocol operations should use W_i. Operator ownership, ordinary withdrawals and NED capacity should use B_i.

4. Split-neutral allocation

Let:

E=\sum_i B_i

be total eligible NED operator stake.

The balanced target allocation is:

\boxed{D_i=uB_i}.

Separately impose a leverage ceiling:

D_i\leq\lambda B_i,

with:

\lambda\leq1

as the conservative reference design.

Proposition 1: Identity-split neutrality

Suppose one hidden economic owner controls total eligible stake:

B_A=\sum_{j\in A}B_j.

Under linear allocation, its total delegated balance is:

\sum_{j\in A}D_j=u\sum_{j\in A}B_j=uB_A.

Therefore arbitrary subdivision across validator identities does not change aggregate delegated allocation.

Why linearity

More generally, suppose allocation is given by a function g(B).

Exact neutrality to subdivision requires:

g(B_1+B_2)=g(B_1)+g(B_2).

Under ordinary continuity or monotonicity assumptions, the additive Cauchy equation implies:

\boxed{g(B)=uB}.

The mathematical fact is not novel. The proposed use here is to treat additivity as a design requirement for routing protocol-native delegated consensus weight in a pseudonymous operator market.

Integer allocation should round downward so that splitting cannot manufacture allocation through rounding:

\sum_j\lfloor uB_j\rfloor\leq\left\lfloor u\sum_jB_j\right\rfloor.

5. Why proportional allocation alone is insufficient

Suppose only a concentrated subset of Ethereum’s validators opts into NED.

Even if NED is perfectly split-neutral inside that subset, adding delegated weight only to eligible validators increases their share relative to non-participating validators.

So the security argument must use the denominator of the entire validator set, not merely the NED subsystem.

This motivates an explicit amplification bound.

6. Full-network concentration-amplification invariant

Define:

S=\text{total active native/base stake excluding NED delegated weight},

E=\text{eligible NED base stake},

and:

D=\sum_iD_i.

Normalize:

e=\frac{E}{S},\quad d=\frac{D}{S}.

Define the greatest currently active delegation leverage:

r=\max_i\frac{D_i}{B_i}.

Let:

\kappa<\frac13

be a security-policy parameter.

Interpret \kappa as the largest pre-NED base-stake coalition that NED is required to prevent from crossing one third because of NED amplification alone.

Define:

m=\min(\kappa,e).

Require the following invariant at every consensus state:

\boxed{3(\kappa+rm)\leq1+d}. \tag{1}

Proposition 2: Bounded consensus amplification

Consider any hidden coalition A controlling fraction p of pre-NED base stake, with:

p\leq\kappa.

Let a be the fraction of total base stake belonging to coalition A that is NED eligible.

Necessarily:

a\leq\min(p,e)\leq m.

Since no eligible validator has leverage greater than r, the coalition’s delegated NED weight is bounded by:

\frac{D_A}{S}\leq ra.

Its post-NED consensus share therefore satisfies:

q_A\leq\frac{p+ra}{1+d}\leq\frac{\kappa+rm}{1+d}.

By (1):

\boxed{q_A\leq\frac13}.

The proof does not require the protocol to know which validators belong to the coalition.

It also does not assume the current allocation is perfectly balanced.

The use of actual r and d makes the invariant applicable during queues, exits and rebalancing.

7. Balanced-state security rule

When the allocation has reached:

D_i=uB_i

for every eligible validator:

r=u,\quad d=ue.

Equation (1) becomes:

3(\kappa+um)\leq1+ue,

or equivalently:

\boxed{u(3m-e)\leq1-3\kappa}. \tag{2}

where:

m=\min(\kappa,e).

Together with demand and the leverage ceiling, the target multiplier can be bounded by the minimum of:

available delegated demand,
\lambda,
and the security constraint in (2).

As an illustration only, with:

\kappa=0.30,\quad\lambda=1,

full 1{:}1 leverage becomes admissible at approximately:

e=0.80.

I do not propose 0.30 as a final Ethereum parameter.

A more transparent parameterization is:

\epsilon=\frac13-\kappa,

where \epsilon directly measures the maximum reduction in the pre-NED one-third base-stake threshold that the mechanism permits.

8. Safety-driven deleveraging

The security invariant should apply to the actual state, not merely the next target allocation.

Suppose the current state violates (1) after a change in base stake or eligible participation.

Scale all active delegated balances by \alpha:

D_i'=\alpha D_i.

Then:

r'=\alpha r,\quad d'=\alpha d.

A continuous upper bound on the safe scaling factor is:

\boxed{\alpha=\min\left(1,\frac{1-3\kappa}{3rm-d}\right)}. \tag{3}

This expression applies when the denominator is positive. If the current state already satisfies the invariant, \alpha=1.

Downward integer rounding only makes the state more conservative.

New NED activation freezes immediately when the invariant would otherwise be violated.

Delegated weight removed for safety stops voting and enters its accountability/retirement state rather than being instantaneously reassigned.

9. Native delegation pool

NED does not require a per-delegator/per-validator relationship.

Users hold claims on one native pool.

The protocol maintains approximately:

account-level pool shares,
free pool ETH,
active delegated balance by validator,
slashable retiring delegated balance by validator,
pending deposits,
withdrawal requests.

This reduces relationship state from a potentially dense delegation graph to approximately:

O(\text{delegators}+\text{NED validators}).

I do not propose a protocol-native transferable LST as part of the core mechanism.

Application-layer wrappers could tokenize pool claims if desired.

10. Deposit semantics

A deposit first becomes pending capital.

It does not immediately mint active pool shares or receive staking rewards.

Only when security capacity and activation churn permit the capital to become active NED delegation are pool shares minted at the then-current NAV.

This avoids diluting existing pool participants with idle capital.

11. Withdrawal semantics

Let:

A=\text{NED pool NAV}

and:

N=\text{outstanding active pool shares}.

The exchange rate is:

R=\frac{A}{N}.

A withdrawal request locks shares rather than crystallizing an ETH amount.

The shares remain economically exposed to rewards and losses while the corresponding underlying NED stake moves through deactivation and its accountability period.

When settlement becomes possible, the shares are burned at the then-current exchange rate.

This prevents a first-withdrawer advantage around delayed slashing information.

12. Delegated slashability lifecycle

For each NED validator maintain:

D_i=\text{active delegated effective balance}

and:

L_i=\text{slashable NED liability balance},

with:

\boxed{L_i\geq D_i}.

The quantity:

L_i-D_i

is retiring NED capital.

Retiring capital:

carries no consensus weight,
earns no new validator rewards,
cannot be reassigned,
cannot yet be withdrawn,
remains slashable for its NED accountability period.

Unlike the earlier runoff construction, L_i is not additive.

A repeated path such as:

10\rightarrow20\rightarrow10\rightarrow20\rightarrow10

does not create unbounded liability. L_i remains bounded by still-accountable historical exposure.

NED retirement should have its own exit and withdrawability semantics analogous to stake leaving the active validator set. The exact delay should be derived from Ethereum’s accountable-safety and weak-subjectivity model rather than selected arbitrarily.

13. Historical slashing attribution

A slashable message may be proven after D_i has changed.

The pool should be liable for delegated weight that was actually active when the slashable action occurred, subject to the amount still inside its NED accountability period.

Because NED balances would be part of BeaconState, historical state commitments can in principle be used to prove old D_i values with SSZ witnesses rather than storing an unbounded per-validator history.

For an offense epoch t, let:

D_i(t)

be the provable historical active NED exposure.

For double proposals and double votes, attribution can use the relevant offense epoch.

For surround votes involving two relevant epochs t_1 and t_2, a conservative candidate is the common exposure:

D_i^{\text{offense}}=\min\left(D_i(t_1),D_i(t_2)\right).

Then economically attributable NED capital is bounded by:

\boxed{X_i=\min\left(D_i^{\text{offense}},L_i\right)}.

A reference-spec implementation is needed to determine the exact witness structure and surround-vote semantics.

14. Slashing pre-emption

A validator should not be able to submit a cheap low-exposure slash against itself to prevent later evidence from revealing a higher historically accountable NED exposure.

Therefore, during the relevant slashing-settlement window, maintain:

\boxed{X_i^{\text{recorded}}=\max\left(X_i^{\text{recorded}},X_i^{\text{new evidence}}\right)}.

Later evidence does not slash the validator twice. It can only update the historically attributable NED exposure used in final settlement.

This part requires careful compatibility analysis with Ethereum’s existing slashing-vector semantics.

15. Reward and penalty attribution

For routine rewards and availability penalties, attribute the outcome according to productive consensus weight.

For total reward R_i>0:

R_{B,i}=R_i\frac{B_i}{B_i+D_i},

R_{D,i}=R_i\frac{D_i}{B_i+D_i}.

A uniform protocol commission \phi on the delegated reward component can compensate the operator.

I would not use operator-specific fee bids to influence allocation, because that reintroduces a market-driven concentration channel into the routing rule.

Routine availability penalties should likewise be proportional.

For objectively slashable faults, I propose considering operator-first-loss treatment, since the operator controls the signing key.

If total slash loss is L:

L_B=\min\left(L,\text{available operator balance}\right),

L_D=\max(0,L-L_B).

At the reference leverage bound D_i\leq B_i, at least half of a fully utilized NED validator’s managed stake is operator-owned.

Whether operator-first-loss is preferable to completely proportional slashing is one area where I would particularly value feedback.

16. Churn and accountable safety

NED must not create a separate unlimited channel for changing active consensus weight.

Conceptually:

D_i\uparrow

is activation-like,

D_i\downarrow

is exit-like,

and moving delegation from validator A to validator B is an exit followed by a later activation.

These operations should consume the same global balance-based accountable-safety/churn budget as equivalent changes in ordinary active stake.

This is consistent with the direction of both EIP-7251 and eODS, which treat changes in active delegated/effective balance as safety-relevant state transitions.

17. Consensus-weight semantics

A two-balance model means current uses of validator effective_balance need to be classified.

Stake-proportional consensus and service obligations should use:

W_i=B_i+D_i.

This includes at least:

FFG/finality weight,
LMD-GHOST fork-choice weight,
proposer probability,
sync-committee probability,
consensus-layer reward weight,
inactivity penalties,
and any stake-proportional protocol service obligation.

Operator ownership and ordinary withdrawal semantics continue to use B_i.

This is a nontrivial consensus-spec change, but EIP-7251 already demonstrates that one validator index can represent substantially more consensus weight without multiplying validator keys or attestations.

18. Commercial providers

The architecture is intentionally neutral toward large staking businesses.

A provider can become commercially dominant without being forced to split itself, shrink its customer base or satisfy a convex concentration penalty.

Its customers’ NED deposits simply do not preferentially route native delegated weight back to that provider.

If the provider wants more NED consensus weight, it must control more actual eligible native stake.

Thus the mechanism aims to break:

\text{commercial market share}\longrightarrow\text{automatic consensus market share},

not to ban either one.

19. Limitations

This mechanism does not solve hidden beneficial ownership of ordinary base stake.

It does not make the existing validator set more decentralized.

It cannot determine whether an exchange’s ordinary validator stake economically belongs to the exchange or to custodial customers.

It cannot stop custodians from bypassing NED and staking customer ETH directly.

It does not prevent LST or staking-service markets from becoming commercially concentrated.

It does not preferentially subsidize “real small operators,” because doing so without an identity oracle would recreate the splitting problem.

The claim is narrower:

Protocol-routed native delegation can be made neutral to operator identity splitting, while an explicit full-network invariant bounds the amount by which that delegation can amplify pre-existing consensus concentration.

20. Relationship to prior work

This proposal uses ideas with substantial prior art.

eODS is the closest Ethereum-native delegation substrate I have found. It proposes consensus-layer operator/delegator separation, explicit delegator-to-validator accounting, proportional reward/slashing treatment and churn-governed delegation/redelegation.

Rainbow Staking explores operator/delegator separation, partially collateralized operation and the broader unbundling of staking services.

Reward Sharing Schemes for Stake Pools and subsequent stake-pool work study pledge, equilibrium decentralization and Sybil-resistant reward design.

The 2026 Canonical LST proposal for Tezos is particularly relevant. It proposes a protocol-native pooled staking system with protocol-controlled validator allocation, self-bond/capacity constraints, pooled accounting and an explicit decentralization motivation.

Its allocation mechanism is materially different from the construction here: eligible validators are ranked by effective fee and filled subject to capacity and per-validator caps.

To my knowledge, I have not found an existing delegation design combining all three of the following:

protocol-routed pooled delegation deliberately separated from the user’s choice of commercial staking provider;
additive self-stake-proportional allocation used specifically as the identity-split-neutral routing law;
a full-validator-set invariant that explicitly bounds how much delegated consensus weight may amplify any hidden coalition below a chosen pre-NED base-stake threshold.

I would consider those the candidate contributions. Native delegation, pooled staking, self-bonding and protocol allocation individually are not novel.

21. Open questions

The mechanism leaves several important questions for implementation and calibration:

What value, if any, should Ethereum choose for \kappa?
Should the leverage ceiling remain \lambda=1?
What uniform operator commission \phi is sufficient for participation?
How should NED consume the existing activation/exit churn budgets?
What is the correct accountability and withdrawability period for retiring NED balance?
Can historical NED exposure proofs be made cheap enough with existing BeaconState commitments?
What exact semantics should surround-vote attribution use?
Should objectively slashable faults be operator-first-loss or proportional?
How should execution-layer proposal revenue be routed between operator and NED pool?
How should the design interact with EIP-7251’s 2048 ETH maximum effective balance and validator consolidation?
Is the protocol complexity of an enshrined neutral delegation pool justified by the concentration property it provides?

The two claims I would most like to see attacked are:

\boxed{D_i=uB_i}

as the identity-split-neutral allocation law, and:

\boxed{3\left(\kappa+r\min(\kappa,e)\right)\leq1+d}

as the full-network delegation-amplification bound.

If those survive scrutiny, I think the remaining questions are primarily protocol engineering and parameter selection rather than a missing concentration mechanism.

The working name is Native Ethereum Delegation (NED).

Informally, the Flanders Protocol.