SPP2 Stream Implementation - Preparing the Executable Proposal

Service Provider Program
1

With EP 6.10 now concluded and our eight service providers selected for Season 2, it’s time to prepare the executable proposal that will implement these changes. This post shares our preparation process and invites community review before we finalize the transactions.

Where We Are

The Service Provider Program has been a cornerstone of ENS ecosystem development. As we transition from Season 1 to Season 2, we need to update our streaming infrastructure to accommodate:

  • The approved budget increase from $3.6M to $4.5M annually
  • Six continuing providers with updated allocations
  • Two new providers joining the program

The good news is that our existing Superfluid architecture (ENS Treasury → Stream Management Pod → Service Providers) has proven reliable and will continue to serve us well.

Our Preparation Process

To ensure we get this transition right, we’ve assembled a testing repository at github.com/5ajaki/SPP2-Streams. This is our workspace for verifying all the numbers and testing the proposed changes before submitting them to the DAO.

What the Repository Does

The repository helps us:

  • Calculate exact amounts: Making sure we request the right USDC allowances and set correct stream rates
  • Test the transactions: Simulating how the changes will work on mainnet before execution
  • Compute transition payments: For providers whose rates are increasing, we need to calculate backdated payments to ensure they receive their full allocation from May 26

For example, when a provider’s rate increases from $500k to $700k annually, they’ll need compensation for the days between their old stream ending and their new stream starting. The tools help calculate these amounts precisely.

The Planned Changes

The executable proposal will include four main transactions:

  1. USDC Allowance - Approving funds for the streaming contracts (exactly one month of the new budget)
  2. Token Conversion - Converting USDC to the streaming token format Superfluid uses
  3. Stream Rate Update - Increasing the master flow rate to match the $4.5M annual budget
  4. Autowrapper Configuration - Adjusting the allowances for the automatic refill system to handle the increased budget

These changes maintain all our existing security measures, including limiting exposure to approximately 50 days of funding if any issues arise.

A Note on Allowances and Runway

[EP 6.3] specified that we should maintain a 3-month runway to ensure program continuity. For this implementation, we’re taking a balanced approach to implementing this:

  • We’re requesting sufficient allowance to cover approximately 18 months of operations
  • This ensures all one-year streams can complete with adequate buffer
  • For the two-year streams (ETH.LIMO and Blockful), we’ll need to renew allowances as part of the SPP3 process

This approach maintains appropriate DAO oversight while ensuring no interruption to service provider funding, which is the intent of the language in 6.3. The two-year stream providers will continue receiving funds throughout their term - the DAO will simply need to approve additional allowances when SPP3 is considered next year.

:rotating_light: This point is open to debate and we’d like feedback. The original plan was to request allowance for the sum of all streams (both 1-year and 2-year plus 3 months of each), but that wouldn’t work as intended because any overrun in year 1 will simply eat into the year 2 allowance, negating the exercise.
The text of [EP 6.3] could require us to approve the larger amount however. Please comment your thoughts on this.

Timeline & Next Steps

We’re currently in the testing and review phase. Once we’re confident in the calculations and have incorporated any community feedback, we’ll:

  1. Finalize the exact transaction amounts
  2. Submit the executable proposal for DAO vote (expected June 11th)
  3. Upon passing of the executable, execute the changes and coordinate with providers for stream activation

We Welcome Your Review

The testing repository is public and we encourage anyone interested to take a look. If you’re technically inclined or just want to understand the process better, your feedback and review is valuable. The repository includes:

  • Documentation explaining our approach
  • Tools to verify calculations
  • Test results showing expected outcomes

You can find it at github.com/5ajaki/SPP2-Streams

In Closing

By sharing our preparation process openly, we hope to leverage the strength of the community, and to maintain the trust and transparency that makes ENS governance work.

If you have questions, suggestions, or concerns about any aspect of this implementation, please share them in the comments. We’re here to ensure this transition goes smoothly for everyone involved.

A big thank you to Clowes.eth for the contributions

8 Likes
2

Thanks for putting this together @5pence.eth!

Just one suggestion:

We have things well defined on EP6.3 and no clear upsides in having 2 separate executable proposals for the execution of SPP2.

We should follow exactly what was approved on EP6.3, so setting the end dates on all streams and approve the allowance for the whole budget that was already passed requires only 1 executable proposal rather than 2 executable proposals as proposed above.

If there is a delay for SPP3/SPP4, then we’ll need a vote to understand if these 3 months should be extended or not. And execute the result of the vote, changing allowances and etc.

Here is a spreadsheet for simple verification of the budget parameters to run the program.

1 Like
3

Thanks @netto - this is the only item left for the proposal. I agree that honoring the text of proposals is important, but neither of the suggested approaches match the text exactly:

The [EP 6.3] proposal was focused on choosing the amount for the entire stream pot, but it included this relevant bit.

“The budget is set per year. However the actual required budget will need to cover 19 months, because as detailed below, 1/3 of the streams will be budgeted for 2 years and we will add another 3 months of runway to make sure the program is not interrupted by eventual delays in the 2026 vote.”

The issue is that the stream allowance for Year 1 and Year 2 is the same bucket. So it’s actually impossible to guarantee a specific allowance for the Year 2 streams.

For instance, if we add 3 months to both amounts as you suggested here, both Year 1 and Year 2 providers draw simultaneously from the shared allowance.

It’s logically not possible to give the Year 2 streams a guaranteed separate buffer as the text in [EP 6.3] likely intended, because they share the same allowance pool.

I’m okay with either answer, but it seemed that if we can’t guarantee Year 2, we might as well talk in terms of “Year 1 + Extra”, to encourage limited allowance numbers and clarity.

So, the choice is to approve:

Both approaches are super close (total runway 18.73 vs 18 months), but neither is the 19 months in the 6.3 text, if that’s what you’re suggesting.

2 Likes
4

If I’m reading this correctly I think @netto.eth is suggesting that the fourth step, ‘Set Autowrap Allowance’ be updated to set the allowance to include the funds for the second year of the 2-year recipients funding up-front.

My calculations mimicked what was implemented in SPP1. I used a 6 month buffer rather than the 3 month buffer written in the social proposal. The numbers work out broadly the same as a result of this difference, and as @5pence.eth mentions they don’t explicitly match the 19 months as outlined in the social proposal anyway.

This is about risk tolerance - minimizing exposure if Superfluid and/or the AutoWrapper are compromised. One assumes that there will be a SPP3 anyway and as such some sort of executable will happen in approximately 1 year anyway, so I don’t believe this creates an extra executable.

Given that @AvsA wrote these proposals, I’d be interested in his opinion.

5

Re: the “two executables” - It wouldn’t require two executables. Essentially both approaches set an almost identical allowance. Either amount fully funds the stream awards that the recipients were granted. The 100k USDC difference only exists in the “extra” amount the DAO is including as a convenience to the recipients. Neither allowance amount guarantees a single proposal or two proposals.

Re: “setting the end dates” - None of the proposals articulate that idea that specific end dates should be set on the providers streams, and we haven’t done that before, so I’d be hesitant to include it in this executable without more discussion.
I do see your logic that if we set end dates on the Year 1 streams, this allowance setting would guarantee the Year 2 streams aren’t cannibalized by Year 1 stream overrruns.

The good news is that if the DAO wants to set end dates on the Year 1 streams to ensure that this one allowance covers the Year 2 streams, that can be anytime in the next 12 -14 months by a proposal, or by the Metagov safe directly, if an obvious situation requires it.

@netto - Are you okay with us continuing to deliberate on the question of “end dates”, since it’s not time sensitive? That way we can go ahead and get an allowance set to support the beginnings of the Season Two streams.
If you’re good with that, all we need to do is pick the allowance amount and we’re ready to go.

Seeing as all the test scripts were built for the 6.375 million USDC number, I’d say let’s go with that.
If you’d like to use the 6.45 million number in the allowance instead, would you mind updating the scripts in the repo to use that? Otherwise, let’s move forward with what’s ready. These numbers are super close.

6

@netto - Are you good with us moving forward with this proposal at the 6.35 million allowance level, or are you still wanting it to be 6.45 million?

I don’t think the 100k difference is material in this case, and as we’ve pointed out, neither matches the text of the proposal because the text is slightly ambiguous. (That’s likely because that section wasn’t what the proposal was focused on).

  • But, I disagree with your suggestion of adding end dates to the streams at this point. If that’s needed, it can be done later when we better understand the reasons for it.

We need to get this proposal up soon. Can we agree on an allowance amount?

1 Like
7

Hey, sorry for the delay. Back from travel last week and still catching up on some personal tasks.

Agree that the value for allowance needs to be 6.35 million, I’ve updated the spreadsheet and that’s also what the spreadsheet points. (The discrepancy between the values was because this field wasn’t filled, my bad).

The main point I’m raising is not about the allowance value, it’s rather about how the end dates, as pointed out in my first comment.

If we don’t have end dates, then the 1 year streams could have a total duration of 18.73 months. While EP 6.3 mentions 3 months of extra runaway (total duration of 15 months for 1 year streams) , so if we let service providers have a larger duration than that, then it should pass through another proposal IMO.

My worry is the DAO spending more than expected (or that was interpreted on 6.3 by delegates) if SPP3 delays to much or doesn’t even happen, who knows. The main thing I’m questioning here is how we gonna interpret and execute, because it can bring some uncertainty for future situations we’ll handle.

The text can also be interpreted as only the 1-year streams having the 3 months extra runaway and 2 years not having it. But there is this comment from Avsa than suggests it has.

So let’s move forward with this and within the next weeks clearly figure that out for aligning expectations and also prevent future surprises.

Thanks for the leadership here @5pence.eth!

And would be great hearing @AvsA’s view about the implementation, as he’s the proposer of SPP!

One last detail:

How can 100k increase have 0.73 month difference in the runaway, if the monthly spending for SPP2 is 375k? I assume the result of the readme should also be 18.73 since we got to the same allowance number.

8

Appreciate the thoughtfulness in the implementation approach here. Chiming in from the sidelines:

  • I’m leaning toward high execution discipline—guardrails now avoid ambiguity later and set a safer trajectory for the SPP.
  • Wherever possible, we should separate political risk from service provider funding. DAO vote delays shouldn’t impact contributor livelihoods, especially when funding has already been committed.
  • Year 2 stream guarantees are essential. Given how contentious SPP2 was, it’s not far-fetched to expect that future SPP cycles could face similar delays.
  • Complexity is acceptable, but only if it’s not time-prohibitive. We’re nearly into Q3, and we shouldn’t delay funding any further.
  • Procedural flexibility is okay—even if we’re not following the original proposal text to the letter, actions that are spiritually aligned and directionally correct feel valid to me.
  • If the DAO is setting a precedent here, that should be made explicit. The rationale should be laid out clearly—so there’s no daylight between intent, implementation, and delegate understanding.

A few questions I’d like to raise:

  • If adding end-dates requires a custom smart contract interaction, how quickly can that be implemented? @netto.eth
  • What exactly is the precedent being set here? Could the Meta-Governance Working Group spell that out explicitly?
  • How do we guarantee funding streams for Year 2 recipients if we skip end-dates? If not via stream logic, then what governance structure will ensure that protection?