The problem

The Explorer now sits on a stable, maintainable foundation following recent RFP work. However, it remains visually and functionally disconnected from the Foundation’s surfaces and limited in what it surfaces to operators and delegators. It was built for an earlier era of the network and has not yet been fully realigned with current needs.

Delegators making stake decisions today have less information than they should. Operators don't have the observability they need. The surface does not reflect the current state of the network or the direction the Foundation is moving.

For the largest cohort of existing Livepeer participants — the people who stake, delegate, and operate — the Explorer is the Foundation's front door. Leaving it in its current state is a visibility liability that undercuts the trust the rest of the quarter's work is trying to build.

Operators with better observability can demonstrate performance; delegators with better data can reward it. Both sides of that loop are currently underserved.

The direction

Restore the Explorer as the permissionless participation portal. The canonical Foundation-owned surface for operators and delegators, aligned with the Foundation's design system and current network reality.

Q2 scope:

• Tailwind restyle aligned with the Foundation's design system and the Developer Portal surface.

• Improved default network stats — the data delegators and operators actually need to make decisions, drawing on the subgraph upgrades and metrics framework developed through the NAAP metrics/SLA process.

• An AI-native interface for stakeholders to query network data, surface custom dashboards, and get answers grounded in live on-chain state — not generic context (#584).

• LIP voting transparency — surfacing proposal status, voting history, and participation rates directly in the Explorer (#482).

• A native notification system for delegators and operators — reward events, proposal activity, stake changes (#319).

This list is a starting point — community members are invited to propose additions during the scoping window.

Work sequences after design system consistency between the Developer Portal and Explorer is specified. The two surfaces share design tokens; they do not share information architecture.

Why now

The Explorer is the most visible artifact of the network for the audience with the largest standing investment in it. Every week the Explorer remains in its current state is a week the Foundation signals that existing participants are not the priority. That is not the signal the quarter's strategy warrants.

Funding this through the Network Engineering SPE provides a path to a retainer-based team that owns the repository and delivers against a clear participation-portal vision — rather than treating the Explorer as spot work between other priorities.

What the community helps scope

The problem statement is settled. The direction is settled. The scoping work ahead is:

• Which features matter most to delegators vs. operators. Current state assumes one surface serves both audiences equally; that assumption deserves testing.

• How AI chat is grounded in real network data. What data sources, what refresh cadence, what accuracy bar.

• Which observability surfaces serve decision-making vs. which are vanity. Specifically: what does a delegator need that they don't have, and what would an operator check daily.

• How LIP voting transparency is designed — what proposal data is surfaced, what participation metrics matter, and how the interface lowers friction without reducing quality (#482).

• What retainer structure best fits the work — a single team, a rotating set of contributors, or a hybrid model.

Funding path

Network Engineering SPE, Priority 2 — Explorer — Participation & Observability. The SPE supports retainer-based contributor work where scope warrants it, in addition to the RFP-and-retroactive structure.