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

@SpikeWatanabe.eth, thanks for taking the time to look at this temp check, I’m here to listen to opinions!

I’m sorry to hear that you feel I’m attempting to bend the rules solely for monetary gain, I’d hoped that I’d been able to convey that this is not about changing the spirit of the rules, but about trying to apply them as I believe they were intended, specifically: rewarding active users.

I’ve made no secret of the fact that I stand to gain from this, but I’m not sure that it is fair to say that this is a single person demand, as there are ~10k accounts in a similar position to me, and I have seen a number of others in the discord and on twitter who have vocalised as much.

Personally I don’t think the rules are that easy to interpret - I was certainly under the impression that I had met the criteria for the 2x multiplier until I saw that I wasn’t. Additionally, @nick.eth has explained how it would be able to amend the query to cover the cases where the reverse record was set on another account; by their nature, these deterministic queries are neither ambiguous nor uncertain, so I don’t feel that any uncertainty or ambiguity would be introduced.

If this is not something that @nick.eth has the time to handle, I would be happy to learn how to use BigQuery and propose changes to meet the spec laid out in his second response in this thread. This will definitely take me longer than nick, but if there’s a large concern about the amount of nick’s time this would take I’ll happily mitigate that one myself.

P.S. the OP is now out of date - I will amend it now to remove the “application” process, and just suggest amending the query.

EDIT: I can’t edit the OP anymore…!


Updated proposal (high level)

  • The ENS airdrop assigned a 2x multiplier to accounts that had interacted with the reverse registrar, as an attempt to identify and reward more active users.

  • The BigData query did not consdier the case where a user would point a name owned by one account at another, then set the reverse record from that other account back to the one that owns the name. This user is just as “active” as the others, but would not receive the multiplier for that name.

  • We propose retrospectively amending the query to include accounts that held a name pointing to an account that had that name set as the reverse record during the ownership.

  • Impact:

    • Fairer allocation of ENS tokens to active users (previously missed “active” status for between 3.5k and 11.5k accounts would now be recognised)
    • Between 570k and 1.8m additional tokens airdropped (this would be calculated exactly before voting on the proposal)

Okay, so I have some authoritative answers. The totals are:

  • 213,049 tokens
  • 1,969 accounts

These are lower even than my lower bound - it would appear even that query was overbroad. It’s possible my new query is too narrow, but I believe it’s accurate; it does complete forward- and reverse- resolution, by time range, and includes any address that at some point owned a name that at that time had a reverse record set correctly.

I’ve hand-checked a few cases at random and they definitely all qualify, but of course there could be rows that should be there but aren’t.

Here’s the list:


I would be in favor of this proposal.

The ENS airdrop was the most widely and fairly distributed, and keeping along with the term of “fair,” this correction would make it even more fair and honorable.

It was a legitimate oversight / edge case, and I can think of nobody getting harmed from it.

I think it would be prudent to separate @greypixel’s potential gain here from the actual issue that he brought to light. If I brought this issue to light, would you feel differently even though I have nothing to gain from this proposal? Greypixel is 1 of ~2,000 accounts that would benefit from this.

There’s also a huuuge difference between someone wanting to add a new qualification for receiving tokens, versus fixing a bug for people who should have received tokens.


I support this proposal as long as we have done enough validation for the list of accounts. I suggest that we use this incidence as an opportunity to exercise our delegate voting mechanism. Let us together demonstrate how our DAO could correct mistakes starting with small ones.


Hey @spencecoin I can certainly understand “separate” argument here, what I’m saying is that there is this whole system in place which works towards building ENS protocol for a very large number of people. Airdrop itself as seen as mechanism, which kickstarted ENS DAO itself. But its not just airdrop, it is the very first example of public policy generated and maintained by ENS.


Whenever any policy is applied it is uncontested general rule that it should be applied universally to every agent in the system. Lets say we are talking about monetary policy and central bank adjusting interest rate, they are building this policy to improve well being for everyone within the system. There certainly would be a number of cases where agent (firm or individual) would argue that rules should be not applied to them because 123. They would say interest rate for them should be cheaper, to alleviate burden of fixed income payments and so on. Would that be prudent to surgically exclude them from nation-wide policy? I don’t think so. In such scenario everyone in economy suffers from increased ambiguity and decreased transparency. This is very high level overview of situation which is enough for me personally to block this proposal. Greatest good for the greatest number.

But let’s stretch this logic from higher level of abstraction to lower, just to be consistent.


Lets imagine for a second that ENS DAO decided to give this case a serious consideration what would be the cost benefit formula here?

COST = [additional work which needs to be done by ENS dev to implement] +

[increased strain on support on discord, people would flow in demanding to reconsider airdrop ***] +

[increased uncertainly and ambiguity for 100% of current users in the system who are one way or the other exposed to ENS token (directly via airdrop or indirectly via market)] +

[this added ambiguity will stretch far into the future for a very long time, because people will be continuously chasing this precedent]

*** I did this exercise hands on myself, figuring out many cases in support channel re airdrop mechanics, I can tell you from experience that approving this proposition would open endless line of people exercising additional strain on support

BENEFIT = Right now the only person who stands to benefit from this is @greypixel , I can see that @nick.eth made a tweet calling out to the community asking who else thinks was affected by this and I totally support that, I would like to see how many people would turn up who would think they are affected by this situation

In my mind COST is greater than BENEFIT by a magnitude of several orders.

No matter how I look at it, I just don’t see how this should be approved, provided that Delegate is voting in the spirit of “Greatest good for the greatest number” principle.


Hey Spike! Thanks a lot for such a detailed answer.

It’s not only @greypixel who will benefit from this. It’s also people like Ben:

And as you can see from Nick’s list it’s quite a few people affected.

I would support this proposal. The reason is simple. Not counting these addresses was a mistake and doing this corrects this mistake.

Disclaimer: I also use a different account to manage my ENS name. Unfortunately for me my account set other records before the snapshot and the reverse one after the snapshot so I am not in the list and as such will not personally benefit from this.


You are the Delegate with considerable voting power, so obviously you what you do

My only question here is, when you approve this, is that in the interest of “Greatest number” ENS users?


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