Showcase orchestrator voting activity in the UI

[rickstaa]

Problem

Governance participation by orchestrators is currently difficult for stakeholders to assess. Voting data exists on-chain, but it is not surfaced in a way that makes individual orchestrator engagement or proposal-level voting trends easy to understand.

Goal

Improve governance transparency by clearly exposing how orchestrators vote over time and how votes are distributed on each proposal.

Proposed Solution

1. Orchestrator History Page

Add governance vote events to the orchestrator history page.

Each vote should appear as a single history entry, consistent with existing activity items, and include:

• Action: “Voted on proposal”
• Proposal: Proposal ID (with link to proposal page)
• Vote: For / Against / Abstain (visually emphasized)
• Date: Timestamp

Behavior:

• Display governance votes as standard History items, consistent with existing style and ordering (most recent first).
• Keep entries compact and scannable, without introducing new layouts or long titles.
• Allow navigation to the associated proposal via link or click.
• Do not change existing History behavior beyond adding this event type.

2. Orchestrator Profile Page

Add a lightweight governance participation stat to the orchestrator overview.

Include:

• Governance Participation: Number of proposals voted on relative to the number of proposals the orchestrator was eligible for while active (e.g. 17 / 20 proposals voted)
• (Optional) Last Vote: Most recent proposal voted on

This should be presented as a compact summary and link to the History tab for full voting details.

3. Governance Proposal (Treasury) Page

Add an “Orchestrator Votes” section to governance proposal pages to surface how orchestrators voted on each proposal.

Include:

• A list of orchestrators that have voted on the proposal
• For each orchestrator:
  • Vote (For / Against / Abstain)
  • Voting power used
  • Link to orchestrator profile
    Behavior:
• Displayed as a secondary section near the bottom of the proposal page, below the proposal details.
• Sorted and paginated as needed.
• Provide transparency without impacting the primary proposal or voting UI.
• Optionally include a lightweight call-to-action in the voting widget (e.g. “View orchestrator votes”) that scrolls to this section.

Design & Review Process

The UI patterns described in this proposal are intended as guidance to achieve the stated goals.
Implementers may propose alternative designs if they better meet usability, clarity, or maintainability requirements.

Any material design changes should be reviewed with UX/UI representatives from the Livepeer Foundation
and relevant advisory boards prior to final merge. @mehrdadmms can guide this process.

Dependency

This work depends on merging [subgraph#175](livepeer/subgraph#175), which exposes the required governance voting data.
Although a Graph Studio deployment is available for development, this PR must be merged before UI changes can be merged into main.

[rickstaa]

#279

[ECWireless]

Forwarding details from #345

Completes this PR: #300

---

• Implement governance vote indexing via The Graph (current PR is using an RPC).
  • Finish any incomplete frontend components.
  • UI/UX adjustments for clarity and responsiveness.