Brief intro into Lido
To understand what Lido’s Custom Staking Module (CSM) v2 enables, we must begin with the fundamental role of staking in Ethereum today, and how Lido fits into that system.
At its core, Ethereum’s proof-of-stake consensus depends on validators who lock up ETH as collateral in order to participate in securing the network. These validators propose and attest to blocks, and in return they earn rewards. But staking also carries risk: if validators misbehave such as by being offline too often or by attempting to act maliciously, their stake can be partially or fully slashed.
This system is permissionless, in the sense that anyone with 32 ETH can become a validator. However, 32 ETH is not a trivial amount, and operating a validator node requires uptime, technical skill, and proper security practices. Most users do not want to run their own infrastructure, and many cannot afford the capital requirement.
This is where liquid staking comes in. Lido is a liquid staking protocol. Rather than requiring users to stake 32 ETH and run their own validator, Lido allows users to stake any amount of ETH into a pooled system. This ETH is then collectively distributed among a set of professional node operators who run the actual validator nodes. In return, users receive a token stETH that represents their claim on the staked ETH plus any rewards it earns. This token is liquid, meaning it can be used in DeFi, traded, or held just like ETH, even while the underlying ETH remains staked in Ethereum consensus.
Under the hood, Lido is not a validator itself, it delegates. It manages a curated list of node operators and distributes stake to them. These operators are trusted, and the selection process is governance-based. But this curated model, while secure and high-performing, is not truly permissionless.
That’s where CSM – Custom Staking Modules enter the picture.
The goal of CSM v2 is to make Lido modular and extensible, allowing new staking modules to be deployed with their own rules, logic, and operator selection mechanisms. These modules can support alternative validator management schemes: permissionless entry, operator collateralization, score-based reward distribution, and even compliance with new Ethereum features such as EIP-7002, which enables smart contracts to be validator withdrawal credentials.
So what kind of staking does CSM v2 enable?
It still ultimately contributes to Ethereum consensus, validators that come through CSM v2 still perform block proposals and attestations, and are rewarded or slashed accordingly. The difference lies in how those validators are onboarded, managed, and rewarded.
Upgrade to CSM v2
Where the original Lido relied on a single, monolithic, manually-curated operator set, CSM v2 allows for many modules, each with different operator rules. One module might allow any user to become an operator by bonding some ETH and passing a score threshold. Another might support a private pool of institutional operators. Yet another could be experimental, designed for DVT (Distributed Validator Technology) or integration with SSV or Obol. All of these contribute to the same purpose: helping users stake ETH without needing to run validators themselves.
In short, Lido’s CSM v2 is still liquid staking, in that end-users stake ETH into a shared pool and receive a liquid token in return. But behind the scenes, the validator selection and management logic becomes open and programmable. It is staking for Ethereum consensus, yes but with flexible mechanisms for validator inclusion, reward distribution, and slashing conditions. It is an architectural evolution designed to decentralize and modularize the system.
With the upgrade to CSM v2 lido is moving from pre-approved monolithic validator set to a modular system via Staking Modules, which will allow anyone to become a validator by having the governance approve the modules.
What are these modules? They are essentially smart contracts made by anyone and they specify the rules the validators must follow, the ways rewards are distributed and much more.
The governance has to approve or reject these modules. What this does is it creates a space for fradulent and dangerously approved code to be running on behalf of lido. And governance should approve this, they cant even read code or know what it does how would they approve or reject these, its jsut mind boggling. This opens are so many attack surfaces its crazy to me.
One of the most intriguing additions in CSM v2 is performance-based scoring. This is a formal mechanism for measuring how well each operator performs: whether their validator is online, whether they miss attestations, how quickly they exit when penalized, and more.
The performance score isn’t just a passive metric, it can determine how much ETH gets delegated to each operator. If you perform poorly, you might be struck by a kind of soft slashing event that limits your participation or cuts into your future earnings. These strikes could be triggered automatically based on objective conditions or enforced by a challenge system where other operators or watchers submit proofs of failure.
“CSM v2 is a permissionless staking module upgrade enabling customizable operator types, entry gates, strikes, EIP-7002 support, and performance-based scoring.”
That tells us what to expect:
- Permissionless — Anyone can register as an operator; opens attack surfaces
- Entry gates — Likely filtering mechanisms; griefing, bypass, DoS
- Strikes — Operator punishment; slashing, reputation, removal logic
- Performance scoring — New reward logic; abuse, sybil splits, underperformance gaming
- EIP-700 — Vault-style ETH withdrawals; check for early withdrawal griefing, race conditions
EIP-7002 allows a smart contract to act as a validator and control the withdrawal address.
For users, the experience remains the same. They stake ETH. They receive stETH. But beneath the surface, that ETH is now flowing through a diverse, programmable validator economy, one that rewards performance, punishes laziness, and invites participation without requiring trust.
What Is a Validator, Really?
On Ethereum, a validator is not a human being, nor even a server. It is a cryptographic identity: a unique public-private key pair that becomes activated when exactly 32 ETH is deposited into the Ethereum staking contract. This identity is entrusted with responsibilities defined by Ethereum’s consensus protocol specifically, proposing blocks, attesting to the validity of others’ blocks, and participating in sync committees when selected.
But a validator, while abstract in concept, requires real machinery to come alive. Behind the scenes, someone, an operator, must run client software that constantly performs these duties. This involves running both a consensus client (such as Lighthouse or Prysm) and an execution client (like Geth or Nethermind), connected to the wider Ethereum network. The validator must sign messages at precise intervals, remain online nearly 100% of the time, and respond accurately to protocol signals. Failure to do so leads to missed rewards. Severe failure, such as double-signing or being offline for extended periods, leads to slashing.
So, when we ask what a validator is, in practice it is both a staked identity on-chain and an off-chain process, a physical or virtual machine running validator software that keeps the identity alive and trustworthy in the eyes of the network.
Now, in the context of Lido’s CSM v2, the definition becomes more layered.
What Are Validators in CSM v2?
In CSM v2, validators are still defined by the Ethereum consensus rules – 32 ETH, validator keys, uptime, and performance, but they are also viewed as participants in a module-defined system. A staking module defines the policies and incentives around how those validators are onboarded, how they receive delegation, how their performance is measured, and how rewards are distributed or penalized.
The validators themselves are still off-chain entities running validator software. What changes in CSM v2 is that the smart contracts governing them, the modules are open to customization and innovation.
Each staking module is a smart contract that defines:
- The onboarding process: how someone becomes an operator.
- The delegation logic: how ETH is distributed among registered validators.
- The reward accounting: how much each validator earned, and when.
- The slashing or punishment mechanisms: if the validator misbehaves, how is that enforced?
- The offboarding or exit process: how do validators get removed from the module or lose delegation?
The validator itself doesn’t live on-chain. It is not a smart contract. But its registration, performance tracking, and economic role is encoded and enforced by the module.
Can Anyone Become a Validator in CSM v2?
Yes, and this is what makes CSM v2 revolutionary. While Lido today only delegates ETH to a tightly curated list of professional validators, CSM v2 introduces permissionless operator registration. If the module allows it, anyone can step forward, prove that they meet the module’s criteria (such as bonding collateral, passing a gate, or meeting a performance threshold), and register as an operator.
What this means is that you, with a home validator setup and perhaps a few ETH, could register yourself as a validator operator in a module that accepts permissionless entries. If your validator performs well, the module may route ETH to it. You would begin validating on behalf of Lido’s stakers, earning a share of rewards.
But the module doesn’t trust you. It can’t. Instead, it uses objective metrics, on-chain proof of performance, consensus participation history, uptime logs, or even external oracles to score your behavior and adjust delegation accordingly. If you perform poorly, your rewards will diminish or disappear. If you try to cheat the system perhaps by changing your withdrawal address before exiting, or by colluding with others to submit falsified performance scores the module is responsible for protecting itself, either through hardcoded constraints or on-chain enforcement mechanisms.
Whats the minimum you can stake to join?
With Lido’s current liquid staking system on Ethereum, users can stake as little as 0.0001 ETH (or even less in practice, though dust limits and gas costs make very small amounts impractical). There’s no minimum like the native 32 ETH requirement enforced by Ethereum’s consensus layer.
That’s one of the main benefits of Lido: it abstracts away the 32 ETH validator requirement and allows anyone to stake any amount. Users deposit ETH into Lido, receive stETH, and their funds are pooled together and delegated to professional validators.
Now for operators (those who want to run validator nodes for Lido), the story is different.
In the original (curated) model, operators were chosen via governance and didn’t need to provide capital upfront. But in CSM v2, which supports permissionless operator entry, the protocol may require bonded ETH or other collateral, plus a minimum performance threshold to join. That exact amount will depend on the specific staking module.
Who Creates CSM Modules?
A module, in the context of Lido’s architecture, is a smart contract that implements a defined interface. It must obey the rules of the staking router system primarily how it accepts deposits, how it tracks validator performance, and how it routes rewards. But within that boundary, it can do nearly anything.
So the author of a module could be:
- A solo developer or validator who wants to create a permissionless module with transparent rules.
- A research group or DAO that wants to experiment with slashing bonds or distributed validator technology.
- A team inside Lido, working on new standards for institutional staking or regional compliance.
- A protocol like Obol or SSV, integrating DVT into a module to enable multi-party validator sharing.
This is where the architecture opens wide. The creation of a module is not restricted. Anyone with the skill to write a smart contract and adhere to the module interface can propose one. They can publish the code, audit it, write documentation, and campaign for its inclusion.
Anyone can write a module, but only Lido governance decides which modules are accepted into the staking router.
Who Decides What Modules Get ETH?
While anyone can write a module, only Lido DAO governance composed of LDO token holders has the authority to register that module with the staking router. Registration means inclusion. Once registered, a module can begin receiving a portion of all new ETH deposits flowing into Lido. Without registration, the module exists in isolation, invisible to Lido’s capital flows.
So this is the answer: Lido governance is the gatekeeper. The staking router is the central dispatcher. It distributes staked ETH across registered modules according to configurable weights or dynamic policies. If governance approves a module, it is added. If not, it remains inactive.
This system balances openness with control. It allows anyone to innovate, but also requires community or governance approval before real capital enters the picture.
When Freedom Becomes Fragility
Modularity, decentralization, permissionlessness, these are beautiful words, but they are also gateways to new forms of failure. The more freedom you introduce, the more surface area you create for misaligned incentives, hidden complexity, and invisible adversaries.
The promise of CSM v2 is that anyone can create a staking module with its own logic. But what if the logic is flawed? What if a module’s strike system can be gamed? What if performance scoring is spoofed using manipulated data? What if a withdrawal vault has an upgradeable backdoor? What if a module sets low bonding requirements, accepts malicious validators, and launders ETH through subtle reward redistribution?
These are not theoretical concerns. In a permissionless system, you must assume that at least one module will be poorly designed, and that at least one validator will exploit that design. In the old Lido model, a single trusted operator set meant a small attack surface. With CSM v2, every module introduces a new validator economy, and every economy is a new domain of possible corruption.
The danger is not that permissionless systems are bad. The danger is that they are brittle when complexity exceeds understanding.
Let’s say a module is approved. ETH begins flowing in. Delegation is routed. Validators register. But the scoring logic has a bug, operators find a way to avoid penalties while missing duties. Rewards are misaccounted. Or worse: the module fails to slash an operator who goes rogue. That operator exits, taking rewards they didn’t earn, perhaps even exploiting Lido’s brand to attract deposits elsewhere.
Even if only one module fails publicly, the reputational damage to Lido is broad. From a staker’s perspective, they don’t care which module their ETH went into. They staked with Lido. If one module is corrupted, all of Lido is questioned.
Lido governance becomes the de facto gatekeeper and auditor of staking modules in CSM v2.
That means a decentralized group of token holders, many of whom are not technical, not security-focused, and often swayed by narrative or social proof, are tasked with reviewing, approving, and allocating capital into smart contracts that could be economically or technically flawed.
This is not a theoretical weakness, it is a systemic one. And it has precedent.
We’ve Seen This Movie Before
We’ve seen governance-driven systems approve protocols that later exploded:
- Governance approved unsafe modules with insufficient test coverage or unaudited external dependencies.
- Tokens were routed into contracts with upgradeable backdoors or flawed slashing mechanisms.
- Social consensus outweighed adversarial review, and risk wasn’t caught until after it was too late.
In DeFi history, every major catastrophic exploit from The DAO, to bZx, to Fei-Rari, to Beanstalk, to Euler has had some form of governance or social-layer blindness. Often, governance approved designs that sounded good but weren’t adversarially hardened.
CSM v2 Magnifies This Problem
Lido’s current model, for all its centralization, works. It routes billions of dollars of ETH through a small, professionally vetted, high-uptime validator set. The smart contracts are mature, hardened, and battle-tested. Users trust Lido because it hasn’t failed.
But with CSM v2, you are now asking:
- For code written by anyone (including opportunists or adversaries)…
- To be reviewed by DAO governance (not professional security teams)…
- And then routed a share of the staked ETH of millions of users.
That is a massive increase in attack surface, and a massive downgrade in security assumption unless Lido governance changes radically.
If a module’s logic is flawed, and Lido governance fails to notice, then user funds (and stETH reputation) are at risk even if the base Ethereum validator layer behaves perfectly.
Can This Be Made Safe?
Only if governance is backed by professional adversarial review, mandatory economic simulations, and formal code audits for every module proposal.
Ideally:
- Every module must come with a public audit, including adversarial economic testing.
- Formal specs of onboarding, scoring, and delegation logic must be published.
- There must be testnet deployments with real operator simulations, including malicious actors.
- Governance should vote only after a module survives adversarial simulation under load.
But as you likely suspect: none of that is guaranteed. It depends on how mature, rigorous, and cautious Lido governance is willing to be and whether or not that caution holds up in bull market pressure when new flashy modules promise “higher performance” or “decentralized onboarding” and try to fast-track approval.
It’s at the heart of whether CSM v2 will make Lido the Ethereum staking standard… or become the protocol’s biggest decentralized failure vector.
Why Lido Is Doing This (Despite the Risk)
The central reason is existential pressure. Lido has grown too big.
Lido today controls over 28% of all staked ETH. That’s not a detail it’s a massive governance and decentralization concern.
Ethereum researchers and the core dev community have been increasingly vocal: if Lido doesn’t decentralize its validator set, it will become an unacceptable centralization vector for the network.
So Lido is facing two conflicting truths:
- It’s the most trusted and widely adopted staking solution.
- Its current validator model is centralized, static, and dangerously concentrated.
In other words: if it doesn’t decentralize, it dies or gets forked out. The Ethereum community will push for alternative liquid staking protocols that are more open, more modular, more decentralized.
CSM v2 says: instead of Lido hand-picking validators forever, why not create an open system?
Let anyone write validator logic.
Let anyone register as a node operator.
Let the modules define custom scoring systems.
Let validators compete for delegation.
Let ETH flow where performance flows.
It’s the “Uniswap for validators” dream. Code is the new validator registry. Performance replaces reputation. Scoring replaces governance. The market decides.
What Should Be Happening Instead?
If Lido wanted to decentralize safely, here’s what you’d expect:
- Years of live DVT testing under adversarial conditions.
- Mandatory slashing bonds enforced by on-chain logic, not reputation.
- Immutable modules, or at minimum governance-imposed change delays.
- Formal verification and simulation of reward logic for each module.
- A governance structure with technical gatekeeping, not just token voting.
- Kill switches, safety valves, and capital flow throttling by default.
Instead, we get optional audits, module-level freedom, and the hope that governance won’t blink.
The Forking Threat: A Shadow Hanging Over Lido
Make no mistake: Ethereum researchers have talked openly about the idea of social-slashing Lido. Not the kind of “slashing” you write into a smart contract, but the kind where the Ethereum community decides that Lido must die, by forking around it, removing stETH from the economic loop, or pushing for protocol-level changes that render it irrelevant.
That is the unspoken threat beneath everything.
And Lido knows it.
So what do you do when you’re sitting on a billion-dollar protocol that might be forked out of existence unless you decentralize?
You open the gates.
But you do it without giving up the core economic flows. You say: “anyone can join, anyone can run validators, anyone can write modules” but only we, through our governance layer, control the router that directs the ETH.
It’s a clever compromise. One that offers the appearance and perhaps even the beginnings of true decentralization, while still keeping the core authority intact.
Now, suppose Lido’s validator set, those it delegates to through modules, controls more than half of all staked ETH. It would not own that ETH. But it would control the validators responsible for Ethereum’s finality. And here lies the real threat.
In Ethereum’s proof-of-stake system, validators propose and attest to blocks. A 51% share of staked ETH doesn’t let you rewrite history outright that would require overwhelming control of the validator set over time, but it does allow you to delay finality, censor transactions, and selectively reorg under specific conditions. It doesn’t matter whether the ETH technically belongs to users via stETH. What matters is that Lido controls enough active validator keys to influence consensus behavior. Ethereum’s entire safety depends on the assumption that no single entity can do this.
You said it clearly: they act as a gate. They don’t hold the ETH, but they control the validator lifecycle that moves it. And in Ethereum, the power to run validators is the power to shape consensus.
So in theory and this is not just theoretical, but structurally possible, if Lido governance ever became compromised, captured, or maliciously influenced, it could redirect delegation toward colluding validators. These validators, once they control a majority of active stake, could begin censoring transactions, delaying finality, or launching more subtle attacks on Ethereum consensus.
They wouldn’t even need to steal ETH. They wouldn’t have to rewrite the chain. They would simply use their influence to shape the future state of Ethereum, invisible at first, perhaps as mild censorship or MEV alignment, but eventually growing into something much more dangerous: a validator cartel with both economic weight and political opacity.
This is what’s meant by “credible neutrality” being at risk. Ethereum isn’t meant to be governed by any protocol Lido included. But the moment one protocol controls most validators, it effectively becomes the arbiter of which transactions settle and which don’t. That’s the real power, and it’s not theoretical. It’s live.
The Ethereum community has already seen this coming. Vitalik himself has called out Lido’s dominance as a risk. So have other core researchers. There has been serious discussion some public, some more hushed about socially slashing Lido out of existence if it crosses the line.
This means that if Lido were ever perceived to have enabled, tolerated, or even just failed to prevent a validator cartel acting maliciously, the Ethereum community could respond by coordinating a hard fork that invalidates all Lido validator activity, effectively nullifying their ETH and breaking stETH’s peg forever.
It would be radical. It would be painful. But it would also be an existential defense of Ethereum’s decentralization.
And yes, this is exactly why Lido is pushing CSM v2 now. It’s not just a technical upgrade. It’s a political maneuver. They are trying to decentralize validator selection enough to remain legitimate to avoid becoming the Microsoft or Facebook of Ethereum. Because they know: if they don’t, Ethereum might kill them.
But still even with the custom validators the modules are still chosen by the governance so still even with v2 it wont be safe
CSM v2 doesn’t remove Lido’s power.
It simply moves it one layer higher.
In version 1, Lido governance directly selects validator operators. It tells you who runs the nodes, and how much ETH they get. That’s easy to see, and easy to criticize. So with version 2, they say: “Let’s open the door. Let anyone write a module. Let anyone create their own rules for validator entry, performance, and delegation.”
At first glance, this looks like decentralization.
But it isn’t.
Because governance still decides which modules get included in the router. And the router is the gatekeeper of ETH flow. That’s the real power. It doesn’t matter how many validator sets exist in theory if the Lido router isn’t routing ETH to your module, you don’t matter. Your code sits idle. Your rules are irrelevant. Your validator keys are just keys in a void.
So now, instead of approving validators, Lido governance approves validator modules. It doesn’t choose who runs the validators directly it chooses who gets to choose who runs the validators.
That’s a shallow form of decentralization. It’s not permissionless staking, it’s permissioned delegation with modular cosmetics.
The governance layer becomes a choke point. Every module is a proposal. Every proposal is a political negotiation. Every negotiation can be influenced by friendships, narratives, lobbying, token holders, whales. The power structure doesn’t go away. It just obfuscates itself behind layers of design.
In a way, that’s more dangerous than version 1. Because now, to the average user, the system looks decentralized. They see custom modules, custom scoring, multiple validator types. But under the surface, the same governance cartel decides where the ETH goes. And that means the attack surface isn’t reduced. It’s just disguised.
In version 1, Lido was centralized and obviously so. In version 2, Lido will still be centralized, but in a way that creates plausible deniability.
That’s not decentralization.
That’s governance theater.
And that right there is the sleight of hand that CSM v2 tries to get away with:
“Look, we didn’t write the modules. They’re external. If something goes wrong, it’s on governance for approving it. The router is safe. The system is modular. Our hands are clean.”
Lido DAO can update the module contracts code
All the talk of “modularity,” “permissionless validator entry,” and “performance-based validator markets” falls flat when you realize this:
The DAO can upgrade the module code at any time.
Not just pause it. Not just control ETH flows. But literally rewrite the logic of validator scoring, bonding, delegation, and reward calculation on the fly.
That’s not decentralization. That’s programmable absolutism.
A system that pretends to be open multiple modules, custom logic, validator competition is still governed by a single mutable authority layer. The Lido DAO.
And let’s be clear about what that means in practice.
The DAO doesn’t need to collude with validators directly. It doesn’t need to hand-pick malicious operators. All it needs to do is:
- Approve a module.
- Allow it to go live.
- Upgrade it later, quietly.
Or worse, approve a module that contains an upgradable proxy. It can appear fair and safe at launch, gather delegation, and then get hot-swapped into something malicious after the money’s already inside.
Governance can do this without notifying users, without contract renouncement, without cryptographic constraint. If the module code is mutable, the entire validator market becomes a dark forest of soft trust.
What’s even more dystopian is that users have no way to opt out. When you hold stETH, your stake gets routed through these modules, chosen by governance, operated by unseen actors, and upgradable at any moment. You’re at the mercy of people you didn’t elect and logic you can’t audit in advance.
Overall thoughts on Lido
But here’s the problem: power compounds.
In 2023, Lido was already too big. By 2025, it’s launching Custom Staking Modules, which superficially open the door to permissionless operators, but only behind the gate of DAO-approved modules. Modules that can have any logic. Modules that are mutable. Modules that can redirect fees, tweak scoring, and punish behavior with no objective standard. In short: programmable validator politics.
The DAO remains the final gatekeeper. And even if you’re allowed to run a validator through some future module, you still don’t own your stake, you still answer to someone else’s logic, and you still depend on an oracle telling you what you earned.
Now let’s talk about EIP-7002, which lets the withdrawal address force validator exit.
This, at face value, seems like a safety feature. But it completes the power loop: now the DAO (who controls the withdrawal credentials of every validator spun up through Lido) has both the carrot and the stick. If an operator defects, they get ejected. If they obey, they get rewards. This is not a marketplace. This is a feudal validator economy, where all yield flows upward and all enforcement flows downward.
And that brings us to the real point:
Lido is no longer just a staking protocol. It’s becoming a layer of meta-governance over Ethereum consensus itself.
With CSM v2, it will pretend to be a market where anyone can compete, and the best operators rise to the top. But the rules of that market, the performance metrics, the bonds, the penalties, the module logic all of it is governed centrally by LDO tokenholders, who can vote any logic into existence.
Why is CSM v2 happening at all?
Because Lido knows it’s too big.
The community knows it’s too big.
The only way out is to look more decentralized. To give validators a false sense of agency, and users a sense of diversity. But without renouncing governance power, or giving up control over who gets to play.
It’s not decentralization. It’s plausible deniability.
So what do I think?
I think we are approaching the most dangerous phase of Lido’s evolution: the invisible capture phase. Where no one attacks, no one gets slashed, and no alarm bells ring but every line of code bends toward central control under the guise of “permissionless design.”
And unless the Ethereum community demands something more radical like exitability from staking pools, locked governance, or mandatory module renunciation then Lido will slowly but surely write the laws of Ethereum consensus in Solidity, one module at a time.
And the last validator left outside its gates will be the one running in your basement, wondering why their uptime score never quite hits the quota.
