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

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) 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. 1 post - 1 participant Read full topic