# EIP-7732 Breakout Room #20 In this call, we covered two major areas: (1) builder → proposer payment design, (2) fork choice signaling, and briefly discussed alternate designs and slot time implications. --- **1. Builder → Proposer Payment** The current 7732 spec changes the builder-to-proposer payment flow in a way that may break existing staking pool contracts, requiring them to rewrite and re-audit their infra. We discussed two simple alternatives to preserve compatibility: * Pay to the proposer’s withdrawal address * Add a new field in the bid to specify a fee recipient (similar to validator registration today) Both options keep the payment within the CL, not EL. Lido (on the call) indicated this would be sufficient for their needs. Other notes: * Supporting compound validators (e.g. allowing self-building with a zero address or similar) is desirable * Payment could be withdrawn from CL to EL using something like EIP-7002 or via a sweep of pending withdrawals **Action item:** Core devs and staking protocols should weigh in on how expressive the payment mechanism needs to be. --- **2. Fork Choice Signaling** We reviewed Potuz’s latest fork choice proposal: [https://hackmd.io/@potuz/HJj04nT7gl](https://hackmd.io/@potuz/HJj04nT7gl) — specifically the section on signaling via attestations. The goal is to protect honest builders by allowing attesters to enforce behavior, especially without relying on reveal boost (which we are aiming to remove). Two signaling approaches were discussed: 1. (Block, Slot) voting in fork choice 2. Adding a `block_hash` or boolean flag to attestations Lighthouse and Prysm expressed that changing attestation data to support this is fine and even preferable for cleanliness. Open questions include: * Should we increase the attestation count in blocks? * Should we verify that block hashes in attestations aren't junk? * A boolean field simplifies this and avoids changes to the state transition function Consensus on the call leaned toward avoiding any state transition changes and limiting changes to fork choice logic. Builder-withheld block safety would still be ensured via standard attestation inclusion delays (i.e. next epoch). This mechanism already exists to avoid slot level huge balance transfer -> attack. **Action item:** Core devs should share any objections to adding a boolean or block hash field to attestations. --- **3. Alternate Designs + Slot Duration** Ansgar raised concerns around PTC and unconditional payments. He encouraged the group to also think 7732 against alternate designs. Toni echoed the sentiment, suggesting we: * Explore the entire design space * Keep unconditional payment separate * Consider removing both unconditional payment and PTC in favor of a staked builder model, with builder safety guarantees Potuz countered back: it's important to note if you want to separate broadcast from block inclusion and maximize throughput up to the PTC attestation, PTC is currently the only known way to do this. We briefly touched on EIP-7732 and its interaction with slot duration. For more, watch the video [recording](https://www.youtube.com/watch?v=b2Z0T6GcxTg)