Added more transparency to the governance page of Livepeer Explorer by displaying how each votes was carried out, the amount of staked LPT, the voters, their vote choice, and the voting history of voters.
Why does it matter?
One to two sentences. What problem does it solve, and for whom on the network?
This feature tackles an important element missing from the Explorer – Transparency. Currently, once polls are finalized, it is not possible to see any information that explains how the decision was reached. Transparency is essential because it builds trust among the participants of the system and the ecosystem as a whole. This feature not only adds more transparency but also shows the voting history of all voters and the choice they made in each poll.
The beneficiaries of this contribution include orchestrators who have/have not participated in a voting decision in the past, and delegators who want to draw certain conclusions from their delegates’ voting history.
Link to the work
Direct link to the merged PR, deployed tool, published docs, or equivalent. No link = no review.
How is this being used? Who benefits? Quantify where possible (e.g. number of users, PRs merged, integrations adopted).
Each poll has an average of 89 voters. Each of these voters can benefit directly from this contribution by previewing their voting history and using that as the basis for their decisions in future polls.
New orchestrators joining the ecosystem and participating in governance for the first time will benefit directly from this, as the transparency on the governance page will give them insight into previous voting decisions and guide them towards making the choice that aligns with them the most.
Community proof points
Link to the Discord thread or other signal. Reminder: you should also get 2-3 Orchestrators commenting their support for this work.
Scope — [Delegators] Governance & Network Observability In scope. Explorer improvement that makes governance more legible for LPT holders.
Work shippedPR #683 plus a deployed Vercel preview. Publicly reviewable and directly linked.
Community proof point Discord discussion thread, with support from Brad and Titan (orchestrators) and Rick (Foundation); also addresses an open issue raised by ECWireless (#482).
Impact (primary criterion)
Importance of the need: Finalized polls currently expose no record of how a decision was reached — the work surfaces voter, staked LPT, vote choice, and per-voter voting history. A recognized transparency/legibility gap in governance.
Breadth: Benefits every governance participant across polls that average ~89 voters, with named orchestrators confirming support. High importance + confirmed reach.
Quality & completeness Complete feature with a working deployed preview.
Proportionality $500 is small and clearly reasonable for the scope of work delivered.
Red flags None. Real, community-requested need with external confirmation — not speculative or self-serving.
Review Team Decision — Approved & Paid
Based on the size of the work and its merit, the impact is clear and the size is small and justified. Approved and paid out.
This contribution addresses a documented governance transparency gap by bringing voter identity, vote choice, staked LPT, transaction details, and voter history to Livepeer governance polls. It extends the established Treasury and orchestrator transparency experience rather than introducing an unrelated architecture, and it integrates appropriately with the Explorer’s Apollo/subgraph data layer, IPFS proposal metadata, ENS resolution, shared design system, and responsive table patterns.
The applicant responded constructively to review feedback. Desktop and mobile ordering are now consistent, vote-event pagination and error handling were added, unknown choices are handled in the primary views, and the final loading-state issue was resolved. The current PR is conflict-free and passes linting, type checking, tests, and Lighthouse checks. The $500 request is proportional to the scope and matches the amount published for the opportunity.
Future maintenance work should include moving the remaining unknown-choice fallback into PollVoteDetail, tightening the decorated vote types instead of relying on a cast, guarding asynchronous ENS decoration against stale updates, lazily starting vote-history work when the Votes view is opened, and adding focused tests for pagination and vote-percentage calculations. These follow-ups improve resilience and maintainability but should not block the grant payout.
AI Pre-Screen — Retro Grant Review