proxmox/docs/03-deployment/EXPLORER_EXECUTION_PLAN_2026-04-09.md

Explorer Execution Plan

Date: 2026-04-09

Companion documents:

• Explorer Competitive Audit
• Chain 138 EOA Nonce Recovery And Cancellation

Purpose:

• convert the competitive audit into an execution-ready plan
• define the fastest path from the current 5.8/10 explorer score toward 8/10, then 10/10, then the “14/10” vision
• map roadmap items to likely implementation surfaces in this repo

Outcome Targets

Phase A: Reach 8/10

Success means:

• public users can investigate transactions and addresses without immediately leaving for another explorer
• tokens feel like real explorer entities, not just shortcuts
• search and degraded states feel deliberate

Phase B: Reach 10/10

Success means:

• the explorer is credible beside strong Blockscout deployments
• developers and power users can verify, inspect, and interact with contracts from the product
• analytics become a real product surface, not a dashboard garnish

Phase C: Reach the “14/10” vision

Success means:

• the explorer becomes the canonical Chain 138 intelligence and action layer
• public explorer, operator awareness, route intelligence, and trust/provenance are fused into one product

Product Principles

These principles should constrain implementation decisions:

1. Every page must answer “what do I do next?”
2. Every important state must degrade clearly and honestly.
3. Deep data should be progressively disclosed, not hidden behind separate products.
4. Chain 138-specific context is not a sidecar. It is the differentiator.
5. Do not chase Etherscan parity blindly. Match the essentials, then exceed it with Chain 138-native intelligence.

Current Leverage In The Codebase

Important existing surfaces:

• Frontend pages:
  • explorer-monorepo/frontend/src/pages/transactions/[hash].tsx
  • explorer-monorepo/frontend/src/pages/addresses/[address].tsx
  • explorer-monorepo/frontend/src/pages/search/index.tsx
  • explorer-monorepo/frontend/src/pages/tokens/index.tsx
  • explorer-monorepo/frontend/src/pages/analytics/index.tsx
• Frontend data layer:
  • explorer-monorepo/frontend/src/services/api/transactions.ts
  • explorer-monorepo/frontend/src/services/api/addresses.ts
  • explorer-monorepo/frontend/src/services/api/blockscout.ts
  • explorer-monorepo/frontend/src/services/api/missionControl.ts
  • explorer-monorepo/frontend/src/services/api/routes.ts
• Backend REST:
  • explorer-monorepo/backend/api/rest/transactions.go
  • explorer-monorepo/backend/api/rest/addresses.go
  • explorer-monorepo/backend/api/rest/search.go
  • explorer-monorepo/backend/api/rest/mission_control.go
  • explorer-monorepo/backend/api/rest/swagger.yaml
• Backend GraphQL:
  • explorer-monorepo/backend/api/graphql/schema.graphql
  • explorer-monorepo/backend/api/graphql/resolvers.go

Important note:

• schema.graphql already declares Transaction.logs and Transaction.trace
• that suggests there is already a conceptual contract for deeper tx pages
• the shortest path may be to wire missing data rather than invent the entire model from scratch

Execution Order

The highest-yield order is:

1. transaction investigation depth
2. address intelligence
3. token explorer overhaul
4. contract and developer tooling
5. analytics overhaul
6. provenance and trust layer
7. explorer-to-action workflows

This order is chosen because it:

• raises perceived quality quickly
• closes the biggest benchmark gaps first
• creates reusable backend primitives for later phases

Workstreams

Workstream 1: Transaction Investigation Depth

Goal:

• turn transaction pages into investigation pages

Scope

• token transfer section
• logs section
• decoded method and arguments
• decoded event logs
• trace or internal call tree
• receipt and raw payload expansions
• richer failure and revert diagnostics

Primary files

• explorer-monorepo/frontend/src/pages/transactions/[hash].tsx
• explorer-monorepo/frontend/src/services/api/transactions.ts
• explorer-monorepo/frontend/src/services/api/blockscout.ts
• explorer-monorepo/backend/api/rest/transactions.go
• explorer-monorepo/backend/api/graphql/schema.graphql
• explorer-monorepo/backend/api/graphql/resolvers.go

Suggested ticket slices

1. Add transaction receipt and token transfer support to the frontend API layer.
2. Add logs and trace support to the backend API contract.
3. Render tabs or sections on the tx detail page for:
   • overview
   • token transfers
   • logs
   • trace
   • raw
4. Add human-readable failure diagnostics when status is failed.
5. Add unit tests for normalized tx payloads and missing/degraded states.

KPI

• a power user can answer “what happened in this tx?” without leaving the explorer

Workstream 2: Address Intelligence

Goal:

• turn address pages into entity pages

Scope

• holdings summary
• token balances list
• incoming vs outgoing segmentation
• latest token transfers
• internal tx tab
• approvals and allowances if available
• better contract-vs-EOA summaries
• saved labels and notes scaffolding

Primary files

• explorer-monorepo/frontend/src/pages/addresses/[address].tsx
• explorer-monorepo/frontend/src/services/api/addresses.ts
• explorer-monorepo/frontend/src/services/api/blockscout.ts
• explorer-monorepo/backend/api/rest/addresses.go
• explorer-monorepo/backend/api/rest/addresses_list.go
• explorer-monorepo/backend/api/graphql/schema.graphql

Suggested ticket slices

1. Add token balances and token transfer retrieval.
2. Add address activity summary aggregation.
3. Add contract profile surfaces:
   • verified status
   • label
   • token/contract classification
4. Add tabs or section navigation:
   • overview
   • transactions
   • token transfers
   • internal txs
   • holdings
5. Extend watchlist into metadata-backed saved entities.

KPI

• a user can answer “what is this address and what does it hold or do?” from one page

Workstream 3: Token Explorer Overhaul

Goal:

• replace the current token shortcut page with real token explorer functionality

Scope

• token detail route
• token overview
• holders table
• transfers table
• supply and metadata
• liquidity and route context
• trust/provenance badges

Primary files

• explorer-monorepo/frontend/src/pages/tokens/index.tsx
• new route likely needed:
  • explorer-monorepo/frontend/src/pages/tokens/[address].tsx
• explorer-monorepo/frontend/src/services/api/blockscout.ts
• likely new frontend service:
  • explorer-monorepo/frontend/src/services/api/tokens.ts
• backend:
  • either new REST handlers or proxied Blockscout surfaces via backend/api/rest/

Suggested ticket slices

1. Add token API service for overview, holders, and transfers.
2. Create token detail route by contract address.
3. Rework /tokens into:
   • token discovery
   • curated token index
   • top token categories
4. Add liquidity and route modules on token pages.
5. Add asset provenance badges backed by the Chain 138 registry.

KPI

• token pages become destinations, not just redirect helpers

Workstream 4: Contract And Developer Tooling

Goal:

• make the explorer developer-serious

Scope

• verification status
• source code browsing
• ABI access
• read contract
• write contract
• verification submission flow
• API examples and developer docs

Primary files

• explorer-monorepo/backend/api/rest/features.go
• explorer-monorepo/backend/api/rest/swagger.yaml
• explorer-monorepo/backend/api/rest/addresses.go
• explorer-monorepo/backend/api/graphql/schema.graphql
• frontend:
  • new contract sections in address pages
  • likely new reusable components under frontend/src/components/

Suggested ticket slices

1. Surface contract verification state on address pages.
2. Add ABI and source tabs for verified contracts.
3. Add read-contract UI for common methods.
4. Add write-contract UX only when the security model is explicit and safe.
5. Publish API examples linked from relevant explorer pages.

KPI

• developers can inspect and interact with contracts without defaulting to a different explorer

Workstream 5: Analytics Overhaul

Goal:

• turn analytics into a real product surface

Scope

• chain activity charts
• gas and throughput trends
• bridge flow analytics
• token flow analytics
• liquidity and route health trends
• notable changes and anomaly callouts

Primary files

• explorer-monorepo/frontend/src/components/explorer/AnalyticsOperationsPage.tsx
• explorer-monorepo/frontend/src/pages/analytics/index.tsx
• explorer-monorepo/frontend/src/services/api/stats.ts
• explorer-monorepo/frontend/src/services/api/missionControl.ts
• backend:
  • explorer-monorepo/backend/api/rest/stats.go
  • explorer-monorepo/backend/api/rest/mission_control.go
  • explorer-monorepo/backend/api/track1/bridge_status_data.go

Suggested ticket slices

1. Add timeseries endpoints for chain stats.
2. Add chart modules for throughput, gas, and indexing health.
3. Add route/liquidity health history.
4. Add top entities dashboards:
   • top contracts
   • top tokens
   • top bridge corridors
5. Add downloadable snapshots for operator and analyst use.

KPI

• analytics explain what changed, not just what exists

Workstream 6: Provenance And Trust Layer

Goal:

• make Chain 138 trust and provenance visible everywhere

Scope

• canonical asset indicators
• verified deployment lineage
• wrapped-asset origin
• partner or official labels
• route confidence and liquidity confidence
• public warnings for risky or unofficial assets

Primary files

• explorer-monorepo/backend/api/rest/config/metamask/DUAL_CHAIN_TOKEN_LIST.tokenlist.json
• explorer-monorepo/backend/api/rest/config/metamask/GRU_V2_PUBLIC_DEPLOYMENT_STATUS.json
• explorer-monorepo/backend/api/rest/config/metamask/CHAIN138_RPC_CAPABILITIES.json
• explorer-monorepo/frontend/src/services/api/missionControl.ts
• token, address, route, and liquidity pages on the frontend

Suggested ticket slices

1. Define provenance badge taxonomy.
2. Add registry-backed trust metadata API.
3. Render badges on token, address, pool, and route pages.
4. Add warning copy for unofficial or incomplete assets.
5. Add route confidence visuals tied to actual backend health.

KPI

• users can tell which assets and routes are canonical, partner-backed, or uncertain at a glance

Workstream 7: Explorer-To-Action Flows

Goal:

• make the explorer actionable, not just informative

Scope

• add-to-wallet from token and contract pages
• route or swap simulation from token pages
• liquidity pivots from token and pool pages
• mission-control pivots from failed tx or route pages
• operator-safe diagnostics for advanced users

Primary files

• explorer-monorepo/frontend/src/components/wallet/AddToMetaMask.tsx
• explorer-monorepo/frontend/src/services/api/routes.ts
• explorer-monorepo/frontend/src/services/api/liquidity.ts
• explorer-monorepo/frontend/src/services/api/planner.ts
• route, pool, token, transaction, and address pages

Suggested ticket slices

1. Add “next action” modules to token pages.
2. Add route simulation hooks where data exists.
3. Add tx troubleshooting suggestions for degraded states.
4. Add operator-depth panels with progressive disclosure.

KPI

• users can move from understanding to action without changing products

Milestone Plan

Milestone M1: Investigation Core

Goal:

• complete Workstreams 1 and 2 at baseline depth

Expected score movement:

• 5.8 to about 7.2

Definition of done:

• transaction pages have logs, transfers, and trace or internal-call context
• address pages have holdings and transfer depth
• all degraded states have explicit next actions

Milestone M2: Real Token Explorer

Goal:

• complete Workstream 3

Expected score movement:

• 7.2 to about 8.0

Definition of done:

• tokens have detail pages
• holders and transfers are visible
• Chain 138 token trust metadata is visible

Milestone M3: Developer Credibility

Goal:

• complete Workstream 4

Expected score movement:

• 8.0 to about 8.8

Definition of done:

• verified contracts are first-class entities
• ABI/source/read-contract are present
• API docs link directly from the explorer

Milestone M4: Analytics And Trust

Goal:

• complete Workstreams 5 and 6

Expected score movement:

• 8.8 to about 9.6

Definition of done:

• analytics show trends and top entities
• provenance is visible across tokens, routes, and addresses
• trust and health are obvious, not buried

Milestone M5: Action Layer

Goal:

• complete Workstream 7

Expected score movement:

• 9.6 to the “14/10” differentiated vision

Definition of done:

• token, address, tx, and route pages guide the user into the right action
• mission-control quality intelligence is embedded into normal explorer workflows
• the explorer becomes the operational home of Chain 138, not just its index

Suggested Initial Backlog

These are the first ten tickets I would create immediately.

1. Add normalized transaction receipt, logs, and token transfer models in frontend/src/services/api/transactions.ts.
2. Extend tx detail UI in frontend/src/pages/transactions/[hash].tsx with overview, logs, transfers, and raw-data sections.
3. Wire backend tx trace or internal transaction support through backend/api/rest/transactions.go and backend/api/graphql/.
4. Extend frontend/src/services/api/addresses.ts to fetch holdings, token transfers, and richer counters.
5. Rebuild frontend/src/pages/addresses/[address].tsx into a tabbed entity page.
6. Introduce frontend/src/services/api/tokens.ts and create frontend/src/pages/tokens/[address].tsx.
7. Replace the current /tokens page with a curated token explorer index and top-asset entry points.
8. Add contract verification and ABI/source visibility to address pages.
9. Expand AnalyticsOperationsPage.tsx with timeseries charts and top-entity modules.
10. Define and expose Chain 138 provenance badges from backend registry sources.

Teaming Recommendation

If work is split across multiple engineers, divide by write scope:

• Engineer 1: transaction and address depth
• Engineer 2: tokens and provenance
• Engineer 3: contract/developer tooling
• Engineer 4: analytics and route/liquidity intelligence

This reduces merge overlap and aligns with the biggest score lifts.

Risks

1. UX sprawl. If too many new surfaces are added without clear hierarchy, the explorer will feel more confusing, not more powerful.

2. Data inconsistency. If REST, GraphQL, Blockscout proxies, and RPC fallbacks disagree, trust will erode quickly.

3. Security exposure. Read/write contract and operator-depth tooling must be introduced carefully.

4. Product identity drift. If the team chases generic parity only, it may lose the Chain 138-specific advantage that makes the explorer special.

Recommendation

The best possible outcome is not just a prettier explorer.

It is:

• an investigator-grade explorer
• a trusted Chain 138 asset and route intelligence layer
• an action surface for both public users and advanced operators

The immediate move is to start Workstreams 1 through 3, because that is the fastest route to a visibly stronger product and the most credible path toward the larger “14/10” vision.