feat(builder): add `bid_included` event by markolazic01 · Pull Request #9875 · ChainSafe/lodestar

markolazic01 · 2026-08-20T13:36:50Z

Motivation

Introduce a new bid_included event which carries block_hash and builder_index bid fields (PoC).

Description

Introduces a new event, opposing the implementation in #9854 where the block event is extended.

Addition of the event to EventType surfaced a type mismatch bug which was fixed with explicit typing here:
https://github.com/markolazic01/lodestar/blob/db528d682aec8480a6a81e12988a628d1ca004d5/packages/beacon-node/src/api/impl/events/index.ts#L17

Update: switched from block_hash and builder_index to signed_bid (SignedExecutionPayloadBid)

AI Assistance Disclosure

External Contributors: I have read the contributor guidelines and disclosed my usage of AI below.

Used Claude to inspect the typing bug and audit the changes.

nflaig · 2026-08-20T13:49:37Z

  /** The node has received a block (from P2P or API) that passes validation rules of the `beacon_block` topic */
  blockGossip = "block_gossip",
+  /** The node has received a gloas block (from P2P or API) that includes an execution payload bid */
+  bidIncluded = "bid_included",


was wondering, do we have a better name for this? I haven't really spent to much thought on it yet

Maybe block_bid?

having hard time on this one to come up with a good name 😅

maybe we can ask the keeper to give us some ideas

nflaig · 2026-08-20T13:49:51Z

          // TODO: What happens if this handler throws? Does it break the other chain.emitter listeners?

-          onEvent({type: topic, message: data});
+          onEvent({type: topic, message: data} as routes.events.BeaconEvent);


why is that needed?

There's an error which shows up without explicit typing:

packages/beacon-node check-types$ tsc │ src/api/impl/events/index.ts(17,19): error TS2345: Argument of type '{ type: routes.events.Even… │ Type '{ type: routes.events.EventType; message: any; }' is not assignable to type '{ type: Ev… │ Types of property 'type' are incompatible. │ Type 'EventType' is not assignable to type 'EventType.fastConfirmation'. │ Found 1 error in src/api/impl/events/index.ts:17 └─ Failed in 2s at /Users/lqzic/lodestar-my/lodestar/packages/beacon-node

Though this has nothing to do with fastConfirmation, it is the last event in the list so it gets 'called out'.

but this is strange, why does this new event trigger this type error?

I am not completely sure, will dig more

nflaig · 2026-08-20T13:50:19Z

+  [EventType.bidIncluded]: {
+    slot: Slot;
+    block: RootHex;
+    blockHash: RootHex;
+    builderIndex: BuilderIndex;
+  };


would be simpler to just emit the signed bid object?

yes, I can switch to that, I was following the discussion on what it should look like
switching

nflaig · 2026-08-20T14:36:05Z

+    slot: 10,
+    block: "0x9a2fefd2fdb57f74993c7780ea5b9030d2897b615b89f808011ca5aebed54eaf",
+    signedBid: ssz.gloas.SignedExecutionPayloadBid.fromJson({
+      message: {
+        parent_block_hash: "0x9a2fefd2fdb57f74993c7780ea5b9030d2897b615b89f808011ca5aebed54eaf",
+        parent_block_root: "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2",


so the slot is duplicated now, need to think about it a bit more what we wanna emit in the event, if we emit a spec container objects, the event itself should also have a version/data container schema

can I introduce versioning then and remove the slot?

I am wondering if we should keep the block or not, it would be nice to have a clean spec object emitted

can we just introduce another location where the execution payload bid is emitted then? if we remove the 'block' then 'bid_included' and 'executionPayloadBid' have the same payload. It makes sense to have a name difference there but maybe it seems weird when payloads are the same.

but essentially we wanna emit it for every block we import successfully if it has a bid from a builder included (ie. exclude self-build blocks), but yes more or less it's just emitted together with the block event

@markolazic01

## Motivation Split out from the block / builder event PRs (#9854, #9875, #9876) as a standalone change, as suggested by @markolazic01. The `eventstream` handler in `getEventsApi` forwards every emitter event through a single `onEvent({type: topic, message: data})` call, where `topic` is the full `EventType` union and `data` (and therefore `message`) is `any`. That object literal only type-checks via TypeScript's discriminated-union distribution path (`typeRelatedToDiscriminatedType`), which bails out once the number of source discriminant combinations exceeds 25. `EventType` currently has exactly **25** members, so it compiles today. Adding a **26th** event tips it over the cap and fails with: ``` TS2345: Argument of type '{ type: EventType; message: any; }' is not assignable to parameter of type 'BeaconEvent'. Types of property 'type' are incompatible. Type 'EventType' is not assignable to type 'EventType.<lastMember>'. ``` which is why each new-event PR currently has to add this cast. Landing it once here unblocks those PRs without each carrying the change. ## Description Assert `routes.events.BeaconEvent` at the `onEvent` call. The cast only makes explicit the type erasure that already exists at this `chain.emitter` boundary — `message` is `any`, so the topic/message pairing was never verified by the compiler regardless. The only cast-free alternative would be to construct the event per-topic instead of funneling every topic through one union-typed `onEvent({type, message})` call, which is a larger refactor not worth it here. **No runtime or current-compile behavior change** on `unstable` (25 `EventType` members). --- 🤖 Generated with AI assistance --------- Co-authored-by: lodekeeper <lodekeeper@users.noreply.github.com>

markolazic01 · 2026-08-23T12:22:19Z

          executionOptimistic: blockSummary != null && isOptimisticBlock(blockSummary),
        });
      }
+      if (this.emitter.listenerCount(routes.events.EventType.bidIncluded) && isGloasBeaconBlock(block.message)) {


Exclusion of self built blocks is missing here, reminder if we decide to go with this version.

markolazic01 · 2026-08-23T13:13:50Z

Final shape: block(rootHex) + SignedExecutionPayloadBid
(slot field removed as it is already present inside SignedExecutionPayloadBid)

feat(builder): bid_included event

db528d6

markolazic01 requested a review from a team as a code owner August 20, 2026 13:36

github-project-automation Bot added this to Lodestar Team Coordination Aug 20, 2026

github-project-automation Bot moved this to In Progress in Lodestar Team Coordination Aug 20, 2026

Merge branch 'unstable' into feat/bid-data-event

e2a1a56

nflaig reviewed Aug 20, 2026

View reviewed changes

feat(builder): switch to full signedBid emission

6a0fd9f

nflaig reviewed Aug 20, 2026

View reviewed changes

fix: remove slot

c93aa2d

markolazic01 mentioned this pull request Aug 20, 2026

feat(builder): add included_execution_payload_bid event #9876

Draft

1 task

markolazic01 marked this pull request as draft August 20, 2026 18:19

markolazic01 added 2 commits August 21, 2026 23:09

Merge branch 'unstable' into feat/bid-data-event

9015d42

fix: remove slot leftover

25a12a7

lodekeeper mentioned this pull request Aug 21, 2026

refactor: assert BeaconEvent type in eventstream handler #9894

Merged

markolazic01 mentioned this pull request Aug 21, 2026

feat: add blockV2 event with new builderIndex and blockHash fields #9896

Draft

Merge branch 'unstable' into feat/bid-data-event

743c79a

markolazic01 commented Aug 23, 2026

View reviewed changes

Uh oh!

Uh oh!

Conversation

markolazic01 commented Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

markolazic01 commented Aug 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

markolazic01 commented Aug 20, 2026 •

edited

Loading