I think we saw what I would call a flurry of activity on X today from SSV and figured I would chime in as someone who fits himself as from an infrastructure standpoint a bit above a homebrew- but certainly not some of these major(and well-known) contributors. Here’s what I took some time to dissect and what I am potentially positioning toward- would love to hear how the rest of you are moving in these directions!
Glamsterdam for Home Operators: What Actually Changes on Our Racks
by steve2z — SSV mainnet operator #2258, Hoodi operators #621/#624, running on self-hosted hardware in upstate NY
Glamsterdam (Gloas on the consensus side, Amsterdam on the execution side, targeting Q4 2026) tries to fit meaningfully more work into Ethereum’s 12-second slot without pushing home operators off the network — and the way it does that changes our duty timing and adds a brand-new duty some of our validators will draw.
Why the current slot is the problem
Today, a proposer usually takes a block built elsewhere via MEV-Boost, delivered through a relay. The crunch comes right after: validators get roughly four seconds to check consensus, execute the block, verify blob availability, and attest. If you’ve ever watched your attestation effectiveness dip when a big block landed while your node was busy, you’ve felt this window personally.
You can’t just make blocks bigger inside that structure. A 200M gas block that has to be fully executed inside the same four seconds is how home operators on residential connections and reasonable hardware get squeezed out — and a validator set that only works in datacenters isn’t the network any of us signed up to secure.
ePBS: the handoff moves into the protocol
EIP-7732 (enshrined proposer-builder separation) restructures the slot instead of just stretching it. The flow becomes:
- A builder commits to a payload
- The proposer puts that commitment in the beacon block
- The builder reveals the payload afterward
- Payment is enforced onchain
Relays can still carry bids, but the exchange no longer depends on trusting a relay. More importantly for us: consensus validation and payload execution get decoupled in time. Attesters vote on the beacon block first, and payload execution happens on its own clock — which is what makes bigger blocks compatible with our four seconds of real work.
The new duty: Payload Timeliness Committee
This is the piece every operator should actually plan around. Under ePBS, when one of your validators is selected for the Payload Timeliness Committee (PTC), it has a new job: attest to whether the builder actually revealed the payload on time.
For SSV/DVT operators this matters double. Our clusters already coordinate duties across multiple nodes; PTC adds a time-sensitive duty type our client software has to handle correctly. The client teams (and for those of us running Anchor, the SSV-side implementation) will carry the actual changes — but “my operator handled PTC duties correctly on testnet” is going to be a real differentiator when this ships, the same way blob handling was for Dencun.
State pricing and the 200M gas floor
Bigger blocks create more permanent state that every node stores forever. Glamsterdam reprices state creation so that cost is accounted for as capacity grows. Alongside ePBS and Block Access Lists, that’s what supports a credible 200M gas-limit floor after the fork — capacity growth that’s paid for honestly, instead of subsidized by whoever runs disks at home. As someone whose chain data lives on an NVMe drive I bought myself, I appreciate the honesty.
What I’m actually doing about it (steal this list)
- Following execution and consensus client release channels now — Lighthouse and Nethermind in my case. Glamsterdam devnet/testnet builds will land there first, and the teams have told validators plainly: watch for testnet releases.
- Keeping my Hoodi operators pristine. Testnet is where PTC duties will be exercisable first, and a clean record there is the cheapest credibility an independent operator can earn.
- Reviewing timing assumptions in my monitoring. My alerting is built around today’s slot structure; the fork changes duty timing, so anything that assumes “attestation happens at second X” gets a second look before Q4.
- Not panicking about hardware. The entire design intent here is that current home-operator hardware stays viable. The work is in software readiness and attention, not a new server.
The bigger picture for independent operators
Every mechanism in this fork — ePBS removing relay trust, state repricing, the PTC — points the same direction: scaling the chain while keeping validation open to people running nodes in their houses. That only stays true if we actually show up: run the testnets, exercise the new duties, report what breaks. That’s the part protocol devs can’t do for us.
I’ll be testing Glamsterdam client releases on my Hoodi operators as they land and posting what I find. If you’re running SSV operators on your own hardware, I’d genuinely like to compare notes — especially from anyone else running Anchor, on how PTC duty handling shakes out in a DVT cluster.
Discussion: What’s your biggest operational concern going into Glamsterdam — the new PTC duty, the slot-timing changes, or state growth on your disks?