I don’t think that proposed committee is relevant here. In recent times two proposals have gone up that have been inaccurate in some way. No shade - this stuff is very complex, and there are lots of moving parts. One was the description, the other was calldata.
It is very apparent that better drafting and verification tooling is needed. We should pay a competent team to build this. Tally are competent, lets pay them.
Whilst I think it is nice to have formal social votes for everything, ultimately we voted in the Metagov stewards to do ‘Metagov stuff’. Yes, lets have a chat about it on the forum and on the working group call but unless the discussion is highly contested I think we should let Metagov use their discretion to just get this done.
I agree with what @Coltron.eth said on the call - Tally have historically provided a great service to ENS, largely unpaid (I believe). Some of the features they are building also have a public good nature in that other DAOs can get value from them. That is to say I don’t think we need to scrimp on every penny - Tally are good people.
Tally likely want some level of financial clarity, but if we as a DAO are clear and transparent with them I do not see an issue. Give them an appropriate amount of money to do the things we need. Assure them, that (assuming they deliver) we will continue to pay them appropriately over time to build features we need.
Delegation of responsibility is vital for the successful operation of an organisation - everyone is incredibly busy. We’ve empowered the Metagov stewards by voting them in. Once we have had the community discussions we should allow them the autonomy to make these decisions.
Personally I don’t want a situation where the Metagov stewards are acting like an insecure partner - constantly seeking the validation of all delegates, over and over, for every decision, for weeks on end.
The only situation that would require further consideration is if there were clear conflicts of interest e.g. If one of the stewards were an investor in Tally. I know Spence wrote this: My Conflict of Interest Pledge as an ENS DAO Steward. I’d like to see the other stewards do something similar.
I’m just going to post this again…
TL;DR
I think Tally should be funded for things we actually need on a case by case basis by Metagov.
Having gone through all the comments, the pull request and post MG discussions on the call yesterday - I think the milestone based distribution is a good idea (esp given the budgeting conversation we had in terms of revenue vs spend). Delivering on specific needs as they arise is also important vs a carte blanche approach. The enterprise support line item can be evaluated based on activity and needs again and could decrease from the 60k estimate. Should overlap with other SPPs, potential Namechain delays and any other misalignments occur, they can be evaluated for that specific case (hence why the milestone approach is healthy and order of delivery can be played with).
Overall, Tally has been a key component of DAO functionality for years and I am confident they will deliver here as well. Testing this out with the milestone progression in place is worthy endeavour.
I appreciate everything that tally’s has done for governance. However, I do not believe most of this is critical right now. It seems the only re-occuring issue we have is the lack of draft proposals.
Given the latest Q2 revenue report, the DAO run rate revenue is roughly 15m/yr. Between the SPP, Working Group ops, and Core protocol development we are in the red.
Reiterating my earlier post, I don’t think the DAO should spend anywhere near $215k on governance tooling at this time and will be voting against if it goes to a social proposal.
My take on each line item:
Proposal lifecycle webhooks: I’m not convinced this is very useful. I recently built a basic DAO proposal monitor that performs some actions (posts to Telegram channel and updates governance docs) when there are new social or executable proposals. It doesn’t trigger on other stages of a proposal lifecycle, but I don’t know how useful that’d be anyways.
ENS integration: this costing $92k is quite steep IMO. The DAO already pays a service provider $1.1m/year to build indexing tools (ENSNode), so there should be no reason to fund another. ENS resolver actions would be cool.
Offchain proposal integration: This would be nice.
Enhanced proposal transparency: I don’t have enough experience publishing/reviewing executable proposals to evaluate this, but it sounds nice.
Enterprise support levels: I don’t think uptime has ever been an issue in the past, so I don’t see a need to start paying for an SLA. There are multiple governance frontends operated by independent teams for redundancy. That’s the beauty of trustless smart contracts!
The problem with framing it as a public good is that it then begs the question of whether the funding should come from the PG multisig.
—
That’s what the DAO Tooling line item was for, but the amount requested by Tally exceeds it, which is why a Social Prop was necessary — so that, when the time comes to request funds in Q3, there’s a clear precedent for why Meta-Gov is requesting that amount (my best inferred guess).
—
This seems to reflect a departure from the earlier position advocating for the formation of a technical advisory committee to support resource allocation decisions, mentioned in Toward Accountable and Strategic Funding in ENS, toward simply granting stewards full autonomy after community discussion.
Could you clarify your position?
—
+1
—
I believe that both our arguments are structurally parallel, semantically differentiated, and directionally equivalent.
Tally merits funding, but I would like to see Meta-Governance proactively discern what the DAO needs in order to ensure longevity. IIRC, @cliffton.eth said something like, ‘With the size of the DAO’s treasury, there should be some assurances about funding.’ But honestly, to be fair, that feels somewhat inappropriate or misplaced given the relatively non-critical nature of the tooling compared to the funding ask.
I’d like to see greater use of RFPs to invite broader participation. Healthy competition fosters accountability and raises the bar for quality — let’s cultivate a standard of excellence.
No additional technical knowledge is needed by delegates if Metagov are making the decision. Metagov don’t need additional technical support here because needs are discerned from experience. For example:
We do need better drafting and verification tools as demonstrated by the two recent incorrect proposals.
We do not need $60k worth on enterprise support as demonstrated by us not needing support last year (as I understand).
We do not need webhooks as demonstrated by no-one (that I’m aware of) asking for webhooks.
It could arguably come from the Public Good multisig, but IMO we need to stop wasting everyones time nitpicking things like this.
We could have a social vote to figure out precisely what proportion should come from which safe… or we could just get on with productive work to improve ENS.
My position was/is that Metagov give Tally a small amount, say $25k, for the work we actually need. That fits within the budget.
Tools like SafeNotes make it pretty transparent what the stewards are spending money on. If we think they are being financially reckless we can hold them to account at that point.
Empowering people and then micromanaging them is a waste of resource.
No change in my position. We should consider a Technical Advisory Committee for high stakes situations where delegates lack necessary technical understanding e.g. The Service Provider Program
Voting on the specced out budget as is will 100% garner against votes - the vote should not be for the full 215k but should be a progressive endeavour scoped out through Meta-Gov working alongside Tally to define clear, time-bound milestones taking all the discussion here re priorities and any double up work into account…
Appreciate everyone for your comments! Will address the key ideas raised.
On Enterprise Support Levels
Totally hear the question, and it’s fair to push on why an “enterprise” layer is necessary when we’ve already supported ENS for free. Two reasons stand out:
Governance resilience now needs hard guarantees.
ENS isn’t a side‑project DAO anymore—it safeguards a treasury worth ≈ $235 million. If a delegate can’t publish or execute a proposal at the wrong moment, funds can be frozen, migrations delayed, or security patches stalled. Volunteer availability and best‑effort uptime were acceptable in 2021; they feel less defensible today.
Dedicated engineering cover is what turns best‑effort into SLA.
The budget finances an on‑call rotation, monitoring, and root‑cause analysis that the free tier simply can’t promise:
Priority response: critical issues paged within 1 hour, continuous updates until resolved.
99.9 % uptime: UI, API, and webhook infra tracked by independent probes; monthly reports shared with Meta‑Gov.
Security & post‑mortems: 24/7 alerts for RPC/graph anomalies or suspicious contract interactions, plus written incident reviews so the DAO knows exactly what happened and how it was fixed.
We’ve always viewed ENS as a strategic partner, hence waiving the 0.25 % proposal fee and absorbing hosting costs to date. Formalising enterprise support simply gives the DAO contractual recourse, while letting us staff a team whose KPI is keeping ENS governance online, secure, and transparent. Also as a quick note, there hasn’t been any significant downtime over the past years since the inception of the ENS DAO.
Side point @estmcmxci - think there’s some confusion here and I do apologize if I miscommunicated this. What I was referring to was that a treasury worth north of $230M needs hard guarantees on resilience and continuity(as mentioned above), instead of implying that Tally needs assurance on funding.
On funding things on a case by case basis
In our opinion (as observed in calls and comments), handling every feature as a separate, one‑off budget puts Meta‑Gov stewards in an awkward bind: if they approve funding unilaterally, they might risk overstepping the mandate delegates gave them, and on the other hand if they kick each item back to a DAO‑wide vote, they lose the agility their role is meant to provide. By pre‑authorising a single, milestone‑gated budget, the DAO explicitly empowers Meta‑Gov to sequence, adjust, or withhold payments as they see fit, without second‑guessing whether the community will support each incremental decision.
Here’s how this proposed setup safeguards both agility and accountability:
Joint milestone planning. If this social proposal passes, Tally and the MetaGov stewards will translate the scope into sequenced, prioritized milestones, taking into account all feedback on priority, potential overlap, and available committee bandwidth.
Steward discretion. Because the funds sit in the MetaGov wallet, the stewards can re‑order, delay, or even cancel any milestone if higher‑priority work emerges or if another grant covers the same ground.
Pay‑on‑delivery. No milestone, no disbursement. Each tranche is released only after the stewards confirm that the agreed deliverable is live, documented, and meets the SLA.
Progressive, not static. The milestone plan is a living document. If circumstances change, MetaGov and Tally can update timelines or scope without needing a fresh DAO‑wide vote for every adjustment.
Transparency to the DAO. Milestone status, spending to date, and upcoming targets will be reported regularly in Meta‑Gov calls and summarised in public forum updates, so delegates can track progress and raise concerns in real time.
In short, the vote doesn’t trigger immediate spending. Instead, it earmarks a budget the stewards can deploy as outcomes are delivered, giving ENS predictable resourcing without sacrificing oversight or flexibility.
I’d like to double down on this take from @simona_pop - we strongly agree with this, and hope that delegates have this mental model when voting. I hope this brings clarity to how we think about this proposal, and if there are other questions that I can help address, feel free to park them in comments.
Ah, okay — pardon me if I misconstrued. I didn’t intend to misrepresent your stance. Thank you for clarifying!
—
Agreed. I believe there is sufficient budget for this now, and a social proposal wouldn’t even be necessary if Meta-Gov chose to fund this specific figure directly, which shouldn’t cause any controversy since DAO tooling is within their mandate.
I also recommend using this approach as scaffolding for the milestone-based funding others are proposing.
Tally has raised several rounds of VC funding, creating pressure to generate returns for their investors. This is not inherently problematic, but it does create incentives to push for larger contracts to justify their valuation. To create larger contracts, more features need to be added, many of which stated here don’t appear needed.
Additionally, during my time as secretary, two venture-backed DAO tools we relied on (Parcel and Metropolis) eventually went under and stopped providing support, leaving working groups in a tough spot. Their core offerings were useful (onchain bookkeeping and onchain organization management) but because they couldn’t charge DAOs enough to return capital to investors they had to shut down.
Because of this, I am not a fan of large contracts to vc backed companies as a whole and would favor towards mg funding small teams/solo devs making custom built open-source tools for specific problems similar to how they have funded ENS Ledger.
ENS DAO requires some form of governance tooling in order to ensure proposal life cycles and wider DAO security. Last week on the metagov call I was generally supportive of this proposal going through, with the understanding that the MetaGov working group agreed on the importance of this proposal AND that the dollar amount of the ask wasn’t too high - Since the proposal was discussed (on the forum and metagov call) the proposal has gone from $100k USD & $80k tokens;
This increase in budget after it had already been discussed drives a no vote from us.
I fully agree with Simona here:
Setting up some type of commercial engagement between Tally and ENS-MetaGov WG makes sense. Ensuring the DAO and its delegates have access to this tooling is a priority - However making a public proposal after losing out on the service provider program as well as the cost of which is increased by 20% in the last few days isn’t the best way forward.
I would encourage Tally to continue conversations with MetaGov to find the right way for some variation of this to still be achieved.
some features do not have a high demand from delegates, leading also to a larger budget requested.
this funding could come from a mechanism where other governance FE also get this opportunity to be sustainable, because client diversity is healthy.
Tally should be supported and there is no opinion I have seen that doesn’t recognizes Tally’s contributions. It’s more about finding the ideal structure, pricing and feature set.
Possible paths moving forward:
Iterating more the current proposal. From the business perspective having a annual contract helps on stability for both sides and it’s what I understand Tally is trying to push forward here. Personally it feels like metagov shouldn’t engage in a +100k and annual contract after SPP election happening, without a larger DAO discussion and approval.
Adding features ad-hoc. In this case I think this can be easily done with the Metagov DAO tooling budget. Because it’s not establishing an annual contract neither, it’s supporting specifics needs that delegates and metagov are requesting.
These are my personal views. I’d prefer path 2 - where we address specific needs, spend less and create space to engage with more governance clients and teams.
As most of you will have seen, the Snapshot for “Enhancing ENS Governance with Tally’s Enterprise Support” did not pass. While the outcome wasn’t what we hoped for, it does not diminish Tally’s commitment to ENS or our conviction that robust, responsive tooling is critical to the DAO’s next phase.
The path forward
In‑demand engagements. Rather than a single omnibus agreement, we’ll collaborate directly with the MetaGov stewards to scope smaller, high‑impact workstreams that delegates and the stewards themselves have signalled are most urgent.
Milestone clarity. For each engagement we will work with the Metagov stewards to publish clear deliverables, timelines, and budgets in advance so delegates can follow progress.
Enterprise layer optionality. Where hard guarantees (24 / 7 response, 99.9 % uptime, incident post‑mortems) remain desirable, we’re happy to structure those as add‑ons the stewards can activate when needed.
Over the past few weeks we’ve learned a great deal from delegates’ feedback, both on MetaGov calls and in this forum thread, and we’re grateful for the candid discussion. We look forward to working in lockstep with the stewards and the broader community to refine, ship, and support the features that keep ENS governance resilient.
As always, our DMs (and this thread) remain open. Appreciate everyone for participating in this process!
