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

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

2 Likes

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.

5 Likes

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.

6 Likes

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.

6 Likes

What about this case I outlined above here?

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

1 Like

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.

1 Like

That seems like a good idea to me. We will at least need to outline a process if there’s going to be any amendments to the airdrop even the first time, right? Maybe the proposal could outlines both parts - how to submit an appeal if you think you qualify, and also how any newly discovered [qualifying] edge cases will be reimbursed.

1 Like

I think the only reasonable argument for a change is that the intent of the airdrop deviated from the implementation - as it arguably is in this case. I don’t think this is going to be an ongoing process, and I don’t think there’s much point in creating a process that encourages people to submit ‘appeals’ over what they think they should have gotten.

3 Likes

Well i totally agree what @greypixel and @nick.eth said. We discussed motives and values, but it is obvious that there are some problems with the 2x airdrop. We are working hard to state the facts and follow ENS DAO’s guidelines and governance processes. This is the most meaningful thing.

so what’s next step? maybe we should move to phase 2 to draft proposal on Draft Proposals - ENS DAO Governance Forum right?

@nick.eth, I think the best way to do something like that would be to use Alchemy. They have archive node access and an API that supports Parity’s trace_* RPC calls.

But anyway, that suggestion is moot now since I think I’ll just bow out and take the loss. If I’m the only one you’ve heard of with this issue, no use going to such lengths, I’ll just chalk it up to bad luck. I appreciate you going through it and considering it though :pray:

I need to see full proposal with exact criteria for retroactive airdrop, as it stands now I’m 50:50 on this.

After reading, I’m in favor of the proposal.

I think there are always edge case and it’s fair to find the ones that feel according to the spirit of the rules but for technical reasons weren’t accounted for. Also, I believe setting your primary name as different than the owner is a legitimate use case (say the primary name is in your mobile wallet but the actual owner is a multisig or hardware wallet).

I expect we will see more edge cases in the future and if we start getting boggled down in exotic edge cases in which it’s not even clear that who is to blame, I will probably vote to end up any new airdrop corrections.

2 Likes

I’d be in support of this. I think one should look more to intent than to execution. If ENS team originally did not intend to exclude this group of users, but they were merely missed in execution, I dont see why we couldn’t include them.

It doesnt seem to me we are rewarding invalid users or farmers here, but legitimate users. In other words, we have a chance to welcome more active ENS users to support the protocol as originally intended.

Full Disclosure: I will not benefit from this proposal.

1 Like

I am in favour of this proposal, I think these edge cases most likely satisfy the spirit of the ENS airdrop process. I also had a reverse record set long before the airdrop but I had to remove it for a while for privacy concerns (got 2x multiplier). Many people experimented with this feature in some form, and these interactions are aligned with the ENS ethos I believe.

Isn’t the real question is what was the intended policy? Is the policy to intended reward active users, or is the policy intended to reward accounts with the primary ENS name set to the same account?

I believe the policy was to reward active users and the latter was just the attempted method to enact it.

To me it makes no sense for the policy to have been “only accounts with primary name set to their self get 2x bonus” as there are plenty of reasons why you may have the reverse record pointing to a different account. It could be argued that people with the reverse record pointing to a different account are more active users since they have more addresses involved with their ENS, instead of 1 address.

If the policy was to reward active users and this was not done, why is it not fair to compensate the people who were missed?

Any update to the ENS system in general will cause a rise in support queries. If its the right/best thing to do it should be done regardless of the support implications. We as a community can surely help manage some of the support queries when we are sitting about in the discord.

If we go by a rule were mistakes cannot be corrected then wouldn’t that bring even more uncertainty? What happens when its something that many more users then this issue? Would we simply tell the majority of users “sorry we did it this way first so that is that, tough luck.”? I would be far more uncertain in the future of ENS knowing that once an action has been taken it cannot be corrected.

If uncertainty and ambiguity are major concerns for ENS, then surely the DAO is the worst thing ever? The DAO its self has created so much uncertainty and ambiguity since now anyone can put a proposal forward, the delegates can interpret it how they choose, and then the proposal may or may not be enacted. Both the point about support and the point about uncertainty and ambiguity don’t hold much weight to me, since it could be argued that literally anything the DAO does will cause a rise in all 3 of those factors.

Uncertainty and ambiguity are naturally going to arise when a protocol moves from being manged by a central team to a DAO. But over time the DAO could alleviate these concerns by showing it can act in a fair and just manner, proving to people that it can actually govern the protocol with good intentions.

I am in full support of @greypixel’s proposal and would like to see the 1,969 accounts affected by the method of collecting the list of active users (which i am not one of), receive an equal reward as everybody else for being active users.

5 Likes

Any update to the ENS system in general will cause a rise in support queries. If its the right/best thing to do it should be done regardless of the support implications. We as a community can surely help manage some of the support queries when we are sitting about in the discord.

@Karp I volunteered as support on ENS discord for sometime now, your help will be kindly appreciated, if you know your MM and can find your way around complicated situations I’m pretty sure that your help will be welcome

Also bring a lot of patience :smiley: