Update lodestar-eip-7732-builder.md

projects/lodestar-eip-7732-builder.md

@@ -120,7 +120,7 @@ flowchart LR
 
 **Week 5 -- Proposal and scope.** Finalize the proposal, living note, base-branch assumptions, and FOCIL/Deathstar scope. *Deliverable: accepted proposal and agreed scope.*
 
-**Weeks 6-7 -- Architecture and builder skeleton.** Map Gloas codepaths, confirm current PR state, choose the service boundary, and build the first configuration/key-handling skeleton. *Deliverable: builder skeleton that starts and connects.*
+**Weeks 6-7 -- Architecture and builder skeleton.** Map Gloas codepaths, confirm current PR state, choose the service boundary, and build the first configuration/key-handling skeleton. *Deliverable: builder skeleton with separate keystore and remote-signer support that starts and connects.*
 
 **Weeks 8-10 -- Preferences, payload, and bid.** Consume proposer preferences, prepare a local payload candidate through the Engine API / self-build path, and construct, sign, and publish valid bids with a baseline policy. *Deliverable: published valid bid for a locally built payload.*
 
@@ -138,8 +138,6 @@ flowchart LR
 
 **Builder service boundary.** The cleanest home for `lodestar builder` is not obvious; the first prototype may need to live near existing beacon-node or validator-client services to reuse code.
 
-**Base branch uncertainty.** `unstable`, a Glamsterdam devnet branch, or FOCIL-related work based on discussions with the Lodestar team -- kept open deliberately.
-
 **Builder identity, registration, and balance.** Builders onboard through dedicated EIP-8282 deposit/exit request contracts (deposits carry inline-verified proofs of possession; exits are authorized by the builder's execution address), need active status and excess balance covering bids plus pending payments. Registration must be reproducible on a devnet, and deposit-signature verification is a known performance surface ([Lodestar #9436](https://github.com/ChainSafe/lodestar/pull/9436)).
 
 **Payload cache correctness.** The exact bid -> payload mapping must survive to reveal; misses and mismatches fail closed. Recent envelope-cache and idempotency PRs show this path has real resource and correctness edge cases.
@@ -163,15 +161,18 @@ The project is successful if Lodestar has a working, tested, and documented hone
 - Reproducible local end-to-end demo with a real local execution client.
 - Configurable bid policy plus bid/win/reveal/timing logs and metrics.
 - One or more PRs merged or in review.
-- Heze / FOCIL adaptation pass if FOCIL has merged to `unstable` (blocked by [FOCIL](https://github.com/ChainSafe/lodestar/pull/7342)).
+- Heze / FOCIL adaptation pass ([dependency](https://github.com/ChainSafe/lodestar/pull/7342)).
 - Server-side of the builder api and serve trustless bids via api (blocked by [client-side builder api](https://github.com/ChainSafe/lodestar/pull/9594) + specs).
 - Final write-up of what existed, what was added, and what remains.
+- Advanced payload preparation: predict whether the proposer will build on the FULL or EMPTY parent and prepare payloads ahead of time, potentially multiple per slot ([see more](https://github.com/eth-protocol-fellows/cohort-seven/pull/161#discussion_r3574786863)).
 
 **Stretch success:**
 
 - Improved bid policy beyond a fixed constant.
 - Builder-adversarial Deathstar matrix with one or two implemented scenarios.
 - Deeper write-up of builder bidding constraints under ePBS and follow-up issues for future adversarial builder work.
+- Run a kurtosis devnet with lodestar builder and Buildoor, consistently out-bid Buildoor's bids and get selected.
+- Research and potentially introduce envelope withholding when early attester signals suggest a weak proposer block (note that there is no unbundling risk in Lodestar and keep in mind that withholding payload on a future canonical block results in a fund loss).
 
 ## Collaborators