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.
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:
- The âslippery slopeâ perception (essentially âgive them an inch and they expect a mileâ)
- 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.
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.
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.
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.
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?
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.
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.
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?
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.