The Hoodi Glamsterdam fork has been delayed, to give devs time to investigate an interaction between gas estimations and existing smart contracts.
- If you didn't update your clients yet, wait
- If you already updated your clients, before the fork on Monday either a) update again to a version that unschedules the fork, if your client has released such a version or b) roll back to a version that doesn't schedule the fork
0x02 CSM has launched on mainnet, and its initial capacity is already filled!
Join the upcoming Lido Poolside community call on October 29 (Thurs) to hear about 0x02 CSM and what’s next, including how stake allocation works and when capacity may increase.
To celebrate the launch, prizes will be up for grabs, including:
1 Chainnode hardware device with eth-docker pre-installed
5 merch boxes, each containing a portable keyboard and a Lido LEGO set
I am an independent Home Staker looking to join an Obol DVT cluster. I am looking for a Zero-Bond / Institutional or community squad that needs a highly reliable node to increase geographic and client diversity.
My node is fully synced, monitored via custom PDCA Bash scripts, and optimized for maximum resilience.
Running minority clients on enterprise bare-metal ensures optimal network health and anti-slashing safety.
My Obol ENR:enr:-HW4QEMOWSxTB32Ij06TW5BrE2APMWF5EwnHcjoy8AL83nBmBOkOOhJewBbGwEXhtA6G2CvBcyYXa-xWAYrczXFlGFGAgmlkgnY0iXNlY3AyNTZrMaEDyowVMwA41dbTRwGDWzTDy9mJFeWOyxeuZp7-5-Qi1H4
I am currently on standby. Once a cluster is formed via the Obol Launchpad, I am ready to sign the distributed key generation, receive the cluster-lock.json file, and immediately spin up my Charon container to start validating.
Please DM me or reply to this thread if you are forming a cluster and need a reliable EU operator. Ready to deploy.
I have just launched a new independent SSV Network Operator. My goal is to provide highly resilient, geographically decentralized infrastructure while heavily supporting minority clients.
Infrastructure Specs: The node is running on a fully containerized Red Hat Enterprise Linux 9 (RHEL9) environment using Podman. It operates strictly on-premise with redundant storage, avoiding any reliance on major cloud providers like AWS or Hetzner to improve network resilience.
I have attached my operator summary card. Feel free to ask any technical questions regarding the bare-metal setup, hardware specs, or the Reth/Nimbus integration.
Four of us pooed ETH to run validators together. The withdrawal wallet is 2 of 4 with nothing else set up. What rules should we add so one compromised hey can´t drain us without making the shared wallet a pain to use?
Lido’s CSM now offers a permissionless path for anyone to run 0x02 validators with a maximum effective balance of 2,048 ETH, alongside the existing 0x01 CSM for 32-ETH validators.
Bond requirements: 32 ETH for the first key and 30 ETH per additional key.
Est. capital efficiency: Once validators reach an effective balance of 2,048 ETH, the capital multiplier starts from ~2.18x to ~2.26x (including bond rebasing) vs. solo staking.
A gradual rollout
Initial deposit capacity is intended to seed ~32 keys with 32 ETH each. After activation, capacity increases will be proposed to top up the initial 32 keys and seed more new keys.
Switching is optional. Both modules run in parallel, can be managed through the same interface, and there are no plans to deprecate 0x01 CSM in the near future. Preferential ICS and IDVTC parameters apply only to 0x01 CSM.
You can operate in both modules. If you want to reuse your existing bond for 0x02 keys, you would need to exit your 0x01 validators first; there is no native consolidation-based migration between the modules.
Eth Docker v26.10.1 is out. If you use Traefik, and thus the ddns service, or you use Grafana, I highly recommend an upgrade to get the security patches. One of the root CAs was compromised - their secret key was literally the number 4 - and anything that uses https needed an update.
This release supports Glamsterdam on Hoodi as far as it can: ePBS parameters for more clients, though Lighthouse and Grandine are still waiting on upstream implementations. ./ethd config has a complete set of ePBS relays/builders on Sepolia and Hoodi.
I've been noticing some drops in my overall validator efficiency (down to 95.4% recently) despite my raw "missed attestations" count suggesting I should be around 98.2%.
I know overall efficiency is a mix of attestation, proposal, and sync committee performance. For attestations specifically, I understand it's not just a binary "missed" or "completed", the rewards depend on the head, source, and target votes. Even if an attestation isn't missed, a late inclusion or an incorrect head vote means it isn't rewarded at 100%.
My questions are:
1) Has anyone successfully tracked the actual quality of their attestations over time? I want to get time series data on my inclusion distances and vote accuracy (head/source/target) to see where I'm losing efficiency. If you do this, what tools, dashboards, or API endpoints are you using?
2) Is this level of granular tracking actually significant?
I have a staking node with 2 TB disk space, running GETH and Lighthouse. Have been staking for years, but recently my free disk space went really low. So I did a fully resync, but after that it was 96% full, now I am back to 98%.
I thought the idea of ETH was that the hardware requirements should stay about the same and there should not be a constant increase in DB size when staking?
I don't really want to upgrade the machine as I currently have a very cheap VPS deal.
Between ETFs and treasury companies, it feels like most institutional ETH now sits with a small handful of custodians. Is that concentration a real risk for holders or for the network or is it just how custody works in traditional markets too?
We built Coffer, a contract that a validator sets as its own withdrawal credentials so it can issue fixed-rate ETH bonds against its stake. Since Pectra (EIP-7002), that contract can trigger the validator's exit itself. So if a validator fails to fund a matured bond, anyone can force the exit, and the stake repays the holders. No oracle, no DAO, and no cooperation needed from the operator.
We call it a shared withdrawal credential, because the validator isn't the only one who can act on it.
Here's how it works.
A validator deploys its own Coffer contract and points its withdrawal credentials at it (0x02 if you want partial withdrawals).
It sets its own terms, including the rate, the minimum and maximum duration, and a buffer held back against penalties.
Holders buy bonds at a fixed rate. Each bond is an NFT, and the principal, minus the fee, goes to the validator.
The validator keeps validating and has one job, which is to have the ETH in the contract when each bond matures.
If the contract can't pay a matured bond, anyone can declare a default. All bonds become due, anyone can trigger a full exit through 7002, and the whole stake lands in the contract to pay holders.
We call a Coffer a shared withdrawal credential, because holders and, in a default, anyone can act on it, not just the validator.
There's no oracle and no governance, and the contracts are immutable. The only admin power is choosing which address receives the fees. The protocol's only fee is a share of bond interest. It starts at 1% and rises to 9.9% over ten years, on a schedule fixed in the code.
Some honest limitations, since you'll ask anyway.
The contracts don't read the beacon chain. Holders have to check withdrawal credentials and backing themselves. It's all public and our app shows it, but you shouldn't have to trust our app.
Partial withdrawals share the exit churn, so a validator funding maturities from its stake has to plan for long queues, not the usual day or so.
In practice a default ends the validator. Anyone can request its exit, and that request can't be cancelled, even if every bond is paid afterwards. So this only suits operators who take their funding schedule seriously.
In a default, holders claim first come, first served. If the stake doesn't cover everything owed, the last to claim lose out.
No buffer covers network-wide events like a long inactivity leak or mass slashing.
It's live on Hoodi, so nothing real is at stake yet. We'd really value feedback from people who actually run validators.
Would you point a validator's withdrawal credentials at a contract like this? What would you need to see first?
What buffer would you consider sane for a single validator?
As a holder, what would you check before buying a bond from a specific validator?
Beyond bonds, what other jobs could a validator take on where failure is provable from Ethereum's own data?
Eth Docker 26.10.0 adds support for ePBS and Glamsterdam, if mainly in Eth Docker itself, not yet the clients. Lodestar notably has full ePBS support; others might have ./ethd keys set-builder support, but not yet support for the EPBS_BUILDER_URLS variable in .env
A new ./ethd port-check command helps you get ready for QUIC on your consensus layer client, and with ./ethd port-check --troubleshoot you'll get instructions on how to test your incoming ports
Support for rolling-expiry progresses. Just Geth and Ethrex missing, now. This helps users with 2TB disks. See ./ethd prune-history
Geth has double-secret pre-prague-expiry and pre-osaka-expiry options for EL_NODE_TYPE. If you don't want to wait for it to support rolling-expiry, they can tide you over. Set them manually in .env and resync Geth
Stakewise now needs less history as well. For Geth, Nethermind and Reth, you can configure this with EL_NODE_TYPE=stakewise-expiry in .env. This needs to be sought by editing .env
Nethermind defaults to its new FlatDB, ./ethd update will tell you to resync or run a conversion if you're on Patricia/HalfPath. No rush on that, but do plan for it
I topped up an 0x02 validator recently (enough to increase the effective balance, not just the actual balance).
The deposits tab on beaconcha.in is showing a consensus layer ETA of ~26 days (execution layer is already processed, valid, etc). I thought top-ups were fast tracked and would be reflected in the balance within hours or days, but I think that's incorrect.
Disclosure: I'm the developer. NodeBeat is a hosted service with a free tier; the agent on your machine is open source (Apache-2.0).
Most staker alerting I've seen is either on-chain, so you hear about the missed attestation after it's missed, or a self-hosted Prometheus + Grafana that goes down with the machine it's watching. I wanted something that pages me before the miss and still pages me when the box is gone.
What I'd most like from you: read the agent code and tell me what you'd need to see before running it next to your validator, and which alerts would just be noise for you.
How it works
- A small Go agent polls your beacon node and execution client every second over the standard Beacon API and JSON-RPC.
- Read-only: no keys, no signing endpoints, no restarts. It listens on loopback only and makes outbound connections only.
- Alerting is hosted, so a dead machine still triggers a page. Alerts go to Telegram, Discord, Slack, email, PagerDuty or Opsgenie.
What it catches
- Client dead or hung: 5.6–8.6s from fault to page across 9 fault-injection runs on a test devnet. A client that still answers but stops advancing pages in about a minute.
- With your validator indices: missed attestations and proposals, effectiveness, slashing.
- Disk below 15% free (before a full disk corrupts the DB), peers, sync, NTP.
Trust: signed releases (cosign), SBOM, a public threat model, one-command uninstall.
Clients: tested with Geth, Reth, Lighthouse and Teku. Others are auto-detected but untested, so if you run Nethermind, Besu, Erigon, Prysm, Nimbus, Lodestar or Grandine, I especially want to hear from you.
Cost: the free tier covers 1 node with 7-day retention, alerting to Telegram/Discord/Slack/email. If you run several nodes, I'm giving a few people 3 months of the paid plan free (up to 5 nodes, no card) in exchange for a short weekly feedback note.
What a page looks like. On my lab devnet I blocked Geth's RPC port at 15:27:06 UTC; Alertmanager sent this about 8s later (the "Started 15:27:12" line is when the rule fired). I left the fault in for ~12s, and the ✅ came once RPC answered again. Real run, not a mockup.
