[final report] SolDB — CLI debugger and simulator for Solidity and Stylus

DAO Programs & Initiatives Domain Allocator Offerings (prev Questbook)
1

Per request from a member of Domain Allocators for Developer Tooling, we are submitting a final report on our work for the Developer Tooling on Arbitrum One and Stylus 3.0 grant.

Project: SolDB — CLI debugger and simulator for Solidity and Stylus

Successfully implemented a cross-environment debugging ecosystem for Arbitrum. All milestones are fully tested, enabling seamless tracing across both Solidity and Stylus contracts.

Given StylusDB is already integrated in the official Stylus SDK PR #370, this work will be available to all Arbitrum users by default right after PR #390 gets merged-significantly increasing the grant’s ecosystem impact.

List of Milestones Delivered

M1: Enhanced Call Traces ($9,000)

• Implemented legacy source map parser for Solidity versions < 0.8.29.

• Enables tracing and function resolution via source mapping.

• Result: Trace visibility for legacy solidity versions where ethdebug is missing.

M2: Debug Adapter Protocol ($9,000)

• Defined unified CrossEnvTrace protocol and built a centralized Bridge Server.

• Result: Standardized communication layer between SolDB (Python) and StylusDB (Rust).

M3: SolDB Import of Stylus Traces ($9,000)

• Developed bridge client for SolDB to request and merge Stylus traces.

• Automated function-level merging into the Solidity call hierarchy.

• Result: Full visibility when a Solidity contract interacts with Stylus.

M4: StylusDB Import of Solidity Traces ($9,000)

• Enhanced cargo stylus usertrace with EVM contract call detection.

• Integrated SolDB trace into the Stylus call tree.

• Result: Full visibility when a Stylus contract interacts with EVM/Solidity logic.

M5: Clear Revert Reasons ($7,000)

• Added error detection and revert message in usertrace.

• Mapping error messages to the failing code frame.

• Result: Faster diagnostics for failed cross-language transactions.

M6: Documentation and Onboarding ($2,000)

• Submitted documentation as part of the main tool repository and to Official Arbitrum Docs.

• Result: Clear onboarding path and documentation for developers.

M7: 6 month support ($5,000)

Quick Start and Testing

Prerequisites

Deployment and Testing

Navigate to the https://github.com/walnuthq/soldb/tree/main/test/stylus test examples and run the deployment script - ./deploy.sh.

This script automatically deploys the contracts and executes a test transaction to complexStylusOperation().

The output will provide an example soldb command similar to this:

Test with soldb:

soldb trace 0x4eac0d80dda629ffbc92eff1746e3be1946352daec5b102a1052f00edc9dafa4 \
  --ethdebug-dir 0xA6E41fFD769491a42A6e5Ce453259b93983a22EF:StylusCounterCaller:/Users/mami/Documents/walnut/walnut-evm/soldb/test/stylus/solidity-caller/out \
  --cross-env-bridge http://127.0.0.1:8765 \
  --stylus-contracts /Users/mami/Documents/walnut/walnut-evm/soldb/test/stylus/stylus-contracts.json \
  --rpc http://localhost:8547

Run the command to see a unified trace showing both EVM and Stylus calls.

Link to full report

https://docs.google.com/document/d/1rOcHDruHDFKjcOQhlK6NkfFfvPAQjG5bLvR4e_2V-7Y/edit?tab=t.0

Project Resources

[RFC] Operational Mandate: Arbitrum Stylus Developer Impact Oracle & Sybil-Resistant ROI Matrix
2

Thank you to the Walnut team for delivering a complete, well-structured final report and for the tangible progress on a genuinely useful piece of developer infrastructure.

The work addresses a real pain point: debugging mixed Solidity + Stylus (EVM ↔ WASM) transactions. Delivering bidirectional trace merging, a CrossEnvTrace bridge, improved revert diagnostics, legacy source-map support, and official documentation PRs shows solid execution against the agreed milestones. The prior integration of StylusDB into the official Stylus SDK (PR #370, merged) and the ongoing PR #390 further increase the potential systemic impact beyond a standalone tool. Clear testing instructions and open-source repositories also support transparency and reproducibility, which are important for Domain Allocator oversight.

The inclusion of a 6-month support milestone is appreciated as a commitment to post-delivery maintenance.

Opinion:

The project is well-aligned with the Developer Tooling domain’s goals of improving the Stylus developer experience and reducing friction for hybrid Solidity–Stylus applications. The technical approach (unified protocol + bridge rather than a fully monolithic debugger) is pragmatic and leverages existing components.

Strengths:

• Concrete, verifiable deliverables tied to specific dollar amounts.

• Integration path into the official Stylus SDK and Arbitrum docs, which multiplies impact.

• Focus on practical usability (clear revert reasons, legacy support, quick-start examples).

Areas for continued attention:

• Ecosystem impact is currently somewhat prospective. Full “available by default” value depends on PR #390 being reviewed, merged, and released in cargo-stylus / the SDK. As of the latest public state, that PR remains open.

• Adoption metrics, real-world usage signals, or developer feedback are not yet visible in the report. For a tooling grant, evidence of usage (or a clear plan to gather it during the support period) strengthens accountability.

• The total funding (~$50k across seven milestones) appears reasonable for the scope, but future similar grants could benefit from more explicit success criteria around integration timelines and post-merge adoption.

Overall, this is positive value for the Arbitrum developer ecosystem and a good example of focused, infrastructure-oriented grant work.

Questions for clarification: @romanm

1. Integration status: What is the current status and expected timeline for PR #390 (Stylus-Solidity interop debugger)? Are there outstanding review comments or blockers from the Offchain Labs team? Has the documentation PR (#3052) been merged?

2. Verification of deliverables: Can independent reviewers or Domain Allocators easily reproduce the end-to-end unified trace using the provided quick-start steps on a clean environment? Are there recorded demo videos, sample output logs, or CI test results that demonstrate the bidirectional merging and clear revert reasons?

3. Support milestone (M7): How will the 6-month support period be structured and reported? Will there be periodic updates on issues fixed, community questions answered, or further upstream contributions?

4. Adoption and impact measurement: Do you have (or plan to collect) any early usage data — e.g., GitHub stars/forks/clones, Discord/Telegram questions, or feedback from Stylus developers? What would success look like 3–6 months after full upstream integration?

5. Sustainability: Beyond the support window, what is the long-term maintenance plan for SolDB and the bridge components? Are there plans for additional funding, community maintainers, or deeper integration into cargo-stylus / other official tools?

6. Any deviations or lessons: Were any milestones adjusted in scope or difficulty during delivery? Are there technical limitations of the current CrossEnvTrace approach that future work should address?