LEGO Grant Proposal: trace-interop, cross-client trace_* API standardization

Community Grants / Initiatives
1

Summary

Ethereum execution clients implement the Parity trace_* API (trace_call, trace_replayTransaction, trace_block, trace_filter and the rest), but they disagree on what it returns. The same request can produce different call trees, errors and state diffs depending on the client. Many tools that read traces carry client-specific workarounds.

I’m working to fix this at the source. I drafted a specification in execution-apis and built trace-interop, a reproducible test harness covering six client implementations, using Hive for execution clients and chain replay for Anvil. I’m sending fixes for the differences it finds upstream to each client.

I’m requesting a $10,000 grant from LEGO. It funds closing Besu’s remaining agreed compatibility gaps, plus a fix to the Parity trace parser in Lido’s depot tooling.

Background

I’ve been reporting trace-compatibility bugs across clients since 2021; Erigon’s trace_filterintersection mode came from erigon#2119. In September 2026 I started a coordinated push, self-funded so far:

  • a draft spec for all nine trace_* methods: execution-apis#895, with discussion in #890

  • a harness with 1,721 cases on frozen chains, run against Besu, Erigon, Nethermind, Reth, an experimental Geth implementation and Anvil, with per-client reports

  • around 100 tracked upstream PRs from the effort, including fixes contributed by client maintainers; more than half were merged as of September 28

  • a working group on Telegram where the client teams review each proposed decision

I’ve also prepared a Geth implementation to support upstream test generation and extend coverage to Geth (go-ethereum#35791).

Why this matters for Lido

  • Lido’s tooling uses this API. lido-cli’s tx trace uses trace_replayTransaction. Consistent responses would make it easier for tools like this to work across clients.

  • A concrete improvement to depot. depot traces omnibus executions to show reviewers the call tree. Its active strategies use debug_traceTransaction; it also has an unused trace_transaction strategy with incorrect handling of failed frames and contract creations. The proposed fix would make that parser usable for future Parity trace integration.

  • Client diversity at the RPC layer. A shared trace contract reduces the client-specific work needed to switch tracing infrastructure between execution clients, supporting Lido’s broader interest in client diversity.

  • Besu has the largest gap. It differs from the draft in 17 places with no fix yet, has 13 open PRs from this effort, and lacks trace_replayTransaction, which Blockscout users have asked for before.

  • No new service for Lido to run. The work lands in the clients and in execution-apis.

Plan and deliverables (Oct–Dec 2026)

  1. Shepherd the 13 open Besu trace PRs through review, submit fixes for the remaining agreed differences, and document any unresolved spec decisions.

  2. Implement trace_replayTransaction in Besu (besu#11357).

  3. Open a PR to lidofinance/depot that fixes the Parity trace strategy’s handling of failed frames, create results and supported transaction trace types, with regression tests.

  4. Post progress updates in this thread, and give a short presentation to the LEGO Council at the end.

Success shows up as Besu’s outcomes in the public matrix moving from “differs” to “agrees”. Merging is up to Besu’s maintainers, so what I commit to is submitted, reviewable fixes and active follow-up.

Requested Grant Amount

$10,000 in DAI, one payment.

ETH Address

0x55bc991b2edf3ddb4c520b222be4f378418ff0fa

4 Likes