Should the DAO have Tally as a Dedicated Governance Service Provider?

DAO-Wide Temp Check
1

Introduction & Background

Tally is the de-facto interface for ENS governance. Approximately 70% of all token-weighted votes in the DAO are cast through Tally.

555×213 14.2 KB

We regard the ENS naming layer as foundational to cross-DAO interoperability and are committed to accelerating its next chapter, particularly for the planned migration of the protocol’s registry logic to Namechain, where Tally will deliver first-class support.

Tally proposes a formal enterprise level service agreement that elevates ENS governance UX, broadens the distribution of ENS primitives across all governance users on Tally, and furnishes the DAO with battle-tested uptime, reporting, and support guarantees.

Scope of Work

Customisable Proposal Webhooks

Proposal webhooks provide the ENS DAO with a streamlined mechanism to tailor onchain workflows, offering a range of benefits, which includes, but not limited to, timely notifications for delegates to engage in governance, improved tracking of proposals throughout their lifecycle for contributors, and alerts upon the successful onchain execution of approved proposals.

Triggerable events include:

  • Draft published (off-chain)

  • Proposal published (on-chain)

  • Quorum reached

  • 24 h left to vote

  • Voting period ends

  • Proposal queued in timelock

  • Proposal executed

ENS Integration & Distribution

  • Prioritize Namechain rollout. As soon as Namechain is live on mainnet, Tally will add support for it on tally.xyz. Tally will index, decode, and display governance contracts on the network.

  • Indexing offchain ENS names. Tally will extend our resolver pipeline to ingest CCIP-Read & wildcard-enabled sub-name registries (eg *.cb.id issued by Coinbase) and Farcaster’s *.fcast.id Fnames, cryptographically verifying gateway signatures before caching in our indexer. Every user, regardless of where their ENS-compatible name is anchored, will see that name reflected on Tally profiles and proposal metadata.

  • Action to Update ENS record. Create a low-code proposal builder that lets all DAOs on Ethereum mainnet easily modify text records directly from a proposal. This includes setting resolvers and records (text, address, reverse).

1380×680 96.4 KB

Enterprise Support Levels

ENS will have access to Tally’s in-house engineers directly available to proactively resolve support issues and assist users, even in cases where the issues are not confined exclusively to the Tally platform. In addition, we will be waiving the 0.25% transfer fee on every proposal.

Support response time guarantees

  • Critical Issues (e.g., service outage, security breach): Initial response within 1 hour, updates every 2 hours until resolved.

  • High-Priority Issues (e.g., significant performance issues, partial system failure): Initial response within 4 hours, updates every 6 hours until resolved.

  • Medium-Priority Issues (e.g., UI/UX bugs, non-critical feature issues): Initial response within 1 business day, resolved within a commercially reasonable timeframe.

  • Low-Priority Issues (e.g., minor bugs, general inquiries): Initial response within 3 business days, resolved within a commercially reasonable timeframe

KPIs and Success Metrics

Ongoing Program KPIs

  • 90 % + attendance at weekly MetaGov calls by at least one Tally team member

  • Maintain 99.9 % + uptime for the ENS Tally client (web + API)

  • Support 100 % of on-chain governance proposals with timely frontend updates reflecting user feedback and governance activity

  • Add full support for Namechain on mainnet launch

Quarterly KPIs

  • Deliver quarterly reports detailing features shipped to the ENS Tally client and their alignment with ENS governance priorities

  • Publish a quarterly feedback and fixes summary documenting bugs, feature requests, and actions taken by the Tally team

  • Report ENS-specific usage metrics within Tally, including delegate discovery traffic, proposal creation frequency, and number of unique ENS-based user sessions

  • Highlight integrations or UI/UX improvements that expand ENS visibility within Tally, such as showcasing ENS names in proposal authorship, delegate profiles, and voting summaries

SLAs

  • Tally usage
    • We will continue to track the number of proposals and % of votes per proposal made on Tally and report on those to the DAO.
  • Roadmap feature usage
    • As we roll out new features for the ENS DAO, we will track usage of those features and report on them to the DAO.
  • Monthly office hours
    • An open feedback session for ENS DAO contributors to suggest new features and contribute to our roadmap
  • Uptime and availability
    • System Uptime: 99.9% monthly uptime, ensuring the system is accessible with minimal disruptions.
    • Scheduled Downtime: Maximum of 2% monthly allowance for scheduled maintenance, communicated in advance.
  • Response and resolution time
    • As per the Enterprise Support Levels section above.
  • Maintenance and support

    • Bug Resolution: Resolution of non-critical bugs within 5 business days and critical bugs within 1 business day. For bugs that are not possible to resolve in this time frame, a post-mortem analysis to be shared with the DAO following resolution.

    • Regular Maintenance Updates: Regular monthly maintenance updates, including minor upgrades, patches, and performance improvements.

  • Public API access

    • Tally provides open access to its governance API, allowing developers to query proposal data, vote records, delegate profiles, and DAO metadata. We ensure 99.9% monthly uptime for the API and will notify the DAO of any major updates, deprecations, or downtime.

    • Feature requests and support for API integrations can be raised during monthly office hours or through direct support channels.

Costs

Workstream Year 1 Cost (USD) Recurring (Year 2 onwards)
Proposal lifecycle Webhooks $28,000
ENS integration (off-chain indexing, Namechain) $92,000
Enterprise Support Levels $60,000
Total $180,000 $60,000
(Enterprise Support Plan)
Payment Split $100,000 (USD) + $80,000 in ENS tokens $40,000 (USD) + $20,000 in ENS tokens

Past Achievements & Useful Links

Tally has delivered proven results:

  • Over $1B moved via DAO proposals on Tally
  • Over 7,000 proposals created using the Tally platform
  • Tally supports over 40 million token holders

Some of our ENS-specific contributions:

  • Integrated Ethereum Follow Protocol
  • Enabled gasless voting and delegation for ENS tokenholders on Tally
  • Integrated ENS name lookup across the Explore Delegates page and governance URLs
  • Supported in-app Discourse commenting for ENS proposals
  • Featured ENS during Tally’s Delegation Week Spotlight

For more:

Conclusion

Formalising Tally as the ENS DAO’s dedicated governance service provider institutionalizes the tooling, reliability, and transparency already trusted by the majority of voters. More so, it unlocks new ENS-centric capabilities, particularly, seamless off-chain name resolution and Namechain readiness.

We welcome feedback from delegates and the broader community, make necessary refinements, and will progress this temperature check to a draft proposal once we have a good sense of the general sentiment.

3 Likes
2

Hey everyone, first, a sincere thank-you to the MetaGov stewards (s/o @daostrat.eth @netto.eth @5pence.eth ) for making room on short notice for us to walk through this proposal during the most recent call. We appreciate the chance to field questions directly and to clarify how Tally hopes to serve the ENS DAO going forward.

–

1. How does this proposal relate to Dennison’s “ Programmatic Tooling Rewards ” concept?

Dennison’s post outlines a baseline funding framework to keep essential governance rails - actions like proposal creation/execution, voting, delegation, up and running in a sustainable way. Our proposal tackles a different (and, we believe, complementary) layer:

  • Customisable Webhooks – real-time notifications tied to ENS governance events (draft, on-chain publish, quorum reached, execution, etc.) that can pipe into Slack, Discord, or any endpoint the DAO chooses.

  • Deep ENS & Namechain Integration – indexing CCIP-Read and wildcard sub-registries (e.g., *.cb.id, *.fcast.id) with signature verification, action to ‘Update ENS record’ which lets all DAOs on Ethereum mainnet easily modify text records directly from a proposal, and day-one support for the forthcoming Namechain migration.

  • Enterprise-Grade Support & SLAs – direct access to Tally engineers, sub-hour critical-issue response, 99.9 % uptime guarantees, quarterly reporting, and the continued waiving of our 0.25% proposal fee.

There is some overlap in the support dimension, and if the DAO ultimately adopts Dennison’s rewards model we are happy to adapt. That said, a purely programmatic stipend would likely fund only the baseline services, leaving the webhook framework, deep integration work, and higher-touch SLAs unfunded.

–

2. Why seek funding outside the SPP, and why not have the DAO progress this through an RFP?

Tally is the de-facto interface for ENS governance. Approximately 70% of all token-weighted votes in the DAO are cast through Tally. Given this track record, we felt it appropriate to bring a targeted proposal rather than ask delegates to draft an RFP from scratch.

We fully understand that the community may wish to benchmark alternatives. If delegates decide an open RFP is the best path, we will participate in good faith.

–

Formalising the relationship now simply allows us to invest even more deeply in ENS-specific functionality, and turn governance into a clear competitive advantage for the DAO, while giving delegates predictable costs and SLA-backed assurance. We look forward to the community’s feedback and remain ready to iterate on the proposal to match ENS’s evolving needs.

3

Hi Cliffton.eth, welcome to the Forum. Nice having you join today’s Meta-Governance Working Group call. Tally is undoubtedly the de facto interface for ENS governance. Onchain proposals would not have been as easily facilitated without the interface it provides. The ability to review proposal status, delegate votes, and execution timing through a clean UI has added clear value to the DAO, needless to say.

I’m not in the business of making enemies, but I do want to call out some aspects of this proposal that give me pause:

  1. Webhooks
    The proposed webhook system doesn’t appear to be a novel cryptographic innovation, but rather a notification layer surfacing events—Discourse threads, Snapshot votes, and Governor logs.

    If that’s the case, it seems like something a moderately skilled developer could build and maintain as a public good. Is Tally’s proposed webhook system proprietary, or will it be open and reproducible by the community?

  2. ENS Integration and Namechain Readiness
    Tally benefits from ENS. It’s how delegates anchor their onchain identity, and it enhances the user experience across their interface. ENS is also one of the most visible and active DAOs on Tally.

    Prioritizing Namechain support, indexing ENS records, and enabling proposers to update those records via the Tally UI all improve Tally’s own product. Integration should be Tally’s default stance. I’m afraid that framing ENS support as a paid feature comes off as rent-seeking.

  3. Enterprise Support and Culture Fit
    Numerous contributors to the ENS DAO show up to weekly Working Group calls where they actively discuss ways to improve the DAO and protocol driven by first principles, not compensation.

    Paying for enterprise support feels out of step with a culture that values intrinsic alignment and voluntary stewardship. It’s great to see Tally at today’s call. I’d encourage them to join more often!

—

My honest take

This proposal feels less like Tally offering net-new value, and more like productizing its presence within the DAO. It shifts the relationship from mutual alignment to a vendor–client dynamic. one that doesn’t fully reflect the open, collaborative ethos ENS has cultivated. Many of the features outlined (webhooks, ENS integration, Namechain readiness) are things Tally would likely build anyway to stay competitive.

4

Hi @estmcmxci, thanks for the constructive feedback and questions! We value our long-standing partnership with ENS and want any next step to reinforce, not replace, the open-source, collaborative spirit the DAO has cultivated. Addressing each point below -

  1. Webhooks

The webhooks will be deeply integrated into Tally’s backend infrastructure (proprietary), but the webhook spec and the onchain proposal events (on-chain publish, quorum reached, execution) are public, and anyone could add them to a community-run webhook system. The part that would be harder for a community-run system to duplicate would be reliability. This proposal includes an SLA, monitoring, alerting and the engineering resources to keep the webhooks and the rest of the tally.xyz services running reliably for ENS DAO.

  1. ENS Integrations

Core governance flows, ENS look-ups, and the waived 0.25% proposal fee all remain free, just as they have for the past 3 years. The paid scope accelerates work that is uniquely heavy for ENS:

  • Day-zero Namechain support — new indexers, search pipelines, and UI/QA so migration happens with zero downtime
  • Wildcard / CCIP-Read indexing — cb.id, Fnames, and future registries automatically surfaced in profiles and proposals
  • Low-code “Update ENS Record” action — lets any DAO amend text records or resolvers directly inside a proposal

We could build these eventually, but a formal mandate moves them to the front of the queue and ties them to explicit SLAs the DAO can hold us to.

  1. Enterprise-grade support & culture fit

ENS’s volunteer ethos is a strength, and our goal is to continue participating in Meta-Gov calls. That said, a $212M treasury also warrants hard guarantees:

  • Priority responses to critical issues
  • 99.9% uptime across UI and API
  • Security monitoring and formal incident post-mortems

The agreement funds the on-call engineers who make those promises real. If delegates prefer lighter coverage, we can explore scaling SLAs and costs down. The goal is to let the DAO choose its risk/coverage trade-off.

–

Stepping back, from our perspective, this isn’t about productizing our relationship with ENS. It’s about codifying mutual commitments so stewards, delegates and contributors can depend on predictable service, while we internally justify having dedicated resources for ENS. Everything currently free stays free - the agreement simply layers complimentary features, and explicit accountability and timelines on work that deepens ENS’s role as the centre of on-chain identity. We appreciate the ongoing dialogue and are happy to refine any detail that still feels out of step.

1 Like
5

That’s great, thanks—and I’m sure everyone reading this finds it really helpful. My question is: instead of putting this to a DAO-wide vote, why can’t one of the existing Working Groups just include it in their budget? Tally’s been a fundamental tool for the ENS DAO since Day 1. Doesn’t it make sense to show our support with a retroactive grant?

Just my 2c.

6

I believe this proposal makes a lot of sense and represents a reasonable ask for the value provided.

Governance is fundamental to smooth DAO operations, and maintaining a diverse governance toolset aligns with the general pattern of client diversity that keeps Ethereum strong.

We’ve engaged in similar arrangements with other governance providers, and in each case, the work benefits not just ENS but also smaller, less capable DAOs that will form the next generation of decentralized governance.

I see some clear benefits to letting this be a DAO-wide proposal instead of working group spend:

Budget: MetaGov didn’t budget for dedicated governance provider support, primarily because the SPP was open at the time with several providers in the application pipeline. Unfortunately, the field was packed and none were selected.

DAO Signaling: Since no governance providers were selected in the recent vote, it’s probably more appropriate for the DAO to explicitly endorse this rather than have a working group potentially act against what could be interpreted as a counter-signal from the DAO.

Recognition: A DAO-level endorsement of Tally is deserved recognition of how critical they’ve been to our operations over the past several years. 70% of token-weighted votes coming through their platform speaks volumes.

The Value

The Namechain support alone justifies serious consideration:

  • Zero-day Namechain support is essential - there’s no way around this requirement
  • Offchain name indexing (*.cb.id, *.fcast.id, etc.) as proposed would be a significant win for all holders of offchain ENS names
  • I also think having the web hooks available would be super helpful for lots of cool smaller experimental apps that could lead to creative new workflows.

I have some thoughts about minor tweaks to the deliverables list that I’ll add to this thread after a bit more research, but overall this looks well-structured and I would support it moving forward.

1 Like
7

Don’t mean to encroach but…

It’s correct to point out that the Meta-gov budget did not include a line item for dedicated governance provider support. But from a capacity standpoint, the Meta-gov multisig currently holds more than enough funds to accommodate Tally’s request (see enswallets.xyz).

IMG_1317
IMG_13171179×309 53.2 KB

That said, I’m not sure what Meta-Gov already has allocated or prioritized, and I’m not looking to disrupt that calculus. I’m just raising the question of whether there’s a way to support Tally without requiring an onchain vote.

On further thought, I do think a DAO-level endorsement would send a strong signal to the broader ecosystem—that Tally is co-signed by ENS DAO.

Edit: I’d like to clarify that I didn’t specify what kind of signal a DAO-level endorsement would send to the broader ecosystem—I’ll leave that open to interpretation.

8

Firstly, I want to acknowledge that Tally provides a polished and valuable web frontend for Governor-based proposal creation and execution.

However, as a founder building in this space, I’d like to raise a few concerns with how this proposal has been framed and the broader implications it has for the ecosystem.

Problematic Framing: “Dedicated Governance Provider”

Using language like “dedicated governance service provider” sets a dangerous precedent that undermines competition. It suggests exclusivity in a category that should remain pluralistic and permissionless.

For example, Snapshot is a critical vendor that also provides DAO tooling and with broader usage. If we’re comparing facilitation:

  • Snapshot has supported 82 off-chain proposals
  • Governor has handled 44 on-chain proposals

Governance is not just proposal creation, it includes delegation UX, voting incentives, metadata indexing, notifications, delegate engagement, and more. Consolidating this complexity under a single vendor creates fragility, not resilience.

Long term impact

While ENS has the luxury of a strong revenue base, the tooling it funds sets a precedent for the wider DAO ecosystem.

If we want to see more Web2 organizations adopt decentralized governance, we need:

  1. Governance tooling that is cost-effective and modular.
  2. A procurement process that encourages innovation and diversity.
  3. Transparent benchmarks for deliverables and pricing.

Let’s not forget: more DAOs → more use of ENS → stronger ENS network effects and revenues. Supporting a diverse marketplace of tools is in ENS’s own long-term interest.

A question: The DAO has already allocated $4.5M via SPP2 to ENS tooling, which includes Namechain indexer work. What makes this proposed integration substantively different?

Stifling Open Innovation

As I raised in the Metagov call: if Tally is in early discussions around the requirements for zero-day support for Namechain, those conversations should happen in public.

Anything less and it actively harms other vendors who are independently investing their resources and capital to build alternate approaches like Agora, Snapshot and Lighthouse.

Final Thought

We respectfully ask ENS stewards and delegates to consider what has been brought up many times before:

“How do we support vendors who clearly add value while also allowing new participants to compete and innovate?”

For context, the Compound governance stewards received a similar proposal from Tally and decided to turn it into a tender process for all vendors.

I would hope to see something similar that also builds on some of the ideas presented in this thread.

3 Likes
9

Hi @Arnold, thank you for the thoughtful push-back. We agree that ENS succeeds when governance tooling is pluralistic, low-friction, and open. Please see our inputs on the points you raised below.

“Dedicated governance provider” ≠ exclusivity

When we say dedicated we mean “formally accountable”, not “sole vendor.” We whole heartedly agree that governance is more than just creating and voting on proposals, and supporting every end to end engagement is not something a single provider can feasibly, and optimally do today.To specify, there will be -

  • No exclusivity clauses. The DAO is free to fund or integrate Snapshot, Agora, Lighthouse or any future entrant.

  • Open interfaces. We’ll open source the webhook specs and Namechain index formats so any client can consume or fork them.

  • Redundancy by design. Even today, ENS proposals can be drafted on Tally or directly in the Governor contract; nothing in our agreement changes that.

Put simply, ENS gains explicit SLAs without foreclosing choice.

How this differs from SPP-2 tooling grants

SPP-2’s $4.5 M allocation focuses on core protocol infrastructure (e.g., Namechain indexers) and broad ecosystem tooling. Our request funds delegate-facing UX and support layers that SPP2 doesn’t cover, specifically:

  • Day-zero surfacing of Namechain proposals, voting power, and history in the Tally UI
  • Wildcard/CCIP-Read name resolution across *.cb.id, *.fcast.id, etc.
  • A low-code action that lets proposers update ENS records from within a governance proposal
  • 24 / 7 on-call engineers and incident reporting tied to 99.9 % uptime guarantees

These user-experience pieces fall outside the scope (and staffing) of the existing Namechain indexer work.

On RFP process

We’re open to an RFP if delegates and stewards feel that is best practice, and we had the same approach to Compound before it ran an open tender. The trade-off is speed and continuity.

ENS delegates already cast ~70 % of on-chain votes through Tally, and many features in this proposal are in active development. If the DAO prefers a competitive bid, we will participate in good faith; the current proposal simply puts a fully-scoped, SLA-backed option on the table today.

We will also keep attending Meta-Gov calls and publishing quarterly road-map and analytics reports so progress is transparent.

In conclusion, this agreement does not “lock in” Tally; it codifies what ENS already relies on, while accelerating ENS-specific UX.

10

As promised:

  • I think that for the ENS DAO, any governance front end that we invest heavily in needs to index both onchain and offchain proposals. Agora does this. I’m not sure it would make a ton of sense for us to invest in a platform that only indexes 1/3 of our proposals. I’d want to see that work included in the deliverables. I don’t think we’ll need 60k worth of Enterprise Support, so perhaps there’s room for Tally to include our offchain proposals on their UI as an augmentation.

  • I’m curious what Tally would do if the Namechain rollout is delayed. I’d want to make sure the payments are milestone related, not time and materials, in case extraneous events limit Tally’s ability to deliver.

  • Based on previous experience, I’d prefer we start with only the first year’s commitment. If, for whatever reason, the DAO isn’t happy with the service, we should have the option to not renew for the second year.

  • It’s great to see providers request governance tokens to participate in the ENS DAO’s mission. Like all $ENS distributions we give out, we’d need to deliver it in a linear vesting contract. (The year’s tokens will vest across the year of service, with full voting power available to delegate on day 1).

11

Regarding Namechain support, we may be getting ahead of ourselves. I haven’t seen any serious discussions about migrating the DAO’s token and governor to Namechain. If those things don’t move (which I don’t think they should in the medium term, but this is a separate discussion), then this part of the proposal is unnecessary.

At a higher level: While I appreciate what Tally and others have done for ENS over the years, I don’t think the DAO should be spending >$100k/year on governance tooling.

3 Likes
12

We now have 2 project OpenBox (OpenBox itself didn’t apply to SPP but 3DNS did) and Tally who are proposing dedicated funding after losing the SPP. Given OpenBox is heading towards proceeding, does the DAO actually have a capacity to fund two extra projects this year without sacrificing long term sustainability?

Namehash was funded by SPP to index all ENS names using their https://www.ensnode.io/ project. Tally and Namehash should work together to make use of ENS node API to minimize their workload, rather than building custom solution from ground up.

As @gregskril mentioned, Namechain isn’t launching till the later this year or next year. It probably makes more sense to include the aspect into discussion if Tally’s proposal is considered for the next year, but not this year.

Like many people noted, I appreciate Tally has contributed to ENS ecosystem. I just would like to express concern against projects start submitting own funding request after losing SPP which looks to me defeating the purpose of SPP itself.

1 Like
13

Hi folks, this is Guillem from Snapshot Labs. We’ve been following the thread with interest and appreciate the thought Tally, Lighthouse, stewards and delegates have already put in.

In the spirit of moving forward this discussion, we’d like to:

  • Clarify the record on where ENS votes (both offchain and onchain) happen
  • Explain why an open RFP best serves the DAO
  • Highlight Snapshot’s capabilities and cost-effectiveness compared to Tally’s quote
  • Propose a clear, delegate-driven path to pick the right provider

1. Clarifying the record on usage

Tally’s claim that “70% of all token-weighted votes in the DAO are cast through Tally” can be misleading as it only accounts for onchain votes and excludes Snapshot votes. Including these, it becomes clear that Snapshot have consistently served as a primary platform for ENS governance:

Year Snapshot votes Governor votes Snapshot share
2021 92,868 0 100 %
2022 16,044 1,980 89 %
2023 12,197 2,211 85 %
2024 3,045 1,564 66 %
2025-YTD 959 939 51 %

Source: Snapshot Hub & Governor subgraph public data

2. Why an open RFP makes sense

With that context, we believe ENS DAO deserves more choices, and thus the logical next step in our opinion is an open Request for Proposals process. This would:

  • Level the playing field: an RFP lets delegates express the features they actually value (on-chain, off-chain, Namechain, webhooks, SLAs) and compare bids apples-to-apples.
  • Provide a market check: competitive bidding is the simplest way to ensure ENS is not overpaying.

3. Snapshot’s indicative bid

Our proposal, if an RFP is issued, would be roughly structured as follows:

  • Governor integration: create, vote, queue and execute Governor proposals from Snapshot.
  • Unified interface: Governor and Snapshot proposals, along with Discourse discussions, accessible from a single organization view, removing context-switching.
  • Unified indexing / API: onchain and offchain data live in the same open API, so dashboards, bots and researchers can pull from a single source.
  • ENS integration: Snapshot has always supported ENS resolving. We’d also be ready to support Namechain when it rolls out.
  • Notifications: Zapier integration, email, Discord, Slack or webhook pings for proposal milestones or security events.
  • Gasless voting: out-of-the-box via our open-source relayers
  • Reliability: 24h support, on-call engineers, 99.9 % uptime SLA.
  • Fully open-source: all our code is open source with MIT-licensed and self-hostable, with zero lock-in ever.
  • Price efficient: US $80k for year 1 integration and support, then US $6k per year. Token component is an option.

4. A simple path forward

If it’s helpful, here’s one straightforward path we’d propose:

  1. MetaGov posts a formal RFP listing desired features, KPIs, pricing format, milestone schedule, and vesting terms.
  2. Snapshot, Tally, Lighthouse, Agora or any qualified team submit bids under identical terms.
  3. MetaGov compiles the bids into a Snapshot proposal and delegates vote on the winner.
  4. If necessary, an onchain vote can ratify the chosen provider.

We hope these ideas are useful and, whatever route the DAO chooses, Snapshot will keep supporting ENS governance. Thanks for taking the time to read!

2 Likes