This article was co-written by AI and the author. The final output was reviewed and refined by the\u00a0author.<\/p>\n
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\u2019re going to talk about one of the latest staking mechanism designs: Rainbow\u00a0Staking<\/strong><\/a>.<\/p>\n Generated by\u00a0AI<\/p>\n 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:<\/p>\n Block Proposal<\/strong>: Takes turns constructing and broadcasting new\u00a0blocks.Attestation<\/strong>: Votes on the chain head and finality checkpoints.Sync Committee<\/strong>: Rotates periodically to help light clients sync to the latest chain\u00a0state.<\/p>\n This looked simple and straightforward at first. But as Ethereum\u2019s ambitions grew, the \u201cone validator does everything\u201d architecture ran into two unavoidable systemic bottlenecks.<\/p>\n # Bottleneck 1: The Physical Limits of Performance and Hardware\u00a0#<\/strong><\/p>\n Ethereum\u2019s next major goal is SSF (Single-Slot Finality(*))<\/strong>: finalizing a block within one slot (12 seconds), rather than the current 2 epochs (~12.8 minutes).<\/p>\n The core technical challenge of SSF is signature aggregation<\/strong>. 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<\/strong> (see Sticking to 8192 signatures\u2026<\/a>), making aggregation feasible within the time\u00a0limit.<\/p>\n But this comes at a steep\u00a0cost:<\/p>\n Assuming staking target = 1\/4 of total ETH supply \u2248 30 million ETH This threshold effectively locks out most home node operators and solo stakers. The price of performance is a step backward for decentralization.<\/p>\n * <\/em>A previous article<\/em><\/a> 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\u2019ll use SSF throughout, and subsequent mentions of SSF carry the same\u00a0meaning.<\/em><\/p>\n # Bottleneck 2: Capital Monopoly and the LST Threat\u00a0#<\/strong><\/p>\n The 32 ETH staking threshold has never been accessible to everyone. So the market naturally gave rise to Liquid Staking Protocols (LSPs)<\/strong> to address this: users don\u2019t need to gather 32 ETH\u200a\u2014\u200athey 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.\u00a0stETH)<\/strong>.<\/p>\n LSTs dramatically improved capital efficiency\u200a\u2014\u200aa user\u2019s 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.<\/p>\n But this created a dual centralization<\/strong> problem:<\/p>\n Capital centralization<\/strong>: Lido at one point controlled over 32% of all staked ETH, giving it disproportionate influence over Gasper consensus.Node centralization<\/strong>: LSPs select their own Node Operators, leaving ordinary users with no say in who is actually running the nodes they delegate\u00a0to.<\/p>\n When a single LST reaches a high enough market share, it effectively replaces ETH as the \u201creserve asset\u201d of the Ethereum ecosystem\u200a\u2014\u200athreatening ETH\u2019s monetary role and undermining the protocol\u2019s credible neutrality.<\/p>\n The high threshold introduced by SSF<\/strong> and the centralization driven by LSTs<\/strong>\u200a\u2014\u200athese two bottlenecks are the starting point for all the design changes that\u00a0follow.<\/p>\n In October 2023, Vitalik published an article<\/a>. Rather than directly solving the bottlenecks above, he asked a more fundamental question:<\/p>\n from the protocol\u2019s perspective, what is the point of having delegators at\u00a0all?<\/p>\n To understand why Delegators must do something meaningful, Vitalik constructed a thought experiment to show why \u201cDelegators who only provide capital passively\u201d add nothing to network security.<\/p>\n # Setting the Premise: A \u201cNear-Perfect\u201d LSP World\u00a0#<\/strong><\/p>\n 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\u200a\u2014\u200aa lower barrier to running a node means more operators can join. Under this setup, even if a Node Operator gets fully slashed, Delegators lose\u00a0nothing.<\/p>\n 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\u00a0yield).<\/p>\n Calculating the Cost of\u00a0Attack<\/strong><\/p>\n Under this assumption, how much would it cost an attacker to acquire 1\/3 of all\u00a0stake?<\/p>\n Since Delegators only provide capital with no voting power, attackers only need to capture 1\/3 of Node Operator bonds. The\u00a0math:<\/p>\n Assumed total ETH supply (per the article): ~100 million ETH<\/p>\n Rocket Pool bond ratio: 2:32 (Node Operator posts 2 ETH, delegated capital is 30 ETH) To get 1\/3 of voting power: # Counterfactual: What If Delegation Didn\u2019t Exist?\u00a0#<\/strong><\/p>\n 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\u00a0ETH.<\/p>\n What\u2019s the cost of attack? To acquire 1\/3 of all stake, an attacker still needs 2.08M ETH<\/strong>\u200a\u2014\u200aexactly the same as the world with delegation.<\/p>\n # Conclusion: Delegation as a Rube Goldberg Machine\u00a0#<\/strong><\/p>\n 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\u2019s a Rube Goldberg Machine<\/strong>: an elaborate contraption that achieves the exact same outcome as a much simpler\u00a0design.<\/p>\n This isn\u2019t an argument for eliminating LSPs. It\u2019s pointing out a fundamental design requirement: \u300cdelegators should be doing something<\/em> that actually matters<\/strong>\u300d\u2014 otherwise their presence only adds complexity without delivering corresponding security or decentralization benefits.<\/strong> This is the core problem Vitalik sets out to explore\u00a0next.<\/p>\n Vitalik proposes two directions:<\/p>\n 1. Delegate Selection<\/strong>: Let Delegators easily choose\u200a\u2014\u200aand switch\u200a\u2014\u200awhich Node Operator they delegate to. Today, cross-pool competition is weak because smaller LSPs\u2019 LSTs have three structural disadvantages: poor liquidity, hard to trust, and limited application support. Vitalik proposes targeted fixes for\u00a0each:<\/p>\n Cap slashing penalties<\/strong> (targets \u201cpoor liquidity\u201d and \u201chard to trust\u201d): If the slashing cap is reduced to 2\u20134 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\u00a0them.A unified LST issuance contract<\/strong> (targets \u201climited application support\u201d): 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\u00a0stETH.Enshrined delegation<\/strong> (protocol-native support): Baking the above logic directly into the protocol instead of relying on smart contracts.<\/p>\n Vitalik also notes in the original article:\u300c token voting governance sucks\u300d<\/strong>. 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\u2019t enough\u200a\u2014\u200ait needs to be paired with light consensus participation to actually\u00a0work.<\/p>\n 2. Consensus Participation<\/strong>: This is the more important direction. Vitalik proposes several \u201csmall-staker roles\u201d:<\/p>\n Chain head checks<\/strong>: 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\u2019, clients refuse to accept any block as finalized, forcing community intervention.Dual-key signing<\/strong>: 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\u2019s Persistent key (P key)<\/strong> and the randomly selected Delegator\u2019s Q key<\/strong>\u200a\u2014\u200amaking Delegators a real-time check on Node Operator behavior.Inclusion List (IL) providers<\/strong>: Randomly selected small stakers construct ILs, forcing blocks to include certain transactions\u200a\u2014\u200athis is the direct predecessor to the light service concept in Rainbow\u00a0Staking<\/strong>.<\/p>\n 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)<\/strong>. Their shared goal is to prevent a 51% majority of Node Operators from censoring transactions<\/strong>. That said, Vitalik\u2019s article doesn\u2019t prescribe a specific solution\u200a\u2014\u200ait\u2019s more of a problem statement with some candidate directions.<\/p>\n In February 2024, EF researcher Barnab\u00e9 Monnot published Unbundling staking: Towards rainbow staking<\/em><\/a>. Building on Vitalik\u2019s foundation, this paper integrates the scattered ideas into a coherent framework.<\/p>\n The core idea maps cleanly to a software engineering analogy: when a monolithic application grows too large and complex, you break it into microservices\u200a\u2014\u200aeach service does one thing, communicates through standard interfaces, and the overall system becomes more robust. Rainbow Staking applies the same thinking to Ethereum\u2019s consensus layer.<\/p>\n The design can be understood along four dimensions:<\/p>\n Architecture: From \u201cTwo-Tier\u201d to \u201cFour Quadrants\u201d Rainbow Staking cuts the staking mechanism along two dimensions:<\/p>\n X-axis (Service Type)<\/strong>: # Role: The Foundation of Economic Finality\u00a0#<\/strong><\/p>\n The core of heavy services is Gasper<\/strong>\u200a\u2014\u200aEthereum\u2019s consensus mechanism, combining FFG finality and LMD-GHOST fork choice. It answers the most fundamental question: \u201cWhich chain is the canonical chain?\u201d<\/strong><\/p>\n Gasper\u2019s security relys on the slashing mechanism<\/strong>: if an Operator attempts to break FFG safety (e.g. double voting on conflicting checkpoints), their entire stake gets burned by the protocol.<\/p>\n Heavy services\u00a0require:<\/p>\n High-end servers and high bandwidth<\/strong>: Under SSF, each of the 8,192 seats must sign reliably and on time every\u00a0slot.Sufficient capital<\/strong>: Through an LSM-style partial collateralization mechanism, an Operator only needs to post a fraction of the capital themselves\u200a\u2014\u200athe rest comes from Delegators.Tolerance for slashing risk<\/strong>: Any mistake can result in loss of principal.<\/p>\n # Who Should Participate? #<\/strong><\/p>\n Generated by\u00a0AI<\/p>\n Professional institutions will naturally dominate heavy services\u200a\u2014\u200athey have the infrastructure, capital management experience, and operational scale.<\/p>\n Solo stakers who want to participate can do so through two mechanisms:<\/p>\n Mechanism 1: Partial\u00a0Pool<\/strong><\/p>\n Borrowing from Cosmos LSM (Liquid Staking Module)<\/a>, Operators don\u2019t need to post the full stake themselves\u200a\u2014\u200aDelegators fill the gap. Using a middle-ground ratio between Rocket Pool\u2019s 1:3 and LSM\u2019s default 1:250, Barnab\u00e9 uses roughly 1:100. The delegation relationship is recorded as an LSM Share at the protocol\u00a0level:<\/p>\n Operator posts: ~36 ETH (bond \u2014 first to be slashed if something goes wrong) Mechanism 2: DVT (Distributed Validator Technology)<\/strong><\/p>\n DVT lets multiple small nodes collectively form a \u201cvirtual Operator\u201d using threshold signatures<\/strong>, presenting as a single validator to the protocol:<\/p>\n Generated by\u00a0AI<\/p>\n The original BLS private key is split into multiple key shares<\/strong> 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\u00a0risk.<\/p>\n The minimum stake requirement per DVT node is not defined at the protocol level<\/strong>, and there\u2019s a tradeoff:<\/p>\n No minimum<\/strong>: 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<\/strong>: Better Sybil resistance, but excludes small stakers\u200a\u2014\u200acontradicting the goal of keeping solo stakers in the heavy\u00a0layer<\/p>\n Rainbow Staking\u2019s position: let LSPs handle this at the market layer<\/strong>. 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\u200a\u2014\u200ano need to mandate specific minimums.<\/p>\n # How Heavy LSTs Are Born: From Enshrinement to Market Competition #<\/strong><\/p>\n Before explaining how heavy LSTs are created, let\u2019s clear up a common misconception: Enshrined LST does not mean Ethereum itself issues an \u201cofficial stETH.\u201d<\/strong> The protocol doesn\u2019t print\u00a0tokens.<\/p>\n \u201cEnshrine\u201d means: letting the protocol see and manage the delegation relationship<\/strong>, so that LST minting is built on protocol-recognized infrastructure rather than purely on external smart contracts.<\/p>\n What\u2019s the problem\u00a0today?<\/strong><\/p>\n When you deposit ETH into Lido, the entire delegation relationship lives inside Lido\u2019s smart contract. The Ethereum protocol only sees \u201csomeone staked ETH and a validator was activated\u201d\u200a\u2014\u200ait has no visibility into who the actual Delegator is (you) or who the actual Operator is (Lido\u2019s node). This makes it hard to implement fast Operator switching, a level playing field for LSPs, and protocol-level prevention of dominant market positions.<\/p>\n # The Enshrinement Solution: Making Delegation Visible to the Protocol\u00a0#<\/strong><\/p>\n Rainbow Staking draws on the Cosmos LSM design and proposes introducing a standardized delegation record object at the protocol layer, conceptually like\u00a0this:<\/p>\n class Share: With this structure, the protocol can \u201csee\u201d the Delegator\u2013Operator separation, enabling:<\/p>\n Fast Re-delegation<\/strong>: Switch Operators without waiting through an unbonding periodA level playing field for LSPs<\/strong>: Any LSP can build on top of this standardized base\u200a\u2014\u200athe market becomes more\u00a0openLight service integration<\/strong>: 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<\/p>\n # The Full Capital Flow for Heavy LSTs\u00a0#<\/strong><\/p>\n Generated by\u00a0AIDelegator deposits\u00a0ETHProtocol mints an LSM Share (recording: who delegated, to which Operator, how\u00a0much)Delegator registers the Share as delegated to their chosen\u00a0LSPLSP 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\u00a010%)LSP mints fungible heavy LSTs (e.g. stETH,\u00a0rETH)Delegator holds the heavy LST and can use it freely in\u00a0DeFi<\/p>\n The key insight: the protocol provides a standardized base layer (the LSM Share mechanism)<\/strong>. Any LSP can build its own product on\u00a0top.<\/p>\n LST Credibility Becomes the Core Competitive Dimension<\/strong><\/p>\n In this architecture, LSPs compete less on fees and more on LST credibility<\/strong>\u200a\u2014\u200athe market evaluates whether an LSP\u2019s 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\u2019t need to judge who is \u201cdecentralized enough\u201d\u200a\u2014\u200athe market and Delegators\u2019 re-delegation choices will do the filtering.<\/p>\n Light services aren\u2019t about economic security\u200a\u2014\u200athey\u2019re about censorship resistance<\/strong>. Their security comes from preference entropy<\/strong>.<\/p>\n source: https:\/\/ethresear.ch\/uploads\/default\/original\/2X\/d\/d7dbff8196573f5476c3b4ed54e59b20532b1cf2.jpeg<\/a><\/p>\n 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\u200a\u2014\u200atypically a disadvantage\u200a\u2014\u200abecomes a core competitive strength\u00a0here.<\/p>\n # Light LSTs: Protocol Objects, Not Market Products\u00a0#<\/strong><\/p>\n Delegators who deposit ETH to light services receive light LSTs, but these are fundamentally different from heavy\u00a0LSTs:<\/p>\n Per-operator non-fungible<\/strong>: Delegating to Operator A gives you LightETH-A. Delegating to Operator B gives you LightETH-B. They are not equivalent.Trustless<\/strong>: Since an Operator\u2019s slashing exposure is capped to their own bond, Delegators can never lose their principal\u200a\u2014\u200aeven when delegating to a completely unknown solo\u00a0staker.Value internalized<\/strong>: Performance differences between operators (commission rates, service quality) are reflected directly in each light LST\u2019s\u00a0yield.<\/p>\n Barnab\u00e9 also points out that Ethereum already has a precedent for light services: the Sync Committee<\/strong> 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 \u201cprotocol incentivizing a light service through issuance\u201d already\u00a0exists.<\/p>\n The Rainbow Staking paper discusses two options for how the output of light services (ILs) should constrain heavy operators:<\/p>\n Strong coupling<\/strong>: Heavy operators are required to include the light certificate(*)<\/strong> proposed by a light committee in their blocks\u200a\u2014\u200aotherwise the block is invalid. This forces heavy services to respect the light layer\u2019s output, but introduces a liveness risk: if the light layer is attacked or goes offline, the entire chain\u00a0halts.Weak coupling<\/strong>: Heavy operators are incentivized<\/em> (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.<\/p>\n Barnab\u00e9\u2019s paper leans toward weak coupling. However, the current FOCIL implementation takes a hybrid approach: strong enforcement on transaction inclusion<\/strong> (a block that ignores a known IL is invalid), but weak coupling on liveness<\/strong> (if no ILs are received before the view freeze deadline, the network safely degrades to normal block production without stalling).<\/p>\n * In the current design, light certificate refers to the\u00a0IL.<\/em><\/p>\n With the theoretical framework in place, let\u2019s look at the actual implementation of light service censorship resistance: Fork-choice enforced Inclusion Lists (FOCIL, EIP-7805)<\/strong>. FOCIL is scheduled to ship in the Hegot\u00e1 upgrade later this\u00a0year.<\/p>\n FOCIL\u2019s 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<\/strong>, rather than with a one-slot delay. Let\u2019s walk through the timeline:<\/p>\n Slot N:<\/strong><\/p>\n t = 0s\u200a\u2014\u200aA new slot begins. Receive the block from the previous slot, confirm the\u00a0head.t = 0 ~ 8s\u200a\u2014\u200a16 IL Committee members each independently scan the mempool, construct their IL, and broadcast it. (Max size per IL: 8\u00a0KiB)t = 9s\u200a\u2014\u200aView Freeze Deadline<\/strong>. All nodes stop accepting new ILs. Each node’s IL set is now locked to whatever it has received up to this\u00a0point.<\/p>\n Slot N+1:<\/strong><\/p>\n t = 0s\u200a\u2014\u200aA block proposer broadcasts the new block (must include all transactions from the ILs it received).t = 4s\u200a\u2014\u200aAttestation 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.Generated by\u00a0AI<\/p>\n The critical piece here is the View Freeze Deadline (t=9s)<\/strong>. Without it, a builder could intentionally \u201cforget\u201d ILs it doesn\u2019t 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\u00a0valid.<\/p>\n This also ties back to the strong\/weak coupling discussion: FOCIL doesn\u2019t 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\u200a\u2014\u200aor none at all\u200a\u2014\u200adue to network conditions. The chain doesn\u2019t stall waiting for all 16. It works with whatever was received before the deadline.<\/p>\n Committee-based<\/strong>: 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\u00a0block.Fork-choice enforced<\/strong>: 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<\/strong>: Inclusion isn\u2019t blind. Exemptions exist\u200a\u2014\u200afor example, if the block is full (insufficient gas) or the transaction itself has become invalid (nonce conflict, insufficient balance).Anywhere-in-block<\/strong>: IL transactions can appear anywhere in the block. Builders retain ordering rights\u200a\u2014\u200athe most profitable part of their role\u200a\u2014\u200awhich significantly reduces their incentive to circumvent the mechanism.No direct rewards<\/strong>: Participating in the IL committee does not earn additional protocol issuance. It relies on altruistic behavior, which keeps implementation complexity low.<\/p>\n Unlike previous proposals, FOCIL requires the Execution Layer (EL) and Consensus Layer (CL) to work closely together\u200a\u2014\u200athe most complex part of the implementation.<\/p>\n Consensus Layer<\/strong>: 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\u00a0slot.Execution Layer<\/strong>: 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 <\/strong>INCLUSION_LIST_UNSATISFIED to CL, and CL rejects the\u00a0block.<\/strong><\/p>\n With FOCIL\u2019s mechanics covered, let\u2019s zoom out. In Paths to SSF revisited<\/em><\/a>, published in March 2025, Barnab\u00e9 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\u00a0SSF.<\/p>\n The 3,662 ETH figure from the first section was a theoretical upper bound derived from an extreme assumption\u200a\u2014\u200a1\/4 of all ETH supply staked. Paths to SSF revisited<\/em> gives a more grounded estimate.<\/p>\n 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\u2019t staking nodes. That leaves approximately 7,000 staking nodes<\/strong>. If these nodes fully consolidate their stake, the 8,192-seat cap means the average stake per seat roughly matches today\u2019s levels\u200a\u2014\u200athe minimum threshold could stay near 32\u00a0ETH<\/strong>.<\/p>\n However, Barnab\u00e9 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<\/strong>\u200a\u2014\u200aby how much depends on the degree of consolidation and what performance targets are prioritized.<\/p>\n The point is: existing solo stakers aren\u2019t necessarily locked out, but they\u2019re not guaranteed to stay in either. This uncertainty is exactly what makes the path choice so consequential.<\/strong><\/p>\n High-TPS chains have historically solved this by just capping the validator count\u200a\u2014\u200afewer validators, easier to coordinate. But this conflicts with Ethereum\u2019s decentralization ethos. SSF faces the same tension, and without role separation, there are only two paths\u00a0forward:<\/p>\n Path A (Orbit)<\/strong><\/a>: 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\u2019s consolidation incentive mechanism still has unresolved economic issues, and SSF timelines would slip significantly.Path B (Capped Validator Set)<\/strong><\/a>: 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.<\/p>\n Rainbow Staking\u2019s 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.<\/strong><\/p>\n This separation gives Path B a way to patch its censorship resistance gap. In Paths to SSF revisited<\/em>, Barnab\u00e9 formally introduces Light FOCIL<\/strong>. The barrier to entry is minimal\u200a\u2014\u200aanyone 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.<\/p>\n In one sentence: we may not get a 1 ETH validator, but Rainbow Staking makes a 1 ETH includer possible.<\/strong><\/p>\n The research community is currently moving toward Path B + Rainbow Staking<\/strong>. Path B\u2019s biggest risk\u200a\u2014\u200adeclining censorship resistance\u200a\u2014\u200ais addressed by Light FOCIL. Rainbow Staking\u2019s heavy layer design (LSM + DVT) also gives solo stakers who can\u2019t get a direct seat ways to participate indirectly. Meanwhile, Orbit\u2019s complexity has been significantly underestimated, and its timeline is too uncertain to commit to right\u00a0now.<\/p>\n Without Rainbow Staking\u2019s heavy\/light service separation, Path B\u2019s decentralization argument falls apart, and SSF\u2019s timeline becomes anyone\u2019s guess. Rainbow Staking is not just an ideal end state after SSF\u200a\u2014\u200ait\u2019s a necessary precondition for SSF to arrive on a reasonable timeline.<\/strong><\/p>\n Rainbow Staking\u2019s protocol-level changes have implications beyond core protocol developers. For DApp developers and the broader DeFi ecosystem, it\u2019s a ground-up restructuring of underlying assumptions.<\/p>\n DeFi protocols have long relied on stETH as a base collateral asset\u200a\u2014\u200abest liquidity, widest integration. After Rainbow Staking, staking tokens will split into two fundamentally different forms:<\/p>\n Heavy LST<\/strong><\/p>\n Liquid and freely usable across\u00a0DeFi.Represents shared exposure to Gasper slashing\u00a0risk<\/strong>.Competition shifts toward credibility<\/strong>\u200a\u2014\u200adiversity of operators composition and resilience to slashing\u00a0events.Analogous to today\u2019s stETH and rETH, but competing within a more complete protocol-level standard.<\/p>\n Light LST<\/strong><\/p>\n A protocol object<\/strong>, not a market\u00a0product.Per-operator non-fungible<\/strong> (e.g. LightETH-Obol \u2260 LightETH-SSV).Represents a stake delegated to a specific light operator\u200a\u2014\u200acrucially, carries no slashing\u00a0risk<\/strong>.More like a risk-free yield receipt than a circulating currency.<\/p>\n Practical Impact for Developers:<\/strong><\/p>\n This isn\u2019t \u201cold stETH disappears\u201d\u200a\u2014\u200ait\u2019s fragmentation and specialization of asset types. Developers need completely different risk models for\u00a0each:<\/p>\n Lending protocols<\/strong>: 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<\/strong>: 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<\/strong>: Will need logic to dynamically reallocate between the heavy and light layers, significantly increasing strategy complexity.<\/p>\n This framework has a clear vision, but several hard problems\u00a0remain:<\/p>\n Complexity explosion<\/strong>: Going from \u201cone validator does everything\u201d to a four-quadrant role separation dramatically increases protocol specification complexity. Each new mechanism (LSM, DVT) is a new potential attack\u00a0surface.Centralization economies of scale in the heavy layer<\/strong>: Even with partial collateralization, professional institutions still have significant advantages in heavy services\u200a\u2014\u200abetter hardware, lower operational costs, stronger reputations. Rainbow Staking can reduce this but not eliminate it.Light LST liquidity problem<\/strong>: The per-operator non-fungibility that keeps the kight layer pure also makes these assets structurally difficult to integrate into DeFi. How to balance \u201cprotocol object\u201d with \u201cusable asset\u201d remains an open question.SSF seat competition incentive distortion<\/strong>: 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\u00a0problem.<\/p>\n Rainbow Staking represents Ethereum asking a fundamental question:<\/p>\n Who should have the right to participate in consensus?<\/strong><\/p>\n The current monolithic architecture bundles capital, hardware, and technical expertise together\u200a\u2014\u200aonly those with all three can participate meaningfully. That design effectively outsources the \u201cwho gets to participate\u201d question to the market, and the market\u2019s answer is almost always \u201cwhoever has the most capital.\u201d<\/p>\n Rainbow Staking takes a different approach: acknowledge that different participants have different comparative advantages<\/strong>, and design service types and incentive mechanisms that match each. Let institutional capital efficiency serve heavy layer security. Let solo stakers\u2019 geographic dispersion and diverse preferences serve light layer censorship resistance. These aren\u2019t competing forces\u200a\u2014\u200athey\u2019re complementary.<\/p>\n From Vitalik\u2019s question in 2023, to Barnab\u00e9\u2019s four-quadrant framework in 2024, to FOCIL shipping on mainnet in 2026\u200a\u2014\u200athis is more than an engineering optimization. It\u2019s a design philosophy for how a decentralized network should be organized: not everyone doing the same thing, but everyone doing what they\u2019re best at, together holding up something more resilient.<\/strong><\/p>\n References:<\/p>\n Protocol and staking pool changes that could improve decentralization and reduce consensus overhead<\/a>\u200a\u2014\u200aVitalik Buterin, Oct\u00a02023Unbundling staking: Towards rainbow staking<\/a>\u200a\u2014\u200aBarnab\u00e9 Monnot, Feb\u00a02024Paths to SSF revisited<\/a>\u200a\u2014\u200aBarnab\u00e9 Monnot, Mar\u00a02025EIP-7805: Fork-choice enforced Inclusion Lists\u00a0(FOCIL)<\/a>Sticking to 8192 signatures per slot post-SSF<\/a>\u200a\u2014\u200aVitalik\u00a0ButerinOrbit SSF: solo-staking-friendly validator set management for\u00a0SSF<\/a>Gemini Deep\u00a0Research<\/p>\n Rainbow Staking: Ethereum\u2019s Next Evolution in Staking<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":" This article was co-written by AI and the author. The final output was reviewed and refined by the\u00a0author. 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\u2019re […]<\/p>\n","protected":false},"author":0,"featured_media":150697,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-150696","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/150696"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=150696"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/150696\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/150697"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=150696"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=150696"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=150696"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The Concerns After The\u00a0Merge<\/h3>\n
The Status Quo: Ethereum\u2019s Monolithic Validator<\/h4>\n
Two Systemic Bottlenecks<\/h4>\n
Each SSF seat requires: 30M \u00f7 8,192 \u2248 3,662 ETH (~$8M\u00a0USD)<\/em><\/p>\nThe Problem Framed: Vitalik\u2019s Two-Tier Staking Proposal\u00a0(2023)<\/h3>\n
The Core\u00a0Question<\/h4>\n
The \u201cRube Goldberg Machine\u201d Argument for Delegation<\/h4>\n
\u2192 Of every 32 ETH staked, only 2 ETH is the Node Operator’s bond
\u2192 Node Operator bonds as a share of total ETH = 2\/32 = 6.25%
\u2192 Total Node Operator bonds = 100M \u00d7 6.25% = 6.25M ETH<\/p>\n
\u2192 Cost of attack = 6.25M ETH \u00d7 1\/3 \u2248 2.08M ETH<\/p>\nTwo Possible Roles for Delegators<\/h4>\n
Bringing It Together: Barnab\u00e9\u2019s Rainbow Staking Framework (2024)<\/h3>\n
From Monolith to Microservices: The Architecture Redesign and Four Dimensions<\/h4>\n
<\/strong>Vitalik\u2019s proposal was primarily a \u201cHeavy\/Light\u201d two-tier model. Barnab\u00e9 fully \u201cmicroservices-ifies\u201d it by formally separating Operators<\/strong> from Delegators<\/strong> at the base protocol level. This decouples capital provision from technical operation across all service\u00a0tiers.Reward Curves: From Rough Intuition to 2-D MVI
<\/strong>Vitalik\u2019s version only roughly discussed the possibility of setting different return rates for the two tiers. Barnab\u00e9 splits total issuance into heavy services and light services\u200a\u2014\u200aletting the protocol dynamically adjust yields based on participation ratios across roles. He also formally defines light LSTs<\/strong> as a non-fungible protocol object, distinct from the market-driven LST derivatives we have\u00a0today.Separating Execution: Integrating APS
<\/strong>Vitalik\u2019s version still assumed validators handle both block building and attestation. Barnab\u00e9 goes further by decoupling Execution Services<\/strong> from consensus validation\u200a\u2014\u200aa step toward Attester-Proposer Separation (APS)<\/strong>.Formalizing Light Staker Duties: Binding IL to the Role
<\/strong>Barnab\u00e9 explicitly defines censorship resistance<\/strong> as the core output of light Services, and formally binds the IL mechanism (today\u2019s FOCIL) to the responsibilities of light stakers\u200a\u2014\u200aletting light nodes focus on being censorship-resistance gatekeepers rather than participating in heavy block validation.source: https:\/\/ethresear.ch\/uploads\/default\/optimized\/2X\/1\/1c1d9fa783c18b2631fcb139f3cdede5aa94086b_2_449x375.jpeg<\/a><\/p>\nThe Four-Quadrant Matrix: Two Dimensions, Four\u00a0Roles<\/h4>\n
– Heavy services<\/strong> require top-tier hardware and significant capital, responsible for \u201ceconomic finality.\u201d
– Light services<\/strong> are accessible with consumer hardware, responsible for \u201ccensorship resistance.\u201dY-axis (Role Type)<\/strong>:
– Operators<\/strong> run the nodes.
– Delegators<\/strong> provide capital and earn\u00a0yield.<\/p>\nHeavy Staking (Heavy services)<\/h4>\n
Delegator provides: ~3,626 ETH (delegated \u2014 partially protected)
Total: ~3,662 ETH \u2192 one SSF seat<\/p>\n
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)<\/p>\nLight Staking (Light Services)<\/h4>\n
Strong Coupling vs. Weak Coupling: The Power Relationship Between Light and Heavy\u00a0Services<\/h4>\n
Going Live: FOCIL\u200a\u2014\u200aA Protocol-Level Censorship Resistance Weapon<\/h3>\n
The Slot Timeline and View Freeze\u00a0Deadline<\/h4>\n
Core Design Principles<\/h4>\n
IL Validity Checking: Deep EL\u2013CL Cooperation<\/h4>\n
Looking Ahead: How Rainbow Staking Enables\u00a0SSF<\/h3>\n
The Real SSF Threshold: Not 3,662 ETH, But Not Guaranteed to Be 32 ETH\u00a0Either<\/h4>\n
The Classic Tradeoff: Performance vs. Decentralization<\/h4>\n
Rainbow Staking\u2019s Answer: Decouple Finality from Transaction Inclusion<\/h4>\n
Implications: DeFi Ecosystem Restructuring<\/h3>\n
LST Lego Gets Restructured<\/h4>\n
Challenges and Closing\u00a0Thoughts<\/h3>\n
Open Challenges<\/h4>\n
Closing: A Paradigm Shift in Consensus Layer Architecture<\/h4>\n
![https:\/\/ethresear.ch\/uploads\/default\/optimized\/2X\/1\/1c1d9fa783c18b2631fcb139f3cdede5aa94086b_2_449x375.jpeg<\/a><\/p>\nThe Four-Quadrant Matrix: Two Dimensions, Four\u00a0Roles<\/h4>\nRainbow Staking cuts the staking mechanism along two dimensions:<\/p>\nX-axis (Service Type)<\/strong>: – Heavy services<\/strong> require top-tier hardware and significant capital, responsible for \u201ceconomic finality.\u201d – Light services<\/strong> are accessible with consumer hardware, responsible for \u201ccensorship resistance.\u201dY-axis (Role Type)<\/strong>: – Operators<\/strong> run the nodes. – Delegators<\/strong> provide capital and earn\u00a0yield.<\/p>\nHeavy Staking (Heavy services)<\/h4>\n# Role: The Foundation of Economic Finality\u00a0#<\/strong><\/p>\nThe core of heavy services is Gasper<\/strong>\u200a\u2014\u200aEthereum\u2019s consensus mechanism, combining FFG finality and LMD-GHOST fork choice. It answers the most fundamental question: \u201cWhich chain is the canonical chain?\u201d<\/strong><\/p>\nGasper\u2019s security relys on the slashing mechanism<\/strong>: if an Operator attempts to break FFG safety (e.g. double voting on conflicting checkpoints), their entire stake gets burned by the protocol.<\/p>\nHeavy services\u00a0require:<\/p>\nHigh-end servers and high bandwidth<\/strong>: Under SSF, each of the 8,192 seats must sign reliably and on time every\u00a0slot.Sufficient capital<\/strong>: Through an LSM-style partial collateralization mechanism, an Operator only needs to post a fraction of the capital themselves\u200a\u2014\u200athe rest comes from Delegators.Tolerance for slashing risk<\/strong>: Any mistake can result in loss of principal.<\/p>\n# Who Should Participate? #<\/strong><\/p>\nGenerated by\u00a0AI<\/p>\nProfessional institutions will naturally dominate heavy services\u200a\u2014\u200athey have the infrastructure, capital management experience, and operational scale.<\/p>\nSolo stakers who want to participate can do so through two mechanisms:<\/p>\nMechanism 1: Partial\u00a0Pool<\/strong><\/p>\nBorrowing from Cosmos LSM (Liquid Staking Module)<\/a>, Operators don\u2019t need to post the full stake themselves\u200a\u2014\u200aDelegators fill the gap. Using a middle-ground ratio between Rocket Pool\u2019s 1:3 and LSM\u2019s default 1:250, Barnab\u00e9 uses roughly 1:100. The delegation relationship is recorded as an LSM Share at the protocol\u00a0level:<\/p>\nOperator posts: ~36 ETH (bond \u2014 first to be slashed if something goes wrong)Delegator provides: ~3,626 ETH (delegated \u2014 partially protected)Total: ~3,662 ETH \u2192 one SSF seat<\/p>\nMechanism 2: DVT (Distributed Validator Technology)<\/strong><\/p>\nDVT lets multiple small nodes collectively form a \u201cvirtual Operator\u201d using threshold signatures<\/strong>, presenting as a single validator to the protocol:<\/p>\nGenerated by\u00a0AI<\/p>\nThe original BLS private key is split into multiple key shares<\/strong> 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\u00a0risk.<\/p>\nThe minimum stake requirement per DVT node is not defined at the protocol level<\/strong>, and there\u2019s a tradeoff:<\/p>\nNo minimum<\/strong>: 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<\/strong>: Better Sybil resistance, but excludes small stakers\u200a\u2014\u200acontradicting the goal of keeping solo stakers in the heavy\u00a0layer<\/p>\nRainbow Staking\u2019s position: let LSPs handle this at the market layer<\/strong>. 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\u200a\u2014\u200ano need to mandate specific minimums.<\/p>\n# How Heavy LSTs Are Born: From Enshrinement to Market Competition #<\/strong><\/p>\nBefore explaining how heavy LSTs are created, let\u2019s clear up a common misconception: Enshrined LST does not mean Ethereum itself issues an \u201cofficial stETH.\u201d<\/strong> The protocol doesn\u2019t print\u00a0tokens.<\/p>\n\u201cEnshrine\u201d means: letting the protocol see and manage the delegation relationship<\/strong>, so that LST minting is built on protocol-recognized infrastructure rather than purely on external smart contracts.<\/p>\nWhat\u2019s the problem\u00a0today?<\/strong><\/p>\nWhen you deposit ETH into Lido, the entire delegation relationship lives inside Lido\u2019s smart contract. The Ethereum protocol only sees \u201csomeone staked ETH and a validator was activated\u201d\u200a\u2014\u200ait has no visibility into who the actual Delegator is (you) or who the actual Operator is (Lido\u2019s node). This makes it hard to implement fast Operator switching, a level playing field for LSPs, and protocol-level prevention of dominant market positions.<\/p>\n# The Enshrinement Solution: Making Delegation Visible to the Protocol\u00a0#<\/strong><\/p>\nRainbow Staking draws on the Cosmos LSM design and proposes introducing a standardized delegation record object at the protocol layer, conceptually like\u00a0this:<\/p>\nclass 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)<\/p>\nWith this structure, the protocol can \u201csee\u201d the Delegator\u2013Operator separation, enabling:<\/p>\nFast Re-delegation<\/strong>: Switch Operators without waiting through an unbonding periodA level playing field for LSPs<\/strong>: Any LSP can build on top of this standardized base\u200a\u2014\u200athe market becomes more\u00a0openLight service integration<\/strong>: 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<\/p>\n# The Full Capital Flow for Heavy LSTs\u00a0#<\/strong><\/p>\nGenerated by\u00a0AIDelegator deposits\u00a0ETHProtocol mints an LSM Share (recording: who delegated, to which Operator, how\u00a0much)Delegator registers the Share as delegated to their chosen\u00a0LSPLSP 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\u00a010%)LSP mints fungible heavy LSTs (e.g. stETH,\u00a0rETH)Delegator holds the heavy LST and can use it freely in\u00a0DeFi<\/p>\nThe key insight: the protocol provides a standardized base layer (the LSM Share mechanism)<\/strong>. Any LSP can build its own product on\u00a0top.<\/p>\nLST Credibility Becomes the Core Competitive Dimension<\/strong><\/p>\nIn this architecture, LSPs compete less on fees and more on LST credibility<\/strong>\u200a\u2014\u200athe market evaluates whether an LSP\u2019s 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\u2019t need to judge who is \u201cdecentralized enough\u201d\u200a\u2014\u200athe market and Delegators\u2019 re-delegation choices will do the filtering.<\/p>\nLight Staking (Light Services)<\/h4>\nLight services aren\u2019t about economic security\u200a\u2014\u200athey\u2019re about censorship resistance<\/strong>. Their security comes from preference entropy<\/strong>.<\/p>\nsource: https:\/\/ethresear.ch\/uploads\/default\/original\/2X\/d\/d7dbff8196573f5476c3b4ed54e59b20532b1cf2.jpeg<\/a><\/p>\nThe 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\u200a\u2014\u200atypically a disadvantage\u200a\u2014\u200abecomes a core competitive strength\u00a0here.<\/p>\n# Light LSTs: Protocol Objects, Not Market Products\u00a0#<\/strong><\/p>\nDelegators who deposit ETH to light services receive light LSTs, but these are fundamentally different from heavy\u00a0LSTs:<\/p>\nPer-operator non-fungible<\/strong>: Delegating to Operator A gives you LightETH-A. Delegating to Operator B gives you LightETH-B. They are not equivalent.Trustless<\/strong>: Since an Operator\u2019s slashing exposure is capped to their own bond, Delegators can never lose their principal\u200a\u2014\u200aeven when delegating to a completely unknown solo\u00a0staker.Value internalized<\/strong>: Performance differences between operators (commission rates, service quality) are reflected directly in each light LST\u2019s\u00a0yield.<\/p>\nBarnab\u00e9 also points out that Ethereum already has a precedent for light services: the Sync Committee<\/strong> 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 \u201cprotocol incentivizing a light service through issuance\u201d already\u00a0exists.<\/p>\nStrong Coupling vs. Weak Coupling: The Power Relationship Between Light and Heavy\u00a0Services<\/h4>\nThe Rainbow Staking paper discusses two options for how the output of light services (ILs) should constrain heavy operators:<\/p>\nStrong coupling<\/strong>: Heavy operators are required to include the light certificate(*)<\/strong> proposed by a light committee in their blocks\u200a\u2014\u200aotherwise the block is invalid. This forces heavy services to respect the light layer\u2019s output, but introduces a liveness risk: if the light layer is attacked or goes offline, the entire chain\u00a0halts.Weak coupling<\/strong>: Heavy operators are incentivized<\/em> (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.<\/p>\nBarnab\u00e9\u2019s paper leans toward weak coupling. However, the current FOCIL implementation takes a hybrid approach: strong enforcement on transaction inclusion<\/strong> (a block that ignores a known IL is invalid), but weak coupling on liveness<\/strong> (if no ILs are received before the view freeze deadline, the network safely degrades to normal block production without stalling).<\/p>\n* In the current design, light certificate refers to the\u00a0IL.<\/em><\/p>\nGoing Live: FOCIL\u200a\u2014\u200aA Protocol-Level Censorship Resistance Weapon<\/h3>\nWith the theoretical framework in place, let\u2019s look at the actual implementation of light service censorship resistance: Fork-choice enforced Inclusion Lists (FOCIL, EIP-7805)<\/strong>. FOCIL is scheduled to ship in the Hegot\u00e1 upgrade later this\u00a0year.<\/p>\nThe Slot Timeline and View Freeze\u00a0Deadline<\/h4>\nFOCIL\u2019s 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<\/strong>, rather than with a one-slot delay. Let\u2019s walk through the timeline:<\/p>\nSlot N:<\/strong><\/p>\nt = 0s\u200a\u2014\u200aA new slot begins. Receive the block from the previous slot, confirm the\u00a0head.t = 0 ~ 8s\u200a\u2014\u200a16 IL Committee members each independently scan the mempool, construct their IL, and broadcast it. (Max size per IL: 8\u00a0KiB)t = 9s\u200a\u2014\u200aView Freeze Deadline<\/strong>. All nodes stop accepting new ILs. Each node’s IL set is now locked to whatever it has received up to this\u00a0point.<\/p>\nSlot N+1:<\/strong><\/p>\nt = 0s\u200a\u2014\u200aA block proposer broadcasts the new block (must include all transactions from the ILs it received).t = 4s\u200a\u2014\u200aAttestation 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.Generated by\u00a0AI<\/p>\nThe critical piece here is the View Freeze Deadline (t=9s)<\/strong>. Without it, a builder could intentionally \u201cforget\u201d ILs it doesn\u2019t 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\u00a0valid.<\/p>\nThis also ties back to the strong\/weak coupling discussion: FOCIL doesn\u2019t 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\u200a\u2014\u200aor none at all\u200a\u2014\u200adue to network conditions. The chain doesn\u2019t stall waiting for all 16. It works with whatever was received before the deadline.<\/p>\nCore Design Principles<\/h4>\nCommittee-based<\/strong>: 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\u00a0block.Fork-choice enforced<\/strong>: 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<\/strong>: Inclusion isn\u2019t blind. Exemptions exist\u200a\u2014\u200afor example, if the block is full (insufficient gas) or the transaction itself has become invalid (nonce conflict, insufficient balance).Anywhere-in-block<\/strong>: IL transactions can appear anywhere in the block. Builders retain ordering rights\u200a\u2014\u200athe most profitable part of their role\u200a\u2014\u200awhich significantly reduces their incentive to circumvent the mechanism.No direct rewards<\/strong>: Participating in the IL committee does not earn additional protocol issuance. It relies on altruistic behavior, which keeps implementation complexity low.<\/p>\nIL Validity Checking: Deep EL\u2013CL Cooperation<\/h4>\nUnlike previous proposals, FOCIL requires the Execution Layer (EL) and Consensus Layer (CL) to work closely together\u200a\u2014\u200athe most complex part of the implementation.<\/p>\nConsensus Layer<\/strong>: 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\u00a0slot.Execution Layer<\/strong>: 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 <\/strong>INCLUSION_LIST_UNSATISFIED to CL, and CL rejects the\u00a0block.<\/strong><\/p>\nLooking Ahead: How Rainbow Staking Enables\u00a0SSF<\/h3>\nWith FOCIL\u2019s mechanics covered, let\u2019s zoom out. In Paths to SSF revisited<\/em><\/a>, published in March 2025, Barnab\u00e9 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\u00a0SSF.<\/p>\nThe Real SSF Threshold: Not 3,662 ETH, But Not Guaranteed to Be 32 ETH\u00a0Either<\/h4>\nThe 3,662 ETH figure from the first section was a theoretical upper bound derived from an extreme assumption\u200a\u2014\u200a1\/4 of all ETH supply staked. Paths to SSF revisited<\/em> gives a more grounded estimate.<\/p>\nBased 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\u2019t staking nodes. That leaves approximately 7,000 staking nodes<\/strong>. If these nodes fully consolidate their stake, the 8,192-seat cap means the average stake per seat roughly matches today\u2019s levels\u200a\u2014\u200athe minimum threshold could stay near 32\u00a0ETH<\/strong>.<\/p>\nHowever, Barnab\u00e9 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<\/strong>\u200a\u2014\u200aby how much depends on the degree of consolidation and what performance targets are prioritized.<\/p>\nThe point is: existing solo stakers aren\u2019t necessarily locked out, but they\u2019re not guaranteed to stay in either. This uncertainty is exactly what makes the path choice so consequential.<\/strong><\/p>\nThe Classic Tradeoff: Performance vs. Decentralization<\/h4>\nHigh-TPS chains have historically solved this by just capping the validator count\u200a\u2014\u200afewer validators, easier to coordinate. But this conflicts with Ethereum\u2019s decentralization ethos. SSF faces the same tension, and without role separation, there are only two paths\u00a0forward:<\/p>\nPath A (Orbit)<\/strong><\/a>: 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\u2019s consolidation incentive mechanism still has unresolved economic issues, and SSF timelines would slip significantly.Path B (Capped Validator Set)<\/strong><\/a>: 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.<\/p>\nRainbow Staking\u2019s Answer: Decouple Finality from Transaction Inclusion<\/h4>\nRainbow Staking\u2019s 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.<\/strong><\/p>\nThis separation gives Path B a way to patch its censorship resistance gap. In Paths to SSF revisited<\/em>, Barnab\u00e9 formally introduces Light FOCIL<\/strong>. The barrier to entry is minimal\u200a\u2014\u200aanyone 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.<\/p>\nIn one sentence: we may not get a 1 ETH validator, but Rainbow Staking makes a 1 ETH includer possible.<\/strong><\/p>\nThe research community is currently moving toward Path B + Rainbow Staking<\/strong>. Path B\u2019s biggest risk\u200a\u2014\u200adeclining censorship resistance\u200a\u2014\u200ais addressed by Light FOCIL. Rainbow Staking\u2019s heavy layer design (LSM + DVT) also gives solo stakers who can\u2019t get a direct seat ways to participate indirectly. Meanwhile, Orbit\u2019s complexity has been significantly underestimated, and its timeline is too uncertain to commit to right\u00a0now.<\/p>\nWithout Rainbow Staking\u2019s heavy\/light service separation, Path B\u2019s decentralization argument falls apart, and SSF\u2019s timeline becomes anyone\u2019s guess. Rainbow Staking is not just an ideal end state after SSF\u200a\u2014\u200ait\u2019s a necessary precondition for SSF to arrive on a reasonable timeline.<\/strong><\/p>\nImplications: DeFi Ecosystem Restructuring<\/h3>\nRainbow Staking\u2019s protocol-level changes have implications beyond core protocol developers. For DApp developers and the broader DeFi ecosystem, it\u2019s a ground-up restructuring of underlying assumptions.<\/p>\nLST Lego Gets Restructured<\/h4>\nDeFi protocols have long relied on stETH as a base collateral asset\u200a\u2014\u200abest liquidity, widest integration. After Rainbow Staking, staking tokens will split into two fundamentally different forms:<\/p>\nHeavy LST<\/strong><\/p>\nLiquid and freely usable across\u00a0DeFi.Represents shared exposure to Gasper slashing\u00a0risk<\/strong>.Competition shifts toward credibility<\/strong>\u200a\u2014\u200adiversity of operators composition and resilience to slashing\u00a0events.Analogous to today\u2019s stETH and rETH, but competing within a more complete protocol-level standard.<\/p>\nLight LST<\/strong><\/p>\nA protocol object<\/strong>, not a market\u00a0product.Per-operator non-fungible<\/strong> (e.g. LightETH-Obol \u2260 LightETH-SSV).Represents a stake delegated to a specific light operator\u200a\u2014\u200acrucially, carries no slashing\u00a0risk<\/strong>.More like a risk-free yield receipt than a circulating currency.<\/p>\nPractical Impact for Developers:<\/strong><\/p>\nThis isn\u2019t \u201cold stETH disappears\u201d\u200a\u2014\u200ait\u2019s fragmentation and specialization of asset types. Developers need completely different risk models for\u00a0each:<\/p>\nLending protocols<\/strong>: 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<\/strong>: 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<\/strong>: Will need logic to dynamically reallocate between the heavy and light layers, significantly increasing strategy complexity.<\/p>\nChallenges and Closing\u00a0Thoughts<\/h3>\nOpen Challenges<\/h4>\nThis framework has a clear vision, but several hard problems\u00a0remain:<\/p>\nComplexity explosion<\/strong>: Going from \u201cone validator does everything\u201d to a four-quadrant role separation dramatically increases protocol specification complexity. Each new mechanism (LSM, DVT) is a new potential attack\u00a0surface.Centralization economies of scale in the heavy layer<\/strong>: Even with partial collateralization, professional institutions still have significant advantages in heavy services\u200a\u2014\u200abetter hardware, lower operational costs, stronger reputations. Rainbow Staking can reduce this but not eliminate it.Light LST liquidity problem<\/strong>: The per-operator non-fungibility that keeps the kight layer pure also makes these assets structurally difficult to integrate into DeFi. How to balance \u201cprotocol object\u201d with \u201cusable asset\u201d remains an open question.SSF seat competition incentive distortion<\/strong>: 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\u00a0problem.<\/p>\nClosing: A Paradigm Shift in Consensus Layer Architecture<\/h4>\nRainbow Staking represents Ethereum asking a fundamental question:<\/p>\nWho should have the right to participate in consensus?<\/strong><\/p>\nThe current monolithic architecture bundles capital, hardware, and technical expertise together\u200a\u2014\u200aonly those with all three can participate meaningfully. That design effectively outsources the \u201cwho gets to participate\u201d question to the market, and the market\u2019s answer is almost always \u201cwhoever has the most capital.\u201d<\/p>\nRainbow Staking takes a different approach: acknowledge that different participants have different comparative advantages<\/strong>, and design service types and incentive mechanisms that match each. Let institutional capital efficiency serve heavy layer security. Let solo stakers\u2019 geographic dispersion and diverse preferences serve light layer censorship resistance. These aren\u2019t competing forces\u200a\u2014\u200athey\u2019re complementary.<\/p>\nFrom Vitalik\u2019s question in 2023, to Barnab\u00e9\u2019s four-quadrant framework in 2024, to FOCIL shipping on mainnet in 2026\u200a\u2014\u200athis is more than an engineering optimization. It\u2019s a design philosophy for how a decentralized network should be organized: not everyone doing the same thing, but everyone doing what they\u2019re best at, together holding up something more resilient.<\/strong><\/p>\nReferences:<\/p>\nProtocol and staking pool changes that could improve decentralization and reduce consensus overhead<\/a>\u200a\u2014\u200aVitalik Buterin, Oct\u00a02023Unbundling staking: Towards rainbow staking<\/a>\u200a\u2014\u200aBarnab\u00e9 Monnot, Feb\u00a02024Paths to SSF revisited<\/a>\u200a\u2014\u200aBarnab\u00e9 Monnot, Mar\u00a02025EIP-7805: Fork-choice enforced Inclusion Lists\u00a0(FOCIL)<\/a>Sticking to 8192 signatures per slot post-SSF<\/a>\u200a\u2014\u200aVitalik\u00a0ButerinOrbit SSF: solo-staking-friendly validator set management for\u00a0SSF<\/a>Gemini Deep\u00a0Research<\/p>\nRainbow Staking: Ethereum\u2019s Next Evolution in Staking<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":"This article was co-written by AI and the author. The final output was reviewed and refined by the\u00a0author. 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\u2019re […]<\/p>\n","protected":false},"author":0,"featured_media":150697,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-150696","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/150696"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=150696"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/150696\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/150697"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=150696"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=150696"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=150696"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}](\"https:\/\/ethresear.ch\/uploads\/default\/optimized\/2X\/1\/1c1d9fa783c18b2631fcb139f3cdede5aa94086b_2_449x375.jpeg\"){kind=link}
![https:\/\/ethresear.ch\/uploads\/default\/original\/2X\/d\/d7dbff8196573f5476c3b4ed54e59b20532b1cf2.jpeg<\/a><\/p>\nThe 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\u200a\u2014\u200atypically a disadvantage\u200a\u2014\u200abecomes a core competitive strength\u00a0here.<\/p>\n# Light LSTs: Protocol Objects, Not Market Products\u00a0#<\/strong><\/p>\nDelegators who deposit ETH to light services receive light LSTs, but these are fundamentally different from heavy\u00a0LSTs:<\/p>\nPer-operator non-fungible<\/strong>: Delegating to Operator A gives you LightETH-A. Delegating to Operator B gives you LightETH-B. They are not equivalent.Trustless<\/strong>: Since an Operator\u2019s slashing exposure is capped to their own bond, Delegators can never lose their principal\u200a\u2014\u200aeven when delegating to a completely unknown solo\u00a0staker.Value internalized<\/strong>: Performance differences between operators (commission rates, service quality) are reflected directly in each light LST\u2019s\u00a0yield.<\/p>\nBarnab\u00e9 also points out that Ethereum already has a precedent for light services: the Sync Committee<\/strong> 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 \u201cprotocol incentivizing a light service through issuance\u201d already\u00a0exists.<\/p>\nStrong Coupling vs. Weak Coupling: The Power Relationship Between Light and Heavy\u00a0Services<\/h4>\nThe Rainbow Staking paper discusses two options for how the output of light services (ILs) should constrain heavy operators:<\/p>\nStrong coupling<\/strong>: Heavy operators are required to include the light certificate(*)<\/strong> proposed by a light committee in their blocks\u200a\u2014\u200aotherwise the block is invalid. This forces heavy services to respect the light layer\u2019s output, but introduces a liveness risk: if the light layer is attacked or goes offline, the entire chain\u00a0halts.Weak coupling<\/strong>: Heavy operators are incentivized<\/em> (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.<\/p>\nBarnab\u00e9\u2019s paper leans toward weak coupling. However, the current FOCIL implementation takes a hybrid approach: strong enforcement on transaction inclusion<\/strong> (a block that ignores a known IL is invalid), but weak coupling on liveness<\/strong> (if no ILs are received before the view freeze deadline, the network safely degrades to normal block production without stalling).<\/p>\n* In the current design, light certificate refers to the\u00a0IL.<\/em><\/p>\nGoing Live: FOCIL\u200a\u2014\u200aA Protocol-Level Censorship Resistance Weapon<\/h3>\nWith the theoretical framework in place, let\u2019s look at the actual implementation of light service censorship resistance: Fork-choice enforced Inclusion Lists (FOCIL, EIP-7805)<\/strong>. FOCIL is scheduled to ship in the Hegot\u00e1 upgrade later this\u00a0year.<\/p>\nThe Slot Timeline and View Freeze\u00a0Deadline<\/h4>\nFOCIL\u2019s 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<\/strong>, rather than with a one-slot delay. Let\u2019s walk through the timeline:<\/p>\nSlot N:<\/strong><\/p>\nt = 0s\u200a\u2014\u200aA new slot begins. Receive the block from the previous slot, confirm the\u00a0head.t = 0 ~ 8s\u200a\u2014\u200a16 IL Committee members each independently scan the mempool, construct their IL, and broadcast it. (Max size per IL: 8\u00a0KiB)t = 9s\u200a\u2014\u200aView Freeze Deadline<\/strong>. All nodes stop accepting new ILs. Each node’s IL set is now locked to whatever it has received up to this\u00a0point.<\/p>\nSlot N+1:<\/strong><\/p>\nt = 0s\u200a\u2014\u200aA block proposer broadcasts the new block (must include all transactions from the ILs it received).t = 4s\u200a\u2014\u200aAttestation 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.Generated by\u00a0AI<\/p>\nThe critical piece here is the View Freeze Deadline (t=9s)<\/strong>. Without it, a builder could intentionally \u201cforget\u201d ILs it doesn\u2019t 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\u00a0valid.<\/p>\nThis also ties back to the strong\/weak coupling discussion: FOCIL doesn\u2019t 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\u200a\u2014\u200aor none at all\u200a\u2014\u200adue to network conditions. The chain doesn\u2019t stall waiting for all 16. It works with whatever was received before the deadline.<\/p>\nCore Design Principles<\/h4>\nCommittee-based<\/strong>: 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\u00a0block.Fork-choice enforced<\/strong>: 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<\/strong>: Inclusion isn\u2019t blind. Exemptions exist\u200a\u2014\u200afor example, if the block is full (insufficient gas) or the transaction itself has become invalid (nonce conflict, insufficient balance).Anywhere-in-block<\/strong>: IL transactions can appear anywhere in the block. Builders retain ordering rights\u200a\u2014\u200athe most profitable part of their role\u200a\u2014\u200awhich significantly reduces their incentive to circumvent the mechanism.No direct rewards<\/strong>: Participating in the IL committee does not earn additional protocol issuance. It relies on altruistic behavior, which keeps implementation complexity low.<\/p>\nIL Validity Checking: Deep EL\u2013CL Cooperation<\/h4>\nUnlike previous proposals, FOCIL requires the Execution Layer (EL) and Consensus Layer (CL) to work closely together\u200a\u2014\u200athe most complex part of the implementation.<\/p>\nConsensus Layer<\/strong>: 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\u00a0slot.Execution Layer<\/strong>: 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 <\/strong>INCLUSION_LIST_UNSATISFIED to CL, and CL rejects the\u00a0block.<\/strong><\/p>\nLooking Ahead: How Rainbow Staking Enables\u00a0SSF<\/h3>\nWith FOCIL\u2019s mechanics covered, let\u2019s zoom out. In Paths to SSF revisited<\/em><\/a>, published in March 2025, Barnab\u00e9 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\u00a0SSF.<\/p>\nThe Real SSF Threshold: Not 3,662 ETH, But Not Guaranteed to Be 32 ETH\u00a0Either<\/h4>\nThe 3,662 ETH figure from the first section was a theoretical upper bound derived from an extreme assumption\u200a\u2014\u200a1\/4 of all ETH supply staked. Paths to SSF revisited<\/em> gives a more grounded estimate.<\/p>\nBased 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\u2019t staking nodes. That leaves approximately 7,000 staking nodes<\/strong>. If these nodes fully consolidate their stake, the 8,192-seat cap means the average stake per seat roughly matches today\u2019s levels\u200a\u2014\u200athe minimum threshold could stay near 32\u00a0ETH<\/strong>.<\/p>\nHowever, Barnab\u00e9 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<\/strong>\u200a\u2014\u200aby how much depends on the degree of consolidation and what performance targets are prioritized.<\/p>\nThe point is: existing solo stakers aren\u2019t necessarily locked out, but they\u2019re not guaranteed to stay in either. This uncertainty is exactly what makes the path choice so consequential.<\/strong><\/p>\nThe Classic Tradeoff: Performance vs. Decentralization<\/h4>\nHigh-TPS chains have historically solved this by just capping the validator count\u200a\u2014\u200afewer validators, easier to coordinate. But this conflicts with Ethereum\u2019s decentralization ethos. SSF faces the same tension, and without role separation, there are only two paths\u00a0forward:<\/p>\nPath A (Orbit)<\/strong><\/a>: 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\u2019s consolidation incentive mechanism still has unresolved economic issues, and SSF timelines would slip significantly.Path B (Capped Validator Set)<\/strong><\/a>: 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.<\/p>\nRainbow Staking\u2019s Answer: Decouple Finality from Transaction Inclusion<\/h4>\nRainbow Staking\u2019s 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.<\/strong><\/p>\nThis separation gives Path B a way to patch its censorship resistance gap. In Paths to SSF revisited<\/em>, Barnab\u00e9 formally introduces Light FOCIL<\/strong>. The barrier to entry is minimal\u200a\u2014\u200aanyone 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.<\/p>\nIn one sentence: we may not get a 1 ETH validator, but Rainbow Staking makes a 1 ETH includer possible.<\/strong><\/p>\nThe research community is currently moving toward Path B + Rainbow Staking<\/strong>. Path B\u2019s biggest risk\u200a\u2014\u200adeclining censorship resistance\u200a\u2014\u200ais addressed by Light FOCIL. Rainbow Staking\u2019s heavy layer design (LSM + DVT) also gives solo stakers who can\u2019t get a direct seat ways to participate indirectly. Meanwhile, Orbit\u2019s complexity has been significantly underestimated, and its timeline is too uncertain to commit to right\u00a0now.<\/p>\nWithout Rainbow Staking\u2019s heavy\/light service separation, Path B\u2019s decentralization argument falls apart, and SSF\u2019s timeline becomes anyone\u2019s guess. Rainbow Staking is not just an ideal end state after SSF\u200a\u2014\u200ait\u2019s a necessary precondition for SSF to arrive on a reasonable timeline.<\/strong><\/p>\nImplications: DeFi Ecosystem Restructuring<\/h3>\nRainbow Staking\u2019s protocol-level changes have implications beyond core protocol developers. For DApp developers and the broader DeFi ecosystem, it\u2019s a ground-up restructuring of underlying assumptions.<\/p>\nLST Lego Gets Restructured<\/h4>\nDeFi protocols have long relied on stETH as a base collateral asset\u200a\u2014\u200abest liquidity, widest integration. After Rainbow Staking, staking tokens will split into two fundamentally different forms:<\/p>\nHeavy LST<\/strong><\/p>\nLiquid and freely usable across\u00a0DeFi.Represents shared exposure to Gasper slashing\u00a0risk<\/strong>.Competition shifts toward credibility<\/strong>\u200a\u2014\u200adiversity of operators composition and resilience to slashing\u00a0events.Analogous to today\u2019s stETH and rETH, but competing within a more complete protocol-level standard.<\/p>\nLight LST<\/strong><\/p>\nA protocol object<\/strong>, not a market\u00a0product.Per-operator non-fungible<\/strong> (e.g. LightETH-Obol \u2260 LightETH-SSV).Represents a stake delegated to a specific light operator\u200a\u2014\u200acrucially, carries no slashing\u00a0risk<\/strong>.More like a risk-free yield receipt than a circulating currency.<\/p>\nPractical Impact for Developers:<\/strong><\/p>\nThis isn\u2019t \u201cold stETH disappears\u201d\u200a\u2014\u200ait\u2019s fragmentation and specialization of asset types. Developers need completely different risk models for\u00a0each:<\/p>\nLending protocols<\/strong>: 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<\/strong>: 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<\/strong>: Will need logic to dynamically reallocate between the heavy and light layers, significantly increasing strategy complexity.<\/p>\nChallenges and Closing\u00a0Thoughts<\/h3>\nOpen Challenges<\/h4>\nThis framework has a clear vision, but several hard problems\u00a0remain:<\/p>\nComplexity explosion<\/strong>: Going from \u201cone validator does everything\u201d to a four-quadrant role separation dramatically increases protocol specification complexity. Each new mechanism (LSM, DVT) is a new potential attack\u00a0surface.Centralization economies of scale in the heavy layer<\/strong>: Even with partial collateralization, professional institutions still have significant advantages in heavy services\u200a\u2014\u200abetter hardware, lower operational costs, stronger reputations. Rainbow Staking can reduce this but not eliminate it.Light LST liquidity problem<\/strong>: The per-operator non-fungibility that keeps the kight layer pure also makes these assets structurally difficult to integrate into DeFi. How to balance \u201cprotocol object\u201d with \u201cusable asset\u201d remains an open question.SSF seat competition incentive distortion<\/strong>: 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\u00a0problem.<\/p>\nClosing: A Paradigm Shift in Consensus Layer Architecture<\/h4>\nRainbow Staking represents Ethereum asking a fundamental question:<\/p>\nWho should have the right to participate in consensus?<\/strong><\/p>\nThe current monolithic architecture bundles capital, hardware, and technical expertise together\u200a\u2014\u200aonly those with all three can participate meaningfully. That design effectively outsources the \u201cwho gets to participate\u201d question to the market, and the market\u2019s answer is almost always \u201cwhoever has the most capital.\u201d<\/p>\nRainbow Staking takes a different approach: acknowledge that different participants have different comparative advantages<\/strong>, and design service types and incentive mechanisms that match each. Let institutional capital efficiency serve heavy layer security. Let solo stakers\u2019 geographic dispersion and diverse preferences serve light layer censorship resistance. These aren\u2019t competing forces\u200a\u2014\u200athey\u2019re complementary.<\/p>\nFrom Vitalik\u2019s question in 2023, to Barnab\u00e9\u2019s four-quadrant framework in 2024, to FOCIL shipping on mainnet in 2026\u200a\u2014\u200athis is more than an engineering optimization. It\u2019s a design philosophy for how a decentralized network should be organized: not everyone doing the same thing, but everyone doing what they\u2019re best at, together holding up something more resilient.<\/strong><\/p>\nReferences:<\/p>\nProtocol and staking pool changes that could improve decentralization and reduce consensus overhead<\/a>\u200a\u2014\u200aVitalik Buterin, Oct\u00a02023Unbundling staking: Towards rainbow staking<\/a>\u200a\u2014\u200aBarnab\u00e9 Monnot, Feb\u00a02024Paths to SSF revisited<\/a>\u200a\u2014\u200aBarnab\u00e9 Monnot, Mar\u00a02025EIP-7805: Fork-choice enforced Inclusion Lists\u00a0(FOCIL)<\/a>Sticking to 8192 signatures per slot post-SSF<\/a>\u200a\u2014\u200aVitalik\u00a0ButerinOrbit SSF: solo-staking-friendly validator set management for\u00a0SSF<\/a>Gemini Deep\u00a0Research<\/p>\nRainbow Staking: Ethereum\u2019s Next Evolution in Staking<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":"This article was co-written by AI and the author. The final output was reviewed and refined by the\u00a0author. 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\u2019re […]<\/p>\n","protected":false},"author":0,"featured_media":150697,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-150696","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/150696"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=150696"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/150696\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/150697"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=150696"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=150696"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=150696"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}](\"https:\/\/ethresear.ch\/uploads\/default\/original\/2X\/d\/d7dbff8196573f5476c3b4ed54e59b20532b1cf2.jpeg\"){kind=link}