Getting Ready for Glamsterdam with Lighthouse

Update (23 Oct 2026): The Glamsterdam fork on Hoodi has been cancelled until further notice. All Hoodi users must upgrade to Lighthouse v8.3.2, which disables the fork, and update their execution client before 26 Oct at 17:42 UTC. We'll update this post once a new fork date is set.

Glamsterdam was scheduled to fork on Hoodi on Mon 26 Oct 2026 at 17:42 UTC (epoch 132352). Lighthouse v8.3.1 supports the fork, and our new experimental release v8.4.0-rc.0 adds native bid streaming.

The fork brings ePBS (enshrined proposer-builder separation, EIP-7732), which separates the execution payload from the beacon block so blocks can safely get larger, and adds builders to the protocol. Hoodi is the last public testnet before mainnet, so it's a good place to test your setup. In this post we cover what changes, how to upgrade Lighthouse, set up builders and turn on bid streaming, and how to connect to Bombora, Sigma Prime's block builder, which bids on Hoodi from the fork.

Before the fork:

1. Upgrade to Lighthouse v8.3.1 or later, and a Glamsterdam-ready execution client.
2. Add your builders to builder_definitions.yml and restart the validator client.
3. If you use MEV-Boost or Commit-Boost, keep its flags until the fork has passed.
4. Optionally, turn on bid streaming (v8.4.0-rc.0) and add Bombora.

What Changes with ePBS

ePBS splits the execution payload from the beacon block. The proposer publishes the beacon block with a builder's bid, and the builder publishes the payload later in the slot. That gives the payload more time to propagate and execute, so blocks can safely get larger. Before their slot, proposers also publish their preferences, such as fee recipient and gas limit, up to an epoch ahead, so builders know what to build.

Slot structure before and after Glamsterdam.

It also adds builders to the protocol. A proposer can now get bids straight from builders, over HTTP or over the peer-to-peer network (gossip), without running a sidecar or going through a relay. Relays can still take part by staking as builders, and whether to connect to them after the fork is up to each operator.

Before and after Glamsterdam, from the proposer's side.

Builders pay proposers in two ways:

• A consensus payment comes from the builder's balance on the beacon chain, and the protocol enforces it.
• An execution payment is made inside the payload. The proposer has to trust the builder to pay it, as with MEV-Boost payments today. It lets a builder bid more than its balance on the beacon chain, which matters for high-value blocks.

For all the EIPs in Glamsterdam, see Glamsterdam on Ethereum.org. For more on ePBS, Mike Neuder's ePBS, distilled is a good read.

Lighthouse Glamsterdam Support and Configuration

Upgrading for the Fork

1. Upgrade the execution client, beacon node and validator client before the fork: Lighthouse v8.3.1 or later, and an execution client release listed in the EF's Glamsterdam Hoodi announcement.
2. Add your builders to builder_definitions.yml before the fork. Lighthouse creates the file in the validators directory (<datadir>/validators by default) the first time the validator client starts. Stop the validator client before editing it, then start it again - it only reads the file at startup. There's an example in the next section.
3. If you use MEV-Boost or Commit-Boost today, keep --builder on the beacon node and --builder-proposals on the validator client until the fork, because blocks before the fork still go through them. After the fork, Lighthouse no longer needs these two flags. If --gas-limit is set, leave --builder-proposals in place after the fork, because the validator client doesn't yet start with --gas-limit on its own.

Sidecars like MEV-Boost and Commit-Boost still work after the fork, but need a release that supports Glamsterdam, so check with each project before upgrading.

Configuring Builders

With no builders configured, the beacon node picks between its locally built payload and bids from gossip. Gossip bids are public and only carry consensus payments. Direct bids from configured builders can include execution payments as well as consensus payments.

Here's an example builder_definitions.yml with Bombora. The Lighthouse book has every field and its default, including per-validator overrides.

# <datadir>/validators/builder_definitions.yml
builders:
  - enabled: true
    url: "https://hoodi.bombora.network"
    max_execution_payment: 0  # Gwei; 0 means no execution payment

max_execution_payment is the largest execution payment the proposer is willing to trust from that builder. The cap is sent to the builder, which has to keep its execution payment within it. When comparing bids, the beacon node also ignores any execution payment above the cap. With 0, the builder can only pay through the consensus payment, so a builder that prefers execution payments might bid less or not at all. Raising the cap lets builders pay that way, at the cost of trusting them to pay.

Circuit Breaker

If builders keep failing to deliver payloads after the fork, the beacon node falls back to building the block itself. It still collects bids, but only uses one if its own build fails. The thresholds are configurable - see the Lighthouse book.

Bid Streaming

Over HTTP, the beacon node requests a bid from each configured builder at proposal time and waits for the response. With streaming, the beacon node connects to each builder shortly before the slot and keeps the connection open until it proposes. In that window, a builder can keep sending better bids, each replacing the last, so the beacon node always has each builder's latest bid. Streaming also puts the proposer in charge of when the auction closes: the beacon node uses the bids it has at proposal time, without waiting for builders to respond. The same stream makes it possible to support things like bid cancellations later. Lighthouse uses the same stream format as Commit-Boost's Gloas bid streaming, so it works with builders and relays that already serve it. Thanks to the Commit-Boost team!

Bid streaming is built into the Lighthouse beacon node from v8.4.0-rc.0. It's experimental and off by default: turn it on with --builder-bid-streaming on the beacon node. Lighthouse opens the stream at the same builder URL and uses HTTP as a fallback.

Bid delivery: HTTP vs streaming.

Bombora

Bombora is Sigma Prime's block builder which has been landing blocks on mainnet since it launched in March, via the existing PBS rails. It has been successfully tested with ePBS on Devnet-8 and Sepolia. From the fork, it bids on Hoodi one way per slot: directly over HTTP or a bid stream, over gossip, or through relays. Each independent builder bidding directly means another bid competing for the proposer's block and more builder diversity. Our goal is to ensure that all bidding venues and payment pathways are thoroughly tested in preparation for mainnet.

Connecting to Bombora on Hoodi

• Endpoint: https://hoodi.bombora.network.
• Set max_execution_payment for Bombora to 0 or the maximum value (18446744073709551615), depending on whether you trust it to pay. Bombora only sends direct bids for these two values.
• Commit-Boost users can connect to Bombora by listing https://hoodi.bombora.network in Commit-Boost's [[relays]] and setting auth_data: "0x686f6f64692e626f6d626f72612e6e6574776f726b" (hoodi.bombora.network in hex) on the builder_definitions.yml entry that points at Commit-Boost.
• Searchers can send bundles to https://rpc-hoodi.bombora.build.

Next Steps

Upgrade before 26 Oct, then try the builder config and Bombora on Hoodi before mainnet. Builders with a Hoodi endpoint are welcome to test against Lighthouse - let us know if anything doesn't work. Our mainnet post will go into more detail on how block building and payments change, along with what's coming next in Lighthouse and Bombora.

We're keen to hear what you think. For Lighthouse, find us on Discord. For Bombora, validators can reach us on Telegram or in the #bombora channel on the Lighthouse Discord, and searchers in our searcher Telegram group.

Thanks for reading!