[Temp Check] SPP3: Marketplace RFP

Summary

  • SPP3 concluded with five selections. The provider selected for the marketplace and revenue vertical declined its award, leaving that vertical unfilled and $1,560,284 of the authorized budget uncommitted.
  • Rather than renegotiate privately outside the published process, the committee requests to run an open, scoped RFP for a live, revenue-generating ENS marketplace, funded from the budget the DAO already authorized for SPP3.
  • The cohort proposal is standalone and it ratifies the four remaining providers.
  • One award of up to $500,000 from the remainder, milestone-gated: roughly half streamed through go-live, half released against traction gates verifiable on-chain. The balance returns to the DAO treasury, the cohort is not delayed, and no new money is requested.
  • If approved, the RFP opens the week of July 20. Award announcements targeted for end of August.

Background

SPP3 concluded with five selections against ~$3.25M in available funding. Following the committee’s recommendation, the provider selected for the marketplace and revenue vertical declined its award. That leaves the vertical unfilled and $1,560,284 of the SPP3 allocation uncommitted.

The committee could have returned to exisiting and prior applicants and renegotiated scope privately. The committee judged that operating outside those bounds would not be in the program’s interest, and as noted in the previous proposal, SPP3 drew many applications from qualified teams. SPP3 ran under an established process everyone agreed to: one published rubric, one deadline. We felt that operating outside those bounds would not be in the program’s interest, and as we noted in our previous proposal, SPP3 drew many applications from qualified teams.

An open, tightly scoped RFP invites those teams, and others inside and outside the ecosystem, to propose for this critical function. The committee will use the same approved funds and the same accountability structure, run through a scoped competition that any team may enter, including prior SPP applicants.

This RFP does not delay the current cohort. The cohort proposal is standalone and it ratifies the four remaining providers.

This proposal is a one-time amendment to the SPP3 authorization, made in response to the declined marketplace and revenue award. It extends the committee’s mandate to run this RFP, ratifies a marketplace-specific rubric, authorizes a milestone-gated payment structure for this award, and re-deploys a portion of the declined allocation. It does not expand the SPP3 budget, reopen the full cohort process, or create a general-purpose grants pool.

RFP Scope

A live, revenue-generating ENS marketplace, operated as an ongoing service. This RFP is not for research, satellite products, or growth services detached from a marketplace.

Proposals should address the scope areas below. Core marketplace functionality, renewals, user-safe custody, and a credible go-live plan are the baseline expectations; depth across the remaining areas will strengthen a proposal under the published rubric.

  1. Core trading. Discovery, listings, offers, and purchases of ENS names, plus new registrations, live as one operated marketplace rather than a research, analytics, or growth product. Proposals should show the full transaction path, fee model, custody assumptions, and launch plan.
  2. Renewals and portfolio management as first-class features. Single-name and bulk renewal flows must sit alongside trading, with portfolio views that surface expirations, renewal urgency, ownership state, and transaction history. Renewal and registration activity should support on-chain referral attribution so impact can be measured from protocol events rather than self-reported dashboards.
  3. Unified listings and ENS-specific search. The marketplace should aggregate active ENS listings from external venues without depending on any single external venue, so buyers can search the market from one interface. Search must cover ENS-native needs: expiration dates, lapsed-name availability, category and club browsing, batch search, and filters that help buyers understand name status before acting.
  4. Continuity by construction. Applicants must provide an open-source or source-escrowed core, non-custodial contracts with user withdrawal rights, exportable listing and order data, and a funded wind-down plan as first-milestone deliverables. The goal is to make service failure survivable: users retain assets, the DAO retains usable data, and the market can migrate without losing liquidity history.
  5. ENSv2 readiness. Proposals must commit to the ENSv2 contract surface, migration UX, and the expected shift toward lower-cost, more flexible name management. Subname listing, renting, and hierarchical ownership flows are in scope, with applicants expected to explain what can ship now and what changes when ENSv2 migration paths are finalized.

Fiat onramps, mobile apps, and adjacent tooling are welcome differentiators, evaluated as extras rather than requirements.

Award structure

  • One award only. The RFP is intended to select a single marketplace provider. Funding multiple teams for the same vertical would deviate from the committee’s intention and risk duplicative spend or dilute accountability.
  • Up to $500,000 total from the $1,560,284 remaining in the SPP3 allocation. This is a ceiling, not a target. Cost will be scored against credible outcomes. Any amount not awarded remains in or returns to the DAO treasury.
  • Eleven-month term, set to co-terminate with the existing SPP3 cohort streams, paid by stream and gated by milestones under a structure specific to this RFP. For reporting and oversight, the selected marketplace provider is otherwise rolled into the SPP3 program.
  • No renewal expectation, no quota. This is bootstrap funding to build, launch, and reach self-sufficiency, not a recurring seat. If no proposal clears the published rubric’s bar, nothing is funded and the remainder returns to the DAO treasury.

Eligibility and evaluation

This RFP is open to any team, including prior SPP3 applicants, existing marketplace operators, new entrants, and teams formed specifically for this opportunity. Prior SPP3 participation is neither required nor disqualifying; all proposals are evaluated through the same published rubric.

To be eligible, a proposal must describe a live or launchable ENS marketplace operated as an ongoing service. Proposals centered on research, analytics, marketing, growth services, or adjacent tooling may be useful to ENS, but they are outside this RFP.

For teams with existing products, demonstrated marketplace impact reduces execution risk, but it is not sufficient on its own. The award is forward-looking: proposals must show what the team will build, improve, operate, and measure during the award term, and why the team is likely to execute that plan.

The committee will evaluate proposals against a marketplace-specific rubric adapted from SPP3’s C1-C4 criteria and ratified by this amendment. Final weights are published in that rubric when the submission window opens, weighted toward:

  1. Prior delivery and demonstrated impact. Evidence that the team has shipped and operated a marketplace, protocol-facing product, or directly comparable service. Existing usage, real transactions, reliability, and prior ENS contributions reduce execution risk, but scoring also depends on how clearly the team connects that track record to a credible forward plan.
  2. Marketplace scope and milestone credibility. How well the proposal addresses the RFP scope, what is live today, what remains to be built, and whether the proposed milestones are concrete, dated, and verifiable.
  3. Revenue and adoption plan. How the marketplace will drive ENS registrations, renewals, secondary sales, and repeat usage, with measurement tied to on-chain activity where possible.
  4. User safety and continuity. Whether users retain control of assets, whether listing and order data can survive operator failure, and whether the proposal includes a credible wind-down or transition path.
  5. ENS alignment and future readiness. How well the proposal supports ENS-specific workflows today and prepares for ENSv2, including migration UX, subnames, renting, and lower-cost name management.
  6. Self-sustainability. Whether the marketplace can operate after the award period through a credible revenue model, cost structure, and distribution plan.

Each proposal must address each dimension above, but does not need to be strongest on every dimension to win.

The committee may select a proposal that has clear tradeoffs if it is credible, launchable, measurable, and likely to produce meaningful ENS marketplace activity. Conversely, the committee may fund none if no proposal clears the published quality bar.

Selection will be made by the SPP3 committee under this published process, under standard SPP3 recusal and quorum rules (three of four Member seats). If recusals threaten quorum, the Chair will disclose and notify the DAO. The winning score is published after the award is announced.

Milestones and payment

Awards are primarily paid through milestone-gated streams and releases. Applicants must submit a milestone plan with target-dated deliverables, requested payment allocation, verification method, and dependencies. Final milestones, payment amounts, and traction thresholds are set at award signing through the SPP3 service agreement and ENS Foundation Terms of Use, with payment initiated by the accountability body.

  • Build milestones. The build portion funds launch readiness: core marketplace functionality, registration and renewal flows, custody and withdrawal safeguards, continuity deliverables, and any proposal-specific features accepted into scope. Applicants should propose a small number of concrete milestones, each with objective acceptance criteria. Go-live is a required milestone; if the marketplace is not live by the agreed date, the stream pauses until the issue is resolved or the committee approves a revised plan.
  • Traction milestones. The traction portion is reserved for measurable market outcomes after go-live. Applicants must propose the outcomes they expect to drive, explain why those outcomes are credible for their model, and identify how each will be verified. The committee may adjust thresholds based on baseline data, proposal maturity, award size, and whether the applicant is launching a new build or scaling an existing product.

Traction gates may include some combination of:

  1. Attributed protocol revenue. Registrations and renewals attributable to the platform, measured on-chain where possible.
  2. Active paying users. Distinct wallets completing value-transferring actions through the platform over a defined period.
  3. Secondary-market activity. Completed ENS sales after anti-wash filters and minimum-value rules.
  4. Retention or repeat usage. Returning users, repeat renewals, portfolio actions, or other evidence that the marketplace is becoming an ongoing service rather than a one-time launch.

Final thresholds are set per award against fresh baseline data at signing. Applicants may counter-propose metrics and thresholds with justification, but all accepted traction gates must be independently verifiable and tied to real marketplace usage. Where DAO referral rails are not available at go-live, accepted gates may use the platform’s settlement contracts, registrar events, or other independently verifiable on-chain evidence. Amounts not released by the end of the award term return to the DAO treasury, consistent with SPP3’s treatment of unspent funds. Specific stream and release mechanics, including signer and administrator setup, will be finalized before awards execute.

Timeline (aggressive by design)

  • RFP opens once the DAO authorizes this amendment via Social proposal. Targeting the week of July 20
  • Two-week submission window
  • Two-week evaluation, interviews as needed
  • Awards announced end of August
  • Go-live milestone set per proposal. Teams with a product live today can date go-live within days of award; new builds are expected in weeks, not months.
  • Selected award executed and stream initiated by the accountability body, per SPP3 mechanics

The compressed schedule is deliberate: the vertical is unserved today, and every month it stays unserved costs the protocol revenue.

Conclusion

This RFP gives the marketplace vertical a clean path forward without reopening SPP3 or requesting new funds. The goal is to select a credible team that can launch or strengthen a live ENS marketplace, prove real usage through milestones, and leave ENS with infrastructure that can sustain itself beyond the award term.


(Credit to @Sov @abdullahumar.eth @gregskril, and Austin for quick turnaround on this draft. The typos are all mine.)

11 Likes

Great job putting this together so quickly, it looks very comprehensive.

I apologize in advance if I missed something (and I hope my questions don’t come across as pointed or accusatory!). I am just trying to understand how this narrow-scoped RFP fits into the larger strategy of increasing registrations and renewals.

Based on my understanding, SPP3 set out a goal to focus on adoption and revenue. EthID was chosen as one key component in fulfilling this goal, and they do so by operating a marketplace. They then withdrew from SPP3 consideration, and so we are looking to replace them with another project.

That all sounds fine, but what I’m curious about is how it was decided that the replacement should also be a marketplace, with a focus on trading. I know the SPP3 cohort was meant to cover a range of categories; was “marketplace” a specific category that was deemed essential to cover? What evidence do we have to suggest that this is the type of product the ecosystem needs (versus a different type of product that also encourages new registrations)?

I’m not trying to imply this is the wrong direction, I’m just trying to get a better picture of how we got here. :folded_hands:

2 Likes