Skip to main content

Blockchain Explorer & Analytics Interface

Design a blockchain explorer: transaction views, block details, address analytics, gas tracking, network stats, and token holder analysis.

Vul de plaatshouders in

Edit the values, then copy your finished prompt.

Jouw Prompt
prompt.txt

                                

What this prompt does

This prompt asks the AI to design a blockchain explorer and analytics interface across seven views: a network overview dashboard, transaction detail, block detail, address/account pages, token analytics, advanced analytics, and a framework-specific implementation section. It anchors the design to your product through [product_name], [blockchain_network], [target_users], and [data_depth], so the explorer fits Ethereum-plus-L2s and the people debugging it rather than a generic chain.

The [target_users] variable shapes which views get priority — developers debugging transactions need decoded input data and internal traces, while traders need whale tracking and token charts. And [framework] (defaulting to Next.js + Tailwind + Recharts + ethers.js) pushes the AI to reason about the genuinely hard parts: WebSocket block streaming, type-detecting search, safe BigInt and wei-to-ETH formatting, and virtualized tables for blocks with thousands of transactions.

When to use it

  • You're building a block explorer for a web3 project and need every view mapped before coding.
  • You want transaction decoding, internal traces, and event logs designed up front.
  • You're targeting a specific audience via [target_users] and need the views weighted accordingly.
  • You need search that auto-detects address vs. tx hash vs. block number specced clearly.
  • You're handling large numbers and big tables and want BigInt formatting and virtualization addressed.

Example output

Expect a structured design document: each view broken into named components — a network dashboard with live block and transaction feeds and a gas tracker, a transaction page with status badges and decoded function calls, an address page with balance, token holdings, and a contract source viewer. The closing [framework] section reads as an implementation checklist covering WebSocket updates, instant typed search, BigInt formatting, hex toggles, table virtualization, and a default dark theme — a spec to build against, not finished code.

Pro tips

  • Set [blockchain_network] precisely — EVM chains, L2s, and non-EVM networks differ in fields like uncle blocks and EIP-1559 fees.
  • Use [target_users] to prioritize: a debugging-developer audience justifies deep trace views a trader audience wouldn't read.
  • Match [data_depth] to what your node actually exposes; promising internal traces you can't index sets a false spec.
  • Swap [framework] if you're not on ethers.js or Recharts so the BigInt and charting guidance stays accurate.
  • The decoded-input and internal-transaction views depend on verified-contract data — confirm your data source before designing them.
  • Re-prompt view by view ("expand the Address/Account page to wireframe detail") to go deeper where users spend the most time.

Frequently Asked Questions

Which blockchains does this prompt support?
Whichever you set in the `[blockchain_network]` variable, defaulting to Ethereum mainnet plus L2s like Arbitrum, Optimism, and Base. EVM-specific elements such as EIP-1559 fees and uncle blocks adapt based on the network you specify.
Does it handle decoding raw transaction data?
Yes. The transaction detail view includes decoded function calls with parameter names, internal transaction traces, and decoded event logs, provided the contract is verified. There's also a toggle between raw hex and decoded views in the implementation section.
How does it deal with very large numbers like wei values?
The framework section specifically calls for BigInt handling with proper wei-to-ETH conversion and formatting. This avoids the precision errors that come from treating large blockchain integers as standard JavaScript numbers.
Can it handle blocks with thousands of transactions without lag?
Yes. The implementation guidance specifies virtualized tables so large blocks render smoothly. Combined with WebSocket streaming for live updates, the design targets responsiveness even with heavy on-chain data volumes.
Is this a finished explorer or a design spec?
It is a detailed view-by-view design specification, not deployable code. The `[framework]` section gives concrete implementation guidance for Next.js and ethers.js, but you build the actual explorer and data pipeline from the spec.
Engr Mejba Ahmed

Need this built for real?

Engr Mejba Ahmed

AI Developer · Software Engineer

I'm Mejba — I design and ship production AI systems, automations, and full-stack apps. If you want this turned into a working solution for your team, let's talk.

Meer in Emerging Tech UI Prompts

Engr Mejba Ahmed

Engr Mejba Ahmed

Claude Code Expert · Online

👋

Hey there!

Quick Actions

WhatsApp Instant reply

Chat on WhatsApp

+880 1723 741224 · Instant reply

Popular Questions

Engr Mejba Ahmed is connected
Engr Mejba Ahmed is typing...
Engr Mejba Ahmed avatar

✉ Want me to follow up? Drop your email

Engr Mejba Ahmed avatar

📞 Connect Directly

Choose how you'd like to reach me

WhatsApp

+880 1723 741224

Email

[email protected]

✓ Details sent! I'll get back to you shortly.

Powered by OpenAI

335+

Blog Posts

25

AI Courses

63

Projects

Services & Expertise

Pricing & Process

Learning & Resources

Connect & Support