SPP3: Submission Timeline and Artifacts

SPP3: Submission Artifacts and Timeline

The SPP3 program and committee were ratified by Snapshot on May 10. The committee is now seated. This post publishes the pre-submission artifacts required before the provider window opens and confirms the binding program timeline.

Required information satisified by this post:

  • Full process timeline with dates
  • Application format and required fields
  • Evaluation rubric
  • Program Terms and Award Notice (previously, “Service Agreement”)

Timeline

Step Dates Notes
Artifacts published (this post) May 14 Rubric, application format, timeline, Program Terms and Award Notice
Provider submissions open May 19 14-day window
Provider submissions close June 2
Committee review June 2 to June 16 14-day review; interviews conducted concurrently
Recommendation posted to forum June 16 to June 19 Public rationale published alongside cohort
On-chain ratification vote June 22 to July 1 7-day vote + 2-day timelock

The committee may extend the submission or review windows if more time is needed for a complete evaluation. Any extension will be announced publicly before the original deadline passes.

Program Eligibility

Before scoring, the committee applies a hard eligibility screen. Applications that do not pass are not reviewed further.

  • Requested amount must be >$200,000
  • Primary deliverable must be a service to ENS (projects whose primary value accrues outside ENS are not eligible)
  • Work must map to one of the four objective categories: ENS Infrastructure, Outreach and Integrations, DAO Infrastructure, or General Ecosystem Benefit
  • Applications claiming Category 4 (General Ecosystem Benefit) must include a written justification for why the work does not fit the first three categories and a concrete theory of value with measurable outcomes
  • No active conflict of interest

Application Format

Submissions will be accepted via the application form. [Link here on May 19]

The form consists of two parts:

1.Text Fields or Selectors for the applicant to fill in or select. This collects administrative information.

  • Team / Organization Name
  • Primary Contact
  • ENS for Payment Address
  • Email
  • Telegram
  • Team Status
    • New
    • SPP1/2 returning
    • Prior ENS work or grantee
  • Requested Amount (USD Value)
  • Category (one of the below)
    • Infrastructure
    • Outreach and Integrations
    • DAO Infrastructure
    • General ENS Ecosystem
  • Attestation that applicant has read the Program Terms and Award Notice (see: Program Terms)

2. Application Document. The form accepts raw markdown for those familiar with styling for the forum. A URL to a document, PDF, markdown file, or Notion page is also acceptable. This is the main body of the application and takes the place of last year’s forum submission.

Application Minimums

Team identity (captured in fixed fields)

  • Team or organization name
  • ENS handle(s) for primary contacts
  • Contact email
  • Links to prior work, GitHub, deployed contracts, or other public evidence

Ecosystem objective (captured in fixed fields)

  • Which category or categories does this work map to (ENS Infrastructure / Outreach and Integrations / DAO Infrastructure / General Ecosystem Benefit)?
  • If claiming Category 4, provide justification

Scope (included in submitted document or markdown)

  • What problem is this work solving?
  • What is the approach?
  • What does success look like at the end of the cycle? Define it in terms the committee can verify independently.

Milestones (included in submitted document or markdown)

  • List each milestone with: deliverable, verification method, and expected date
  • Milestones should be output-defined, not activity-defined
  • At minimum, quarterly checkpoints are identified

Prior delivery record (included in submitted document or markdown)

  • Prior ENS grants: list each, link to the proposal, and describe what was delivered versus committed
  • Prior work from other ecosystems or grant programs: same format
  • Links to public evidence (GitHub repos, deployed contracts, live products, forum reports)

Budget (included in submitted document or markdown)

  • Total requested amount (minimum $200,000)
  • Breakdown by line item
  • Brief justification for each major cost

Application Follow-up

The committee will schedule calls with qualified applicants. Applicants will be required to monitor their telegram and e-mails for outreach from the committee for scheduling.

A call is not required to be evaluated, but it is encouraged to allow:

  • the opportunity for the committee to ask clarifying questions synchronously; and,
  • the applicant to highlight any items in their proposal.

This step will be the most likely area for bottleneck in the application review process. The committee will attend with at least two members (inclusive of the chair), and record a transcript to to share with members who could not attend.

A public call will be held after the submission window opens where applicants can ask questions related to the application procedure or program details. The date and time for this call will be updated here once finalized.

Evaluation Rubric

Applications that pass the eligibility screen are scored by the committee on four criteria. Scores run from 1 to 5 in 0.5 increments. Weighted scores sum to a final out of 5.0. Committee members rank individually and a composite score is computed across the four members.

This rubric is an evaluation tool, not a selection formula. Final cohort composition will account for budget constraints, provider overlap, and strategic gaps across the cohort as a whole.


Criterion Weight
C1: Prior Delivery History 25%
C2: Scope Clarity 15%
C3: Milestone Structure 15%
C4: Adoption, Revenue, and Ecosystem Utility 40%
Discretion: Team and Budget Fit 5%

C1: Prior Delivery History: 25%

The committee is evaluating execution credibility, not intent. The central question is whether this team has delivered work of similar scope and technical complexity to what they are now proposing, verifiable through public artifacts: deployed contracts, merged PRs, live products, or documented adoption. For SPP2 returning providers, the SPP2 record is the primary evidence base; what was promised versus what shipped, and whether reporting was maintained on schedule. Late or missing reports weigh negatively, not neutrally. New teams are evaluated on equivalent delivery from other ecosystems or grant programs; no ENS history is not a penalty, but the evidence standard is the same.

Insufficient (1) Weak (2) Adequate (3) Strong (4) Exceptional (5)
What it looks like Prior grants abandoned, unverifiable, or undisclosed where they clearly exist. One or more grants incomplete or significantly descoped without explanation. Limited public evidence. Mixed record but explainable. Delays communicated, scope adjusted with rationale. Most commitments delivered. Minor scope reductions negotiated transparently. Public evidence available. All prior commitments delivered in full. Independently verifiable. Reporting was proactive throughout.

C2: Scope Clarity: 15%

The committee needs to understand what is actually being proposed. A strong proposal names a specific problem, connects a credible approach to it, and defines success in terms the committee can verify at cycle end. Flexibility in execution is expected; vagueness is not.

Budget requests that are materially disproportionate to the described scope (either significantly over or under) weigh negatively. A $200K proposal describing $2M of work signals the team hasn’t costed the effort. A $1M request for narrowly scoped work with no budget breakdown signals padding. The committee will probe both in the interview.

Insufficient (1) Weak (2) Adequate (3) Strong (4) Exceptional (5)
What it looks like No coherent scope. Cannot evaluate what the team intends to do, how, or what success looks like. Problem framing is generic. Approach too abstract to evaluate. Success defined only in activity terms. Work is identifiable but requires interpretation. Approach plausible but underspecified. Success partially verifiable. Problem and approach well-defined. Success has a measurable component. Minor gaps but nothing that blocks evaluation. Problem is specific and well-evidenced. Approach is technically credible and traceable. Success defined in verifiable, outcome-based terms.

C3: Milestone Structure: 15%

Milestones are targets, not gates. Stream continuation is tied to reporting and engagement, not milestone completion. The committee needs checkpoints sufficient for 12-month accountability. Each milestone should answer: what is being delivered, how completion is verified, and when it is expected.

Insufficient (1) Weak (2) Adequate (3) Strong (4) Exceptional (5)
What it looks like No milestones, or milestones that are entirely activity-based with no verifiable output. Deliverables described too loosely to evaluate. Dates missing or implausible. Verification relies entirely on self-report. Some output-defined milestones with partial verification methods. Timeline exists but has gaps. Milestones are mostly output-defined with credible verification methods and specific dates. All milestones output-defined, independently verifiable, sequenced credibly, with a clear picture of what on-track looks like at each check-in.

C4: Adoption, Revenue, and Ecosystem Utility: 40%

The highest-weighted criterion. Registration growth is the program’s first-order outcome. Every application receives explicit evaluation of how it connects to ENS registrations, renewals, and ecosystem utility. The committee also assesses integration breadth, the quality of proposed metrics, and whether this work would happen without SPP3 funding.

Insufficient (1) Weak (2) Adequate (3) Strong (4) Exceptional (5)
What it looks like No credible connection to ENS adoption, revenue, or utility. Metrics absent or purely vanity. Weak or speculative connection to registration/revenue impact. Metrics are activity-based only. Plausible indirect connection to ENS utility. Some adoption metrics proposed, but attribution is uncertain. Evident connection to ENS adoption or revenue. Named integrations or quantified outcomes. Metrics are specific and attributable. Direct and well-evidenced connection to ENS registration or revenue growth. Metrics are outcome-based, attributable, and independently verifiable. Strong counterfactual case for why SPP3 funding matters.

Discretion: Team and Budget Fit: 5%

Applied after individual scoring. This is a cohort-shaping factor, not a standalone criterion. The committee uses it to account for team capacity relative to requested scope, budget efficiency, duplication across funded teams, and strategic gaps in the cohort as a whole.


Program Terms

The ENS DAO Service Provider Program Terms (Version 1.0, 14 May 2026) governs all funded providers. By submitting an application, applicants will acknowledge they have read the Program Terms and agree to be bound by them if selected. The Program Terms are not subject to negotiation or modification following submission.

The Award Notice, a short recipient-specific document covering identity, project scope, fees, and term will be issued by the ENS Foundation to each selected provider before funding begins.

The application form includes a mandatory acknowledgement block that applicants must affirm before submitting. Providers will need to agree to both the Program Terms and Award Notice to be eligible.

Budget

The SPP3 budget cap is approximately $3.4M as ratified in [6.42] [Social] SPP3: Program Authorization and Committee Model. After committee compensation ($150,000), approximately $3.25M is available for service provider funding. All funded providers are paid via stream from the accountability body’s multisig. Unspent funds return to the DAO treasury at cycle close. Committee can not expand this budget. Committee is not required to exhaust all of the available funding in the cohort reccomendation.

Questions

Questions about the process or application format can be posted in this thread. The committee will not discuss SPP3 with applicants outside of the structured interview process or publicly held calls once the submission window opens.

Next Steps for Providers

The two-week application window opens on May 19th. You can use the information in this post to begin pre-work on applications.

10 Likes

Thanks for posting, @Coltron.eth,

Committee-side conflict of interest came up in the temperature check thread but didn’t make it into this document, and I think it’s worth a short note before applications open. With a five-person committee, the relationships individual members do or don’t have with applicants will weigh heavily on outcomes.

A couple of sentences on how members will determine and disclose conflicts, and how recusals will be handled, would help set expectations before submissions come in.

3 Likes

Thanks for the detailed write-up, the rubric and timeline are much clearer than prior cycles.

we’d like to raise one concern around budget structure: the post sets a hard floor ($200K minimum) but no ceiling or indicative range per applicant. With ~$3.25M available, the math implies a cohort of anywhere from 2 to 16 providers. That’s a very wide band, and in practice it creates a few issues:

  • Anchoring risk: without published guidance, applicants have an incentive to ask for more than they need, since there’s no signal about what the committee considers “proportionate.”

  • Crowd-out: a small number of large requests could consume the majority of the pool before smaller, high-utility work is even evaluated and the committee may face implicit pressure to fund them simply because they passed eligibility.

  • Calibration gap for new teams: SPP1/2 returning providers have historical reference points, new applicants don’t, and the $200K floor is the only number they have to work with.

Could the committee consider publishing a soft cap or tiered guidance, A few options that wouldn’t constrain committee discretion:

  1. A percentage cap (e.g. no single provider should exceed ~15–20% of the pool absent exceptional justification).

  2. Tiered bands with corresponding evidence expectations, e.g. $200–400K standard, $400–700K requires named integrations / quantified revenue case, $700K+ requires exceptional prior delivery and counterfactual.

  3. Simply publish the distribution of SPP2 awards as an indicative reference, with a note that SPP3 is not bound by it.

Any of these would help applicants self-calibrate, reduce wasted committee review time on misaligned asks, and give the committee a cleaner basis for pushing back on inflated budgets in interviews, which Section C2 already flags as a scoring concern.

Happy to discuss further if useful.

Is this not one of the crux benefits of this structure? Namely the flexibility that the committee has to discern what the greatest total value add will be across options.

If one provider asks for a particularly large amount ($1M+) they would logically be under serious scrutiny during the research/interview stages of the process. If the committee believes another entity can do the same work for less or that the total summated value add of having 5 teams funded at $200k is greater then logically the $1M request would be rejected.

It also makes sense that whilst the committee has flexibility to offer providers less than what they have requested, if a proposal requests a completely unreasonable amount then in my opinion it should be thrown out in its entirety. This structure would - in my opinion - be a complete failure if teams that do not add value in excess of their cost still got funded..

1 Like

Many thanks @Coltron.eth for preparing this nicely structured process.

A few questions:

  1. For the four objective categories, can we change that from “select one” to “select all that apply”? Even under SPP2 we already have large projects spanning “ENS Infrastructure” (ENSNode), “Outreach and Integrations” (the ENS Referral Program and ENSAwards), and “DAO Infrastructure” (ENSAnalytics, which provides new levels of detailed analytics for data-driven decision making about DAO revenue streams – we’ve already been building ENSAnalytics as part of the ENS Referral Program and ENSAwards as it’s a foundation of the work there to calculate real-time referral leaderboards and live feeds).

  2. [6.42] [Social] SPP3: Program Authorization and Committee Model describes that the SPP3 submission window and committee context-building will occur concurrently over the next ~14 days.

    While providers are preparing and submitting applications, the committee is building shared context on the current ecosystem, existing integrations, and ongoing work.

    Can more details please be shared on how the committee will execute this ENS context-building over the next ~14 days? The no backchanneling rule is well noted and supported. At the same time, this rule is exclusive to SPP3 while the context-building would be exclusive to work already completed under SPP2. I’m concerned at the difficulty the committee will face building the needed accuracy and depth of context on work already completed in SPP2. How can we and others support this committee context building process?

  3. Conflicts of Interest: I note how the current COI rules are constrained only to the very narrow case of COI relationships where a committee member worked for or received compensation from a SPP3 applicant. But this leaves open other key COI gaps such as: a SPP3 applicant having other forms of relationships with committee members. Such as being former colleagues, business partners, or otherwise friendships or other connecting relationships. What rules will be enforced to fill the key COI gaps and protect the integrity of this process? Suggest that COI rules are added that include each committee member proactively disclosing in writing any form of relationship they might have with any applicant being reviewed and to abstain from any vote where that relationship might form a perceived COI. I note how @5pence.eth also flagged COI concerns above in this thread as well.

Additionally appreciate that the Service Agreements have been proactively published for SPP3 . We’ll review these soon but understand these should be very similar to SPP2. For now assuming no special surprises will be found here upon review.

1 Like

Members may not be applicants, employed by, contracted to, or have received compensation from an applicant in the 3 months prior to nomination. Any new conflict must be self-disclosed immediately; breach triggers automatic suspension.

Below that threshold, if a relationship with a provider is material enough to affect objectivity, the member discloses to the chair, abstains from that applicant’s evaluation.

The committee will push back on askew budgets in interviews; that’s baked into the evaluation criteria. Publishing caps or tiers creates its own problem: last cycle, funding options turned into a pricing game where providers (imo) optimized for inclusion.

As written in the passing proposal, the budget and the $200K floor are the only guardrails. Teams should request fair compensation for the work. That’s the standard.

Yes.

I think this is a fair request. I will see about multi-field selection. If not possible I don’t see this negatively effecting a submission because a provider can select “General ENS Ecosystem” if they don’t fit a single category.

Scope Clarity is a criteria. It will be on the provider to precisely communicate and connect a multi-objective application with specific problems and a credible approach to them.

Update all of your public information and schedule a call promptly after submitting so we can provide feedback and ask questions about your work.

The burden is on the applicant to effectively and accurately communicate the depth and value propositon of their work. A good application will do this.

There is already public documentation on previous provider work. Your reports for example detail lot. There are call notes, githubs, websites, tweets, etc. This is all for context building. The committee will have access to a consolidated list of all of this information.

You can’t be credibly involved in ENS or Ethereum and not know other people. The committee was selected because it presents a balanced group without the pollution of delegate politics, and without outsourcing evaluation to someone with no context on the work.

Prohibited interests: Members may not be applicants, employed by, contracted to, hold stake in, or serve in any advisory capacity to any SPP3 applicant. Direct compensation from an applicant in the 3 months prior to nomination also disqualifies.

After ratification: Any new conflict must be self-disclosed immediately as it arises. Failing to disclose is independently grounds for removal.

Enforcement: Breach triggers automatic suspension pending a removal vote. Removal = forfeiture of all unpaid compensation.

No backchanneling: Once the application window opens, members cannot meet privately with applicants. All program discussion goes through the structured interview.

Disputes: Handled within the committee; defaults to delegate coordination or an executable DAO vote if the accountability body isn’t functioning.

The standard is simple: does a member stand to benefit financially or professionally from how they rate a provider? The rules covering that are in the proposal and restated above.

3 Likes

Thanks @Coltron.eth that sounds good.

For the potential COI concerns that were raised, agreed with what you wrote in “Definition 1”:

While here in “Definition 2” is a different idea that leaves too much open to COI:

In other words, let’s say a committee member is a friend of a provider. Maybe they regularly meet up at social events (ex: non-ENS social events together, walks on the beach, etc.) Such relationships are material enough to affect objectivity even if they do not have a direct financial benefit. My goal is to strengthen the COI policy in a pragmatic and reasonable way in line with your “Definition 1”.

Hi, @Coltron.eth ,

Quick question RE: privacy and intellectual property rights, particularly for rejected (by committee).

When exactly are full copies of applications taken (if ever), and when are they revealed to the public, if ever?

I understand that applicants must submit using public hosting in order for the committee to evaluate, however, if for instance we submit using public, obscured, and transient techniques, it’s theoretically possible that rejected applications and their intellectual property could stay private.

It seems fair to preserve the privacy of rejected applications.

But maybe something in the process forces this in a different direction.

edit: fixed a word

When the proposal for cohort selection is posted, we will share an expanded summary of the application and a link to the full application for delegate review. Before doing so, we will give selected applicants time to review and redact that sort of information.

Any disqualified or rejected application will be treated similarly: we will get confirmation before sharing the full application.

Let me know if that helps!