{
  "meeting": "ACDC #185 - 2026-08-20",
  "sections": [
    {
      "heading": "Devnet 8 (Plataberget) Fork Transition Issues",
      "summary": "Gloas fork activated ~6 hours before the call; multiple CL clients struggled with builder deposit caching, but finality was restored minutes before the call.",
      "timestamp": "00:07:07",
      "body": "- Devnet 8 was stable until the Gloas fork was activated approximately 6 hours before the call; finality was lost and only recovered minutes before the call began.\n- The main issue was that Lighthouse, Prysm, and Teku had problems processing ~16,000 queued builder deposits at the first post-fork slot due to missing or broken deposit caching.\n  - Lighthouse had merged the caching optimization only hours before the fork; deposits that arrived before the feature was added were not cached.\n  - Prysm had removed the deposit cache from their branch while evaluating its value; a separate optimization by Dustin reduced recovery time from over an hour to one slot even without the cache.\n  - Teku experienced prolonged DHX (data hash exchange) processing on the first blocks; a stall-detection mechanism aborted block batches and queued progressively longer retries, causing multi-hour delays. Fix in progress; restarting nodes recovered them after 3–4 hours.\n- Grandine sent proposal preferences before the fork, which triggered a Lodestar bug that broke its event stream, causing Lodestar's connected builder to stop submitting bids.\n  - Nico suggested a missing gossip condition: pre-fork proposal preferences should be ignored.\n- Lodestar and Nimbus reported no fork-transition issues.\n  - Lodestar's optimization brought fork-transition processing down to ~500 ms; all PandaOps nodes had the optimization.\n  - Nimbus measured sub-half-second state transitions even on stress-test scenarios.\n- pk910 noted that on mainnet, deposits will arrive weeks or months before the fork, so relying on hot caches populated during the process runtime is unreliable.\n  - potuz countered that builders will deposit relatively close to the fork, but agreed that no one should expect all nodes to restart right before the fork.\n  - Nico noted the deposit queue is ~40,000 long, meaning deposits can be made almost 2 months before the fork; Lodestar preprocesses deposits two epochs before the fork.\n- potuz and Nico wrote rationale for why the circuit breaker works the way it does; notes shared on ETH R&D."
    },
    {
      "heading": "Non-Finality Devnet Planning",
      "summary": "Clients target trunk branches by next week; a non-finality devnet is planned for roughly the week after, with a possible smaller happy-path devnet for external testers.",
      "timestamp": "00:20:35",
      "body": "- Lido requested at least 1–2 days on a devnet before the Glamsterdam fork to deploy and test oracles and tooling; Optimism also requested a testing environment.\n  - Pari confirmed they can accommodate this and may include external validators in genesis state for the large network.\n- Client readiness for trunk branches:\n  - Lighthouse: ready by next week.\n  - Prysm: already has the changes.\n  - Teku: already on master.\n  - Lodestar: merged and tested on devnet 8.\n  - Nimbus: already on trunk branch (unstable).\n  - Grandine: still on a dedicated branch; hopes to merge to main by next week.\n- The non-finality devnet will run ~1,000 nodes and is expensive; Pari said it likely cannot run for a full week, but 1–1.5 days of pre-fork operation is feasible.\n- Mass deposits from devnet 8 will be repeated on the non-finality network, potentially scaled up; Nico shared a [gist documenting malicious deposits](https://gist.github.com/nflaig/c02c00714d07df076bed23200805d2c6) for reproducibility.\n- A separate, smaller devnet for happy-path testing (with finality) may also be created so external teams can validate their integrations."
    },
    {
      "heading": "Remote Signing API Glamsterdam Changes",
      "summary": "The remote signing API PR for Glamsterdam is still incomplete; client teams asked to review and begin implementing.",
      "timestamp": "00:26:01",
      "body": "- Pari raised [remote-signing-api PR #28](https://github.com/ethereum/remote-signing-api/pull/28) for Glamsterdam changes.\n- Nico noted the PR appears to be missing content.\n- Prysm (james) has a PR open but not yet merged; pinged the author (uzi) for updates.\n- Lodestar has all remote signer features implemented except the signed auth request for the builder API.\n- Client teams were asked to review and start implementing."
    },
    {
      "heading": "Testnet Fork Dates (Sepolia and Hoodi)",
      "summary": "Proposed dates are Sepolia on Mon 28 Sep 2026 and Hoodi on Mon 26 Oct 2026; no formal decision yet — final confirmation targeted for the next ACDC.",
      "timestamp": "00:27:01",
      "body": "- Proposed Sepolia date: epoch 351232, slot 11239424, unix 1790606688, Mon 28 Sep 2026, 14:44:48 UTC.\n  - Rationale: Sepolia is dapp-focused, so forking it first lets application developers test repricing changes early.\n- Proposed Hoodi date: epoch 132352, slot 4235264, unix 1793036568, Mon 26 Oct 2026, 17:42:48 UTC.\n- Lighthouse (kingy_sigp): fine with the dates provided a stable devnet is achieved first.\n- Lido (Dima) preferred both dates pushed back ~1 week to allow more devnet testing time; this sentiment was echoed by SSV (Chris Berry) and others.\n- No objections raised blocking the proposal; decision deferred to the next ACDC (in ~2 weeks).\n- Barnabas noted \"no objection = agreement\" as the operating principle.\n- Pari emphasized the dates are preliminary and contingent on stable devnets and client satisfaction with trunk branches."
    },
    {
      "heading": "EIP-7610 Removal from Glamsterdam",
      "summary": "EIP-7610 (revert creation on non-empty storage) is formally removed from Glamsterdam; EIP-8253 in Hegotá renders it unnecessary.",
      "timestamp": "00:30:12",
      "body": "- jochem-brouwer confirmed that EIP-7610 was decided for removal at the ACDT call on Monday; implementing it would impose performance overhead on clients for a scenario that effectively never occurs.\n- [EIP-8253](https://eips.ethereum.org/EIPS/eip-8253), which is PFI for Hegotá, directly solves the underlying problem by ensuring the targeted account type cannot exist in the state tree.\n- jochem-brouwer will ask the EIP-7610 authors to formally withdraw the EIP.\n- No objections were raised to removing EIP-7610.\n- Before the removal PR can be merged, [PR #11855](https://github.com/ethereum/EIPs/pull/11855) (moving the Glamsterdam meta EIP from Draft to Review status) needs an EIP officer sign-off and merge first.\n  - jochem-brouwer asked officers to review and approve PR #11855."
    },
    {
      "heading": "EIP-8333: Align Checkpoint with Epoch Boundary Block",
      "summary": "Cayman presented EIP-8333, which fixes an off-by-one error in checkpoint root calculation and could improve target vote accuracy, especially with faster slots.",
      "timestamp": "00:33:34",
      "body": "- EIP-8333 moves the checkpoint root calculation to use the boundary block leading up to the checkpoint epoch, instead of the first block of the epoch.\n- This fixes a long-standing off-by-one error: currently, finalizing an epoch only truly finalizes the first block of that epoch.\n- Practical benefit: improves target vote accuracy on the first slot of an epoch, since late-arriving blocks currently impact both head and target votes.\n- Cayman suggested it pairs well with quicker slots, as it relaxes timing requirements for target voting.\n- Presentation slides shared: [gist](https://gist.github.com/lodekeeper/ab3164dc62c81f2d172ae7ce0f0d2c55).\n- No questions or objections were raised."
    },
    {
      "heading": "EIP-8379: Engine API Sync Status",
      "summary": "Dustin (Nimbus) proposed making the CL the sole source of sync truth via a new Engine API endpoint, reducing reliance on devp2p block gossip.",
      "timestamp": "00:35:35",
      "body": "- [EIP-8379](https://github.com/ethereum/EIPs/pull/12154) adds an Engine API endpoint so the CL can be the authoritative sync source, addressing issues on unstable/highly-forked networks where both CL and EL must independently find peers on the correct fork.\n  - On networks like Holesky with many forks, if either layer fails to find peers, neither can fully recover.\n- Additional benefits: eliminates duplicative block gossip between CL and EL (less relevant post-EPBS but still present), and opens a path to narrowing devp2p's scope long-term.\n- The EIP distinguishes blocks the EL lacks pre-state for, keeping semantics within the Engine API rather than relying on loosely-spec'd ETH protocol methods like `eth_getBlockBy*`.\n- Barnabas asked if this could be optional; Dustin argued Engine API endpoints need to be mandatory because `exchange_capabilities` is a tally-by-construction mechanism, and optional endpoints have limited value.\n  - Dustin also noted the EIP will likely integrate with the forthcoming SSZ Engine API, expected by Hegotá deployment.\n- Commit link shared: [tersec EIP commit](https://github.com/tersec/EIPs/commit/6fc997491b1e3d1d1cb241bdea31a44c9984d87b)."
    },
    {
      "heading": "CL Block Retention Window Reduction",
      "summary": "Kevaundray proposed reducing the CL block retention window and standardizing the epoch number, but potuz questioned the motivation; further discussion deferred to ETH R&D.",
      "timestamp": "00:42:13",
      "body": "- [EIP PR #12188](https://github.com/ethereum/EIPs/pull/12188/) proposes reducing the CL block retention window. The current constant derives from a safety decay of 100, which should be halved following the introduction of EIP-8061 in Glamsterdam.\n- Kevaundray found that client behavior varies: some store more blocks, some fewer, and some don't have the retention window enabled by default. The EIP is currently informational, aiming to standardize on an epoch number that matches EIP-8252's reorg retention window.\n- The EIP also suggests that CL and EL should store all non-finalized blocks, since using the retention constant for non-finalized backfill is risky — a non-finality period exceeding 4–5 months would leave no blocks stored.\n- Dustin expressed mild skepticism: the current long retention window has the advantage of not requiring any finality-aware logic; shortening it introduces complexity (finality-gated pruning). However, he acknowledged value in aligning CL and EL retention windows.\n- potuz questioned the motivation: CL blocks don't occupy much space, the current approach works, and changes would require client modifications for unclear benefit. He suggested targeting only the EL side.\n- Kevaundray noted that ELs copy the CL block retention window because some CLs don't store execution payloads, making CL-EL alignment relevant.\n- Toni clarified that the weak subjectivity period post-Glamsterdam is ~6 days, while the safety-decay-based constant is 36 days; these are distinct from the 4–5 month retention window.\n- Barnabas commented that 4–5 months of non-finality means \"game over\" regardless.\n- Decision deferred to async discussion on ETH R&D."
    },
    {
      "heading": "Hegotá CFI/DFI Timeline and Tier Rankings",
      "summary": "Client teams asked to publish tiered EIP rankings with rationale by mid-September; goal is to finalize Hegotá scope by Devcon.",
      "timestamp": "00:54:39",
      "body": "- Andrew has written a framework for tiering EIPs into S (strongly recommend), A (recommend if blockers cleared), B (stretch goal), and D (recommend rejection) tiers.\n- All client teams are asked to publish at least a first version of their tier list by mid-September (~1 month from the call).\n- Process: start by resolving obvious DFI (all teams reject) and obvious CFI (all teams agree) first, then work through rough consensus on remaining EIPs.\n- Target: finish the Hegotá scope process by Devcon, so all teams enter the conference with a shared understanding.\n- jochem-brouwer cautioned that tier labels are subjective (\"my A is not your A\") and asked teams to define their tier criteria when publishing rankings.\n- Pari encouraged teams to also publish rationale for their choices to help navigate differences.\n- [Forkcast ranking tool](https://forkcast.org/rank/) was mentioned as an available option but not required.\n- Intention announced to DFI EIPs with no champions by the next ACDC."
    }
  ]
}