EIP-7732 Breakout Room Call #25, October 10, 2025

[jtraglia]

UTC Date & Time

October 10, 2025, 14:00 UTC

Agenda

Specifications & testing

Open

• eip7732: add tests for process_withdrawals block processing
• eip7732: add fork choice tests (part1)
• Small fixes to Gloas spec
• TODO: Remove merkle proof tests in Gloas (reference)
• TODO: Add pending payment withdrawal epoch asserts (reference)

Merged

• Fix output for gloas test

Implementation updates from client teams

• Prysm
• Lighthouse
• Teku
• Nimbus
• Lodestar
• Grandine

Trustless payments

Quick writeup: https://hackmd.io/@tchain/payment-config

• Should we have trustless payments in the current EIP in the first place? Is it possible to separate so we don't have to decide the following points right now?
• If we are to keep trustless payments, how would that look in-protocol? E.g., should bids go through the withdrawal queue directly? What are the tradeoffs?
• How would off-protocol bids be supported? How and what should we standardize?

Some discord threads from after the discussion on ACD:

• https://discord.com/channels/595666850260713488/1423326524873900238
• https://discord.com/channels/595666850260713488/874767108809031740/1422849400647979078

Attestation container refactoring

• EIP-7732 Breakout Room Call #25, October 10, 2025 #1744 (comment)

Reusing the same container adds complexity & confusion.

Call Series

EIP-7732 Breakout Room

🔧 Meeting Configuration

Duration

60 minutes

Occurrence Rate

bi-weekly

Use Custom Meeting Link (Optional)

• I will provide my own meeting link

Facilitator Emails (Optional)

jtraglia@ethereum.org

Display Zoom Link in Calendar Invite (Optional)

• Display Zoom link in invite

YouTube Livestream Link (Optional)

• Create YouTube livestream link

[github-actions]

⚡ Protocol Call Resources:

✅ Zoom: Join Meeting
✅ Calendar: Add to Calendar
✅ Discourse: Discussion Topic
✅ YouTube Live: Watch Live

[linoscope]

As a continuation of our ACDC call last week, I would like to talk about trustless payments in ePBS. I believe the following should be covered:

• Should we have trustless payments in the current EIP in the first place? Is it possible to separate so we don't have to decide the following points right now?
• If we are to keep trustless payments, how would that look in-protocol? E.g., should bids go through the withdrawal queue directly? What are the tradeoffs?
• How would off-protocol bids be supported? How and what should we standardize?

[terencechain]

• How would off-protocol bids be supported? How and what should we standardize?

@linoscope I have a quick writeup here: https://hackmd.io/@tchain/payment-config feedback welcome

[mehdi-aouadi]

I'd like to discuss an eventual attestation container refactoring since the attestation.data.index is now used to signal the payload status of the block being attested to.
In Electra we agreed to set the index to 0 and now we're reusing it which introduces a conceptual change.
Even though the container still has the same data structure, the index field is interpreted differently based on the fork:

• Phase 0 -> Deneb : represents the committee index
• Electra: ignored and set to 0
• Gloas : could be 0 or 1 to signal the payload status

This have many side effects:

• The /eth/v1/validator/attestation_data rest api since in Electra we've introduced this change that won't be valid anymore:
  https://github.com/ethereum/beacon-APIs/blob/master/apis/validator/attestation_data.yaml#L21
• The gossip rules https://github.com/ethereum/beacon-APIs/blob/master/apis/validator/attestation_data.yaml#L21
• The attestation creation: https://github.com/ethereum/consensus-specs/blob/master/specs/gloas/validator.md#attestation

Reusing the same attestation container without introducing a new spec changes (a new Gloas attestation container) will likely introduce bugs and add complexity/confusion on how the index field should be interpreted.

[akashkshirsagar31]

X Stream: https://x.com/i/broadcasts/1lPKqvlmQLbGb