[Temp Sheck] SPP3: Program Authorization and Committee Model

Abstract

The Service Provider Program funds teams that provide defined services to the ENS ecosystem. This proposal authorizes a third season, specifies the objectives SPP3 should advance, names the committee that will execute it, and caps the budget at 20% of trailing protocol revenue.

The program parameters and budget are ratified in a single Snapshot vote alongside the named committee; the committee then returns to the DAO with a final cohort recommendation ratified via on-chain executable.

SPP3 requires two votes from delegates:

  1. The first approves the program, budget, and committee;
  2. the second ratifies the cohort.

This removes the burden on delegates of rating and ranking every service provider themselves, a structural problem SPP2 exposed.

The committee reports to the DAO directly through standard governance channels. Nothing in this proposal depends on any specific governance evolution.

Specification

Part I: Program Authorization

Authorization

SPP3 is authorized as a one-cycle program. Renewal requires a new DAO vote. Nothing in this proposal commits the DAO to future seasons.

The program funds teams that provide a defined service to the ENS ecosystem in exchange for payment. The primary deliverable must be a service to ENS. Projects whose primary value accrues outside the ENS ecosystem are not eligible.

Ecosystem Objectives

SPP3 applicants must map their proposed work to one or more of the following objective categories.

Across all categories, growth in ENS registrations and integrations is a primary outcome the program is desires to advance.

  • ENS Infrastructure. Work that improves ENS as a protocol: smart contract development, frontend and client library improvements, resolver infrastructure, L2 support, and any engineering that increases the utility or reliability of the naming system.
  • Outreach and Integrations. Work that increases adoption and usage of ENS: integration support for wallets, dApps, and exchanges; developer relations; documentation; marketing; and partnership development.
  • DAO Infrastructure. Work that improves the operation of the DAO itself: governance tooling, transparency and accountability tools, voting infrastructure, communication platforms, and process automation.
  • General Ecosystem Benefit. Work that broadly benefits ENS without fitting into the first three categories. Applicants claiming this category must demonstrate why their work does not fit and provide a concrete theory of value, including measurable outcomes. Category 4 is a narrow residual; the committee should prefer placing work into the first three categories where a reasonable mapping exists.

The committee may define subcategories and weights when it publishes the rubric, but may not create new top-level categories. Different objectives in a future cycle require a new Program Authorization vote.

Budget

The SPP3 budget shall not exceed 20% of gross protocol revenue (registrations and renewals).

The 20% formula is applied to trailing 12-month protocol revenue as measured at the time of the original draft (February 2026): approximately $16.9M, producing a binding budget cap of approximately $3.4M for SPP3. The cap is not recomputed at ratification.

For comparison, SPP2 was $4.5M; the decrease reflects a year-over-year decline in protocol revenue, not a policy decision to reduce program funding. Proportionally to last year it remains the same.

Committee compensation totals $150,000 USDC across the three compensated seats (one Chair at $45,000 and three compensated Members at $35,000 each). The ENS Labs Technical Representative seat is non-compensated. After overhead, approximately $3.25M is available for service provider funding. Funds are transferred to the accountability body’s multisig upon cohort ratification and disbursed to providers via stream from there. Unspent funds return to the DAO treasury.

Revenue source: dune.com/steakhouse/ens-steakhouse

Relationship to SPP2

SPP3 is independent of SPP2. SPP2 streams continue on their original terms. SPP3 does not modify, terminate, or extend them. SPP2 providers agreements coming to an end may apply to SPP3 on the same basis as any other applicant.

Part II: Committee Model

Model Justification

Throughout this proposal, “the accountability body” refers to the body the DAO designates as the SPP3 accountability counterparty. At the time of this proposal, that body is the Meta-Governance Working Group.

A standing committee addresses accountability gaps without removing the DAO from the decision. The DAO ratifies the committee in this proposal, approves the cohort recommendation by on-chain vote, and holds removal authority throughout.

The primary improvement over SPP2 is structural. Under SPP2, delegates were asked to rate and rank each provider proposal individually. That placed a heavy evaluation burden on the DAO and produced cohorts shaped more by aggregated voter sorting than by deliberate composition. SPP3 moves that work to a named, accountable committee whose recommendation the DAO ratifies as a single cohort.

SPP2 also surfaced smaller structural questions this model addresses:

  • Program scope wasn’t formally ratified by the DAO ahead of selection
  • Some disagreements landed mid-cycle, after applications had opened
  • The fixed budget wasn’t tied to protocol revenue

Compensation reflects 12 months of accountability: reading every application, conducting interviews, negotiating service agreements, voting on the cohort, defending the recommendation publicly, and remaining the DAO’s contact point for the funded providers across the year.

Roles

Committee Chair. Owns the full lifecycle of SPP3: timeline, interview calendar, forum updates, primary DAO contact for the 12-month term, post-cycle retrospective, and the point of contact for the funded cohort post-ratification. The Chair is a neutral process owner during selection and votes or ranks only as a tiebreaker.

Committee Member. Reads every qualifying submission in full, participates in structured interviews, votes on allocation, and approves the cohort rationale before publication. No Member has unilateral authority to disqualify applicants.

ENS Labs Technical Representative (non-compensated). A Labs-designated voting Member seat (currently gregskril.eth). Brings protocol-level technical judgment. This seat is bound by the same CoI requirements as all other members. Not eligible for promotion to Chair.

Composition

Role Count Compensation
Chair 1 $45,000 / cycle
Member (compensated) 3 $35,000 / cycle
Member (ENS Labs Rep) 1 Non-compensated

Named seats:

Seat Name Profile
Chair coltron.eth Long-standing ENS DAO contributor and steward and current steward.
Member sovsignal.eth Current steward and experienced grants administrator. Cross-ecosystem experience in Gitcoin, ENS, and Uniswap.
Member austingriffith.eth Long-standing Ethereum builder, mentor, and educator. Founder of BuidlGuidl and creator of Scaffold-ETH. Currently working with the Ethereum Foundation.
Member abdullahumar.eth Former co-president and head of governance at Michigan Blockchain. Active across Arbitrum, Lido, and Uniswap DAO’s with a broad context on DAO operations and grants programs.
Member gregskril.eth ENS Labs technical representative providing protocol-level engineering judgment. Non-compensated

The committee is named in this proposal and ratified by the DAO in the same Snapshot vote that authorizes the program. No separate election is held. Naming constitutes tacit acceptance of the role.

Term and Payment

Term aligns with the SPP3 funding cycle (12 months). If continued, Members may not serve more than two consecutive cycles in the same seat without a cycle off.

Compensation: 20% paid upon on-chain submission of the cohort recommendation; 80% streamed over the remainder of the 12-month term, beginning on cohort on-chain ratification. The accountability body initiates the upfront payment and the stream; the committee holds no funds directly. If the accountability body changes during the cycle, responsibility passes to the successor body without interruption.

Dissolution. Each member receives only compensation earned to that point. The 20% upfront tranche is owed if the cohort recommendation has been submitted on-chain. Any portion of the 80% stream that has elapsed is owed; the remainder returns to the treasury.

Vacancies

If a compensated Member seat becomes vacant, it is filled by mutual agreement of the remaining members, subject to eligibility and DAO notification within 7 days. The replacement receives the remaining unpaid compensation of the member they replace. If the ENS Labs Rep seat becomes vacant, ENS Labs designates a replacement.

If the Chair seat becomes vacant, the remaining Members promote one of the three compensated Members to Chair by simple majority. The promoted Chair receives the Chair stream from the date of promotion forward; the outgoing Chair retains anything vested. If the vacancy occurs before or during cohort selection, a replacement Member is also appointed and the published timeline may be extended by up to 14 days. The ENS Labs Rep is not eligible for promotion to Chair.

Quorum and Voting

Voting or ranking of the cohort requires 3 of the 4 Member seats to be active and participating. Decisions require a simple majority of participating Members. The Chair votes only as a tiebreaker.

Conflict of Interest

A ommittee Member or Chair may not:

  • Be a current or pending SPP3 applicant
  • Be employed by, contracted to, hold stake in, or serve in any advisory capacity to any current or pending SPP3 applicant
  • Have received direct compensation from any SPP3 applicant in the 3 months prior to nomination
  • Acquire any of the above interests after ratification

Breach triggers automatic suspension pending a removal vote. Self-disclosure is required at nomination, and any new potential conflict must be disclosed as it arises. Failing to disclose a new conflict after ratification is grounds for removal.

No Backchanneling

Once the application window opens, committee members must not meet privately with applicants to discuss SPP3. All program discussion happens through the structured interview process. Providers who attempt to gain advantage by pressuring individual members may be considered for disqualification.

Removal

A committee member may be removed by unanimous vote of the remaining members with documented cause (persistent non-performance or material CoI breach). Upon removal, any unpaid compensation is forfeited.

Part III: SPP Application Process

The committee sets and publishes the full process timeline before the submission window opens. Window extensions may be considered by the committee if more time is needed for evaluation.

Pre-Submission Work

Before the provider submission window opens, the committee is responsible for preparing the infrastructure that makes the cycle run. This work begins immediately upon committee seating and includes:

  • Developing and publishing the evaluation rubric based on the suggested criteria below
  • Drafting and publishing the standard service agreement template
  • Publishing the application format and required fields
  • Building or configuring the submission system (intake form, confidential storage, interview scheduling)
  • Posting the full process timeline with binding dates
  • Setting up internal scoring and rationale-tracking tools

All pre-submission artifacts (rubric, service agreement template, application format, timeline) will be posted publicly to the forum before the submission window opens.

Cohort Composition

The committee determines the number of funded providers. There is no minimum or maximum; the only binding constraint is that total funding fits within the ratified budget envelope.

The committee has discretion within the following principles:

  • Category coverage: The cohort should advance the program’s objectives across all relevant categories, but the committee is not required to fund every category. If the applicant pool in a given category does not meet the evaluation threshold, the committee may decline to fund it.
  • Award sizing: The committee may negotiate tfund providers at amounts smaller than requested, with rationale, and may negotiate scope or milestone adjustments.

The committee will make best efforts to construct a cohort that fits well as a whole, reducing funding overlaps and avoiding duplicative work across funded teams.

Process

Week 1: Submission window (7 days). Applicants submit privately to the committee. Private submissions protect competitive information, preserve evaluation integrity, and prevent unsolicited outreach. The committee filters spam and erroneous submissions concurrently. Pre-qualification is a basic screen, not a quality judgment.

Week 2: Committee review (7 days). The committee reads every qualifying application in full and conducts a structured interview with each team in a consistent format. Scoring begins on pre-qualified applications before the submission window closes. The committee may negotiate scope, objectives, or award amounts during this period.

Week 3: Recommendation and ratification. The committee submits a cohort recommendation publicly to the DAO. Selected applicants, individual award amounts, total program cost, and a public rationale on the forum. Internal working documents may be shared with the accountability body or the ENS Foundation upon request.

The committee then submits the recommendation as an executable proposal. Delegates vote on the cohort as a whole; the recommendation is a take-it-or-leave-it and cannot be amended on-chain.

If rejected, the committee may revise and resubmit a maximum of two additional times. If no cohort is ratified within 30 days of the first failure, or if the committee voluntarily steps down, the committee is dissolved.

Evaluation Criteria

Eligibility (Ecosystem Objective category fit) is established in Part I.

The criteria below evaluate the quality and likely impact of eligible applicants and are ratified as the floor of the rubric. The committee may expand on these criteria, define sub-criteria, or set weights, but the criteria themselves are binding.

Prior Delivery History within ENS. Has the team shipped what it committed to in previous ENS work? Incomplete or abandoned prior grants are weighted negatively. New teams without ENS history must demonstrate comparable delivery elsewhere.

Scope Clarity. Is the team’s intended work clearly defined? The committee looks for a coherent problem statement, a credible approach, and a clear articulation of what success looks like. Flexibility in execution is expected; the committee evaluates whether the team can credibly deliver meaningful outcomes, not whether they have followed a prescribed format.

Milestone Structure. Are deliverables broken into realistic and verifiable checkpoints with dates? Proposals with lump-sum outputs and no interim milestones score lower.

Adoption, Revenue, and Ecosystem Utility. Does this work expand ENS’s reach or usage? Covers direct user adoption metrics, name sales and renewal revenue attributable to the work, integrations, and broader ecosystem health. As stated in the program objectives, registration growth is a first-order outcome; the committee should weigh contributions to registration and revenue growth alongside non-revenue forms of adoption.

Service Provider Obligations

Individual service agreements are negotiated by the committee and specified per provider before cohort submission, within the following constraints:

Payment structure. Funded providers are compensated via stream, not lump sum. Streams are optimistic and continue by default. The committee negotiates schedule, duration, and milestones with each provider individually.

Milestone accountability. Milestones are targets, not gates. Service providers commit to verifiable milestones and a quarterly reporting cadence to keep the DAO informed of progress. The committee may recommend suspension or termination of a stream if a provider stops reporting or abandons the work, subject to a written notice and response period defined in the agreement. Disputes may be raised to the accountability body for resolution.

Treasury return. Unspent funds from terminated agreements return to the DAO treasury at the conclusion of the cycle. They do not roll over without a new DAO vote.

The standard service agreement template must be published to the forum before the application window opens. Material per-provider deviations must be noted in the cohort recommendation.

Voting

This proposal will be submitted as a Snapshot vote.

  • For: Authorize SPP3.
  • Against: Do not authorize SPP3.
  • Abstain: Abstain from this vote. Counts toward quorum but not approval.

Quorum: 1% of total $ENS supply.
Approval: Simple majority (>50%) of For vs. Against votes.

Next Steps

  1. All five committee seats confirmed publicly during forum discussion (5–7 days)
  2. Proposal submitted to Snapshot upon close of forum discussion
  3. Committee seated upon Snapshot passage
  4. Rubric and service agreement template published within 7 days of seating
  5. Provider submission window opens (minimum 5 days after rubric publication)

Timeline

Phase 1: Forum Discussion + Snapshot

Step Dates Notes
Forum discussion Apr 25 – May 2 Named seats declared publicly
Program + committee Snapshot May 2 – May 7 Single proposal, 5 days
Committee seated ~May 7 Rubric due within 7 days

Phase 2: Provider selection + Executable

Step Dates Notes
Provider submissions May 19 – May 26 Rubric publishes ≥5 days prior; review runs concurrently
Committee review May 26 – Jun 2 Scoring begins before window closes
Recommendation posted Jun 2 – Jun 5 Forum publication
On-chain ratification Jun 5 – Jun 14 7-day vote + 2-day timelock
3 Likes

I drafted SPP3 while observing conversations from temp check on expanding the ENS Foundation Board, the findings from the MetaGov retrospective, and even the recent post [Temp Check] Working Group Restructure.

I’m hoping to move forward a SPP program that improves on previous iterations, brings real oversight to provider work, and aligns provider scope with where the DAO needs to grow. I also want whatever we do here to remain forward compatible with however the DAO evolves organizationally.

I’m sure there are improvements to be made to this draft, and questions. Feedback on the budget, the committee model, or anything else in the proposal is welcome.

It’s clear that a lot of effort and thought has been put into this proposal for SPP3. It is something, where before there was nothing. Sincerely respect that.

Also appreciate how there’s an urgency to get the next steps for SPP3 confirmed, and confirmed in a way that will be best for the future of ENS. We all want this.

It’s past 1:30am here now and need to get up extra early tomorrow morning, so will keep this very brief.

There’s red flags in this proposal and it should not proceed as written. The described process here is also framed to ram this proposal through without appropriate opportunities for DAO feedback or discussion. For example, it’s already framed as a “[Social]” vote, rather than as a temp check. This post also calls to be put to a social vote in under a week. That seems to suggest a take-it-or-leave-it approach before DAO feedback is collected, taken into appropriate consideration, and accounted for in what is ultimately put to vote.

An alternate proposal for SPP3 is needed.

Once again, it’s past 1:30am here now. Will follow up with more detailed and specific thoughts. Let’s have a healthy debate on the future of the ENS SPP. No, this isn’t about stalling. This is an important time in the arc of ENS. A new ENS Foundation board is being assembled with a big new mandate, restructured working groups, SPP3, ENSv2, pricing changes, and more — let’s not take destructive shortcuts by ramming through the first proposal on SPP3 when better options are well within reach. More to come on that soon.

Thank you for working so hard on this, I really appreciate you running with this.

I will say that I feel a time pressure here and I would like to see us move forward with this sooner rather than later, and I’m willing to be pragmatic to see that happen.

I agree with a cap, but this kind of formula will result in potentially large swings year by year. Would Labs accept a percentage cap based on the last year? Probably not because they’d say it would lead to too much annual uncertainty, adding and cutting positions, etc. I’d recommend a percentage on a longer time horizon.

All good people. Not sure I like the precedent this sets, particularly for things like the Board composition (which is higher stakes). But I also understand time constraints here.

Greg’s great but I lean against this, since I think this program should be detached from Labs. Although maybe just one is fine for coordination purposes.

Eh, things like this could bite us in the future, I’d delete.

Very important! I support.

Asking the team to explain how they can held accountable is right and good. Requesting checkpoints with specific dates I think is not how real software development works and will lead to applications having lots of fake dates just to fulfill this requirement. I recommend replacing this with a more open-ended request for teams to define how their work will be measured (which the committee can respond to and probe, or request more).

To be clear, my previous post encourages feedback and I welcome yours.

The timeline is provided to add clarity. If there is demand to extend the discussion process this can easily happen. In the same spirit, the committee review phase after provider submission can be extended.

I reformatted the title. I don’t think I’ve demanded any rush here.

I appreciate the feedback, @brantlymillegan. Some of my thoughts on the points you raised:

Budget formula

I’m actually very open to discussion on the budget. If a 24-month or 26-month trailing formula makes more sense and adds more stability it is an easy change.

That said, my perspective is that I want to see a balance of growth-oriented spending while delegates engage in honest talks about the state of the treasury. Revenue and registrations are down. I understand that ENSv2, changes in name prices, and the broader market could significantly affect our current position, but I’m going off what we know now.

I also concede that trailing revenue calculation (of any duration) isn’t a perfect solution, but my goal is that this is an incremental improvement on the process last year which didn’t seem rooted in the protocol’s performance.

(Earmarking for revision, will consider 24/36-mo calculation.)

Milestone dates (Earmarking for revision)

We’re aligned. I want milestones to show there is a plan, not be rigid checkpoints. I meant for the current language to frame milestones as targets not gates, with stream continuation tied to reporting and not abandoning work. As long as providers have not abandoned work and are reporting, I consider them in good standing.

(Earmarking for revision, my language is unclear)

Term limits

Easy to drop, maybe over engineered there.

(Earmarking for removal unless there is support)

Named seats precedent

I recognize that this is a massive change from the previous process. I wrestled with it.

I ultimately decided to put forward named committee because although it removed a possible democratic process, I think providing a named committee adds simplicity and transparency for delegates choosing to ratify the program. There is no high-stakes election for large delegates to jockey: what you see is what you get. I also stand behind every name on that list

Nothing in this proposal binds future versions of the SPP, so I agree with you that if the program proceeds this way it should be evaluated and not considered precedent.

Labs Rep Seat

My take is the seat provides real value. Protocol-level technical judgment is hard to source elsewhere without creating a conflict. If we can find another protocol-level expert without an SPP application or conflict of interest, happy to discuss.

No backchanneling

Glad we agree.

2 Likes