pulse

a user-friendly block explorer

scroll to explore(pun intended ツ)

Concept

Block explorers are the default surface for understanding what's happening on-chain. Over time, they have evolved into dense user interfaces that try to capture everything in a broad way, from transaction details, to chain analytics, to ecosystem apps.

Most users encounter explorers through transaction links, which usually serve as receipts. Apps provide them to verify a transaction went through, and users share them as proof. They want to confirm what happened, understand it, and be able to reference it. Developers, researchers, and data analysts have different needs. They rely on explorers to debug failed transactions, trace executions, validate contract deployments, and monitor how users interact with smart contracts.

Pulse separates these two experiences. The default view is minimal and opinionated, designed to cover the needs of most users, while Dev Mode provides a perspective closer to how existing explorers look.

Pulse is about breaking down the typical explorer experience and rebuilding it with intention and a user-first perspective.

Pages

Landing

Most users care about one thing when they land on an explorer: checking a specific transaction. The landing page is focused on exactly this. The search bar is auto-focused, so users can start typing immediately. Pasting anywhere on the page triggers the search. If the transaction hash is valid, they're taken directly to the transaction Receipt page. In the corner, blocks update in real-time to signal that the network is live.

/

Search Transaction ID
or double-click anywhere to paste

Receipt

The Receipt page is about capturing the essence of a transaction and presenting it in a way that's easy for the user to understand.

The default view focuses on token transfers, with values shown in dollars first, separated into payments (ERC-20) and assets (ERC-721). A generated human-readable summary describes what happened in the transaction. The View As bar lets users see the transaction from their own perspective, understanding inflows and outflows of payments and assets relative to their address. Dev Mode can be enabled on the Receipt page to get fully detailed insights into the transaction.

/receipt/0x4dc8082ceb97893c890290ab0081867ef1fc04cddfd8e176c363cb0684bc9ee7

Address

The Address page provides a quick overview of an address, focused on net worth in dollars and its holdings. Dev Mode can be enabled for a more detailed view.

/address/0xaA52941EFEE63E8a647D05b404e51461b3b35C06

My Account

Users can connect their wallet to see a personal dashboard. The view focuses on address's net worth and holdings denominated in dollars. The Activity tab shows a list of recent transactions the address has been involved in. Transactions are displayed from the user's perspective as inflows and outflows of tokens and assets relative to their address.

/me
Connect your wallet
Sign in to view your account overview, assets, and activity.

Features

View Mode

View Mode lets users switch between the default view and a detailed view (Dev Mode) on the Receipt and Address pages. It can be toggled using the Dev Mode button in the top right corner or via a query parameter in the URL (viewMode=dev), allowing shareable links that open directly in the intended view.

Developer View

View As

View As provides a personalized view at a transaction from a specific address's perspective. This includes indications for inflows and outflows, a more personalized summary, and labeling the viewing address as You to make it clear how the address is impacted by the transaction.

View As is enabled automatically when users sign in for their address (and can be disabled via profile settings) but can also be changed using the View As bar. It also syncs with a query parameter (viewAs=<address>), allowing apps and users to share links that open a transaction from a specific address's perspective.

Default View
Viewing as 0xaA52...5C06

Human-Friendly Summaries

Every transaction includes a human-readable summary so even non-technical users can understand what happened at a glance. When View As is enabled, the summary becomes more personalized describing the transaction from the viewing address's perspective.

You received $100.00 in USDC from 0x7465...6d706f

Challenges and Improvements

What is a payment?

This might seem obvious, but defining what a payment is on-chain can be nuanced. A single transaction can contain multiple token transfers—some related to the actual payment, others related to fees or other types of value movement that aren't necessarily a payment in exchange for something. There's also the challenge of clarifying what was received in return for a payment and separating it from additional value that wasn't part of the exchange, like an airdrop or loyalty points for buying a product from the product itself.

Summary Generation

Pulse uses heuristics to categorize transactions and determine the direction of value flow. The current logic works for simple cases but has room for improvement.

Direction detection

The logic counts the number of incoming vs. outgoing transfers relative to the viewing address. If more transfers are incoming, the transaction is labeled as received; if more are outgoing, it's sent. When counts are equal (common in swaps), it defaults to outgoing since the user initiated the transaction.

Category detection

The categorization of a transaction follows a priority chain:

  • API label: the API provides high-level transaction labels, which are the ones used to categorize non-token-transfer transactions (i.e. contract creation).
  • Purchase: both ERC-20 and ERC-721 transfers are present, indicating a value exchange.
  • Swap: an address has both positive and negative token positions (sent one token, received another).
  • Batch: one sender to multiple recipients, or multiple senders to one recipient.
  • Payment: transaction only includes ERC-20 transfers.
  • Transfer: non-ERC-20 transfers only (ERC-721, ERC-1155).
  • Generic: all other transactions.

Potential improvements

  • USD-based direction: use total USD inflow vs. outflow instead of transfer count for more accurate direction detection in complex transactions.
  • Protocol-specific detection: identify transactions by known router or contract addresses for more accurate labeling.
  • Fee separation: separate protocol fees from the actual transactions.
  • LLMs: use LLMs to go from the structured analysis of the transaction to a human-readable summary.

Search

Search for an address or transaction