Update: Following up after spending time with the ENSv2 contracts — the epoch-push model I outlined in March was built on ENSv1 revenue mechanics that v2 doesn’t share.
The ERC-4337 paymaster path I’d ranked out is now the most natural fit — because of how HCAs are wired into the v2 registrar.
Below: why this makes the paymaster path feasible, its trust model, and open design questions.
1. V2 Changes
ENSv2 collects payment as ERC-20 sent straight to an immutable BENEFICIARY on every registration and renewal:
SafeERC20.safeTransferFrom(paymentToken, _msgSender(), BENEFICIARY, base + premium)
There’s no withdrawal step. The epoch-push design I previously advocated for depended on one — it’s where RevenueSplitter was supposed to attach.
Without the withdrawal step, that approach is rendered null.
The v2 registrar contracts are deliberately payment-agnostic; they expose a clean ERC-20 entry point and leave the gas story to the integration layer. That’s where the subsidy mechanism has to exist.
2. HCAs make paymasters feasible
We had previously crossed out the paymaster path because it appeared to require end-users to hold ERC-4337-enabled smart-account wallets, while most ENS users transact from EOAs.
After learning about HCAs, I realized that conclusion was wrong.
Hidden Contract Accounts (HCAs) are an attribution primitive. ETHRegistrar inherits HCAEquivalence, takes the HCA factory as a constructor arg, and resolves _msgSender() through it.
This means that when a user registers or renews through a proxy, the v2 registrar pulls the ERC-20 registration fee from the resolved owner EOA — its balance and approval — not from the proxy.
The proxy is only the EVM-level transaction submitter.
This unblocks the paymaster path. An EOA user can have their tx submitted via an ERC-4337 flow with a paymaster sponsoring gas, and because _msgSender() resolves to their EOA, they stay the payer of record — without having to pre-fund the proxy or migrate to a smart account.
One nuance: HCA isn’t necessarily the only path in. EIP-7702 lets a plain EOA temporarily delegate to smart-account code and submit a UserOp itself.
So there is likely a complementary path for both HCA and 7702, where HCA covers users already behind real proxies (Safes, AAs, multisigs, etc.), and 7702 covers plain EOAs directly.
Looking further, the contracts-v2 repo includes a full ERC-4337 CI harness that exercises v2 registration flows — though it’s stale, a July 2025 proof-of-concept that hasn’t been substantively revised since.
What remains is wiring the production HCA factory into the deploy scripts — it’s a mock placeholder there today (MockHCAFactoryBasic). And there’s no production paymaster yet either, only the mock in the CI harness.
3. Trust model for the paymaster path
With an on-chain-rule paymaster — eligibility encoded in the contract, owned by the DAO timelock, not a verifying paymaster with an off-chain signer — the trust surface looks something like this:
- Liveness dependency — keeping the paymaster’s deposit at the EntryPoint funded
- DAO governance — the DAO owns the paymaster’s params and upgrades
- Rhinestone HCA Factory — external contract under separate audit scope; trusted for correct proxy → owner resolution
- EntryPoint — the canonical, audited ERC-4337 singleton
- Bundlers — can censor (decline to include a UserOp), but cannot steal or forge
A note on where the sponsored-gas direction comes from. The CI harness above uses a verifying paymaster mock — and “verifying” bundles two separate things:
- What’s paid — it sponsors gas rather than charging the end-user in tokens. That’s the sponsored-gas direction we’re advocating for here. Given the harness’s vintage, I’d treat this as a weak signal rather than a settled one — but it’s at least the pattern ENS reached for when they scoped it.
- How eligibility is decided — via an off-chain signature. The mock is sig-based because that’s the simplest thing to stand up in CI; it doesn’t settle the production eligibility model — which is why the trust surface above deliberately assumes on-chain-rule instead.
4. What the mechanism would look like
A paymaster contract, owned by the DAO timelock, encodes which transactions it sponsors — commit, register, renew on the v2 ETHRegistrar — plus a per-address cap (covered below).
Because registration is commit-then-reveal with a ~60s minimum commitment age, a sponsored registration is two UserOps, not one. The full flow:
- UserOp 1 —
approve + commit. The user approves the ETHRegistrar to pull the ERC-20 fee from their EOA and submits the commitment, batched into a single UserOp via an HCA proxy. Because of HCA resolution, the registrar treats the user’s EOA — not the proxy — as payer of record.
- The paymaster checks its on-chain rule and sponsors the gas; the EntryPoint settles.
- Wait out the ~60s minimum commitment age.
- UserOp 2 — register. Submitted the same way: the registrar pulls the ERC-20 fee from the user’s EOA, the paymaster sponsors the gas again, the EntryPoint settles.
Net result: the user pays the name’s ERC-20 price and nothing else — across two transactions they otherwise never have to think about. Collapsing it to a single signature requires a smart account with session/intent support to auto-fire UserOp 2 after the delay (see open questions).
5. Costs
According to ENS Blog:
“If we subsidized every single ENS transaction that occurred in 2025, we’d spend roughly $10,000 at current gas prices. Even at the highest gas prices we’ve observed post-Fusaka, that number only rises to around $250,000.”
Earlier, I assumed that the subsidy contract should partition a structural proportion of protocol revenue — an assumption that stemmed from ENSv1-era gas costs.
At ~$10k/year for full coverage at current gas — and ~$250k even at peak post-Fusaka prices — this becomes a trivial budget line either way.
This changes two things:
- Funding — the paymaster’s deposit at the EntryPoint can be topped up permissionlessly — anyone can fund it. Only the sponsorship rules and withdrawal authority remain with the DAO timelock.
- User caps — nick.eth’s concern wasn’t the subsidy’s budget, it was implementation. He warned the obvious “10% of registration fees” cap adds significant accounting overhead to all transactions — not just subsidized ones. Because enforcing it onchain means the registrar must accumulate each user’s cumulative fees — taxing every register / renew, subsidized or not. A flat per-address-per-epoch cap avoids that: it lives entirely in the paymaster, so it only adds cost to sponsored transactions and never touches the base registrar path.
6. Open design questions
- What will the paymaster’s production eligibility model be? I’m advocating for an on-chain rule, per §3.
- What is the eligibility scope? Given the discussion thus far, I’m leaning towards
commit, register, renew, but perhaps we consider resolver writes as well.
- Cap design: leaning flat per-address-per-epoch to counter griefing. Fee-proportional seems unnecessary and costly, though it provides better sybil resistance.
- Does user participation in gas subsidies require routing through an HCA proxy, or are there plans to also integrate EIP-7702 to let plain EOAs participate directly?
- The two-UserOp commit-reveal flow needs something to fire the register op after the ~60s delay without a second user signature — a smart account with session-key or intent support. Does that capability come from the HCA proxy, an EIP-7702 delegation, or the wallet/app layer?
- Will the DAO periodically fund the EntryPoint deposit, and are top-ups automated via a keeper function or governance-triggered?
- Is there active work toward a production AA/paymaster setup?
—
Sharing this in the spirit of research and contribution to the ENS protocol. @nick.eth @mdt — would value your input here.
