[RFC] Introducing a Subsidy Contract

[estmcmxci]

Previously, I had discussed the idea of subsidizing gas costs for verified, ENS-aligned voters as a way to strengthen governance participation and create a flywheel between voter activity, developer incentives, and ENS ecosystem growth.

I’d like to pivot this conversation toward a broader and more infrastructure-oriented approach: exploring how .eth L1 gas subsidies could be funded directly from registration and renewal revenue, and structured as a universal public good for all .eth holders rather than a discretionary or participant-exclusive incentive.

—

Introduce a dedicated subsidy contract

Currently, the Registrar Controller collects funds from .eth registrations and renewals, and the DAO withdraws those funds into its treasury. I propose developing a dedicated subsidy contract that receives a percentage of revenue from the Registrar Controller and uses it to subsidize .eth-related gas costs.

How it works

Revenue split at the Registrar Controller

Modify the Registrar Controller so that, instead of routing 100% of proceeds to the treasury, it splits incoming funds by a configurable ratio (for example, 90/10) between the DAO treasury and the new subsidy contract.

This creates a sustainable, automatic funding source for gas subsidies rather than relying on ad-hoc DAO votes or periodic treasury grants.

Subsidy contract accumulation and reimbursement

The subsidy contract accumulates its share of revenue and is programmed to reimburse or sponsor eligible .eth transactions (to be defined in the proposal).

It can include:

• per-transaction reimbursement cap to protect against gas spikes.
• periodic budget cap that limits the total amount distributed within a given timeframe.

DAO governance and parameters

The subsidy contract would remain fully governed by the DAO, which could set or adjust parameters such as reimbursement caps, eligible actions, budget ratios, and emergency overrides.

This approach ties subsidies directly to ENS usage, improving long-term sustainability, while keeping all parameters transparent and adjustable by the DAO with clear on-chain records.

—

The Ask

This would naturally require careful design and comprehensive auditing, as it introduces new logic and potential attack surfaces. I’m seeking input on whether the benefits of implementing this contract outweigh the risks.

[nick.eth]

I’ve been thinking along similar lines. The obvious simple approach is to say that up to 10% of a user’s registration fees can be claimed back in subsidized transactions - but the main issue with this is accounting overhead; if we have to track an extra token balance for gas sponsorship, that adds significant overhead to all transactions; it may as much as double gas usage!

[Arnold]

I think blanket routing 10% could be a dangerous. Looking at Q4-25 registration rev. That’s a ~0.5M program per quarter which “feels” wasteful.

It’s important to consider what the nature of the subsidy is for. Is the DAO supporting new builders? First time ENS users? Users from marginalised countries? Students? NonProfits?

If so a 100% rebate in these clear cut cases feels more meaningful than a blanket 10% subsidy.

I would be in favour of a system where, with some smart onchain/offchain lookups, we could process some eligibility assertions and issue a rebate. This type of system would also scale cleanly as the program is refined and evolves.

It also pushes fwd innovation with respect to what can be stored on ENS and provably verified.

eg. I think if you were an EthGlobal builder who submitted a hack, you may have some on-chain proof which we could easily verify?

[nick.eth]

@Arnold

I think blanket routing 10% could be a dangerous. Looking at Q4-25 registration rev. That’s a ~0.5M program per quarter which “feels” wasteful.

It only costs as much as is actually spent on qualifying transaction gas costs. Some form of expiry would be needed to recover unused funds either way.

@Arnold

It’s important to consider what the nature of the subsidy is for. Is the DAO supporting new builders? First time ENS users? Users from marginalised countries? Students? NonProfits?

If so a 100% rebate in these clear cut cases feels more meaningful than a blanket 10% subsidy.

Given the cost savings of not running an L2, I’d like to spend a meaningful proportion of that on subsidizing all ENS transactions for users, up to a reasonable limit (such as 10% of that user’s registration fees).

[Arnold]

@nick.eth

subsidizing all ENS transactions for users

Would this include Text updates?

Personally I think that would be interesting. I’m all for encouraging users to put more data on ENS. Some quick and dirty analysis on what that roughly looks like historically.

[nick.eth]

@Arnold

Would this include Text updates?

I don’t see any reason to discriminate on what users do with their subsidized transactions, as long as they’re on ENS contracts!

[estmcmxci]

Circling back to this with a more concrete design. The OP left the accounting mechanism open-ended intentionally — the conversation surfaced why per-user credit balance tracking is a naive approach.

Regarding the accounting mechanism: we need a way to avoid the state-write problem entirely to eliminate overhead, and a way to require no user action for seamless, universal UX.

I propose a novel approach — a retroactive gas rebate via epoch push:

How it works

1. A publisher posts a Merkle root onchain by submitting a bond — anyone can do this. The computation is deterministic from public onchain event data, so any actor can independently verify or produce the correct root.
2. A 24–48h dispute window opens — anyone can verify and challenge
3. ETH is pushed automatically to eligible addresses

No claim step. No wallet requirement. Works for EOAs, smart accounts, multisigs — the vast majority of address types.

The only failure case is contracts that explicitly reject ETH (no receive(), or a receive() that reverts) — an edge case mostly limited to protocol treasuries and some proxy contracts.

Failed pushes don’t lose the rebate: it stays in the subsidy contract and is claimable directly by that address before the epoch expires. Push is the default; claim is the fallback.

The UX: you used ENS, ETH arrived in your wallet — contingent on a root being published each epoch. In practice this is a low-maintenance operation; the bond mechanism ensures anyone can step in.

The epoch delay is addressed by a real-time accrual dashboard — users see their pending rebate growing as they interact with ENS throughout the epoch. The delay becomes engagement, not friction.

—

Funding the subsidy contract

Originally, I’d intended to modify the Registrar Controller directly to split funds between the Treasury and the proposed Subsidy Contract. @Blockful’s Treasury Flow Automation (TFA) proposal changes that — and improves on it.

The epoch push rebate mechanism is downstream of TFA. Because TFA introduces the RegistrarManager as the single owner of all controllers — with a permissionless withdrawAll() that routes ETH to a DAO-configurable destination — we can insert a RevenueSplitter contract at that destination rather than touching the controllers at all.

The RevenueSplitter would be set as the RegistrarManager’s destination via a single setDestination() call, bundled into the same executable proposal that deploys both contracts.

Its properties:

• Receives ETH from RegistrarManager on withdrawAll()
• Splits by a DAO-configured ratio (e.g. 95/5) — set on deployment, adjustable by timelock
• Routes the majority to the Endowment (endowment.ensdao.eth)
• Routes the minority to the Subsidy Contract
• Zero changes required to blockful’s contracts
• Simple, auditable — ~50 lines of Solidity

—

Design Questions:

Building on Nick’s framing — rebates capped at 10% of a user’s registration fees, with expiry — the open design questions are around the mechanism itself.

1. Bond sizing and slashing: the publisher bond needs to exceed the maximum epoch rebate to make griefing unprofitable. What’s the right floor, and who captures a slashed bond — the challenger, or does it burn?
2. Dispute mechanism: “anyone can challenge” needs to be deterministic in practice. The standard pattern is: challenger submits a leaf, proof, and expected value that contradicts the root, and the contract verifies and slashes. Does this feel sufficient, or is there a simpler construction?
3. Batched push execution — if an epoch has thousands of eligible addresses, a single push transaction will exceed the block gas limit. Push execution would need to be batched across multiple transactions. Worth designing for from the start; at current gas levels the execution cost is negligible.

—

If this reasoning sounds right, I’ll follow up with a more detailed spec for community feedback on the design — and if there’s rough consensus, move to a Temp Check.

[estmcmxci]

Update: Following yesterday’s Meta-Governance Meeting, I committed to sharing my rationale for settling on the retroactive epoch push model.

In total, I evaluated four implementation paths against three criteria:

1. Forward compatibility with @blockful’s upcoming Treasury Flow Automation proposal
2. User Experience, and
3. Universality.

Below, I outline other paths I considered, and why the merkle proof path wins out, despite the engineering overhead:

Pull Model: off-chain accounting + onchain claim

This pattern computes eligibility off-chain, publishes a merkle root onchain, and lets users claim their rebate by submitting a proof.

It scores well on universality — EOAs, smart accounts, and any wallet type can participate — and adds zero per-tx overhead to normal ENS usage. The tradeoff is UX and participation rate. Users must know the rebate exists, actively initiate a claim transaction, and pay gas to do so.

ENS’s own 5.19 distribution shows what happens in practice: only 26 out of 98 eligible recipients (26%) claimed their tokens six months after distribution — and @danch.quixote noted that those who did were “exactly those who are close to the DAO and are aware of what is happening in it.”

In this case, the subsidy reaches the people who are already engaged, not the ones gas friction is actually costing.

ERC-4337 paymaster

This pattern covers gas in-transaction, and while the UX is seamless (no claim step necessary), it’s currently limited to users transacting via a 4337-enabled wallet. The restriction isn’t about how a name was registered — it’s about the wallet being used to interact with ENS today.

While we are trending towards transacting on such wallets, the majority of ENS users transact via EOA wallets — evidenced by the wallet options surfaced on app.ens.domains, where MetaMask, Ledger, Rainbow, and Browser Wallet (all EOA) represent the primary connection paths.

Requiring smart account adoption as a precondition defeats the purpose of a subsidy designed to reduce friction for all ENS users. It also introduces bundler and EntryPoint infrastructure dependencies, and requires smart account adoption to reach meaningful scale before the subsidy has any real impact.

Lazy accounting at claim time

This pattern keeps everything onchain and eliminates offchain computation entirely. No merkle root, no watcher, no centralization risk. Eligibility is computed directly from onchain state when the user initiates a claim. It’s the simplest of the four designs to reason and audit. However, the simplicity comes with a heavy tax to the user, computing the claim amount is compute-heavy compared to a merkle proof, which means the gas cost is much higher.

Paying gas to get a gas rebate is an oxymoron and kills the attractiveness of this approach.

—

One dimension the path descriptions above don’t fully expose is how trust and centralization risk vary across each:

Path	Trust Model	Centralization Risk
Off-chain claim	Trustless (verifiable from public data)	Low — liveness dependency on publisher, not correctness
ERC-4337 paymaster	Operational trust in paymaster operator	Moderate — operator controls funding and eligibility policy
Lazy accounting	Fully trustless (on-chain only)	Lowest — no off-chain actors
Epoch push (selected)	Trust-minimized via dispute window	Low — permissionless publisher model; bond makes incorrect roots economically irrational, dispute window provides recourse

The Epoch push is genuinely worth the engineering overhead when you take everything into consideration.

It’s the only path that scores on all three criteria — forward compatibility with TFA, UX, and universality. It asks nothing of users.

At the end of every epoch, ETH arrives in their wallet, and they’re happier for it.

—

Backtesting is the natural next step — will follow up with data, a detailed spec, and implementation design, though it’ll take some time to pull together.

If you’re curious and want to follow updates and/or contribute, I created a dedicated space to talk about this: join here.