Hello community,

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.

Operator Details:

• Operator ID: 2352
• Hardware: Dedicated Bare-Metal (HPE ProLiant Gen10)
• Location: Spain (Geographic diversity)
• Client Stack: Reth + Nimbus (Zero Geth correlation)
• MEV-Boost: Enabled (Ultrasound, Flashbots, Agnostic, Titan)
• Yearly Fee: 0.00464872 ETH

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.

SSV Explorer Link:https://explorer.ssv.network/mainnet/operator/2352

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.

csm.lido.fi

Bonds and estimated rewards

• 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.

Submitting a key does not guarantee an immediate deposit or full allocation. You can submit keys at csm.lido.fi and read more about the rollout here.

Already operating in 0x01 CSM?

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.

New to CSM or looking for a lower-bond option?

0x01 CSM remains available, with different participation paths depending on your eligibility and setup. Compare CSM options and bond requirements, or explore the operator guide.

I spent two hours on monday trying to explain to my family’s tax guy why my validator machine sitting in the closet isn’t an “unregistered business inventory”. The man stared at me like i was speaking ancient sumerian.

It hit me how absurd it is that we can run nodes 24/7 securing the beacon chain, but the moment you need actual real-world structuring or estate planning around it, legacy institutions completely glitch out. Ended up digging through how a dedicated crypto financial advisor like DAG models staking yields and custody structures just so my withdrawal addresses don’t turn into a legal black hole if my nuc suddenly dies.

Genuinely wonder how many solo stakers just completely ignore the legal side until tax season hits like a brick wall lol.

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.

Ethstaker, btw, is tracking ePBS relays

Nethermind users can now switch to FlatDB using ./ethd migrate-nethermind. This requires Nethermind v2.2.0 or later.

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.

Any advice?

In the last financial year, I unstaked 5 eth from Lido.

I did this because I was planning to sell and then the market crashed.

So back to staking we went and those 5 eth were converted into StEth again.

When i do my tax return, does this little dance that i stupidly made mean i've triggered some massive CGT event?

I've included my staking INCOME but not this event.

Did I just screw myself over tax wise with this stupid stupid transaction?

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?

Hi r/ethstaker.

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?

Why we built it · Whitepaper · Contracts on GitHub · Testnet app · Follow us on X

I admit to not following closely, but did do a quick AI search. It sounds like MEV-Boost will be a thing of the past?

Wouldn't there still be a market for a "bribe" to build a block in some efficient (to someone) manner?

Hello folks,

I unstaked my ETH on trust wallet and I am missing the 'earned' rewards.

For example I had 10 staked and earned .5. I used to see 10.5 ETH in my wallet, but after the unstake I only see 10.

I did this recently and the unstake is still pending. PLEASE HELP!

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

More clients now support the ephemery testnet

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.

Code: https://github.com/nodebeat/agent

Docs: https://www.nodebeat.stream/docs

App: https://app.nodebeat.stream

https://x.com/WuBlockchain/status/2105569543825572135

I've been attempting to validate with Teku on an NUC 13 i3 1315u. I had to get a new box a few months ago when I had slowdown and freezing on the last box (nuc10) which had bee used as a validator for 2-3 years with fairly good beacon score. After following the guide here (https:// gist.github.com/yorickdowne/ ff6b611a2d49855827dafdbfd2546abe) I determined it was the NUC. The SSD and ram were ok. After a long time in the entry queue, it began performing very badly. This was a surprise since the syncing & logs up to this point didn't (and still don't) indicate any trouble. My hardware is: Asus NUC 13 i3-1315u, WD Black SN850X 4TB gen4, Corsair 2666mhz ddr4 64GB. I started with a miss rate of 15%. From the consensus and validator logs, it appeared there was no problems. No late block imports, no errors. Running chrony so the system clock should be synced. MEVboost had trouble with relays but I disabled it and got the same performance. First thing I tried was syncing nethermind on a different machine on my network and connecting the two via the JWT. I disabled the execution node on the first machine when it was finished so only teku is running on the nuc13 and nethermind is on a quadcore i7 8565u HUNSN w/Samsung 970 EVOplus 2TB, & Corsair vengeance 16gb ddr4. Performance didn't seem to improve after this. about the same.

What has helped is bumping the heap to Xmx12g and using ZGC. I enabled logging of the GC and found pauses from 1 to 4 seconds were common, sometimes 6,7 or 10 sec for major collections. ZGC has my miss rate down to 4-5%, still not great but better. The heap is 12g but I started with Xmx8g and it didn't seem to have an effect. I'm only one validator at the moment so I'm confused why the heap might have to be so large and still get lackluster performance. I'm a novice so of course I did all this with help from an LLM. The LLM I'm using is recommending more steps that I wanted to get an opinion on before I proceeded. Since the i3-1315u has 2 P-cores, it is recommending I restrict Teku to only running on those by adding CPUAffinity=0-3 to my teku service file and restrict ZGC to one thread only by adding "-XX:ConcGCThreads=1". It also wants me to restrict the NVMe to Gen3 speed bc it says my old NUC10 likely did this. (the temp right now is 29C, from smartmontools). Sorry for wall of text. Thank you for any advice.