Rainbow Staking: Ethereum’s Next Evolution in Staking

Introduction

After The Merge in 2022, Ethereum officially entered the PoS era. In the years that followed, the Ethereum ecosystem grew explosively. To achieve faster finality while preserving decentralization, the research community proposed many approaches. Today we’re going to talk about one of the latest staking mechanism designs: Rainbow Staking.

The Concerns After The Merge

The Status Quo: Ethereum’s Monolithic Validator

After The Merge, anyone who stakes 32 ETH can spin up a validator. In this design, a validator is a monolith that handles all of the following:

• Block Proposal: Takes turns constructing and broadcasting new blocks.
• Attestation: Votes on the chain head and finality checkpoints.
• Sync Committee: Rotates periodically to help light clients sync to the latest chain state.

This looked simple and straightforward at first. But as Ethereum’s ambitions grew, the “one validator does everything” architecture ran into two unavoidable systemic bottlenecks.

Two Systemic Bottlenecks

# Bottleneck 1: The Physical Limits of Performance and Hardware #

Ethereum’s next major goal is SSF (Single-Slot Finality(*)): finalizing a block within one slot (12 seconds), rather than the current 2 epochs (~12.8 minutes).

The core technical challenge of SSF is signature aggregation. With over 1 million active validators on the network, aggregating that many BLS signatures within 12 seconds is nearly impossible given current bandwidth and compute constraints. The proposed solution from researchers is to cap the number of active signers per slot at roughly 8,192 (see Sticking to 8192 signatures…), making aggregation feasible within the time limit.

But this comes at a steep cost:

This threshold effectively locks out most home node operators and solo stakers. The price of performance is a step backward for decentralization.

* A previous article mentioned that the current preferred design is 3SF rather than SSF. However, in research forums, SSF is still the commonly used term for next-generation fast finality, with 3SF being more of a specific implementation approach. So we’ll use SSF throughout, and subsequent mentions of SSF carry the same meaning.

# Bottleneck 2: Capital Monopoly and the LST Threat #

The 32 ETH staking threshold has never been accessible to everyone. So the market naturally gave rise to Liquid Staking Protocols (LSPs) to address this: users don’t need to gather 32 ETH — they simply deposit any amount of ETH into a protocol like Lido, which pools the funds and delegates them to Node Operators for staking. In return, users receive equivalent LSTs (Liquid Staking Tokens, e.g. stETH).

LSTs dramatically improved capital efficiency — a user’s ETH earns staking rewards while their stETH can simultaneously be used in DeFi for lending or liquidity provision. The same capital is doing two things at once. This proved extremely attractive to retail participants.

But this created a dual centralization problem:

• Capital centralization: Lido at one point controlled over 32% of all staked ETH, giving it disproportionate influence over Gasper consensus.
• Node centralization: LSPs select their own Node Operators, leaving ordinary users with no say in who is actually running the nodes they delegate to.

When a single LST reaches a high enough market share, it effectively replaces ETH as the “reserve asset” of the Ethereum ecosystem — threatening ETH’s monetary role and undermining the protocol’s credible neutrality.

The high threshold introduced by SSF and the centralization driven by LSTs — these two bottlenecks are the starting point for all the design changes that follow.

The Problem Framed: Vitalik’s Two-Tier Staking Proposal (2023)

The Core Question

In October 2023, Vitalik published an article. Rather than directly solving the bottlenecks above, he asked a more fundamental question:

The “Rube Goldberg Machine” Argument for Delegation

To understand why Delegators must do something meaningful, Vitalik constructed a thought experiment to show why “Delegators who only provide capital passively” add nothing to network security.

# Setting the Premise: A “Near-Perfect” LSP World #

Suppose Ethereum limits slashing penalties to 2 ETH. Rocket Pool would likely follow by lowering the Node Operator minimum bond to 2 ETH as well — a lower barrier to running a node means more operators can join. Under this setup, even if a Node Operator gets fully slashed, Delegators lose nothing.

In this world, rETH is essentially interest-bearing ETH with almost no additional risk. The result: virtually all ETH holders would deposit into Rocket Pool, either becoming Node Operators (posting a 2 ETH bond and receiving delegated capital) or holding rETH (purely passive yield).

Calculating the Cost of Attack

Under this assumption, how much would it cost an attacker to acquire 1/3 of all stake?

Since Delegators only provide capital with no voting power, attackers only need to capture 1/3 of Node Operator bonds. The math:

Assumed total ETH supply (per the article): ~100 million ETH
Rocket Pool bond ratio: 2:32 (Node Operator posts 2 ETH, delegated capital is 30 ETH)
→ Of every 32 ETH staked, only 2 ETH is the Node Operator's bond
→ Node Operator bonds as a share of total ETH = 2/32 = 6.25%
→ Total Node Operator bonds = 100M × 6.25% = 6.25M ETH
To get 1/3 of voting power:
→ Cost of attack = 6.25M ETH × 1/3 ≈ 2.08M ETH

# Counterfactual: What If Delegation Didn’t Exist? #

Now imagine a different world: no LSPs or delegation mechanisms, but the minimum staking deposit is reduced from 32 ETH to 2 ETH, and total staked ETH is capped at 6.25M ETH.

What’s the cost of attack? To acquire 1/3 of all stake, an attacker still needs 2.08M ETH — exactly the same as the world with delegation.

# Conclusion: Delegation as a Rube Goldberg Machine #

From a pure security standpoint, the two worlds are identical. Delegation adds complexity in the form of a full LSP ecosystem, but if Delegators are just passively providing capital, it’s a Rube Goldberg Machine: an elaborate contraption that achieves the exact same outcome as a much simpler design.

This isn’t an argument for eliminating LSPs. It’s pointing out a fundamental design requirement: 「delegators should be doing something that actually matters」— otherwise their presence only adds complexity without delivering corresponding security or decentralization benefits. This is the core problem Vitalik sets out to explore next.

Two Possible Roles for Delegators

Vitalik proposes two directions:

1. Delegate Selection: Let Delegators easily choose — and switch — which Node Operator they delegate to. Today, cross-pool competition is weak because smaller LSPs’ LSTs have three structural disadvantages: poor liquidity, hard to trust, and limited application support. Vitalik proposes targeted fixes for each:

• Cap slashing penalties (targets “poor liquidity” and “hard to trust”): If the slashing cap is reduced to 2–4 ETH, the remaining ETH becomes non-slashable and can be instantly deposited and withdrawn. Even small LSPs could offer LSTs that are instantly redeemable 1:1 for ETH, dramatically lowering the barrier to hold them.
• A unified LST issuance contract (targets “limited application support”): Similar to how ERC-4337 standardized smart wallets, a central LST issuance contract would give any LST issued through it a verifiable safety guarantee. Applications could then support all compliant LSTs rather than just stETH.
• Enshrined delegation (protocol-native support): Baking the above logic directly into the protocol instead of relying on smart contracts.

Vitalik also notes in the original article:「 token voting governance sucks」. Any form of unincentivized delegate selection is ultimately just token voting, which has well-known failure modes. This is why he believes delegate selection alone isn’t enough — it needs to be paired with light consensus participation to actually work.

2. Consensus Participation: This is the more important direction. Vitalik proposes several “small-staker roles”:

• Chain head checks: Each slot, 10,000 small stakers are randomly selected to signal their view of the chain head. If their fork choice diverges from the Node Operators’, clients refuse to accept any block as finalized, forcing community intervention.
• Dual-key signing: A Delegator can proactively declare themselves online, becoming the Quick key (Q key) holder for the next hour. A message from a Node Operator is only valid if it carries both the node’s Persistent key (P key) and the randomly selected Delegator’s Q key — making Delegators a real-time check on Node Operator behavior.
• Inclusion List (IL) providers: Randomly selected small stakers construct ILs, forcing blocks to include certain transactions — this is the direct predecessor to the light service concept in Rainbow Staking.

These roles share three properties: no requirement to participate every slot, no slashing risk, no need for a full node (a browser extension could suffice). Their shared goal is to prevent a 51% majority of Node Operators from censoring transactions. That said, Vitalik’s article doesn’t prescribe a specific solution — it’s more of a problem statement with some candidate directions.

Bringing It Together: Barnabé’s Rainbow Staking Framework (2024)

From Monolith to Microservices: The Architecture Redesign and Four Dimensions

In February 2024, EF researcher Barnabé Monnot published Unbundling staking: Towards rainbow staking. Building on Vitalik’s foundation, this paper integrates the scattered ideas into a coherent framework.

The core idea maps cleanly to a software engineering analogy: when a monolithic application grows too large and complex, you break it into microservices — each service does one thing, communicates through standard interfaces, and the overall system becomes more robust. Rainbow Staking applies the same thinking to Ethereum’s consensus layer.

The design can be understood along four dimensions:

1. Architecture: From “Two-Tier” to “Four Quadrants”
   Vitalik’s proposal was primarily a “Heavy/Light” two-tier model. Barnabé fully “microservices-ifies” it by formally separating Operators from Delegators at the base protocol level. This decouples capital provision from technical operation across all service tiers.
2. Reward Curves: From Rough Intuition to 2-D MVI
   Vitalik’s version only roughly discussed the possibility of setting different return rates for the two tiers. Barnabé splits total issuance into heavy services and light services — letting the protocol dynamically adjust yields based on participation ratios across roles. He also formally defines light LSTs as a non-fungible protocol object, distinct from the market-driven LST derivatives we have today.
3. Separating Execution: Integrating APS
   Vitalik’s version still assumed validators handle both block building and attestation. Barnabé goes further by decoupling Execution Services from consensus validation — a step toward Attester-Proposer Separation (APS).
4. Formalizing Light Staker Duties: Binding IL to the Role
   Barnabé explicitly defines censorship resistance as the core output of light Services, and formally binds the IL mechanism (today’s FOCIL) to the responsibilities of light stakers — letting light nodes focus on being censorship-resistance gatekeepers rather than participating in heavy block validation.

The Four-Quadrant Matrix: Two Dimensions, Four Roles

Rainbow Staking cuts the staking mechanism along two dimensions:

• X-axis (Service Type):
  - Heavy services require top-tier hardware and significant capital, responsible for “economic finality.”
  - Light services are accessible with consumer hardware, responsible for “censorship resistance.”
• Y-axis (Role Type):
  - Operators run the nodes.
  - Delegators provide capital and earn yield.

Heavy Staking (Heavy services)

# Role: The Foundation of Economic Finality #

The core of heavy services is Gasper — Ethereum’s consensus mechanism, combining FFG finality and LMD-GHOST fork choice. It answers the most fundamental question: “Which chain is the canonical chain?”

Gasper’s security relys on the slashing mechanism: if an Operator attempts to break FFG safety (e.g. double voting on conflicting checkpoints), their entire stake gets burned by the protocol.

Heavy services require:

• High-end servers and high bandwidth: Under SSF, each of the 8,192 seats must sign reliably and on time every slot.
• Sufficient capital: Through an LSM-style partial collateralization mechanism, an Operator only needs to post a fraction of the capital themselves — the rest comes from Delegators.
• Tolerance for slashing risk: Any mistake can result in loss of principal.

# Who Should Participate? #

Professional institutions will naturally dominate heavy services — they have the infrastructure, capital management experience, and operational scale.

Solo stakers who want to participate can do so through two mechanisms:

Mechanism 1: Partial Pool

Borrowing from Cosmos LSM (Liquid Staking Module), Operators don’t need to post the full stake themselves — Delegators fill the gap. Using a middle-ground ratio between Rocket Pool’s 1:3 and LSM’s default 1:250, Barnabé uses roughly 1:100. The delegation relationship is recorded as an LSM Share at the protocol level:

Operator posts: ~36 ETH (bond — first to be slashed if something goes wrong)
Delegator provides: ~3,626 ETH (delegated — partially protected)
Total: ~3,662 ETH → one SSF seat

Mechanism 2: DVT (Distributed Validator Technology)

DVT lets multiple small nodes collectively form a “virtual Operator” using threshold signatures, presenting as a single validator to the protocol:

The original BLS private key is split into multiple key shares distributed across nodes. Any M-of-N nodes can produce a valid signature, and no single node ever holds the complete key. This solves two problems: single points of failure (the validator keeps running if some nodes go offline) and private key exposure risk.

The minimum stake requirement per DVT node is not defined at the protocol level, and there’s a tradeoff:

• No minimum: Maximum decentralization, but higher Sybil attack risk (an attacker can flood the DVT pool with zero-cost nodes to control the virtual Operator)
• Higher minimum: Better Sybil resistance, but excludes small stakers — contradicting the goal of keeping solo stakers in the heavy layer

Rainbow Staking’s position: let LSPs handle this at the market layer. LSPs will design their own DVT pool admission rules to protect LST credibility (e.g. requiring each node to post a minimum bond). The protocol just needs to make DVT technically feasible — no need to mandate specific minimums.

# How Heavy LSTs Are Born: From Enshrinement to Market Competition #

Before explaining how heavy LSTs are created, let’s clear up a common misconception: Enshrined LST does not mean Ethereum itself issues an “official stETH.” The protocol doesn’t print tokens.

“Enshrine” means: letting the protocol see and manage the delegation relationship, so that LST minting is built on protocol-recognized infrastructure rather than purely on external smart contracts.

What’s the problem today?

When you deposit ETH into Lido, the entire delegation relationship lives inside Lido’s smart contract. The Ethereum protocol only sees “someone staked ETH and a validator was activated” — it has no visibility into who the actual Delegator is (you) or who the actual Operator is (Lido’s node). This makes it hard to implement fast Operator switching, a level playing field for LSPs, and protocol-level prevention of dominant market positions.

# The Enshrinement Solution: Making Delegation Visible to the Protocol #

Rainbow Staking draws on the Cosmos LSM design and proposes introducing a standardized delegation record object at the protocol layer, conceptually like this:

class Share:
amount: Gwei
owner: address # who the Delegator is
heavy_operator: address # which heavy Operator they're delegating to
light_operator: address # which light Operator (optional)

With this structure, the protocol can “see” the Delegator–Operator separation, enabling:

• Fast Re-delegation: Switch Operators without waiting through an unbonding period
• A level playing field for LSPs: Any LSP can build on top of this standardized base — the market becomes more open
• Light service integration: The same Share has a field reserved for light operators, so Delegators can participate in light services through the same mechanism in the future without needing a separate delegation system

# The Full Capital Flow for Heavy LSTs #

1. Delegator deposits ETH
2. Protocol mints an LSM Share (recording: who delegated, to which Operator, how much)
3. Delegator registers the Share as delegated to their chosen LSP
4. LSP aggregates Shares from multiple operators and screens operator composition per its own rules (e.g. at least 20% from DVT nodes, no single Operator holding more than 10%)
5. LSP mints fungible heavy LSTs (e.g. stETH, rETH)
6. Delegator holds the heavy LST and can use it freely in DeFi

The key insight: the protocol provides a standardized base layer (the LSM Share mechanism). Any LSP can build its own product on top.

LST Credibility Becomes the Core Competitive Dimension

In this architecture, LSPs compete less on fees and more on LST credibility — the market evaluates whether an LSP’s Operator set is diverse enough and resilient to slashing. An LSP backed by DVT nodes and solo stakers will be perceived as safer, attracting more delegation. The protocol doesn’t need to judge who is “decentralized enough” — the market and Delegators’ re-delegation choices will do the filtering.

Light Staking (Light Services)

Light services aren’t about economic security — they’re about censorship resistance. Their security comes from preference entropy.

The image above is from the original paper. Preference entropy represents geographic diversity. Why does this matter? Nodes in different regions under different legal jurisdictions observe different mempool states. Even if nodes in one country filter certain transactions due to local regulations, nodes elsewhere will still surface them. The geographic dispersion of solo stakers — typically a disadvantage — becomes a core competitive strength here.

# Light LSTs: Protocol Objects, Not Market Products #

Delegators who deposit ETH to light services receive light LSTs, but these are fundamentally different from heavy LSTs:

• Per-operator non-fungible: Delegating to Operator A gives you LightETH-A. Delegating to Operator B gives you LightETH-B. They are not equivalent.
• Trustless: Since an Operator’s slashing exposure is capped to their own bond, Delegators can never lose their principal — even when delegating to a completely unknown solo staker.
• Value internalized: Performance differences between operators (commission rates, service quality) are reflected directly in each light LST’s yield.

Barnabé also points out that Ethereum already has a precedent for light services: the Sync Committee is a rotating light service that accounts for roughly 3.5% of total network issuance. The service type differs (helping light clients sync vs. censorship resistance), but the pattern of “protocol incentivizing a light service through issuance” already exists.

Strong Coupling vs. Weak Coupling: The Power Relationship Between Light and Heavy Services

The Rainbow Staking paper discusses two options for how the output of light services (ILs) should constrain heavy operators:

• Strong coupling: Heavy operators are required to include the light certificate(*) proposed by a light committee in their blocks — otherwise the block is invalid. This forces heavy services to respect the light layer’s output, but introduces a liveness risk: if the light layer is attacked or goes offline, the entire chain halts.
• Weak coupling: Heavy operators are incentivized (but not required) to include light certificates. In the worst case this degrades to the status quo, but it leaves behind an objective, attributable artifact for accountability.

Barnabé’s paper leans toward weak coupling. However, the current FOCIL implementation takes a hybrid approach: strong enforcement on transaction inclusion (a block that ignores a known IL is invalid), but weak coupling on liveness (if no ILs are received before the view freeze deadline, the network safely degrades to normal block production without stalling).

* In the current design, light certificate refers to the IL.

Going Live: FOCIL — A Protocol-Level Censorship Resistance Weapon

With the theoretical framework in place, let’s look at the actual implementation of light service censorship resistance: Fork-choice enforced Inclusion Lists (FOCIL, EIP-7805). FOCIL is scheduled to ship in the Hegotá upgrade later this year.

The Slot Timeline and View Freeze Deadline

FOCIL’s design is elegant. It exploits the time segments within a 12-second slot to allow IL construction and the block building process to run concurrently within the same slot, rather than with a one-slot delay. Let’s walk through the timeline:

Slot N:

• t = 0s — A new slot begins. Receive the block from the previous slot, confirm the head.
• t = 0 ~ 8s — 16 IL Committee members each independently scan the mempool, construct their IL, and broadcast it. (Max size per IL: 8 KiB)
• t = 9s — View Freeze Deadline. All nodes stop accepting new ILs. Each node's IL set is now locked to whatever it has received up to this point.

Slot N+1:

• t = 0s — A block proposer broadcasts the new block (must include all transactions from the ILs it received).
• t = 4s — Attestation deadline. Attesters only vote for blocks that satisfy all IL conditions. If a block is missing IL transactions without a valid exemption, Attesters reject it outright.

The critical piece here is the View Freeze Deadline (t=9s). Without it, a builder could intentionally “forget” ILs it doesn’t like at t=11s, claiming network delay, and use that as cover to bypass censorship constraints. With this hard deadline, attesters and builders are forced to agree on which ILs are valid.

This also ties back to the strong/weak coupling discussion: FOCIL doesn’t offer extra rewards for IL Committee participation (no additional strong coupling incentive), but the view freeze at t=9s means a node might only receive 10 out of 16 ILs — or none at all — due to network conditions. The chain doesn’t stall waiting for all 16. It works with whatever was received before the deadline.

Core Design Principles

• Committee-based: 16 randomly selected nodes each independently construct an IL. An attacker would need to simultaneously bribe or coerce all 16 to successfully censor a transaction. As long as one honest node includes a transaction in its IL, that transaction must be included in the block.
• Fork-choice enforced: LMD-GHOST rules are modified so that blocks failing to satisfy ILs are rejected by attesters. A builder whose block gets invalidated loses its MEV revenue for that slot entirely.
• Conditional inclusion: Inclusion isn’t blind. Exemptions exist — for example, if the block is full (insufficient gas) or the transaction itself has become invalid (nonce conflict, insufficient balance).
• Anywhere-in-block: IL transactions can appear anywhere in the block. Builders retain ordering rights — the most profitable part of their role — which significantly reduces their incentive to circumvent the mechanism.
• No direct rewards: Participating in the IL committee does not earn additional protocol issuance. It relies on altruistic behavior, which keeps implementation complexity low.

IL Validity Checking: Deep EL–CL Cooperation

Unlike previous proposals, FOCIL requires the Execution Layer (EL) and Consensus Layer (CL) to work closely together — the most complex part of the implementation.

• Consensus Layer: Verifies IL signatures, committee membership eligibility, the 8 KiB size limit, and strictly prevents any committee member from broadcasting two different ILs for the same slot.
• Execution Layer: After receiving a new execution payload, EL checks each IL transaction to see if it was included. If a transaction is missing, the EL checks: is the nonce still valid? Is the balance sufficient? Is there remaining gas space in the block? If all three conditions are satisfied but the transaction is not included, EL returns INCLUSION_LIST_UNSATISFIED to CL, and CL rejects the block.

Looking Ahead: How Rainbow Staking Enables SSF

With FOCIL’s mechanics covered, let’s zoom out. In Paths to SSF revisited, published in March 2025, Barnabé identifies a key insight: Rainbow Staking has gained traction in the research community largely because it resolves the hardest decentralization problem on the path to SSF.

The Real SSF Threshold: Not 3,662 ETH, But Not Guaranteed to Be 32 ETH Either

The 3,662 ETH figure from the first section was a theoretical upper bound derived from an extreme assumption — 1/4 of all ETH supply staked. Paths to SSF revisited gives a more grounded estimate.

Based on 2024 data, the network has roughly 12,000 nodes total. Around 5,000 of them are not connected to any attestation subnet, suggesting they likely aren’t staking nodes. That leaves approximately 7,000 staking nodes. If these nodes fully consolidate their stake, the 8,192-seat cap means the average stake per seat roughly matches today’s levels — the minimum threshold could stay near 32 ETH.

However, Barnabé is explicit that this is the optimistic scenario. In practice, nodes may not voluntarily consolidate. And with a target slot time of 4 seconds, the required number of seats may be well below 8,192. In that case, the minimum threshold would exceed 32 ETH — by how much depends on the degree of consolidation and what performance targets are prioritized.

The point is: existing solo stakers aren’t necessarily locked out, but they’re not guaranteed to stay in either. This uncertainty is exactly what makes the path choice so consequential.

The Classic Tradeoff: Performance vs. Decentralization

High-TPS chains have historically solved this by just capping the validator count — fewer validators, easier to coordinate. But this conflicts with Ethereum’s decentralization ethos. SSF faces the same tension, and without role separation, there are only two paths forward:

• Path A (Orbit): Design a new seat allocation mechanism that lets small stakers participate directly, preserving as much space for solo stakers as possible. The cost is high development complexity. Orbit’s consolidation incentive mechanism still has unresolved economic issues, and SSF timelines would slip significantly.
• Path B (Capped Validator Set): Accept the higher threshold reality. Only the top-N nodes by stake are active validators. The protocol is simpler, and SSF can ship on a timeline compatible with Lean Consensus. But the obvious problem is centralization: a validator set dominated by institutional operators would face significant censorship risk under regulatory pressure.

Rainbow Staking’s Answer: Decouple Finality from Transaction Inclusion

Rainbow Staking’s four-quadrant framework offers a different way to think about this: finalizing the chain (heavy services) and guaranteeing transactions get included (light services) are two distinct problems that can be handled by different types of participants.

This separation gives Path B a way to patch its censorship resistance gap. In Paths to SSF revisited, Barnabé formally introduces Light FOCIL. The barrier to entry is minimal — anyone willing to run a node can serve as a light includer. As long as one of the 16 IL committee members is honest, censorship resistance holds.

In one sentence: we may not get a 1 ETH validator, but Rainbow Staking makes a 1 ETH includer possible.

The research community is currently moving toward Path B + Rainbow Staking. Path B’s biggest risk — declining censorship resistance — is addressed by Light FOCIL. Rainbow Staking’s heavy layer design (LSM + DVT) also gives solo stakers who can’t get a direct seat ways to participate indirectly. Meanwhile, Orbit’s complexity has been significantly underestimated, and its timeline is too uncertain to commit to right now.

Without Rainbow Staking’s heavy/light service separation, Path B’s decentralization argument falls apart, and SSF’s timeline becomes anyone’s guess. Rainbow Staking is not just an ideal end state after SSF — it’s a necessary precondition for SSF to arrive on a reasonable timeline.

Implications: DeFi Ecosystem Restructuring

Rainbow Staking’s protocol-level changes have implications beyond core protocol developers. For DApp developers and the broader DeFi ecosystem, it’s a ground-up restructuring of underlying assumptions.

LST Lego Gets Restructured

DeFi protocols have long relied on stETH as a base collateral asset — best liquidity, widest integration. After Rainbow Staking, staking tokens will split into two fundamentally different forms:

Heavy LST

• Liquid and freely usable across DeFi.
• Represents shared exposure to Gasper slashing risk.
• Competition shifts toward credibility — diversity of operators composition and resilience to slashing events.
• Analogous to today’s stETH and rETH, but competing within a more complete protocol-level standard.

Light LST

• A protocol object, not a market product.
• Per-operator non-fungible (e.g. LightETH-Obol ≠ LightETH-SSV).
• Represents a stake delegated to a specific light operator — crucially, carries no slashing risk.
• More like a risk-free yield receipt than a circulating currency.

Practical Impact for Developers:

This isn’t “old stETH disappears” — it’s fragmentation and specialization of asset types. Developers need completely different risk models for each:

• Lending protocols: Liquidation parameters need revisiting. Heavy LSTs carry slashing risk and warrant more conservative LTVs. Light LSTs have guaranteed principal but are non-fungible, requiring a completely different liquidity assessment approach.
• AMMs / Vaults: Expect more competitive liquidity fragmentation across heavy LSTs. Light LSTs lack a universal standard and are structurally difficult to route into deep liquidity pools.
• Yield Aggregators: Will need logic to dynamically reallocate between the heavy and light layers, significantly increasing strategy complexity.

Challenges and Closing Thoughts

Open Challenges

This framework has a clear vision, but several hard problems remain:

1. Complexity explosion: Going from “one validator does everything” to a four-quadrant role separation dramatically increases protocol specification complexity. Each new mechanism (LSM, DVT) is a new potential attack surface.
2. Centralization economies of scale in the heavy layer: Even with partial collateralization, professional institutions still have significant advantages in heavy services — better hardware, lower operational costs, stronger reputations. Rainbow Staking can reduce this but not eliminate it.
3. Light LST liquidity problem: The per-operator non-fungibility that keeps the kight layer pure also makes these assets structurally difficult to integrate into DeFi. How to balance “protocol object” with “usable asset” remains an open question.
4. SSF seat competition incentive distortion: Large LSPs may try to split their operators into more units to occupy more SSF seats, crowding out solo stakers. Designing effective countermeasures at the protocol level is still an open problem.

Closing: A Paradigm Shift in Consensus Layer Architecture

Rainbow Staking represents Ethereum asking a fundamental question:

The current monolithic architecture bundles capital, hardware, and technical expertise together — only those with all three can participate meaningfully. That design effectively outsources the “who gets to participate” question to the market, and the market’s answer is almost always “whoever has the most capital.”

Rainbow Staking takes a different approach: acknowledge that different participants have different comparative advantages, and design service types and incentive mechanisms that match each. Let institutional capital efficiency serve heavy layer security. Let solo stakers’ geographic dispersion and diverse preferences serve light layer censorship resistance. These aren’t competing forces — they’re complementary.

From Vitalik’s question in 2023, to Barnabé’s four-quadrant framework in 2024, to FOCIL shipping on mainnet in 2026 — this is more than an engineering optimization. It’s a design philosophy for how a decentralized network should be organized: not everyone doing the same thing, but everyone doing what they’re best at, together holding up something more resilient.

References:

• Protocol and staking pool changes that could improve decentralization and reduce consensus overhead — Vitalik Buterin, Oct 2023
• Unbundling staking: Towards rainbow staking — Barnabé Monnot, Feb 2024
• Paths to SSF revisited — Barnabé Monnot, Mar 2025
• EIP-7805: Fork-choice enforced Inclusion Lists (FOCIL)
• Sticking to 8192 signatures per slot post-SSF — Vitalik Buterin
• Orbit SSF: solo-staking-friendly validator set management for SSF
• Gemini Deep Research

Rainbow Staking: Ethereum’s Next Evolution in Staking was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.