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
1 Like
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.
4 Likes
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
1 Like
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 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)
4 Likes
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.
4 Likes
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.
5 Likes
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.
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
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.
5 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
@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.
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?
1 Like