RFP — Delegator UX Analysis (Self-Custody vs. Custodial Staking)

[rickstaa]

Budget Envelope: Up to $10,000 USD equivalent
Date Issued: 2026-05-14
Issued By: Rick Staa

---

1. Purpose

Objective

Analyse the Explorer’s delegation UX against the staking experiences offered by major exchanges (Binance, Coinbase, Kraken) and comparable PoS tokens. No major exchange currently offers a user-facing LPT staking product, but their staking UX sets the bar for user expectations. Produce a design-ready specification for a self-custody delegation experience that could compete or pull users away from the path of least resistance of holding on an exchange, thus preserving the direct protocol participation that makes self-custody valuable: governance rights, earnings transparency, and independence from custodial intermediaries.

Problem Statement

Livepeer’s on-chain delegator count has fallen ~36% over two years, but total staked LPT and participation rate have held steady or grown. The gap is explained by a structural shift: centralised exchanges are delegating growing pools of custodial LPT without any user-facing staking product. No major exchange such as Binance, Coinbase, or Kraken offers LPT staking. The delegation is happening without user involvement.

The Explorer’s delegation flow needs to be compelling. Simply holding LPT on an exchange while the exchange stakes it without their involvement results in centralisation that undermines the network. We want actively grow delegators and direct governance participation.

We need to:

• Precisely quantify the UX gap between the Explorer’s delegation flow and the top staking UX standard set by major exchanges and comparable PoS tokens
• Identify the specific design and information-architecture changes that would improve self-custody delegation
• Produce a shippable design brief the Foundation can convert directly into build work (retro grants or follow-on RFP)

Desired Outcome

Within 3–4 weeks, we have:

• A competitive teardown showing exactly where and why the Explorer’s delegation experience falls short of the standard set by exchange staking UX or other ecosystems at each step of the journey
• A design-ready specification for a “minimum competitive staking experience” in the Explorer
• A prioritised backlog of improvements with expected impact and effort that can be shipped as follow-on work

---

2. Requirements

Key Deliverables

1. Competitive teardown
   • Primary analysis (external competitive frame): Side-by-side comparison of the Explorer delegation flow vs. the staking experiences offered by major exchanges (Binance, Coinbase, Kraken) for comparable PoS tokens. No major exchange currently offers a user-facing LPT staking product, but their staking UX for other tokens sets a standard users expect.
     Dimensions: steps-to-stake, time-to-stake, information architecture, trust signals, yield presentation, risk framing, reward monitoring, and unstaking/exit experience (including offboarding from custodial products to self-custody: withdraw/transfer out). Each comparison should include annotated screenshots or screen recordings documenting the full flow.
   • Secondary analysis (decentralised staking UX): Review of the best delegation and staking experiences across decentralised protocols, including but not limited to Lido, Rocket Pool, Cosmos/Keplr and/or other PoS ecosystems with strong delegator UX. This analysis should identify the UX patterns, information design, and onboarding flows that make these experiences work. What can we learn from the best decentralised staking UX?
2. Standardised baseline scenarios (for comparable measurement)
   • Use the same comparison dimensions as in the Competitive Teardown above, and explicitly quantify total fees, under consistent starting states:
     • Scenario A (Fiat start): new user starting from fiat → staked/delegated
     • Scenario B (Funds already on exchange): user already has funds on exchange → staked/delegated
   • Include at least one concrete comparison like “What does it take to get $100 → staked LPT?” (time, steps, fees, failure points) across platforms.
3. Gap specification
   • Map each identified UX gap to a specific Explorer screen, flow, or missing feature
   • Classify gaps by severity (blocking, friction, polish) and estimated effort (small / medium / large)
   • Highlight the gaps that most plausibly explain the shift toward custodial staking
4. Design brief: “Permissionless staking experience”
   • What would a new user need to see and do in the Explorer to choose self-custody delegation over leaving LPT on an exchange?
   • Wireframes or annotated flow diagrams (not just a written list) for the redesigned delegation journey
   • Cover: discovery/landing, orchestrator selection, delegation execution, earnings monitoring, and re-delegation/exit
   • Address the specific trust and clarity signals that custodial services provide and the Explorer currently lacks (yield clarity, risk framing, earnings visibility)
5. Instrumentation plan
   • What events and metrics need to be tracked to measure delegation conversion going forward
   • Minimal and implementable, scoped to what can be added to the Explorer’s existing codebase without major infrastructure changes
   • Propose a baseline measurement approach so future UX improvements can be evaluated
6. Prioritised backlog
   • Top 10–15 improvements ranked by: expected impact on self-custody delegation competitiveness, implementation effort, and dependency chain
   • Clear split: quick wins (shippable via retro grants) vs. larger items (follow-on build RFP)
   • Each item should reference the competitive teardown evidence that motivates it

Out of Scope

• Diagnosing why delegator count is declining (recent analysis confirms stake is centralising because exchanges are delegating custodial holdings, not because users are opting into custodial staking products)
• Implementing UX changes (this is an analysis + design specification scope)
• Protocol-level changes to staking mechanics (separate governance process)
• General-purpose user research unconnected to the competitive comparison
• Outreach / conversion strategy to migrate exchange-delegated LPT toward Explorer-based self-custody delegation (higher earnings, voting rights, orchestrator choice).
• Arbitrum liquidity readiness for sustained new stake originating from fiat — does the contributor see any concerns from the journey/teardown research?

Definition of Done — by Tranche

Tranche	% Budget	Unlocks On
1 — Signing	25%	Audit plan agreed, competitive teardown scope confirmed (which services, which dimensions), kickoff doc filed
2 — Delivery	50%	Competitive teardown delivered, gap specification delivered, design brief with wireframes delivered, instrumentation plan delivered
3 — Impact	25%	Prioritised backlog accepted by Review Team after a public comment window (≥7 days) on the forum, with community feedback/reaction explicitly weighed as part of acceptance. At least 3 items converted into follow-on work (retro grants or RFP scope) within 30 days of acceptance.

---

3. Capabilities Required

Skills

• Product design and UX analysis (competitive teardowns, information architecture)
• Ability to produce wireframes or annotated flow diagrams (Figma, or equivalent)
• Familiarity with web3 wallet interaction patterns and staking UX conventions
• Experience analysing decentralised protocol UX (delegation flows, validator/orchestrator selection, reward mechanics)
• Ability to read a modern web codebase (Explorer is React/Next.js) enough to assess instrumentation feasibility

Knowledge

• How centralised staking services (Binance, Coinbase, Kraken) present yield, risk, and onboarding to retail users for comparable PoS tokens
• How decentralised staking ecosystems (Cosmos/Keplr, Lido, Rocket Pool or others) handle delegator onboarding, validator discovery, and earnings transparency
• Livepeer delegator mechanics (L1/L2 bridging, orchestrator selection, reward cuts, bonding/unbonding)
• Web3 onboarding friction points and trust/risk communication patterns

Attitude

• Evidence-first: every recommendation grounded in the competitive comparison, not opinion
• Design-oriented: outputs should be visual and specification-ready, not just written analysis
• Comfortable working in public and with async feedback from the Foundation team

---

4. Proposal Requirements

Please include:

• Contributor / Team Overview
• Why you’re a fit (prior UX competitive analysis, staking product design, or delegation UX work)
• Approach & Timeline (mapped to tranches above)
• Which competitive services you will analyse (primary: Binance, Coinbase, Kraken staking UX for comparable PoS tokens; secondary: best-in-class decentralised staking/delegation experiences, e.g. Lido, Rocket Pool, Cosmos/Keplr or others you propose)
• Design output format (Figma, annotated screenshots, other)
• Pricing breakdown
• Conflict of interest disclosure

---

5. RFP Timeline

Milestone	Date
RFP Posted	2026-05-18
Application Deadline	2026-05-24
Decision Announced	2026-05-29
Project Start	2026-06-01
Expected Completion	2026-07-03

---

6. Proposal Submission Instructions

Reply to this forum post in the comments with your proposal (linking a doc or including it inline).

Questions: reach out to @rickstaa on Discord.

---

7. Decision & Governance

Selection criteria:

• Quality and specificity of competitive analysis approach, and do they understand what makes exchange staking UX set user expectations, and why users default to holding on exchanges?
• Demonstrated ability to produce design-ready specifications (wireframes, annotated flows), not just written reports
• Practical instrumentation plan that respects the Explorer’s current technical constraints
• Speed and clarity of execution

[ECWireless]

Hi all,

RaidGuild’s full proposal is linked here! https://drive.google.com/file/d/1XYSwnUrdx2-6xePGlMz5v-8hdehWpdtF/view?usp=sharing

Looking forward to any feedback.

Elliott

[Mehrdad]

Just over-communicating this for transparency: I’m technically a RaidGuild member.

I’m not involved in reviewing or approving applications, but wanted to flag the affiliation so there’s no ambiguity.

[lily]

Hi, we’ve prepared a proposal on delegator UX (self-custody vs custodial staking) and some practical ideas to improve the experience.

Sharing it here, would love any feedback: https://drive.google.com/file/d/1FzB15ylRKZ6_K-V7c-K72CNhnuh9LWIy/view?usp=sharing

[Mehrdad]

RFP — Delegator UX Analysis: Pre-Screening Assessment of Submissions

Submissions received: 2

What this is

A structured pre-screen against the Network Engineering SPE’s published RFP rubric — four checks: process compliance, pricing agreement readiness, execution standards, and quality bar. Output is one of two states per proposal: READY FOR REVIEW or NOT READY (with the specific items the applicant must fix).

Submissions

#	Applicant	Budget ask	Posted (UTC)	Doc
1	RaidGuild — Elliott Conway (ECWireless), with Beyondr	$10,000	2026-05-24 17:21	Proposal
2	Zera Rahmani & Fateme Rahmani	$8,000	2026-05-25 09:47	Proposal

Submission 1 — RaidGuild (Elliott Conway + Beyondr)

READY FOR REVIEW

A DAO-born product collective (150+ contributors, 200+ shipped projects since 2019) proposing a $10,000, three-tranche engagement that delivers a competitive teardown (Coinbase / Kraken / Binance.US primary; Keplr/Cosmos / Lido / Rocket Pool secondary), gap specification, design brief with wireframes, instrumentation plan, and prioritised backlog. Outputs split across Figma (visual), Google Doc (narrative), Google Sheet (matrix + backlog + event spec). Tranche dates anchored to June 8 / June 24 / July 3.

Rubric check

Process compliance

• Responds to this RFP; in scope.
• Proposes the how (comparison matrix, scenarios A/B/C with C1/C2 split, methodology constraints) without re-specifying the what.

Pricing agreement readiness

• Scope clearly bounded; three tranches map 1:1 to the RFP’s tranche structure.
• Each tranche has a specific output list usable as a definition of done.
• 25% / 50% / 25% explicit ($2,500 / $5,000 / $2,500).
• Budget $10,000 — at the RFP ceiling.

Execution standards

• Demonstrated capability: Beyondr previously shipped the governance visibility feature on the Explorer (PR #457) — direct prior contribution to this exact codebase. RaidGuild built the POKT bridge (~$7M flow) and Gnosis Omni Token Bridge (~$367M processed). Elliott runs a dev studio with 8+ years of protocol delivery experience.
• N/A — code-review / merge gate doesn’t apply (analysis RFP, no code delivery).
• No explicit commitment to update documentation, but the documentation is the delivery here (design brief, instrumentation spec, backlog).
• No explicit commitment to post monthly progress updates in this forum thread. With a 3–4 week timeline this is likely one mid-project update — should be confirmed at signing.
• No explicit commitment to a GitHub milestone board with connected issues. Less directly applicable to a research/design deliverable, but a public progress surface (Figma board, Notion page, or GitHub project) should be confirmed at signing.

Quality bar

• Substantive, specific, evidence-first. Comparison matrix column structure is reproduced inline (Platform / Scenario / Journey Stage / Qualitative Notes / Step Count / Time / Fee / Decision Count / Risk-Trust / Failure Points / Score / Evidence / Explorer Implication). Scenarios A/B/C with C1/C2 split goes beyond what the RFP asked for.
• Real Explorer understanding: identifies that Explorer is hosted on Vercel with a Pro account already, and recommends Vercel Web Analytics as the lowest-lift instrumentation path. Lists concrete funnel events. Separates Explorer-controllable friction from ecosystem- and protocol-level friction (a useful constraint the RFP doesn’t enforce).
• COI disclosure included (“RaidGuild recently completed work on another Livepeer RFP”).

Notable strengths

• Beyondr’s existing Explorer codebase experience (PR #457) is the strongest single signal in either submission of “ability to read a modern web codebase,” called out explicitly in the RFP capabilities.
• Implementation-aware instrumentation recommendation (Vercel Web Analytics) acknowledges existing infrastructure rather than proposing a buildout.
• Tranche calendar dates are concrete (June 8 / June 24 / July 3) — makes the pricing agreement easy to write.

Items to confirm before signing

• Forum-thread monthly update commitment.
• Public progress surface (board / milestone / Notion page).

---

Submission 2 — Zera & Fateme Rahmani

READY FOR REVIEW

A two-person team — protocol engineer + crypto UI/UX designer — proposing a $8,000, one-month engagement covering competitive teardown (Coinbase / Binance / Kraken primary; Lido / Rocket Pool / Cosmos-Keplr secondary), standardised baseline scenarios A and B with a $100→staked LPT benchmark, gap spec, design brief with Figma wireframes, documentation/content recommendations, instrumentation plan tied to specific Explorer components, and a 10–15-item prioritised backlog. Tranches split 25% / 50% / 25% ($2,000 / $4,000 / $2,000).

Rubric check

Process compliance

• Responds to this RFP; in scope. One borderline item: an “SEO and content-discovery strength for LPT staking queries” comparison dimension touches the RFP’s out-of-scope outreach/conversion item — the proposal addresses this directly by stating SEO is “treated as part of the delegation onboarding journey, not as a standalone SEO project.” Acceptable as scoped; worth a check at signing.
• Proposes the how without re-specifying the what.

Pricing agreement readiness

• Scope clearly bounded; seven enumerated deliverables.
• Each deliverable has output items usable as a definition of done.
• 25% / 50% / 25% explicit, with each tranche’s release criteria stated.
• Budget $8,000 — within ceiling ($2k under).

Execution standards

• Demonstrated capability: Fateme is a blockchain protocol engineer with 5+ years experience, designed the staking/reward mechanics for ErgoProfitSharing, designed the Rosen Bridge smart contracts across six chains (~$10M+ secured). Zera ran a full competitive UX teardown for the fintech product ThisCard and led the ErgoRaffle v2 redesign (where they previously collaborated with Fateme).
• N/A — code-review / merge gate doesn’t apply.
• Documentation/content recommendations is an explicit deliverable category (token page, FAQ, tooltips, risk/reward explanations).
• No explicit commitment to post monthly progress updates in this forum thread — should be confirmed at signing.
• No explicit commitment to a GitHub milestone board / public progress surface — should be confirmed at signing.

Quality bar

• Substantive, specific. Includes a “Preliminary Product Observations to Validate” section showing they’ve already opened Explorer and noticed concrete UX issues (token page doesn’t explain orchestrators or reward sources; primary “Delegate” action is hidden behind a three-dot menu; orchestrator table information hierarchy isn’t clear). They explicitly mark these as observations to validate, not findings.
• Deepest single signal of codebase-level engagement in either submission: the instrumentation plan identifies that Explorer currently ships react-ga against a Universal Analytics property that “no longer processes data,” distinguishes on-chain outcomes (already available via the existing Livepeer subgraph through Apollo Client) from browser-side funnel events that can’t be captured on-chain, and names specific components (DelegatingWidget, orchestrator table sort/filter, three-dot menu). Proposes a single-PR change with no backend, no database, no new infrastructure.
• Includes four user groups (passive exchange holders, new users, yield-focused holders, crypto-native delegators).
• Explicit “What This Proposal Is Not” section — clear scope boundary.
• COI: none declared.

Notable strengths

• Codebase diagnosis already done in the proposal itself (react-ga obsolescence, Apollo subgraph integration, named components) is the strongest single signal of Explorer familiarity in either submission.
• Preliminary product observations show direct pre-engagement with the product before proposing.
• Lower budget — $8k vs the $10k envelope — leaves room for related follow-on within the same RFP cycle if useful.
• Documentation/content recommendations called out as a first-class deliverable, which is a real gap the RFP’s “design brief” deliverable doesn’t fully cover on its own.
• Explicit out-of-scope statement reduces scope-creep risk.

Items to confirm before signing

• Forum-thread monthly update commitment.
• Public progress surface (board / milestone / Notion page).
• The week-by-week timeline doesn’t anchor to calendar dates — confirm start/end at signing.
• Confirm the SEO/content-discovery dimension stays bounded inside the onboarding journey scope per their own framing.

---

Side-by-side at a glance

Criterion	RaidGuild	Rahmani team
Responds to correct RFP
Proposes how not what
Scope bounded
Definition-of-done specificity
Tranche structure explicit	25/50/25	25/50/25
Budget within ceiling	$10,000 (at cap)	$8,000 (under cap)
Demonstrated capability	Strong (incl. prior Explorer PR #457)	Strong (incl. codebase-level proposal)
Documentation commitment	Implicit (docs are the delivery)	Explicit deliverable category
Monthly forum update commitment	Missing	Missing
Public progress surface	Missing	Missing
Substantive & specific
Network/problem understanding	Strong	Strong
COI disclosure	Stated (prior Livepeer RFP)	None declared

Both proposals clear the screening bar. Both have the same two minor gaps (monthly forum updates and a public progress surface), which can be resolved at the pricing-agreement stage rather than blocking either application.

The differentiation between them is about emphasis, not pass/fail:

• RaidGuild brings direct prior Explorer codebase contribution (PR #457), a larger organisation behind the work, more concrete calendar dates, and a slightly broader scenario design (A/B/C with C1/C2 split).
• Rahmani team brings deeper codebase-level diagnosis already in the proposal (react-ga, Apollo, named components), preliminary product observations from prior Explorer engagement, an explicit documentation-and-content deliverable category, and a lower price point.

Recommended Review Team next steps

1. Both proposals → READY FOR REVIEW. Move to Review Team scoring against the RFP’s selection criteria (quality and specificity of competitive analysis approach; design-readiness; practical instrumentation; speed and clarity of execution).
2. Regardless of selection, resolve at pricing-agreement signing: monthly forum updates in this thread, and the public progress surface (board / milestone / Notion page).
3. The author of this pre-screen is recused — selection sits with the Review Team.

---

Pre-screen produced via the Skill: Review RFP Application against How The RFP Process Works. Source forum data fetched 2026-05-26.

[Mehrdad]

Decision

After reviewing the submissions to the Delegator UX Analysis (Self-Custody vs. Custodial Staking) RFP, the Review Team has decided to award the work to RaidGuild.

Thank you to both submitting teams for the time and care put into the proposals. Each helped clarify what will be important for this work to succeed.

Rational

RaidGuild was selected because their proposal was the strongest overall fit against the RFP criteria: delivery confidence, familiarity with the Livepeer Explorer, implementation-aware framing, clear tranche structure, and a practical path toward follow-on work. Their prior Explorer experience reduces onboarding risk, and their proposal showed a useful distinction between Explorer-controllable friction, protocol-level friction, and broader ecosystem constraints.

The Review Team also saw strengths in the Rahmani team’s proposal, especially their preliminary Explorer observations, user-group framing, documentation/content recommendations, instrumentation thinking, and example design work. We appreciate their submission and would welcome their continued participation in the Livepeer ecosystem, including future RFPs or contribution opportunities where their skills may be a strong fit.

Scope alignment before signing

The award is subject to final scope alignment before signing. The RFP already defines the required comparison areas: major exchange staking experiences, decentralized staking/delegation products, and the current Explorer delegation journey. RaidGuild’s Tranche 1 audit phase should be used to confirm and sharpen the benchmark set, comparison depth, scenarios, and access assumptions before the main teardown and design work begins.

As part of that alignment, the Review Team would like RaidGuild to explicitly address user-group segmentation, evidence standards for recommendations, and practical funnel instrumentation showing where users start and where they fall off. They should also consider whether additional benchmarks such as The Graph, deeper Keplr/Cosmos monitoring and exit comparisons, or non-US Binance access would improve the analysis. The work should also identify KYC, regional availability, ecosystem-level, and protocol-level frictions, and explain how each limits the delegator experience.

The design brief should focus on the minimum adjustments needed to create a lower-friction LPT staking experience through Explorer, rather than a broad redesign exercise. Where workflow changes are proposed, the Review Team would like to see lightweight reaction testing or walkthroughs, such as asking users where they would click next, to validate whether the proposed changes actually reduce confusion. Deliverables should be maintained in a Foundation-accessible workspace, such as Notion, so the Review Team can track progress and comment as the work develops.

We believe this gives Livepeer the best available path to an evidence-backed handoff for future Explorer improvements, follow-on RFPs, and broader work around delegator participation.

Honorarium

In addition, the Review Team intends to explore — subject to the Foundation’s normal approval process — a $500 USD-equivalent honorarium in LPT for the Rahmani team. This is a one-off exception and not standard practice: non-selected submissions should not expect funding, and this is not a precedent for future RFPs.

Their proposal created standalone value during review by sharpening scope, particularly around concrete Explorer/UI tweaks (e.g., clearer primary actions and decision hierarchy), the pre-Explorer discovery path (how users encounter exchange/token pages before Livepeer-owned onboarding), the four user groups they outlined, and the preliminary product observations they surfaced (token page onboarding clarity, orchestrator selection complexity, and hidden CTAs). Reviewers found these inputs substantive and actionable; the honorarium is solely a retroactive acknowledgement of that impact, and it does not change the award decision or create any obligation for future work or future non-selected RFPs.

Next steps

• Kickoff with RaidGuild next week.
• Process honorarium
• Progress updates posted on this thread by RaidGuild.

Questions on this decision or the next phase — drop them below.

— Mehrdad, on behalf of the Network Engineering SPE