Issue ticket: https://github.com/livepeer/explorer/issues/692

Definitions

• Platform: the product being analyzed, such as Livepeer Explorer, Coinbase, Kraken, Binance.US, Keplr/Cosmos, Lido, or Rocket Pool.
• Scenario: the starting point being tested. For Explorer, this may include fiat to delegated LPT, exchange-held funds to delegated LPT, or wallet-held LPT to delegation. For benchmark products, this may use a supported staking asset rather than LPT.
• Journey stage: the part of the flow being evaluated, such as discovery, asset setup, selection, execution, monitoring, or exit.
• Qualitative notes: what the user sees, understands, or struggles with during that stage.
• Step / time / fee estimates: the measurable friction in the flow, including screens, prompts, delays, trading fees, withdrawal fees, gas, or bridge costs.
• Risk / trust notes: how the product gives the user confidence, explains tradeoffs, or fails to explain them.
• Failure points: the places where the user is most likely to get blocked, confused, or abandon the flow.
• Score: a lightweight 1–5 synthesis score used to compare patterns across products. Scores will not replace the written analysis; they will help identify the highest-severity Explorer gaps.
• Explorer implication: what the finding suggests for Explorer’s design brief, instrumentation plan, or backlog.

Comparison Matrix

• I’m ignoring wallet connection as its not apart of discovery | $0 | 1 decision: how do you want to get started? | None | Sidebar nesting obscures multi-chain staking options. Clicking the staking link while not logged in leads nowhere productive. | 5 | Surface feedback prominently for high-impact operations. Encourage users to act in alignment with the protocol's ethos (decentralization). Answer "what happens next?" at each stage. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3005-123&t=N6KPTtYGQCBzWYSW-4 | | - | C1 | - | Selection | Chain and validator selection happen within a modal. The app offers a wide range of chains and validators, and actively encourages users to delegate outside the top 10 to support decentralization. | 3 decisions: which chain, which validator, how much to stake. | ~30 seconds | $0 | 3 decisions: • which chain • which validator • how much to stake | The UI actively nudges toward decentralization, which doubles as a trust signal. APR is displayed per staking option. | Success toasts appear in the top-right and move quickly; easy to miss on important operations. The flow assumes familiarity with web3 tooling and doesn't explain what staking does, why it routes through validators, or what happens next. | 4 | • User feedback should be clearly visible for important operations • Encourage users to align with the ethos of the flow (decentralization, fairness etc.) • Answer “what happens next?” and inform the user | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3040-305&t=tnTj3G7a7YiiqDXX-4 | | - | C1 | OSMO | Staking | Straightforward execution. No explanation of how staking benefits the user or the ecosystem. | 2 steps: click stake, approve | ~10s | $0 | 1 decision: whether to approve the token spend. | No risk or trust information addressed in this flow. | Transaction confirmation toast is top-right and easy to miss. No social proof or signal that the staking method is working for other users. | 3 | Fast transaction speed is a positive. Route users to where they can find the result of their action immediately after completion. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3067-369&t=tnTj3G7a7YiiqDXX-4 | | - | C1 | - | Monitoring | Staked tokens appear in both the dashboard overview and the Staking tab. | Max 2 clicks | ~5s | $0 | 1 implicit decision: whether to view token breakdown or modify the stake. | The Staking tab shows the exact staked amount, confirming the action completed successfully. | None | 3 | Post-action artifacts should be surfaced in the place most relevant to the user, at appropriate prominence. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3067-472&t=tnTj3G7a7YiiqDXX-4 | | - | C1 | - | Exit | The unstaking flow is accessible but doesn't explain what unstaking means or why an unbonding period exists. | ~3 steps: click validator in UI, choose unstake, approve txn | ~8s | $0 | 1 decision: whether to unstake and accept the unbonding period. | Users are informed of the unstaking period and any applicable restrictions. | Transaction failure. Users may not understand the unbonding period or why it exists. | 4 | Consequences of high-impact actions should be explained before the user commits. "Here's what happens when you proceed" is a useful pattern. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3067-522&t=tnTj3G7a7YiiqDXX-4 | | Keplr | Validation | OSMO | Discovery | Access to the Keplr Validator Dashboard is via a link in the main app's nav, under "products." Positioned as a separate tool rather than an integrated feature. The dashboard surfaces a welcome modal with a get-started button for non-validators. | Navigate to products dropdown in the main Keplr app, click "Validator Dashboard.” | ~5–10s | $0 | 1 decision: whether to unstake and accept the unbonding period. | None | Users may not associate "Validator Dashboard" with delegation or permissioning. Non-validators land on a different onboarding modal, which can further obscure intent. | 2 | Treating delegation as a separate product fragments the experience. Worth considering whether Livepeer's governance/voting actions should be grouped with delegation or kept distinct. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3067-522&t=tnTj3G7a7YiiqDXX-4 | | - | Validation | - | Selection | User searches by validator name and links the validator to a chain. Linked validators appear in a "Connected Validator" list with chain badges. The flow requires linking before any permission management can begin. | Search validator, select chain, confirm link. | ~5–10s | $0 | 2 decisions: which validator, which chain. | None | User may not know which validator or chain applies if they manage multiple. Required link step adds friction before the actual permission flow begins. | 3 | Clear step differentiation | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3067-522&t=tnTj3G7a7YiiqDXX-4 | | - | Validation | - | Permissions | Manage Permissions modal lists granular actions the validator can grant: Vote, Set Withdraw Address, Claim Commission. Each shows current grant status. Granting requires running a CLI command outside the UI, followed by clicking a Check button in the UI to verify the permission was granted. After verification, the row updates to show the grantee is "now authorized.” | Search validator, select chain, confirm link. | ~5–10s | $0 | Which permissions to grant. | Permission status is explicit (e.g., "Vote permission not granted" → "Keplr Infra is now authorized to vote on behalf of [validator]"). The Check button provides verification feedback, which closes the loop on the off-UI CLI step. | Granting requires CLI execution outside the UI, which is a significant technical barrier. The flow assumes Cosmos SDK CLI familiarity. Users uncomfortable with the command line may abandon at this step. | 3 | Authority delegation (vote, withdraw, claim) is conceptually distinct from stake delegation but coexists in many ecosystems. Worth considering whether Livepeer's governance flow needs analogous granular permissioning, and if so, whether it can avoid requiring off-UI steps. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3067-522&t=tnTj3G7a7YiiqDXX-4 | | - | Validation | - | Monitoring | Rewards are shown in the portfolio with daily accrual. UI not depicted in this section of the analysis. | None | ~4-day unbonding. | $0 | None | None | No explanation of why the unbonding period exists; users may not understand the underlying mechanic. | 1 | Explanation for periods of unbonding. Mechanics should be transparent | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3067-522&t=tnTj3G7a7YiiqDXX-4 | | - | Validation | - | Exit | Flow diagram indicates unstaking is requested through the dashboard with a ~4-day unbonding period. UI not depicted in this section of the analysis. | None | Unknown | $0 | None | Permission status is explicit (e.g., "Vote permission not granted" → "Keplr Infra is now authorized to vote on behalf of [validator]"). The Check button provides verification feedback, which closes the loop on the off-UI CLI step. | No instruction in the flow on where to monitor accrual; users would need to know to check the portfolio independently. | 1 | Authority delegation (vote, withdraw, claim) is conceptually distinct from stake delegation but coexists in many ecosystems. Worth considering whether Livepeer's governance flow needs analogous granular permissioning, and if so, whether it can avoid requiring off-UI steps. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3067-522&t=tnTj3G7a7YiiqDXX-4 | | Lido | C1 | ETH | Discovery | Staking CTAs are prominent and high-contrast on the homepage. The page is effectively dedicated to establishing Lido's security and performance before asking the user to act. | 1 step | 2s | | None | The home page is basically dedicated to this: addressing security and performance of Lido | None | 5 | Giving users immediate access to their intended action, and front-loading trust signals on the entry page, reduces friction and drop-off at the discovery stage. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3078-533&t=vtefACXCh5GnoM4N-4 | | - | C1 | - | Selection | Selection is a single amount input. An FAQ section sits directly below the staking widget, addressing common questions about the process and surfacing trust and safety information in context. | 1 step: enter the amount of ETH you’d like to deposit | 2s | $0 | • How much ETH to stake | FAQ section below the main action area covers staking mechanics, safety, and relevant contract addresses. | Entering an amount above the user's available balance. | 4 | An inline FAQ near the delegation widget would address common concerns without requiring users to leave the flow. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3079-728&t=vtefACXCh5GnoM4N-4 | | - | C1 | - | Staking | Simple, fast execution. Two steps: hit stake, confirm in wallet. | 2 steps: hit stake button / confirm in wallet | 5s | $0.04 | • Whether to confirm txn in wallet | Trust and risk information was front-loaded earlier in the flow; not repeated here. | • Failing to confirm wallet transaction | 5 | Front-load trust and risk information before the user reaches the high-impact action, and reference at the point of execution. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3084-145&t=oQPNIxFZRFbpFWpa-4 | | - | C1 | - | Monitoring | No post-staking redirect or instruction. User must navigate to the Rewards page independently via the top nav. | 1 step: use the top nav to access “Rewards” page | 1s | $0 | None | None | User not connecting wallet; user entering an incorrect wallet address in the search bar. | 3 | After a high-impact action completes, direct or redirect the user to where they can monitor the result. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3089-205&t=oQPNIxFZRFbpFWpa-4 | | - | C1 | - | Exit | Withdrawal is a two-phase flow: request and claim. Submitting a request mints an NFT the user can use to track progress. The claims tab becomes active once the request is approved. | Steps: • Go to withdrawal page and choose request tab • Enter amount you’d like to withdraw • Hit request • Add NFT to wallet (optional) • Go to claims tab • If request is approved you can claim the requested amount | • 8s to request • ~11h approval wait time • 10s claim | Request: $0.42

Claim: $0.17 | None | Withdrawal FAQ sits below the main action area. Etherscan transaction links are provided as a source of truth. | Not connecting wallet; not confirming the transaction. | 4 | Inline FAQ near high-impact features is a reliable pattern for addressing user concerns without interrupting the flow. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3104-246&t=oQPNIxFZRFbpFWpa-4 | | Rocket Pool | C1 | ETH | Discovery | Staking is accessible from three locations on the homepage: the liquid staking dropdown in the nav, a primary nav CTA, and a liquid staking section on the page. | 1 step: click any link | 1s | $0 | Where to access the staking page from | Nav dropdown includes a link to the risk disclosure page. | Users may not identify all three entry points as leading to the same place. | 4 | Multiple prominent entry points reduce the chance a user misses the feature entirely. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3106-351&t=oQPNIxFZRFbpFWpa-4 | | - | C1 | - | Selection | Selection is a single ETH amount input, as expected. No additional context or guidance on the page. | 1 step: enter ETH Amount | depends on user | $0 | how much to stake | No risk information on the page; no link to the risk disclosure page from this screen. | Entering an invalid amount | 5 | Risk disclosures should be accessible at or near the point of selection, not only reachable via the nav. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3125-421&t=oQPNIxFZRFbpFWpa-4 | | - | C1 | - | Staking | Fast, minimal execution. Two steps: hit stake, confirm in wallet. No risk or trust information present in the staking flow itself. | 2 steps: hit stake button / confirm in wallet | ~2s | $0.31 | • wallet confirmation | Nothing on the page addresses risk or links to the risk disclosure page. | no wallet connection | 5 | Link to risk disclosures at or near the execution step. Fast transaction times and clear outcome feedback (animation, focused copy) reinforce that the action completed successfully. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3127-424&t=oQPNIxFZRFbpFWpa-4 | | - | C1 | - | Monitoring | No meaningful monitoring experience. The only post-stake indicator is a display of the user's rETH balance. No APR, reward history, or performance data is shown. | 1 click to the menu | ~1s | $0 | None | None | No wallet connection | 1 | A dedicated monitoring dashboard showing rewards and performance is a baseline expectation users will bring from other products. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3127-452&t=oQPNIxFZRFbpFWpa-4 | | - | C1 | - | Exit | Fast, minimal execution. Two steps: hit unstake, confirm in wallet. Same absence of risk and trust information as the staking flow. | 2 steps: hit unstake button / confirm in wallet | ~2s | $0.31 | • wallet confirmation | Nothing on the page addresses risk or links to the risk disclosure page. | no wallet connection | 5 | Same as Staking: link to risk disclosures, use animation and focused copy to confirm the action completed. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3127-468&t=oQPNIxFZRFbpFWpa-4 | | The Graph | C1 | GRT | Discovery | Delegation is accessible via the "Delegate" link under the Participate dropdown in the nav. | 1 click from the nav. | ~2s | $0 | None | A section addressing trust and risk exists elsewhere on the site, but there's no callout to it within this flow. | None | 3 | The delegation interface should be easily discoverable from wherever the user enters the app, ideally promoted to a visible top-level nav item rather than buried in a dropdown | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3155-325&t=cxEoDg4uwZDqMDCD-4 | | - | C1 | - | Selection | Clicking through from the nav lands on a dedicated delegation page. The page includes video content explaining what delegation is, how to acquire the token needed to delegate, and why delegation matters, alongside a list of indexers to delegate to. One video specifically addresses what to look for when choosing an indexer. | There are no specific steps here, but it seems like they're encouraging users to watch the videos and get educated before scrolling down on the page and choosing an indexer. One of the videos even talks about what to look for in choosing an indexer, which is nice. | Variable; depends on whether the user engages with the educational content first or already knows which indexer they want. | $0 | 1 decision: which indexer to delegate to. | None | Users may fail to understand how delegation works, why it matters to The Graph's ecosystem, or what criteria to use when choosing an indexer, if they skip the educational content. | 4 | Video content addressing delegation mechanics, token acquisition, and risk would meet users where their attention already is. A short, accessible explainer (video or written) embedded in the selection flow is worth testing. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3155-399&t=cxEoDg4uwZDqMDCD-4 | | - | C2 | - | Swap (External) | So swapping is not done on the Graph platform itself. They encourage you to use Uniswap. I used CowSwap to swap from ETH on Arbitrum to the GRT token on Arbitrum. | | | | | | | | | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3167-612&t=cxEoDg4uwZDqMDCD-4 | | - | C1 | - | Staking | Once the user holds GRT, the flow is a straightforward token spend approval followed by confirmation. | Choose delegation amount, confirm token spend approval, confirm the transaction. | ~10s | $0 | 1 decision: how many tokens to delegate. | None | Entering an amount the user doesn't hold; failing to sign the transaction; wallet not connected. | 4 | The flow itself is clean, but it's missing trust and risk context that could be surfaced here. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3169-798&t=cxEoDg4uwZDqMDCD-4 | | - | C1 | - | Monitoring | The user's position and the indexer they delegated to are visible on their profile page after staking, but there's no redirect or instruction pointing them there post-transaction. | No steps really, you just have to click around and try to find out where you can see your position. | ~5s | ~$0 | None | None | Users may not realize the wallet icon in the nav leads to their profile and position data. | 3 | Folding the monitoring destination into the post-transaction flow, directly instructing users where to check their results, would close this gap. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3170-902&t=cxEoDg4uwZDqMDCD-4 | | - | C1 | - | Redelegate | I don't see this option. | | | | | | | | | | | - | C1 | - | Exit | Same access pattern as staking; reached through the indexer's submenu on the user's profile. | Choose amount to undelegate, confirm token spend approval, confirm the transaction. | Undelegating itself takes about 10 seconds, but there's a 21-day unbonding period before tokens can be withdrawn. | ~$0 | 1 decision: how much to undelegate. | None | Entering an amount the user doesn't hold; failing to sign the transaction; wallet not connected. The unbonding period isn't explained anywhere in the flow. | 4 | Waiting periods need an explanation of why they exist; users may not understand the underlying protocol mechanics otherwise. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3171-959&t=cxEoDg4uwZDqMDCD-4 | | Livepeer | C1 | LPT | Discovery | Observation: Orchestrator link exists in nav, but a user unfamiliar with delegation wouldn't know to look there. Delegation also reachable via "My Account."

Core issue: Nav structured around artifacts (Orchestrators, Treasury) rather than user actions.

Comparison point (The Graph): Not purely action-based either; Subgraphs, Participants, Network remain artifact pages. But Delegate is promoted to top-level nav alongside artifacts. Livepeer has no equivalent; delegation nested inside Orchestrators or buried under Account.

Implication: Likely doesn't require full nav overhaul, just surfacing delegation at top level alongside existing artifact pages. | The step is to first find links and then click them. | ~1s. Time grows exponentially when assuming the user doesn’t know exactly what to look for | $0 | None | None | Not being able to find where you want to go. | 3 | Promote a core action, Delegate, to a top-level nav item, at the same hierarchy as artifact pages like Orchestrators and Treasury. Right now that action is either nested inside the Orchestrators page or tucked under Account, with no direct top-level path. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3223-678&t=0vbjvbqvcV1xiwXp-4 | | - | C1 | - | Selection | • Observation: Orchestrator selection presented as a bare table with no surrounding context. No explanation of what delegation is or why it matters for the ecosystem, just a ranked list with yield/stake/fees columns. • Interaction issue: Delegate action accessed via hidden sub-menu ("..." per row). Not visible by default; requires discovering and opening the row menu to find it. Action present but not prominent. • Naming collision: Same row menu contains "Delegate" (under Actions) and "Delegating" (under Account Details). These are easily conflated but serve different purposes: "Delegate" lets any user delegate to that orchestrator, while "Delegating" shows that orchestrator's own delegation details/relationships. Near-identical labels in the same menu risk user confusion about which one performs the action they want. | • Choose a delegator • Hit the “…” menu • Choose “Delegate” under Actions header | ~3s | $0 | Which orchestrator to delegate to | None | 1. Delegate action not discoverable Primary delegation action is hidden behind a per-row "..." sub-menu. No indication on the page or in each row that this menu exists or that delegation is accessible from it. Users unfamiliar with the pattern may never find the entry point and abandon before initiating the flow

2. Naming collision in row menu Same sub-menu contains "Delegate" (Actions) and "Delegating" (Account Details). Near-identical labels, different functions. A user who finds the menu may select "Delegating" expecting to initiate delegation, and instead land on that orchestrator's delegation data. Likely to cause confusion or false completion (user thinks they've done something when they haven't). | 2 | Surface "Delegate" as a persistent, visible action on each orchestrator row — not behind a sub-menu. Resolves both failure points: the action becomes discoverable without requiring knowledge of the "..." pattern, and separating it visually from "Delegating" (an Account Details view) eliminates the naming collision at the point of action. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3224-772&t=0vbjvbqvcV1xiwXp-4 | | - | C1 | - | Staking | Clicking "Delegate" from the row submenu navigates to the orchestrator overview page, not a dedicated delegation flow. All submenu links route here; the only difference is which tab is active under Account Details. Clicking "Delegate" specifically lands on the overview tab, not the delegation panel. User is dropped onto the page with no clear orientation toward the action they initiated. | • hit approve • confirm wallet txx • hit delegate • confirm wallet txn | ~3s | $0 | How much to stake | None | 1. No focus state on delegation panel after navigation User clicks "Delegate" and lands on a page that looks the same regardless of entry point. Delegation panel is present but not surfaced or emphasized. User has to locate it themselves

2. No decision-making support before delegation App doesn't explain what makes a good orchestrator choice. Fee cut and reward history are available as data but there's no guidance on how to interpret or weigh them.

3. Warning message is a disclaimer, not guidance Upon entering an amount, a callout reads "Please ensure you have checked the reward & fee cut history before delegating." Surfaces reactively after the user has already entered an amount. Tells the user to do something without giving them the means to act on it.

4. Approve and Delegate presented as options, not steps Two-step flow (Approve token spend, then Delegate) is presented as two side-by-side buttons. Side-by-side implies choice; these are sequential steps. Delegate button is greyed out but no explanation is given for why. The step indicator (dots at the bottom) is present but minimal and easy to miss. | 2 | Replace two-button layout with a single progressive button: "Approve" visible first, transitioning to "Delegate" only after approval is confirmed. Fold decision-making guidance into the orchestrator selection step, before the user reaches the delegation panel. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3230-913&t=0vbjvbqvcV1xiwXp-4 | | - | C1 | - | Monitoring | After delegation completes, user receives no confirmation state, success message, or redirect. No instruction on where to go to monitor their position. User must independently discover that "My Account" in the nav leads to their delegation metrics. | 1 step to find monitoring (navigate to My Account) but the user has to know to look there. | Low if user finds My Account immediately. Indeterminate if they don't. | $0 | 0 explicit decisions, but 1 implicit one: figure out where to go next without guidance. | No confirmation state after delegation completes. User has committed tokens with no acknowledgment of success. For a first-time delegator this is a meaningful trust gap, the absence of feedback can read as a failed transaction. | No post-delegation handoff. Flow ends without closure. User is left on the orchestrator page with no signal that anything changed or where to go next. | 2 | Post-delegation state needs a defined destination: either a confirmation screen with a direct link to the user's delegation metrics, or an automatic redirect to My Account (Delegating tab) with a success state. This is also an instrumentation opportunity: drop-off after the Delegate transaction confirms, before the user ever views their position, would indicate users who completed the action but couldn't find their way to monitoring it. | https://www.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3232-965&t=0vbjvbqvcV1xiwXp-4 | | - | C1 | - | Redelegate | | | | | | | | | | | | - | C1 | - | Exit | | | | | | | | | | |

https://embed.figma.com/board/QOTjdAaNAxBw2dKRGNu5I2/Livepeer-UX-Analysis?node-id=3011-107&t=jO0rpt48pUKzSOu9-0&embed-host=notion&footer=false&theme=system