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:
- Forward compatibility with @blockful’s upcoming Treasury Flow Automation proposal
- User Experience, and
- 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.