# RFP — Delegator UX Analysis (Self-Custody vs. Custodial Staking) **URL:** \ **Category:** RFP Applications\ **Created:** [May 18, 2026, 4:55pm UTC](https://forum.livepeer.org/t/rfp-delegator-ux-analysis-self-custody-vs-custodial-staking/3254 "2026-05-18T16:55:59Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![Mehrdad](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.livepeer.org/mehrdad/32/1800_2.png) [@Mehrdad](https://forum.livepeer.org/u/Mehrdad)\ **Post date:** [May 26, 2026, 8:21pm UTC](https://forum.livepeer.org/t/rfp-delegator-ux-analysis-self-custody-vs-custodial-staking/3254/5 "2026-05-26T20:21:30Z")
# 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](https://www.notion.so/64e82cb9d41c481397069be79d900318) — 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](https://drive.google.com/file/d/1XYSwnUrdx2-6xePGlMz5v-8hdehWpdtF/view?usp=sharing) | | 2 | Zera Rahmani & Fateme Rahmani | $8,000 | 2026-05-25 09:47 | [Proposal](https://drive.google.com/file/d/1FzB15ylRKZ6_K-V7c-K72CNhnuh9LWIy/view?usp=sharing) | ## 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](http://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)](https://github.com/livepeer/explorer/pull/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](https://www.notion.so/9fc86af1a75d4294be6d773d4d54807b) against [How The RFP Process Works](https://www.notion.so/64e82cb9d41c481397069be79d900318). Source forum data fetched 2026-05-26._ --- _[View the full topic](https://forum.livepeer.org/t/rfp-delegator-ux-analysis-self-custody-vs-custodial-staking/3254)._