Hey Lido community 
I am writing on behalf of Erigon, the team running the Ethereum execution layer client and Caplin (consensus layer client). With CMv2 now live and the Public Good Operator type active, we wanted to formally introduce ourselves and share where we stand.
Who We Are
Erigon is one of Ethereum’s execution layer clients, running alongside Geth, Nethermind, Besu, and Reth. We also develop Caplin, our consensus layer client, making us one of the few teams building both EL and CL implementations.
Our Journey with Lido
Since late 2025, we’ve been working with the NOM team (Will, Ivan, Sat) to support Lido operators who want to validate Ethereum using Erigon+Caplin.
We’re now running the same stack ourselves. Same client, same guides, same failure modes — which means when an operator hits something, we’ve usually hit it too.
Hoodi Testnet - the dry run:
- We deployed 15 validators as a deliberate learning exercise before touching mainnet. It paid off: we found and fixed a Caplin issue that was hurting attestation performance, and worked out all the operational details — key generation, pre-signed exit messages, ejector setup, monitoring — in an environment where mistakes cost nothing.
Mainnet - Live:
- Our CSM Node Operator is now active with 500 keys deposited and is already participating in validation.
The setup:
-
2x Erigon+Caplin nodes (3.5), each in a different European datacenter
-
Lighthouse VC
-
MEV-Boost with the Lido-vetted relay set
-
validator-ejector running on both EL nodes
-
Private network between all nodes
The two nodes sit in separate cities for HA, and we’ve tested that properly rather than assuming it works. We can take one EL/CL node out for maintenance — version upgrade, kernel patch, whatever — while the other keeps serving the VC, with no impact on validator duties. That was the main thing we wanted to prove before putting real stake behind it.
Governance:
-
Voted FOR on LIP-33, LIP-35, SDVTM wind-down
-
Voted FOR on 0x02 CSM launch and CMv2 Penalty Framework
-
Holding LDO and actively following governance discussions
Why Public Good Operator?
We noticed that CMv2 went live in July with the Public Good Operator type, and the first rebates were awarded to seven client teams on July 24th.
Looking at the Node Operator Type Assessment Framework, the Public Good Operator type is defined as:
“an entity developing or substantially supporting in a financial manner an Ethereum Execution, Consensus Layer or validator client.”
As developers of both an EL client (Erigon) and a CL client (Caplin), we believe we clearly meet these criteria. Client diversity remains critical for Ethereum’s resilience, and having a client team as a node operator creates a direct feedback loop: operational insights improve the client for everyone running it.
Our Ask
We understand that the Public Good Operator type is assignable to existing Curated Node Operators, and that new operators typically enter through onboarding rounds as Professional Operators.
However, we note that the Node Operator Type Assessment Framework provides for exceptional onboarding cases where the CMC may propose operators that “enable meaningful collaboration with an important ecosystem participant” or “advance the protocol’s strategic objectives.”
As developers of both an Execution Layer and Consensus Layer client, we believe we could represent such an exceptional case. We’d welcome guidance from the CMC and community on whether this path is appropriate, or whether we should wait for the next standard onboarding round.
Specific questions:
-
Is an exceptional onboarding case viable for a client team like Erigon?
-
If not, what is the expected timeline for the next onboarding round?
-
Are there additional steps we should take to strengthen our application?
In the meantime, we continue building our operational track record in CSM and participating in Lido governance.
Happy to answer any questions about Erigon, Caplin, or our infrastructure.
Links: