[EP2] [Executable] Retrospective airdrop for accounts that owned another account's primary ENS name

Status: Queued for execution - executes at 2022-01-14 20:11:25 UTC


Send 213,049 ENS tokens to a new airdrop contract for users who did not receive the 2x multiplier despite owning a name that was used as a primary ENS name.


One of the criteria used for the ENS airdrop was whether the account had a primary ENS name set. Those accounts that did got a 2x multiplier on their airdrop amount. The intention was to use this as a measure of involvement in the ENS ecosystem; those accounts that set primary ENS names are typically using their names in supported applications, while those that don’t are less likely to be doing so.

The way this was implemented was to award the multiplier to all accounts that had interacted with the reverse registrar. This had the unintended side effect that if a user owned an ENS name on account A, and configured it to resolve to account B, which used it as its primary name, account A would get tokens, and account B would get the multiplier. As B doesn’t own any names, the multiplier has no effect and the end result is that some users got fewer tokens than they would have if they had used the same account for everything.

This proposal aims to correct this, by introducing a new criteria for determining who to award the multiplier to, and creating a new airdrop contract for all accounts that qualify for the new criteria but not the old one.

In plain english terms, the new criteria is that the account must have at some point in time owned a name that was used as the primary ENS name for an account.

More formally, for each account a, the account is assigned the multiplier if there exists a name n and a time before 2021-11-01 00:00:00 UTC, where all of the following are true:

  1. a is the registrant of n.
  2. n has a resolver, r, set on the ENS registry.
  3. r has an addr record, a', set for n, and has emitted an AddrChanged event to record this fact.
  4. The reverse record for a' has a resolver, r', set on the ENS registry.
  5. r' has a name record, n', set for the reverse record of a. r' is either the default reverse resolver, or has emitted a NameChanged event for n' and a'.
  6. n == n'.

This logic is implemented by this series of BigQuery queries, and shows that 1,969 accounts meet these criteria but did not qualify for the multiplier under the original criteria. The sum of the tokens these accounts would be entitled to comes to ~213,049 ENS tokens.

A list of affected accounts and balances is here.

This proposal, if executed, will transfer 213,049 ENS tokens to a new merkle airdrop contract allowing affected users to claim them.


  1. Request that True Names Limited write and deploy a contract that allows claiming of tokens via Merkle Proofs using the same methodology as was used for the airdrop.
  2. Request that True Names Limited make changes to the claim.ens.domains site to support claiming this additional airdrop for qualifying accounts.
  3. Authorise the contract deployed in (1) to spend 213049736662531485206636 base ENS tokens from the ENS DAO account.


const ethers = require('ethers');
const abi = [
  'function approve(address _spender, uint256 _value) public returns (bool success)'
const token = new ethers.Contract('0xC18360217D8F7Ab5e7c516566761Ea12Ce7F9D72', abi);
const airdropAddress = 'TBD';
const tx = await token.populateTransaction.approve(airdropAddress, '213049736662531485206636');

With thanks to @greypixel for raising the original issue and creating the temp check.


Happy to be the first vote!


This is the first draft I have participated in the discussion and it is a great honor. Regardless of the outcome, thanks to @greypixel for asking the questions, to everyone involved in the discussion, and to @nick.eth for moving the project forward.

we are frENS~


Retro rewards for the users who were meant to be rewarded for involvement but missed out due to a technicality, feels like the right thing to do


Agree with this, seems like some well intentioned users could have been missed.


Even though I’m not a delegate, I too support this.

1 Like

I support this. This is well intentioned, well written, and clearly defined. It is retroactive and seems unlikely anyone predicted and abused this.


Voted. Got a question. Since there is already a forum post to discuss this, why make another forum post, this time a poll, instead of going directly to snapshot?

Just curious. No criticism.

Also have we created somewhere perhaps a set of guidelines of what the lifetime of a discussion proposal should be? Example: Forum post discussion at least 7 days → If clean signal open snapshot → if passed make on-chain proposal to execute etc.

1 Like

The previous post was a “temp check” - an optional first step to see what people think of an idea before proceeding to a formal proposal. This one is a draft proposal - an opportunity for participants to provide feedback on an actual proposal before it goes to a formal vote.

We’re still experimenting with polls and how useful they are; I figure it is useful to attach one to either the temp check, the draft proposal, or both, to get an indication of whether it’s worth proceeding to the next step.

We have some docs on the governance process, though they could probably use expanding and clarifying.


I support this and would use the votes delegated to me to vote in favor of it it was put to a vote


Metaphor.xyz supports this too (I can’t vote on the poll, seems I lost my Delegate tag)


I’ve edited the proposal slightly to specify that the proposal is asking True Names to write and deploy infrastructure to facilitate this. Unless there are objections, I’m going to advance this to a Snapshot vote.

Edit: I’ll do this tomorrow at around this time, so people who don’t live in the future like those of us in NZ have a chance to see this and respond on a weekday.


I’m in support of this


This is now live on Snapshot!

1 Like

I support this even i am not delegate


Voted yes in support

1 Like

Also voted yes.

Just curious, True Names I’m assuming hasn’t started any infrastructure work on this, so if this passes we should then expect some time for them to complete their work before the on-chain proposal is created, is that right?


We will support this proposal. Just a question: are there some black hole addresses on the receiver list?

I am in favor, as it is in-line with the spirit of the airdrop

1 Like

I’ve written the airdrop contract (see my post in the dev category for details). Once it’s ready, it can be deployed as soon as the distribution is locked in.

My expectation would be that if this proposal passes, we put up the “accidentally sent funds” amendment for a snapshot vote, and then we can set the final amount, deploy the contract, and start the onchain vote straight afterwards.

No, only accounts that were in the original airdrop are on the list.