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

greypixel · November 14, 2021, 10:28am

Gm all!

Wanted to put out a temperature check for a way for people who feel they were erroneously missed from the 2x multiplier intended for active ENS uses to request it.

Note that this is not an attempt to change the rules (or at least their intentions) for allocating the airdrop multiplier, but is instead intended to correctly apply them in cases where active user slipped through the net in the existing system.

The proposal would be based off the fact that the goal of the 2x multiplier was for rewarding active users by checking if they had a reverse record set: https://twitter.com/ensdomains/status/1455754484676710400

My case was missed, I believe because the reverse record I set up (significantly before the snapshot was taken) was pointing to a different account that I owned.

I discussed this with nick.eth on discord and he stated “that’s an unfortunate edge case that we didn’t handle well - sorry!”
An application would have to show that the reverse record was set in advance of the snapshot.

In my case: this transaction, containing the addressChanged event

Just a little bonus note - I definitely consider myself an active ENS user, and was in fact responsible for implementing reverse record lookups on AirSwap’s new DEX.

Anyone agree or opposed to this?

greypixel · November 14, 2021, 10:31am

I’m currently only allowed to have two links in a post, I’ll update with references to Nick’s comments in discord and my PR for ENS names to AirSwap.io as soon as I can!

nick.eth · November 14, 2021, 8:48pm

To give a bit of background here, the ENS airdrop was calculated on the following basis:

Generate a list of all addresses that have interacted with the reverse registrar
Generate a list of ‘ownership extents’ - tuples of name id, owner, start date, and end date - based on the registrant of a name.
For each account, aggregate the ownership extents to count the number of seconds the user was the registrant of at least one name. Use this to determine the airdrop for ‘past tokens’.
For each account, find the ownership extent whose end date is latest. Use this to determine the ‘future tokens’.
If the account is in the list from step 1, double both amounts.

As you can see, the edge case arises because everything is based on what the account owns - both reverse record and names - but some people have a name owned by one account, pointing at another account which has its reverse record set. In that case the first account gets the tokens, and the second account gets the multiplier; not very useful.

If there’s appetite in the DAO, I can construct a more complex query that finds all accounts that ever owned a name that points to an address that has interacted with the reverse registrar, and we can take the diff of that and the existing list to determine affected users, and allocate them more tokens from the DAO treasury in a second airdrop. 40% of the original airdrop had the multiplier, so the maximum theoretical impact is roughly 30% (7.5M tokens) but more realistically would be an order of magnitude less, as this was a fairly uncommon situation. The DAO has 5M tokens unlocked immediately that they could choose to use on this.

Jeff.eth · November 14, 2021, 9:02pm

I think the easiest way to advance this proposal would be to put together the actual query (assuming it’s not too much work). If it’s a small number total (as I suspect it is) then this may be an easy proposal to pass!

nick.eth · November 14, 2021, 9:40pm

Okay, this query was easier to put together than I thought!

If we include all accounts that have at some point owned a name that currently points to an account that has its reverse record set, we find 11,520 accounts that would receive a total of 1,776,717 additional tokens.

This seems overbroad, though; if you owned a name and sold it, or let it expire, and the new registrant set a reverse record, you would both get the multiplier. A fairer metric would be to require that the address had held a name that pointed to an account that had that name set as the reverse record at the time the user owned it. Calculating this would be much more complex, and I’d like to see if there’s an appetite for going further with this before putting a substantial amount of time into researching it.

(Alternately, if anyone wants to take a look - the relevant tables are available at ens-manager.airdrop and ens-manager.names in BigQuery; I can also provide the queries they were constructed from.)

greypixel · November 15, 2021, 11:59am

@nick.eth - thank you so much for your responses and all of your help with this to date - much appreciated.

I agree that the query is overbroad.

Given the “strict” query is a lot of work - is there a way to see out of the 11,520 names identified above how many have been owned by more than one account? This might inform whether or not it will be ‘worth it’ to invest the additional time based on a theoretical best case saving for not over-allocating.

Personally think it would be worthwhile implementing this, but that’s probably a given as the proposal is about trying to update the airdrop parameters to be more accurate. Really interested to hear thoughts from others.

nick.eth · November 16, 2021, 1:16am

Excellent point!

It looks like approximately 30% of those domains have only one owner, accounting for about 32% of the tokens above. The tables I’m relying on have been updated since I ran the previous query, so I can’t get an exact match, but that would come to around 568k tokens as a lower-bound.

greypixel · November 16, 2021, 9:48am

Thanks nick! One more point of clarification before summarising - can you confirm whether or not your recent query is excluding accounts that already have a multiplier?

i.e.:
I have 2 addresses:
0x111, 0x222

I have 2 names, both owned by 0x111:
one.eth, two.eth

I point one.eth at 0x111 and two.eth at 0x222 then set reverse records from both

I would already have correctly received a 2x multiplier for the airdrop (which would only go to 0x111 due to ownership of the name) because of 0x111's interaction with the reverse registrar. Would your query from Nov 14 be artificially inflated because it is counting these false positives for newly receiving a multiplier, or have you excluded all accounts that already have the modifier set?

nick.eth · November 16, 2021, 4:43pm

The math still allocates tokens based on ownership of names - so in that scenario, 0x222 would get the multiplier, but still no tokens.

greypixel · November 16, 2021, 5:00pm

Sorry, I wasn’t clear. The question was whether the 11,520 accounts identified in your query yesterday are guaranteed to not already have the multiplier. In the example I provided 0x111 would already have the multiplier from the original airdrop query, but could also be contributing to the number, depending on how you ran that query.

In other words, could it be an over-estimate for another reason (other than the one you mention in the actual post).

It sounds like you have this all covered though - I’ll write a summary post later this evening and link to it in the discord to see if anyone has any strong opposition to progressing this to a more formal proposal.

nick.eth · November 16, 2021, 5:19pm

Yes, I excluded accounts that already had the multiplier from this calculation.

SpikeWatanabe.eth · November 16, 2021, 6:58pm

I’m voting against this either way

there is so much work here at play to satisfy single person demand, need of the many outweigh needs of the few

right now the rules are very clear and easy to interpret, modifying current landscape would introduce a lot of uncertainty and ambiguity into this design

on top of that my impression is that @greypixel has this “money” edge here, fighting ferociously for that chunk of tokens, how is it justified to bend whole system because one person feels so strongly that he missed some money

greypixel · November 16, 2021, 11:08pm

@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…!

greypixel · November 16, 2021, 11:42pm

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)

nick.eth · November 17, 2021, 5:51am

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: https://gist.github.com/Arachnid/d6495f57ac6a5b17cf28e01b646e99a8

spencecoin · November 17, 2021, 6:34am

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.

alanxing · November 17, 2021, 7:31am

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.

SpikeWatanabe.eth · November 17, 2021, 7:54am

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.

TOP LEVEL ANALYSIS

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.

BOTTOM LEVEL ANALYSIS

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.

lefterisjp · November 17, 2021, 8:46am

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: https://twitter.com/benjaminion_xyz/status/1460871836892381186

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.

SpikeWatanabe.eth · November 17, 2021, 9:07am

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?