Hey all — we want to present a new debugger for Solidity based on ETHDebug.
1. The Problem
Debugging is one of the most critical but underserved needs in Solidity development. Today, most developers rely on closed, cloud-based services — despite community surveys ranking better debugging as one of the most requested features. This gap was highlighted in the latest Solidity Survey [link], where better debugging support ranks as the second most requested feature.
2. The Solution: SolDB
We’re introducing SolDB, the first fully local and open-source debugger for Solidity. Think of it as the GDB/LLDB of the EVM: CLI-first, standards-driven, and designed to integrate with IDEs, explorers, and other tools.
Repo: github.com/walnuthq/soldb (give it a 
)
Key features:
- Full transaction tracing with decoded calldata and return values
- Step-by-step interactive mode, with visibility into variables and process state
- Support for local and remote RPC debugging
- ETHDebug-first by design—built from first principles for modern Solidity.
We’re already integrating SolDB into Walnut, a web-based transaction debugger and simulator for EVM rollups, proving that this is a practical and composable foundation.
3. Demo / Example Usage
Check the repository for more examples: github.com/walnuthq/soldb
4. Comparison
Existing tools are either closed-source or UI-first. SolDB is the only local, CLI-first debugger designed to also serve as a building block for the wider tooling ecosystem.
| Tool | CLI-first / Building Block | Local debugging | Open-source | Remote (onchain) debugging | Visual (UI) debugging |
|---|---|---|---|---|---|
| SolDB |  |
|
|
|
 |
| Simbolik: Solidity Debugger (VSCode Extension) | |
|
 partial |
|
(VSCode) |
| Walnut | |
|
|
|
|
| Tenderly | |
|
|
|
|
5. Roadmap
We’ve built the foundations. Our next steps focus on expanding Solidity support, improving trace quality, and making SolDB easier to use across developer workflows:
- Expand Solidity feature coverage
- Support for events (indexed params, topics, full decoding)
- Support for view/pure functions
- Tracking of local variables (slot/stack mapping and lifetimes)
- Enhance call traces
- Decode more arguments and return values
- Recover calls when ETHDebug lacks per-instruction source mapping (e.g. around JUMP/CALL)
- Improve developer experience
- Add Debug Adapter Protocol support
- Release a VS Code extension for interactive debugging
- Collaborate upstream on ETHDebug
- Improve metadata completeness
- Add compiler mechanisms to enhance preserving metadata under optimisations
6. Architecture & Design Choices
Standards-first, GDB/LLDB-inspired. SolDB follows the classic debugger split you know from C/C++/Rust: the compiler emits rich debug metadata; the debugger consumes it. For the EVM, that standard is ETHDebug (emitted today by solc), analogous to how Clang emits DWARF and tools like GDB/LLDB consume it.
Why this matters
- Stable compiler–debugger boundary. Soldb targets a spec (ETHDebug) instead of hard-coding compiler internals.
- Cross-compiler compatibility. Any Solidity compiler that outputs ETHDebug can be debugged—not just
solc. - Language-agnostic path. Any EVM-targeting language that emits ETHDebug (not only Solidity) can plug into SolDB. Looking at you Vyper
What we built
- CLI-first, local-first core with a modular design: an ETHDebug symbol layer, an execution/control layer for the EVM via standard RPC, and an extensible set of commands (breakpoints by source line, stepping, variable inspection, etc.).
- Extensibility to swap in new backends or additional debug formats as the ecosystem evolves.
Known challenges:
- Completeness of ETHDebug. High-quality metadata is essential for reliable source-level debugging. We are excited to start working with Argot collective to improve ETHDebug.
- Optimization vs. debuggability. Aggressive compiler optimisations can sometimes reduce the quality of ETHDebug metadata. SolDB can degrade gracefully in such cases, but we would still encourage compilers to emit richer debug information even under heavy optimization. In more mature ecosystems, such as with DWARF, the debug format was extended specifically to provide better metadata during optimized builds (e.g. symbols to describe inlining). We believe the Solidity ecosystem may need a similar approach for ETHDebug. We have prior experience in this area as we directly contributed to better DWARF after optimizations (How to Update Debug Info: A Guide for LLVM Pass Authors — LLVM 22.0.0git documentation) and would be happy to discuss this further with the Argot collective.
This standards-first approach keeps SolDB simple, portable, and future-proof—immediately useful for Solidity, and ready for other EVM languages as ETHDebug adoption grows.
7. Ambition
We’re quite excited — and ambitious — about this project. Our goal is for SolDB to become the canonical building block for Solidity debugging.
By being a CLI-first tool, SolDB is easy to integrate into other environments: IDE extensions, blockchain explorers, debuggers, or other tooling in the ecosystem.
We’re already integrating SolDB into Walnut, our transaction debugger/simulator for EVM rollups, proving that it’s a practical and composable foundation.
Looking ahead:
- We’d love to see SolDB integrated into Foundry — the interactive mode could be especially valuable for test debugging. (If anyone from the Foundry team is reading, please ping us!)
- Longer term, we’d like SolDB to become part of the Argot collective as a core Solidity tool.
We love open source, and we will keep SolDB open source. GPL-3.0 license, same as Solidity. We believe debugging should be a shared, community-driven capability — not locked behind closed platforms.
8. Who We Are: Walnut
For almost two years, our team has been building Walnut, a web-based debugger and transaction simulator for Starknet. It’s become a successful product used daily by Cairo developers to understand and debug their contracts.
With that experience, we are now ready — and excited — to expand to EVM and Solidity. SolDB is our first step: a local, open-source debugger that we believe can become the foundation for better developer tooling across the Ethereum ecosystem.
9. Feedback Request
We’ve put a lot of work into SolDB — and this is just the beginning.
Try it out here: github.com/walnuthq/soldb
We’d love your feedback to shape SolDB. Which workflows matter most to you? Which environments should we prioritize? And what would make you switch from closed tools?
Join our dedicated Telegram channel to follow progress and share feedback: @walnut_soldb
We’ll also keep posting updates on Twitter: https://x.com/walnut_dev