Blockchain Explorer Design
End-to-end design of a blockchain explorer for Nuklai — giving developers, NAI holders, and community members a clear window into on-chain activity on a non-standard L1.
The Project
Nuklai is a Layer 1 blockchain infrastructure built for data economies. The network runs on HelixVM, a custom virtual machine built with HyperSDK — Avalanche's framework for high-throughput, parallel transaction execution. Developers, data scientists, NAI token holders, and community members had no window into what was actually happening on-chain.
I designed the Explorer end-to-end as the sole Product Designer — research, information architecture, interaction design, and high-fidelity UI. I worked directly with the lead blockchain architect to understand HyperSDK's data model, then translated it into a browsable interface for a mixed-expertise audience.
My Role
Solo Product Designer. I owned the product end-to-end: research, information architecture, interaction design, and high-fidelity UI.
Scope
Dashboard, Blocks, Transactions, Assets, Validators, Accounts, Health. Detail views for every on-chain entity. Global search. Live network ticker. MetaMask Snap integration design.
Collaboration
Lead Blockchain Architect (KP), Backend Engineers, Community Manager.
The Challenge
HyperSDK produces a non-standard data model. Blocks don't behave like Ethereum blocks. Actions replace traditional transactions. Assets are native to the VM, not smart contracts. The Sponsor field — a third party that can pay the fee for another user's action — has no Etherscan equivalent. None of the mental models users bring from Etherscan or Solscan apply here. I had to design an explorer that served three fundamentally different users simultaneously: a developer debugging a failed action, an NAI holder evaluating validators before delegating stake, and a community member trying to understand if the network was healthy.
Understand and Sympathize
Directional Interviews
I spoke with two groups before touching any wireframes — internal Nuklai team members and external community members. Each group knew a different version of the same problem.
Nuklai Team
- Developers
- Blockchain Architect
- Community Manager
Community
- NAI Token Holders
- Delegators
- Data Contributors
The internal group knew what the Explorer could expose. The external group knew what would make them actually use it. The gap between those two perspectives shaped every information architecture decision.
The team could describe the data the network produced. The community could describe what they needed to trust it. Neither group could see the explorer that would serve both — that was the design problem.
10 Questions
What do you check first when something goes wrong on the network?
What data do you pull manually that a good explorer would show you automatically?
How do you verify that a validator is performing correctly right now?
What would make you feel confident recommending this explorer to a non-technical community member?
When you stake NAI to a validator, what do you look for to confirm it's a safe choice?
What does "the network is healthy" mean to you, and where would you go to check it?
Have you looked at a blockchain explorer before? What confused you most?
If you wanted to show a friend that Nuklai is active and growing, what would you point them to?
When you hear about a network incident, what's the first thing you want to know?
What's the first thing an investor asks you about the chain that you currently have to explain verbally?
Competitive Benchmark
I benchmarked the three blockchain explorers most relevant to our audience — Etherscan, Solscan, and Mintscan — looking specifically for patterns that could be adapted to a non-EVM, non-standard L1 data model without inheriting assumptions that don't apply to HyperSDK.
Etherscan
Strengths
- Complete data depth
- Trusted brand, universal EVM mental model
- Top stats bar gives immediate network orientation
Weaknesses
- Information density without hierarchy
- Fourteen data columns with no signal about which matters most
- "Everything is important" means nothing is
Useful patterns
- Persistent stats bar — adapted as the live global ticker
Solscan
Strengths
- Clean hierarchy
- Good visual separation between overview and entity detail
- Tabbed detail view keeps pages focused without losing depth
Weaknesses
- Built around Solana's account model
- Asset explorer is buried
- Validator data disconnected from main navigation
Useful patterns
- Tabbed detail structure for individual entities
Mintscan
Strengths
- Excellent validator view
- Staking context is front and center
- Uptime is visualized, not just listed
Weaknesses
- Dashboard overloaded
- Charts compete for attention without a clear reading order
Useful patterns
- Validator card with delegation rate and uptime
- Influenced Validators list and Specific Validator detail
Translating Insights into Strategy
Research surfaced three recurring gaps — invisible validator risk, an opaque action model, and no self-service path for network status. This phase translated those gaps into a shared strategic direction: product goals, user goals, and technical constraints that stayed aligned throughout the entire design process.
Product Goals
- Give investors and community members confidence in network activity
- Give developers raw data without sending them to the CLI
- Reduce the Discord support burden caused by users unable to self-diagnose network events
User Goals
- Get an immediate read on network health without technical knowledge
- Find any transaction, block, or address in under 10 seconds
- Understand validator performance before delegating stake
Technical Considerations
- HyperSDK's action model doesn't map to standard tx types — every action name requires custom display logic
- Non-EVM address format (nuklai1…) breaks standard wallet integrations
- Assets are native to HelixVM — no ABI, no standard token interface to lean on
How might we
With the strategic direction clear, the gaps were reframed as design opportunities. Each question is anchored to a specific research finding — precise enough to focus ideation, broad enough to leave room for unexpected solutions.
HOW MIGHT WE...
...surface network health so that a non-technical community member gets an answer before they ask in Discord?
HOW MIGHT WE...
...present validator performance so that an NAI holder can make a delegation decision without reading the documentation?
HOW MIGHT WE...
...expose HyperSDK's action model so that a developer coming from EVM can understand what happened in a transaction without learning a new vocabulary from scratch?
Design Principles
Each principle maps directly to one of the three research findings. Every design decision in the sections that follow can be traced back to one of them.
Lead with network state
- First question on arrival: is the network running?
- Network orientation resolved before asking users to navigate
- Persistent ticker carries network context across every page
- Health section surfaces proactive status before users ask
One action name, one treatment
- Every HyperSDK action type carries a fixed label and fixed color pill
- Users learn the vocabulary through repetition, not a glossary page
- Transfer, Create Asset, Mint, Delegate, Register Validator — consistent everywhere
Earned density
- List views show only what is needed to identify an entity and navigate
- Full data lives in the detail view — never punished for exploring
- Users are rewarded with more depth the deeper they go
- Proactive status replaces reactive Discord support
Shaping the User Experience
Information Architecture
The navigation reflects the entities that exist on-chain, not a list of pages an engineer thought to build. Every section is a first-class citizen because every user type has an equally urgent primary destination: Dashboard → Blockchain (Blocks / Transactions / Validators) → Assets → Accounts → Health.
Dashboard tradeoffs examples
Every decision has a tradeoff. Below are two key dashboard moments with different approaches. Choose the path you believe strikes the right balance.
Tradeoff 1
Dashboard structure
I chose option B
Charts without hierarchy produce noise, not signal. A community member landing for the first time cannot tell which number answers "is the network okay?" and which answers "how busy was the network last Tuesday?" When everything is equally prominent, users default to reading top-to-bottom, which means the most actionable data is whatever happened to be placed first — not whatever actually matters most.
Tradeoff 2
Live ticker placement
I chose option A
Once a user navigates to Transactions or Validators, they lose network context entirely with Option A. A developer debugging a failed transaction has no way to know from the Transactions page whether the network is currently delayed or whether the failure was a one-time event. This was not an aesthetic decision — it was about making network context a constant, not a destination.
Health tradeoffs examples
Every decision has a tradeoff. Below are two key health-section moments with different approaches. Choose the path you believe strikes the right balance.
Tradeoff 3
Where does network status live?
I chose option A
A colored dot carries no history. It tells the user what is happening now but nothing about January 4th at 14:00. An investor doing due diligence and a developer investigating why their transaction failed three days ago need a log, not a dot. A dot also creates a false equivalence between "current status is green" and "this network has a strong uptime record." Those are completely different statements.
Tradeoff 4
Subscription model for Health alerts
I chose option B
External status pages take users off the product at the exact moment they are most anxious. More critically, for a network positioning itself as decentralized infrastructure, routing trust through a vendor's uptime creates a contradiction that sophisticated users will notice. The repetition of the subscribe button is deliberate: a user who has just read through a serious incident report has a materially stronger motivation to subscribe than one who just arrived on the page.
Iterating Toward Clarity
Dashboard Overview
I split the Dashboard into three vertical layers: persistent ticker (permanent network context), real-time activity panel (latest transactions list and latest block, side by side at the same vertical level), and analytical charts below the fold. The two-column real-time panel is the central architectural decision — it answers "what just happened?" in a single visual scan without forcing the user to choose between checking transactions or checking blocks. Every screen shown here is the output of a specific decision about what a specific user needs at a specific moment.
Validators Overview
Eliminating invisible delegation risk before the user commits stake
Goal
Let an NAI holder evaluate validators and eliminate non-viable candidates without opening any detail page.
Risk
Showing only staked amounts. A validator with 100M staked NAI and a delegation cap at 98% is functionally closed to new delegators. Displaying the amount without the cap forces users to click into every detail page before understanding their real options.
Design decision
The Validators list treats Delegation Fee Rate as a primary column, not a detail-page field. It sits alongside Stake Amount because it is the most important financial variable in any delegation decision. The truncated Reward Address with a color-coded avatar gives each validator a visual identity that makes the list scannable even when NodeID prefixes are visually similar.
Outcome
An NAI holder can eliminate non-viable validators at list level and open only the detail pages of candidates that meet their delegation criteria, reducing the number of detail page visits to a shortlist rather than an exhaustive scan.
Transactions Overview
Teaching HyperSDK vocabulary through context, not documentation
Goal
Let any user find a specific transaction quickly, and let developers filter by action type, block range, and time — without learning a new vocabulary from scratch.
Risk
A flat list that treats a token Transfer identically to a Delegate Stake action. Users cannot scan for what they need — they have to read every row in sequence. Worse: omitting the Sponsor field leaves developers building sponsored transaction flows with incomplete verification data.
Design decision
Consistent action type labeling with color-coded pills across the product: Transfer, Create Asset, Mint, Delegate, Register Validator each have a fixed visual identity. The detail page surfaces the full HyperSDK data model including the Sponsor field with first-class visual weight — equal to From and To — because for dApp developers building fee-abstraction flows, it is the most critical verification field.
Outcome
An EVM developer landing on Nuklai's transaction list can orient immediately using familiar column logic. The action type pill teaches HyperSDK vocabulary through context, not a documentation page. Developers can verify sponsored transaction fees and confirm fee-payer identity without a single RPC call.
Health Overview
Giving community members a self-service path out of Discord
Goal
Give community members a self-service answer to "is the network okay?" and let them subscribe to proactive alerts so they never need to ask in Discord.
Risk
A static status indicator with no history. Without an incident log, users can see current status but cannot investigate past events. Developers cannot correlate their failed transactions with specific network windows. Community managers remain the default support channel because the product gives users no alternative.
Design decision
Three components: real-time 90-day status bars for Blockchain, Nuklai Subscriber, and Nuklai Faucet; a calendar-based incident log where any date surfaces all incidents for that day; and a detailed incident timeline with four resolution states — Investigating, Identified, Monitoring, Resolved — each with a timestamp. This section was my initiative — it was not in the original project scope.
Outcome
Community members can self-diagnose network events without Discord. Developers can correlate failed transactions with specific incident windows in the historical log. The subscription converts passive page visitors into informed stakeholders who receive proactive notification rather than reactive news.
