In addition to these expenses, ENS Labs actually also has expenses for R&D, Marketing, Accounting, etc.
ENS Labs spent 2.56m out of 4.2m in 2022 on salaries. Assuming the ratio remains the same (~61%), then with funding of 9.7m, compensation costs will be around 5.9m, which is about 170 thousand per employee per year.
This only confirms Lefteris’ point – $170k/y is still more than the requested $158k/y.
Catching up on the discussion.
I support Unruggable’s work and believe they demonstrate value to ENS through their contributions. I would favor accepting a modified proposal with:
IMO this highlights the opportunity to establish formal processes around:
Based on the discussion in this thread, particularly the points raised by @Griff and @lefterisjp, it’s clear the core challenge is balancing reliable infrastructure funding with governance. A revised proposal addressing these elements - especially around accountability and metrics - would earn my support as a delegate.
I appreciate @AvsA and @katherine.eth’s concerns about process and precedent, which is why I believe this is an opportunity to develop more formal frameworks rather than just handle it as a one-off exception
Just to clarify on this one point - I am not claiming the compensation per staff member is too high, just that the number of staff required for the proposed work is too high. Our own estimates are more in line with requiring one developer and two devops staff, with the latter potentially having time for other projects as well.
I wanted to take this opportunity to thank everyone who has engaged with the conversation surrounding this proposal. Process, accountability, and financial prudence are a vital element of DAO governance.
On a personal level, it means a lot that people have acknowledged the quality of our work and our contributions to the ecosystem.
We have taken the time to consider the feedback outlined in the thread, and are making the following revisions to our proposal.
We are reducing the ask to 24,000 ENS tokens with a 2 year vesting schedule and a 1 year cliff.
This is exactly inline with the terms associated with allocations given to Security council members and Service Providers.
We are adding the following milestones for accountability.
Recruitment: Hire a DevOps Engineer and a Blockchain Engineer to lead infrastructure deployment, and performance optimisation.
Timeline: Complete hiring by Q1 2025.
Production Gateway Deployment: Launch scalable, redundant gateways across five chains (Arbitrum, Base, Linea, Optimism, and Scroll) in five globally distributed regions (North America, Europe, Asia-Pacific, Middle East/Africa, South America).
Timeline: Deployment complete by Q1 2025.
Infrastructure Optimisation: Finalise infrastructure design and demonstrate cost reductions through performance and efficiency optimisations.
Timeline: Initial optimisation complete by Q2 2025, with ongoing improvements.
L2 Collaboration and Documentation: Collaborate with L2 developers to enhance gateway compatibility and API stability. Publish documentation detailing performance improvements and best practices.
Timeline: Ongoing, with quarterly reports.
Resiliency Benchmark: Maintain 99.9% uptime (excluding external dependencies) over a monitored evaluation period, with transparent reporting on outages and performance metrics.
Timeline: Achieve benchmark by Q4 2025.
We strongly believe that the DAO directly funding Unruggable is in the best interest of ENS moving forward.
There is huge value in having the operation of gateways handled by us, especially while Layer 2 blockchains are still a nascent technology. We are currently seeing rapid innovation and evolution in rollup architectures and being agile and responsive to these changes is vital.
We built Unruggable Gateways and look forward to serving the ENS DAO by operating the production gateway network for Arbitrum, Base, Linea, Optimism, and Scroll.
Thanks for these revisions @clowes.eth.
The reduced ENS allocation with clearer vesting terms and the detailed milestones effectively address many of the concerns raised in this thread.
Yes, this is still a significant ask and a departure from our existing service provider framework. However, given Unruggable’s years of consistent and exemplary contributions to ENS, and the critical nature of the gateway codebase you’ve developed, I believe this revised structure strikes the right balance between accountability and supporting essential infrastructure development.
I’m comfortable supporting this proposal in its revised form.
If this proposal is successful, I hope to see Unruggable dedicate resources in the coming year to engaging L2s in subsidizing these mutually beneficial gateways through reimbursement to the ENS DAO.
Thomas’ latest revisions have helped with some of the concerns people had. But there are two key points that have not been addressed that I think are some of the crux of the issues.
The streaming provider stream is new and we shouldn’t be moving providers off to their own separate streams. Alex puts it very succinctly here.
Unruggable’s request is insistent to run all the gateways themselves and therefore incur dev ops costs is short sighted and costly. The Ethereum foundation and geth team does not run an infura type service and it is very hard to run infrastructure well. Despite Unruggable’s excellent work on the gateway code, they do not have experience spinning up large scale infrastructure. I would like to see more justification for why this has not been explored. In our own research this cost could be significantly reduced with providers that already run nodes that we could also pay as you go.
I won’t be supporting this proposal, and would hope that Unruggable takes their significant social capital, compromise with Alex and the streaming provider (which really kick started this opportunity) and take their proposal to the streaming provider stream proposal.
If there are things that need to change in the stream provider stream proposal. I’m sure @AvsA will be all ears to help to adjust it. One of the concerns I’ve heard is that there is uncertainty for funding, which means possibly bringing forward the vote so teams have time to adjust to variable funding (which I feel this is one of the reasons this temp check exists in the first place).
Delegates should be aware there are good options for hosting gateway infrastructure that have not been discussed yet. Existing node providers are the experts here, and I’d like to use dRPC as an example of what this avenue brings to the table (we have been in talks with them):
We currently work with infrastructure providers for node operation. Our proposal is about dedicating resources to this complex problem, assessing and appraising the available solutions, and discerning the optimal solution. We have already had conversations with decentralised node providers and note that there is a lot of nuance to their offerings but it is something that we want to continue to explore.
That is why we, as a dedicated team should do it. We care about getting it right, and the accountability mechanisms built into this proposal incentivise us to do so.
We are not trying to avoid all risk, but rather take considered risk for an optimal long term outcome. We have added incredible talent to our team thus far - Raffy and Mely, and we expect to add other great employees over time.
Our company is dedicated to doing just that. Our discord and our documentation is tailored specifically to making it as easy as possible for developers to launch their own gateways using our code.
What complex problem? Is running gateways more complicated than running nodes?
This is why we shouldn’t do it, and let teams who have already been doing this kind of thing do it. If Unruggable are the only people capable of running gateways, that’s not a good sign.
Seems to contradict the comment about complexity above, please clarify.
I appreciate Unruggable’s agreeing to take some of the feedback from delegates into account, and to adjust their proposal. Like @Leon and @jefflau.eth, I believe that engaging an external provider like dRPC to host the gateways is likely the most effective way forward.
I’ve worked in SRE (AKA DevOps) at Google, and I can say from experience that running world class production grade infrastructure is much harder than it seems; anyone thinking of operating gateways at this scale - and I include both Labs and Unruggable - would be well placed to consider outsourcing the actual operation to a talented partner who can offer contractual SLAs and is already running high availability nodes for the chains concerned. It will be difficult to beat the combination of latency and uptime that they can offer.
Assuming Unruggable are prepared to give this option serious consideration, I’d be prepared to support this proposal on behalf of myself and Labs, provided it were adjusted to be part of the streaming provider program. This could be achieved either via interim funding until the program is renewed next year, or by passing a separate proposal approving the funding and specifying that it will be grandfathered in to the next iteration, counting as already approved and allocated from its budget.
If we are correct about third-party providers being a more affordable way to run production infrastructure, I have no doubt Unruggable will put the budget thus freed up to good use, and demonstrate as much to the DAO.
I continue to have serious concerns with bypassing the streaming provider program; if the program is not fit for purpose, we should be fixing it rather than bypassing it, and while I believe Unruggable are more than capable of delivering what they promise, I am concerned about the precedent that an easy bypass of the streaming provider program sets for both the DAO’s budget and for future requests. I cannot support the proposal if it continues to bypass the mechanisms we have put in place for ongoing funding of ENS public goods.
I share @nick.eth views that collaborating with a third-party node provider could reduce complexity. I also share concerns on bypassing existing frameworks.
As a path forward we could consider adjusting to align with the streaming provider framework—possibly through interim funding as a bridge until the next round or by securing an advance approval that can carry forward.
This approach keeps us from bypassing established governance mechanisms, respects the integrity of the Service Provider program, and ensures that our efforts are both cost-effective and operationally sound.
We support Unruggable’s efforts in this regard and given the necessity of EVM gateway deployments as a prerequisite for ENSv2, it makes sense to move forward. However, as many others have pointed out, there is a clear need to drastically improve the service provider program to take things like this into account and provide a clearly defined path for other critical infrastructure projects to continue to receive meaningful support.
: @blockful - this proposal is now onchain. Can you give us a 2nd check on a simulation of the calldata? It is a little more complex than the normal USDC Tx and would be good to have another review.
I’m voting against this because the updated proposal lacks a framework or mechanism for the DAO to objectively measure accountability—I would have liked to see the milestones included in the proposal onchain itself as well, as it would grant procedural valence and legitimacy to the deliverables, ensuring transparency and creating a measurable basis for holding the proposers accountable.
Including the milestones in the vote itself would reinforce procedural rigor by establishing a clear and formal structure for what is being approved. When milestones are explicitly part of the voting process, the DAO is not just approving an idea but also a roadmap for execution, making it easier to track progress and assess outcomes.
This level of formality reduces ambiguity, aligns expectations, and sets a standard for governance processes, ensuring that future proposals adhere to similar levels of clarity and commitment. Moreover, procedural rigor helps safeguard the DAO’s credibility, as it demonstrates a commitment to holding proposers accountable to transparent and immutable deliverables that have been collectively agreed upon.
I have posted a thread outlining how this proposal was built, and the accountability mechanisms that were built in: Accountablity: [EP 5.29] Funding request for Unruggable
We welcome additional eyes verifying the integrity of the generated calldata.
So this is a tough one.
I spent quite some time mulling this over and thinking what the right approach is. I ended up voting for this. But with some concerns. I will outline my thinking below.
As already discussed and outlined above I think the ask is rather high but not unreasonable if we compare it to the ENS labs one. To that end I would like to see same high quality work from Unruggable as ENS Labs and to have them contribute in multiple ways to DAO.
I agree with the accountability issues raised by @estmcmxci. And I find the post by Thomas here: Accountablity: [EP 5.29] Funding request for Unruggable to more than cover at least the concerns I had for accountability and what I would expect Unruggable to do with these funds.
What’s more remember, this is not Unruggable getting the funds and running away. If at any single point we want to stop the stream we can do it as a DAO. To that end, in that post Unruggable even provided the appropriate call data.
I see that as the thing that annoys me with Unruggable’s request. And also from discussions with other delegates and stake holders and from the reason some people voted No above this is the major pain point.
The idea is that we should follow due process. And I get it and I have to agree it annoys me too. But then what’s the process? There seems to be no given process to graduate from the SP program and that program does not seem to guarantee continuity in a stable enough way so that projects can grow and flourish their team while building for ENS.
Various solutions were proposed. I think Unruggable could have and should have taken them. Interim funding until the next SP vote, increase in SP budgets etc.
Frankly I don’t see why Unruggable did not opt for that. That approach would have worked, and the DAO would have a united front FOR it from what I can read. I am annoyed that this did not happen and we now have a quite contentious vote in our hands.
But though I find it annoying they did not accept the interim funding, I can’t find myself to consider this as the reason to not vote for them. They are a good team, been with us for long, what they are building is useful for ENS.
What’s more there is one other company that also does not stick to the SP process. ENS Labs is somehow an exception. And perhaps that’s fine. But then we should allow for more exceptions. This is a DAO after all.
Voting yes.
I want to say that I agree with Lefteris on many points here and I hope Thomas, Premm and team see this not as a rejection of Unrugabble but the DAO disagreeing with the process for which to give them the funds. I voted No but I look forward to funding them in February. It’s right there.
This post addresses some of my concerns as well. However, I believe a more transparent approach would have been to post this before the vote went live and to verbally include the milestones in the onchain proposal (which they were not).
I do not believe this proposal meets the standard necessary for the DAO to consider approving the stream. Other teams, such as @Karpatkey, have demonstrated a more robust approach, including an audit report by a third party—something the DAO requested from Unruggable but did not receive.
This is not meant as a criticism but rather as an opportunity to raise our standards when voting on actions that have far-reaching second- and third-order effects.
—
The fact that this is even part of our conversation is a red flag to me. It never crosses my mind that ENS Labs would rug the DAO, so why has it become part of our vernacular to suggest that Unruggable might? Strange.
—
We haven’t had enough time as an organization to reflect on and learn from the first season of the SP program. I see this as a responsibility of the @Meta-Gov_Stewards, and I look forward to fostering conversations about the process in the next term.
—
This conversation has highlighted that there seems to be a double standard in the process. I acknowledge that even Labs could be more forthcoming in committing to transparency, among other things. However, as the creators of the protocol, Labs naturally benefit from more implicit trust than newer teams.
As long as we can all recognize and acknowledge this, I think it’s acceptable. That said, I agree that greater weight should be given to teams with a proven track record.
Alex, we really appreciate your support of our work, and the incredibly positive commentary on our work across this thread. Thank you !
In the conversations that we have had, many have said that we could have just waited for next years Service Provider streams. Unfortunately this overlooks the fact that the Service Provider program is not designed to support the operation of core infrastructure. We think the Service Provider program is great - it helped us bootstrap our team - but we do not believe it is appropriate for Unruggable moving forward.
We need a stable stream (albeit one that can be turned off by the ENS DAO at any time) that is not constrained by a fixed-sized budget or subject to annual (or biennial) renewals such that we can hire talent, focus on our work, and deliver for ENS.
We have also been asked if ENS Labs and Unruggable will be able to work together given our difference of opinion on funding mechanisms. Absolutely. As we have said in more than one conversation, “we are adults”. We might disagree about how core infrastructure should be funded, but everyone is aligned in wanting the best for ENS.
We continue to advocate for our proposal, and appreciate all the delegates that have participated in this conversation.
We are look forward to working with everyone in 2025. I expect it to be an amazing year for ENS!
The simulation and tests of EP 5.29 can be found here . Calldata matched the proposal description as expected.
The proposal was simulated by proposing, passing, executing, and asserting the difference between the flow rate on the Superfluid contract, and the ENS balance considering the vesting and cliff periods.
This can be checked by cloning the repo and running:
forge test --match-path src/ens/proposals/ep-5-29/* -vvvv