Earlier this year, Rumble Fish received a $131,200 grant from the Stellar Community Fund to build a Soroban-first block explorer. Today, that tool is publicly available at sorobanscan.rumblefish.dev.

The grant announcement covered what we were going to build and why. This one covers what we actually shipped, what we learned building it, and what we want from the community now that it's live.

What Soroban Scan Does

If you've tried to debug Soroban transactions using existing tools, you know the problem. Events show up as raw XDR. Contract invocations are unreadable without manually decoding binary data. Account history is incomplete or absent for anything Soroban-specific. For anyone who isn't fluent in the Stellar protocol's binary formats, existing explorers offer very little. Soroban Scan is built around the assumption that block explorers should be readable by developers, users, and anyone curious about what's happening on-chain, not just protocol engineers who know how to interpret XDR.

Transaction pages show Soroban invocations with decoded function names, arguments, and return values. If a transaction called a swap function with specific token amounts, you see the function name and the amounts, not a hex string. Contract pages list all invocations of a given contract with the same human-readable decoding applied across the board. Function signatures are extracted from the WASM bytecode at deployment time, which is what makes decoding possible without a separate ABI file.

Event tabs decode CAP-67 contract events into structured tables: topics and data fields presented as typed values, not opaque base64 blobs. For DeFi activity like swaps, transfers, and liquidity changes, the Event Interpreter layer generates plain-language summaries. Account pages surface Soroban-specific history: which contracts an account has interacted with, what those interactions did, and the full event trail. Global search covers transaction hashes, account IDs, and contract IDs. 

How We Got Here

The build followed the three-tranche structure in our SCF submission. Tranche 1 was the data pipeline: Galexie running on ECS Fargate, writing LedgerCloseMeta XDR files to S3 every five to six seconds, a Rust Lambda firing on each file to parse and write to our database, and the CloudWatch monitoring stack. By the end of Tranche 1, we were ingesting live mainnet data reliably.

Tranche 2 brought the frontend and the full API surface: all REST endpoints, the React SPA with transaction, ledger, account, contract, and search pages, and the Event Interpreter that generates human-readable summaries for known DeFi protocol interactions. The staging environment at this point was showing live mainnet data with Soroban events decoded.

Tranche 3 was production hardening: load testing to p95 under 200ms at 1 million requests/month equivalent load, a security audit against OWASP Top 10, full API documentation, CI/CD via GitHub Actions, and a seven-day post-launch monitoring report. The architecture is AWS-first (Lambda, ECS Fargate, API Gateway, CloudFront), with a ClickHouse database on Hetzner that turned a projected 7 TB PostgreSQL dataset into roughly 900 MB.

One thing that was genuinely harder than the architecture docs suggested: the historical backfill. Soroban has been on mainnet since late 2023, which meant indexing roughly two years of history before going live. We ended up running the backfill on local machines writing to a local ClickHouse instance, then migrating the result to production, because the event-driven pipeline optimised for continuous ingestion is simply the wrong shape for a one-time bulk operation across millions of ledgers. 

What We Need From You

Soroban Scan is live and stable, but no block explorer gets to call itself finished at launch. The DeFi protocol coverage in the Event Interpreter is real but limited. We're pattern-matching against Soroswap, Aquarius, and Phoenix today, and every Soroban project that builds something new is a new case to handle. Contract decoding works for contracts that embed their WASM, but the ecosystem is growing, and there will be edge cases we haven't seen.

To use Soroban Scan as a Soroban debugger: paste any transaction hash from a smart contract invocation into the search and open the detail page. The decoded function arguments, return values, and event trail are on one page. If something looks wrong, or if a transaction you'd expect to be readable isn't, that's exactly the kind of feedback we need.

Useful things to tell us: contracts or protocols where events aren't decoding correctly; transactions where the human-readable summary is wrong or missing; search edge cases where a transaction hash, account ID, or contract ID returns something unexpected; anything about the UI that makes it harder to understand what a transaction actually did.

GitHub issues are open. We're also in the Stellar Discord and Telegram. If you're building on Soroban and want your contracts well-represented in the explorer, reach out directly.

The tool is free and indexed from Soroban genesis.

Try it out here → sorobanscan.rumblefish.dev.