Developers want a block explorer that’s data rich, intuitive, and useful

Block explorers allow users to view public Ethereum blockchain data “in real time”. Users come to block explorers for a myriad of different use cases, mainly with the objective of finding out more information about a contract, transaction or wallet.

Block explorers today are good, not great

Traditional block explorers focus on surface-level data like transactions, balances, and contract interactions, but they often fall short for developers working with complex dApps.

Fragmented and Surface-Level Data: Traditional block explorers only offer high-level data (e.g., transaction history, gas fees) but lack insights into deeper on-chain structures like contract storage or internal interactions, making debugging and audits difficult for developers.

Lack of Customization: Traditional explorers are built for general users and offer limited customization, making it hard for developers to tailor data views or analyze contract behavior in depth.

Understanding Behavior: Traditional explorers provide little context for understanding smart contract behavior (storage), making it hard for users to follow how contracts manipulate data and interact with other contracts.

Limited multi-chain support: Traditional explorers typically focus on a single blockchain, forcing developers to use different tools for different networks, increasing complexity in multi-chain environments.

Enter sim.explorer, the best tool to explore contract storage

sim.explorer addresses this gap by providing deeper insights into smart contract storage—the internal data layer where contracts manage crucial variables like token balances, ownership, and flags (e.g., paused status).

By offering granular analysis of contract storage, sim.explorer empowers technical users to explore the inner workings of smart contracts, making it a powerful tool for those who need more than basic blockchain data.

Bringing the developer experience to the forefront

An intuitive transaction tracer is essential for improving transparency, simplifying debugging and auditing, increasing security, and enhancing the overall developer experience. Our invocation flow has a goal of providing more insight for the same level of complexity.

With the first dedicated mobile block explorer (no seriously)

Surprisingly, no other product on the market had implemented a mobile experience for their tracers. With 41% of our users on mobile, we want to ensure that developers can debug from anywhere, no matter where they are.

❤️ by thousands of devs

With steady engagement of around 10k monthly active users, sim.explorer focuses on delivering a top-tier developer experience for contract exploration. For the sake of scope, other parts of the product (block, EoA, dashboards, etc.) aren't shown here, but feel free to explore on your own! Here’s an interesting contract to get you started—enjoy!

Deep dive: The building of a transaction tracer

What’s a transaction tracer?

Transactions drive storage changes, offering detailed insights when isolated. However, to fully understand an event, you need to zoom out and view the transaction in context.

A transaction tracer displays function calls as a tree structure, with each node representing a call or event trigger, including key details like call depth and parameters.

Our goal is to provide deeper insights without increasing complexity. While transaction tracers give a detailed look at function calls, a storage explorer could be an even more approachable way to help users understand how transactions work—especially those more interested in the contract data.

Deconstructing transactions

We began by taking a few key example transactions (of ranging scope) in other products and began by deconstructing them line by line. Understanding what is happening in each so we can begin to familiarize ourselves with the entire flow as well as note what feature requirements, considerations, and questions we had along the way.

Data mapping + Structure

Mapping:

Once we identified the parts, we needed to choose a path of how the sum of the parts would work. There are several different means of expression we identified that could be useful with the flow.

After speaking with users, we found that their primary goal was debugging. To support this, it became clear that highlighting key data types would help users identify critical points in the flow and better understand how to navigate and interpret it.

Structure:

Linear Call Stack: A simple, step-by-step view of function calls, perfect for straightforward debugging. But when it comes to complex or deeply nested contracts, it can be hard to keep track of everything.

Tree Structure: Ideal for complex transactions, clearly showing how function calls and internal transactions branch out. While it does require careful design to avoid clutter, it’s great for visualizing dependencies and gives users a clear view of the entire flow.

Timeline View: A good option for seeing performance or timing, but it doesn’t handle nested structures as well as the tree approach.

How much information to include, when

One of the biggest challenges in designing the invocation flow for the tracer was managing the scale of data we needed to present. Initially, we weren’t sure how much information to display or how much users actually wanted to see. As we gathered more insights, we iterated on different approaches to balance information disclosure.

Ultimately, we chose the tabbed approach. When sharing options with users, they gravitated toward a solution that provided a quick overview of the trace (the row view) upfront—enough to get a sense of the flow without overwhelming them. At the same time, they still wanted access to all the trace details. The tab system allowed users to dig deeper when needed, offering a detailed view in separate tabs for easy exploration. This approach also enabled users to have multiple traces open simultaneously for comparison, making it easier to analyze and contrast data.

This solution allowed for the holistic stripped back overview upfront to inform users where to dig deeper, and then the rich details view to get the answers they are looking for.

Detail breakdown

We designed the interface to be quick and intuitive, with minimal clutter, so users can easily interpret and act on the data. Simple, consistent rules—like underlined links for actions and labeled traces for detailed views—make it easy for users to spot where they can take action.

More coming soon!