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-gaagainst 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
- 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). - Regardless of selection, resolve at pricing-agreement signing: monthly forum updates in this thread, and the public progress surface (board / milestone / Notion page).
- 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.