Problem
Solidity transaction debugging is harder than it should be in 2026. Existing tools often lag behind the Foundry workflow, surface limited information about custom errors, or stop at "transaction reverted" without telling you which call in a deep call stack actually reverted and why.
Production debugging usually requires replaying a real mainnet transaction with full context, including the historical state at the block the transaction landed in. The tool needs to fetch that state, run the transaction against a forked chain, and produce something a developer can read.
I wanted a debugger that I would actually reach for when a Foundry test fails or when a mainnet trade reverts and I need to know why.
Constraints
It has to work against forked chains, not just synthetic local state. That means real RPC fetching, real historical state, and the same EVM semantics Foundry uses.
It has to surface enough information to be useful: custom error decoding against the contract ABI, function call arguments, full stack traces with named contracts, and human-readable revert reasons.
It should be fast enough to use in a tight feedback loop. Replaying a transaction in seconds, not minutes.
It is a personal project, so the constraint set also includes "don't get sucked into building a UI before the engine is good." CLI first.
Architecture
A Rust binary built on REVM, the same EVM Foundry uses internally, and Alloy, the Rust Ethereum primitive library. Building on those two means the debugger speaks the same dialect as the rest of the modern Foundry ecosystem.
The replay flow fetches the transaction and the block it landed in, forks state at the parent block, runs the transaction through REVM with full tracing enabled, and decodes the resulting trace.
The decode layer is where most of the work lives. Function calls are decoded against contract ABIs. Custom errors are matched against the four-byte selectors in the ABI and decoded with their parameters. Revert reasons are extracted whether they came from require, revert, or a custom error. The output is a structured trace that a developer can read top to bottom.
My role
Sole author. Open-source.
Outcome
In active development. The repository is public. The CLI produces useful traces against forked chains today.
Tradeoffs
Rust as the implementation language costs more upfront than TypeScript or Go would have. The payoff is that REVM and Alloy give the project zero-friction access to the Foundry-shaped ecosystem, and the binary is fast enough that there is no second pass needed for performance.
CLI before UI is a deliberate choice. A debugger is only as useful as its trace quality. Spending time on a UI before the trace is right would be optimizing the wrong thing. A UI may follow once the engine has earned it.
A debugger that replays against forked chains is intentionally narrower than a debugger that hooks into a live local node. The narrower scope is the feature, not the limitation. The vast majority of the time I want to debug a transaction, the question is "why did this specific historical transaction revert," and a forked-chain replay is the right tool for that question.
The lesson I keep coming back to with developer tools: pick the tightest possible problem statement, build the tool you would reach for, and let scope expand only when the core is correct.