[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!