Retrospective 2x airdrop multiplier application process for "unfortunate edge cases"

It’s in the interest of the ENS DAO since it upholds our principles. These addresses should have received the 2x bonus according to the rules as stated by the allocation blog post. Not getting it was a mistake done by the team during calculation.

Correcting such a mistake and being just and good is the right play here. It’s through actions like these that the character of the ENS DAO will be defined.

I get where you are coming from. Keeping more tokens for the DAO treasury and not giving out to pepole who will probably dump it may make the most financial sense for the DAO. But money and token value is not everything.

In fact I would argue that in a world of abundance and with a treasury as strong as ENS’s being moral, just and good and setting a good example is of far greater value than of having more tokens in the treasury.


I get where you are coming from. Keeping more tokens for the DAO treasury and not giving out to pepole who will probably dump it may make the most financial sense for the DAO. But money and token value is not everything.


@lefterisjp I don’t recall ever saying anything about treasury, or market price, or dump … or anything of the sort, can you link please?

1 Like

This is the assumption I made as this is the only view I can see why one would not support this proposal. Perhaps I misunderstood in which case I apologize.

what I’m saying is this:

lets say we had 2 systems, one is with little amount of uncertainty and the other with considerable amount of uncertainty, any rational agent at any time will be choosing system with less uncertainty, thats just common sense, people dislike uncertainty

if the rules of the game are changing fairly frequently = that is extra uncertainty

In my mind it is pretty much required from ENS to be as stable as rock to be “global public good naming protocol”, as such introducing constant policy changes directly contradicts mission statement

Voting “yes” on this is like approving more uncertainty as the very first DAO proposal that in turn sets a potentially dangerous signal to general public

Same principle applies for example to changes introduced to .eth names annual fee mechanism

I think that reasoning is enough for me personally to reject this proposal, on top of that for community as a whole sum of COSTs and BENEFITs of approving this clearly is NEGATIVE (as I argued here Retrospective 2x airdrop multiplier application process for "unfortunate edge cases" - #18 by SpikeWatanabe.eth)

I personally just don’t see how this can be approved, its not even a borderline case in my opinion


But the rules of the game did not change. The rules are exactly the same. A new clause was not added in the allocation blog post. This proposal is to fix a mistake at the application of those rules. Some users were unjustly, due to a team’s mistake, denied the 2x bonus.


Look, its not an argument, I think that my point is fairly clear, you do what you do, vote yes if you will, this is why we have system of Delegates in place, I just shared my opinion


We shouldn’t change the rules that are in effect, it’s not fair to others, but we should never make corrections to things that are done wrong, either.

1 Like

I support this proposal.


I think this is a typo, right? Just checking.

Where I basically land on this is that because 1) we are talking about an error/limitation in the stated objectives of the airdrop, and 2) because the total amount involved is small and thus there isn’t a big “bait and switch” thing going on for other token holders and buyers, I think this is a great example of something we can and should fix. As a delegate I’ve promised specifically to protect and improve the legitimacy of the ENS system, while maintaining as much credible neutrality as possible. Given that the goal of the $ENS airdrop is to decentralize governance (not to financially reward ENS users) I think that fixing this makes the distribution “more flat” and that the non-inclusion of these addresses was essentially an unnoticed error. We’re not talking about a single individual looking for special treatment here but muliple people who are all affected relatively evenly. To me it looks like these accounts are covered by the stated intent of the airdrop but just got missed because of a technical issue.

Unless there are specific moral hazards involved or things of that nature that I can’t think of right now and which will be raised later, I support this proposal.

(Btw, as far as I know, I am not affected by this, but people who have delegated to me specifically say that they are)


I’ve been lurking here in waiting and considering my position, and I think I have to agree with yours. The purpose of the airdrop as I understand it was to reward early, actively interested users. For that reason I would propose that edge cases such as the ones brought up here be handled on as small of a level as possible. Those that make the effort to explain and propose their valid case definitely seem like the intended type of user for the airdrop.

That being said, all my hesitance has been for two main reasons:

  1. The “slippery slope” perception (essentially “give them an inch and they expect a mile”)
  2. On the other end of the spectrum I have concerns about the actual logistics or how such edge cases should be handled. It shouldn’t be impossible but also shouldn’t be any more bureaucratic than necessary.

TDLR: I support this with hesitancy considering how it would happen, and the precedent it might set if not handled very carefully. That said, I see no misalignment of intentions or reason why edge cases shouldn’t at least have a process to petition their case.


Just to push back on this a little - I don’t think that’s an entirely fair characterisation.

The criteria as actually implemented for the airdrop when considering an account for the multiplier was “has a primary ENS name set”. The criteria here is “owns a name that is used as a primary ENS name”.

I don’t think either criteria is a mistake - and if we’d gone for the latter criteria from the start it would have missed out people who got the multiplier with the first criteria.

I think either definition is defensible. Personally I think these accounts should get the multiplier because at a minimum they meet the spirit of the rules.


I think what they may have been describing is the precedent it would set. Allowing for retroactive exceptions unfortunately opens the door to a whole spectrum of allegations, be it preferential treatment or just general loss of credibility. It is easy to imagine the domino effects. The most concerning in my opinion is once you make one exception, you are then expected to defend and reinforce that decision against anyone else’s claim that is even tangentially related. It’s a tricky balance.

1 Like

Maybe. But “we should never make corrections” is a pretty extreme position to take, so I was thinking they may have misstyped something.


Yeah I completely agree, just giving them the benefit of the doubt.

1 Like

I align with @greypixel @lefterisjp @Jeff.eth regarding this situation. I believe it makes sense to include such an edge case, especially considering the minimal amount of addresses affected, the intent of the airdrop in terms of active users with a reverse address set, and that in some cases it was a result of attempting greater security which shouldn’t realistically disqualify active users. I don’t believe this introduces any additional ambiguity, but actually reduces ambiguity of what an “active user” is, given that it shouldn’t matter where the reverse address is set to, but as long a reverse address was set for a name owned by an address.


Agree with this summary.

1 Like

Thank you everyone for all of your feedback to date - I have to say this has been a good “first proposal” experience from my perspective with an encouraging level of engagement and discussion - I think it’s a great sign for the new shape of ENS.

Just to be clear, this initially started as a temperature check for a kind of ‘appeals’ process for specific cases that were missed.

After @nick.eth 's investigations, I think the better proposal to pass is specifically an amendment the query used to apply the activity multiplier as discussed in detail above. This is less ambiguous, and in my opinion should at least partially mitigate concerns expressed by @SpikeWatanabe.eth about an overwhelming number of people asking for further changes.

Is there anyone who prefers keeping the broader scope of defining an appeals process? @daylon.eth - I got the impression you might from one of your comments?

I will let this simmer and listen for a little longer, (and get up to date with any discussions about it on discord) then proceed to writing a draft proposal over the next couple of days incorporating feedback.


That sounds good to me. For a draft proposal, it would probably make sense to combine this with the people affected by accidental transfers back to the token contract in a single airdrop.


@broccolirob.eth - personally don’t have enough knowledge of the contracts involved to properly understand your situation, @nick.eth - did you have any thoughts?

Sorry, I missed this the first time around. Thank you for the detailed analysis!

I’ve seen the issue with people who didn’t finalise their domains, and thus didn’t receive tokens until the migration (in my mind, working as intended, since that’s a strong signal they weren’t using ENS). This is the first I’ve seen where the name was in use but never finalised, and I didn’t realise that edge case existed in the original contract.

Calculating this correctly is extremely difficult, because the original registrar contract doesn’t emit ownership transfer events; only the individual Deed contract does. And the registrar contract doesn’t emit any events with the address of the Deed contract, either. So figuring out the exact ownership history on the original registrar requires first of all recreating the auction logic - to determine the owner of the name without a finalise event - and also using either an archive node or complete execution traces (BigQuery has these) to determine the exact ownership history on the original registrar.

While this is far from impossible, it’d be a lengthy process and prone to error. If the will is there to do it I will try and find time to write the queries, but I’d want someone else who knows BigQuery and ENS well to double check my results.