← Notes
WEEK 04–05 · July 20, 2026 · ~5 min

Marrying the proposals

Weeks 4 and 5 were fully dedicated to producing a draft of the project proposal together with Vansh.

As an initial draft, I decided to throw it at Anthropic's Fable to see what it would do. The quality wasn't terrible[1] considering that the prompt included guidance for existing dependencies, e.g. EIP-7916 (ProgressiveList)[2], but it was far from acceptable for the project proposal.

To get more clarity on testing and benchmarking, I started reading the ethereum-package[3] code and documentation. It was a nice surprise to see an AI Agent skill[4] that would help a lot in the future. But the main takeaway was that we'd basically need to run it somewhere (either locally or in the cloud) and the implementation would be served using a Docker image.

Other fellow Ray's article about the TLI implementation[5] came in extremely helpful for structuring how the implementation would work end-to-end, and showed that re-orgs and making sure that roots are posted to the system contract during block creation would be a critical and important part to cover in our tests.

Then we started marrying mine and Vansh's proposals, and I had to be OOO to follow up on my IRL proposal to also get married ~yay.

While I was off, Vansh produced a pretty good summary of the previous proposals that reflects all the necessary work without too much water, and we decided that Vansh would focus on completing the Geth PoC while I'd start working on Kurtosis + Viem experimental API for e2e testing that might come in handy for other fellows working on the same project but for other client teams.

Probably the biggest mind shift in the last two weeks was understanding that this EIP not only allows trustless access to logs, but also provides a new, unique way to have temporary verifiable state in Ethereum that is much cheaper than using storage slots.

After checking ACDE #239[6], I also found an answer to how the log proofs are going to be stored for long-term access — Zsolt's vision is to have a separate contract that would handle older state if needed.

That pretty much concludes the current state of things. Now happily married (both me and the proposals), we're almost ready to be presented at the next weekly office hours.

Sources

  1. [1]
    docs.fileverse.io/d/02000b870003#k=nsEfcfCN78gd2yKZXeWQSd9z7mrUstQl9YU_ppAe4roFable's first-pass draft of the project proposal — decent given the constraints, but not acceptable as-is.
  2. [2]
    eips.ethereum.org/EIPS/eip-7916EIP-7916 (ProgressiveList) — an existing dependency the proposal builds on.
  3. [3]
    github.com/ethpandaops/ethereum-packageethpandaops/ethereum-package — the Kurtosis package for spinning up test networks.
  4. [4]
    github.com/ethpandaops/ethereum-package#ai-agent-skill-claude-code--codexThe ethereum-package AI Agent skill for Claude Code / Codex.
  5. [5]
    hackmd.io/@zBK5wwtLTrqYmlLNZd8CPA/rJpY1JOQMlFellow Ray's HackMD article on the TLI implementation, end-to-end.
  6. [6]
    youtube.com/live/Y1r-O9Vdl7I?t=1729sACDE #239 — Zsolt on long-term storage of log proofs via a separate contract.