Thanks @Premm.eth for this breakdown of a potential two-pool structure.
I think this approach could help balance both established teams and focused/innovative projects. The separation into large and small pools might help address some of the eligibility criteria concerns that @5pence.eth and I discussed earlier - we could also consider different evaluation frameworks for each pool.
Specific focus areas for each pool (like Core Infrastructure vs DAO Tooling) aligns well with @clowes.eth’s point about clarifying what kinds of applicants the DAO would like to see.
Thanks again for the comments. It would be good to try and come together on what a path forward on all of this could look like and start to form something up collectively.
The way I’m interpreting this is we have Program 1) Enables 2 asks and Program 2) Enables 2 pools now.
The intent behind them:
2 asks (bigger and smaller) – making sure all Service Providers’ financial needs are met and more teams get funded possibly.
2 pools – ensures maximum capital utilization and is intended for more equal or equitable funds distribution.
This is my interpretation, correct me if I’m wrong, but I think it’s important to define the intent behind these and what we want them to achieve.
On top of that, we also discussed having a lower-tier “Talent Provider” program, which I think fits nicely and is directionally correct with what Prem is proposing.
One important question I’m asking myself – does funding smaller teams equal more value to ENS vs. funding the best and proven teams? Arguments can be made both ways. Considering we’re a small team that I believe is doing good, I would love others to be able to do the same!
That said, even though I’d love to have more teams and builders, I don’t think the right way to do it is to carve a piece of an existing program and allocate 1/3 of it to smaller teams just because their ask is smaller.
Yes, we should do more to bring new talent and builders. And I’d love to see this happen through a separate program for smaller teams/asks, and not at the cost of sacrificing a few bigger teams for a few (more) smaller teams.
We should aim to develop programs so teams can evolve through them every year. For example: Talent Program → Service Provider Program → Graduates/Partners (or whatever), and do not break down existing programs into smaller pieces and try to fit it for everyone. Just my two cents. Scale horizontally.
P.S. I didn’t run the numbers on all possible scenarios with these two pools so I’m open to being proven wrong.
@Premm.eth I believe we should not encourage more small budget projects, but rather more ambitious high quality ones. I am proposing to increase the minimum to 300k this year, so the small pool wouldn’t make sense.
There are effectively 3 pools:
extended + 2 years
extended + 1 year
basic + 1 year.
The 2 year pool will have a separate budget (⅓ of the per annum of the others) so that it encourages organizations not to asks too much for their extended budget, otherwise they can miss on having more stability, nor asking too much as their minimum budget or risk not getting into the program at all.
Thanks for this clarity. I think, in general, there is an interest in better understanding the goals of the Service Provider Program.
Is it designed for routine services provided to the DAO? Is it designed for moonshot innovation? Is it designed to incubate ENS-related projects?
What if a team is providing high-quality services to the ENS DAO but does not require a minimum $300k budget?
How exactly does this work? I think, for most teams, the #1 goal will be to get funding, and getting two years of funding is a nice-to-have but will not play into sizing their budget request.
When I started running some numbers and scenarios, I found that the minimum budget only comes into play for the last funded team. Therefore, the incentives are for teams to ask for very high amounts for their extended budgets and very low amounts for their minimum budgets.