[RFC] Aligning Governance and Developer Incentives on Namechain

DAO-Wide General Discussion
1

Rewarding verified, ENS-aligned voters

Namechain will launch as a based rollup with ETH gas for low-cost, scalable ENS activity (unless final implementation diverges from the Linea stack defaults). Let’s align governance with developer incentives by subsidizing gas for verified, ENS-aligned voters — for example, delegates who set a delegate record and pass proof-of-human checks via Dentity, World ID, or similar.

Issued as ENS-bound wrapped ETH, these credits would offset gas for deploying contracts, registering names, publishing ENS metadata, and other developer activity — subsidizing the ENS economy and fueling new services.

Why reward verified, ENS-aligned voters?

Because attracting and engaging the broader developer community is essential for ENS’s security and growth. By rewarding verified voters, we encourage wide voter turnout from builders, thereby raising the cost of capture, and ensuring governance participation comes from those committed to ENS’s long-term mission: names, everywhere.

Flywheel: voter participation → gas credits → lowers developer costs → increases ENS activity/fees → feeds reward pools

Mechanisms available for use today, albeit limited:

  • Wrapped-ETH rebates via a rewards contract
  • Sponsored transactions via a paymaster

Because ETH is native on Namechain, these mechanism are possible now—but treasury-funded reward pools are cyclical and often tied to a single activity (registrations fees).

Nested hypothetical mechanism: Sequencer fee recycling

By contrast, if Namechain falls back to using its own sequencer (because based rollups prove too slow or expensive), fees captured from every transaction could be recycled into reward pools, mapping subsidies to the entire L2 economy (subname updates, metadata writes, dapp transactions, etc).

While exotic, sequencer fee recycling ties aligned governance participation directly to developer incentives, allowing rewards to scale proportionally with usage—the same flywheel, but broader and more resilient.

3 Likes
2

Thanks for surfacing this idea!

If I understand this correctly, the credits fund activity that generates fees, which are then used to fund additional credits.

I wonder if, instead of rewarding votes with developer subsidies, flip it: subsidize developers directly based on ecosystem contributions, with governance participation as one criterion among several. It feels like this approach would achieve the same alignment.

1 Like
3

The goal of moving to an L2 is to reduce gas fees to a fraction of what they are today. If costs are as low as we hope them to be, is a further discount going to be particularly compelling to users?

4

I’m not 100% clear on the new governance implementation for L2, but sponsoring gas (especially via something like Paymaster) would be useful in the case that people aren’t actively holding funds on Namechain. It would avoid the multi-step bridge to vote inertia even if the cost is practically zero. However, you could also argue that an aligned user might want to leave even a dollar there for processing votes.

1 Like
5

You’re right that offering gas subsidies on Namechain isn’t a meaningful builder incentive, since fees will be trivial. I had overlooked that, but the spirit of the design still has merit.

It’s worth exploring this further in the context of rewarding verified, ENS-aligned participants — perhaps through a “voters-as-builders” or “verified builders” pilot.

How can we structure alignment between voters, builders, and the protocol itself? Let’s naively scope what it means to become a “verified, ENS-aligned delegate” and how a rewards system could work.

Scope: "Aligned Identity

Baseline criteria for a verified, ENS-aligned delegate :

  1. Delegate record set (onchain, self-selected identity).
  2. PoH (e.g., Dentity or World ID).

For simplicity, assume these two conditions define an Aligned Identity the DAO can track whenever someone participates in governance.

We could design a Watcher that monitors governance activity and batches verified participants:

#  alignment watcher (pseudocode)

def is_verified_delegate(address):
    return has_delegate_record(address) and is_poh_verified(address)

def track_aligned_voters(proposal_id):
    aligned_voters = []
    for voter in get_voters(proposal_id):
        if is_verified_delegate(voter):
            aligned_voters.append(voter)
    return aligned_voters

This renders a per-proposal list of “aligned and verified” participants.

Rewards distribution logic

Rather than gas subsidies, distribute wENS: an internal, redeemable unit (think “ENS miles”), earned for aligned participation and developer actions.

# wENS distribution (pseudocode)

def distribute_wens(aligned_voters, reward_pool_ens):
    per_voter = reward_pool_ens / max(1, len(aligned_voters))
    for voter in aligned_voters:
        mint_wens(voter, per_voter)
  • where reward_pool_ens is funded by treasury allocations or recycled protocol revenue.
  • wENS is a non-transferable ERC-5192 until redemption, to signal verified alignment rather than invite farming.

Hypothetical Mechanism: Sequencer fee recycling

If the DAO later captures revenue from sequencer fees, recycle it into ENS buybacks to back new wENS issuance—an options-style rewards program for aligned contributors.

# loop for ENS buybacks and wENS issuance

def reflexive_buyback():
    revenue = get_protocol_revenue()                 
    ens_bought = buy_ens_on_open_market(revenue)     
    mint_wens_backed_by(ens_bought)            
    log_event("reflexive_cycle_complete", ens_bought)
  • where revenue captures DAO or sequencer fees
  • where ens_bought applies soft buy pressure
  • where mint_wens_backed_by(ens_bought) issues wENS to verified participants

This lets ENS function as its own internal economy, where verified builders (voters are builders) earn redeemable claims (wENS) on the protocol’s long-term value.

1 Like
6

Okay, I’ve read your post. This highlights one of the biggest problems facing DAOs today: the lack of incentives for governance participation.

The main issue is evaluating which participants are genuine contributors and which are bots (or, as you said, ENS-aligned vs. not). If you simply incentivize all voters, it may attract bot-like activity, though I’m not entirely sure that would happen. Your PoH approach doesn’t fully prevent human-operated bots either, and I’m not sure that kind of verification is even necessary.

Since it’s nearly impossible with today’s technology to objectively evaluate which delegates are truly valuable to the protocol, I think the best proxy is their own stake. Delegates with a significant personal stake are more likely to be genuinely aligned with the protocol. Based on that assumption, both these ENS-aligned delegates and their delegators could receive incentives reserved in the DAO Treasury for governance participation.

Even a small percentage of protocol yield could be enough to attract more token-holders to vote or delegate. Currently, only about 3% of the circulating ENS supply participates in governance — this approach could easily increase that to 10–15% in the near term, and potentially 30% over time. It’s similar to how Ethereum directs its revenue to validators, and they have %30 of circ. supply at stake.

Another complementary solution is education and awareness. Even without incentives, tokenholders should understand that delegating their tokens supports the protocol’s sustainability and security. Centralized and temporary solutions like security councils don’t align with the principles of any truly decentralized DAO.

7

True — which is why I advocated for that hypothetical mechanism I mentioned above. However, since ENSv2 is pursuing a pursuing a based rollup architecture, there won’t be sequencers that you can stake with or operate independently in order to enable this.

I think there should be a way for dedicated builders to capture upside through securing the protocol, however. It’s something that I’ve begun to explore with others in this discussion re: ENS Research: Namechain, ENSIP-19 & Multichain Interop - #5 by estmcmxci

—

Another idea: we can borrow a framework that already works — the validator set. Validators stake and perform duties each epoch to earn rewards from the protocol.

In this model, delegates are like validators, but they validate proposals instead of blocks. To make this possible, we’d introduce two new voting primitives: (1) a Delegate Registry and (2) a Governor Escrow.

By bonding governance tokens into the Governor contract, delegates become Secured Delegates, performing defined duties each epoch (reviewing, endorsing, and voting on proposals) to help secure the protocol.

The Governor rewards active delegates from this registry from an ENS pool, while inactivity or misconduct triggers penalties, leaks, or slashing.

1 Like