Yep, that is one reason why doing this one-time “mulligan” now makes sense.
and the right thing to do.
This is up for debate in my opinion. If it’s “the right thing to do” now, wouldn’t it also be “the right thing to do” later on too, whenever anyone makes such a mistake? We don’t want to set a precedent with this, but I think saying that it’s “the right thing to do” sets a future precedent, in the eyes of many in the community.
One could argue that not returning these funds at all could also be “the right thing to do”, because it preserves the immutability and code-is-law features of the blockchain, and forces people to learn hard lessons and become better self-custodians in the future.
The difference here is that the DAO has control over the token contract so it’s a bit different than just accidentally burning your ETH without recourse by sending it to the wrong address. And this airdrop was able to reach a lot of newbies in the crypto space at large, which is great! But it also means that mistakes were rampant. That’s why I’m still for this one-time proposal.
Yes - but that has to be weighed against the cost of doing it. I’m personally in favor of doing this periodically when it can be done with minimal overhead to the DAO - but I don’t think that this proposal should be taken as precedent for my personal preference on the matter.
Agreed that it’s important to always consider the costs/benefits, and the cost for this specific proposal would be low, with a significant benefit to many people (most of whom are probably newbies who just made a naive mistake).
I would also be open to something along the lines of what @AvsA said, like a once-a-year occurrence to minimize costs/overhead for the DAO. It would obviously need to be spelled out with very clear rules, like only applying to ENS tokens sent to this specific contract address, etc. If someone accidentally sends some other token/NFT to the address, I don’t think we want to be complicating things further by trying to handle that too. Even so I’m only open to that idea at the moment, pending further discussion…
I support this.
I agree that the DAO can help, especially in this early instance.
I also agree with Spike and Brantly that a DAO can not always help every user mistake.
Worrying about costs is a bit silly in my opinion. Mistaken tokens can total hundreds of thousands or millions of dollars, you can’t not do it because someone can’t come up with a few thousand dollars for the cost of developing it.
Doing that now absolutely makes it a precedent and an expectation that more will be done and it feels wrong to correct mistakes done in the first 4 weeks of claims but never again.
Since there is so little overhead in baking this into the airdrop I’m for this out of practicality, as a “one-off” as nick put it.
I think that it would be interesting to discuss how the DAO views rectifying future user mistakes in a separate thread, though, as that’s a broad enough topic in and of itself.
I think it’s absolutely reasonable - essential even - to weigh the cost to the DAO of sending tokens back against the magnitude of the stuck tokens. I’m onboard with doing this once or twice a year as part of something else, but we can’t ask hundreds of delegates and several developers to collectively spend many hours on correcting someone else’s mistake every time it happens.
I would totally be ok in charging a fee from lost tokens in order to do that. Let’s say we only send 95%-99% of the tokens back and the rest remains with the dao, half of which is then used to pay for the developer who implemented the queries. It’s also a good way to know if it’s worth it: we only do it the amount of tokens lost is large enough that 1% of the amount covers the costs.
I don’t share at all the reverence for immutability regarding DAOs and dApps. For sure, we need it for the base layer. It doesn’t mean that it automatically translates to any collective decision.
The whole point of governance tokens, forums, and votes is to empower the community to make decisions. About everything, and as the community see fits. The last time I checked (and I just checked again), Immutability is not part of the core principles approved in the ENS constitution. Why should it become a reason to do or not to do certain things now?
If there have been obvious mistakes that cost members their tokens and that we can fix without occurring much effort nor cost as a community, why shouldn’t we do it, if it’s not out of respect for a principle that we haven’t approved in the first place?
I hear that there’s the risk of creating a precedent. Yes, if this proposal makes sense now, it could happen again - and what’s wrong with that? If it happens again but the then-conditions make it irrelevant or too costly or detrimental to the project, we can and will downvote it then. We don’t have a jurisprudential system that forces us to comply with our previous judgments. If we vote yes, we won’t have to help users every time they make a mistake, just as voting any proposal won’t necessarily create an enforceable precedent.
I like the last idea of @AvsA regarding charging a fee that will be used to pay for the implementation, though.
I will vote YES - just need to wait for feedback from my delegators first.
I believe I have explained here (and on twitter). I have concerns about expanding the scope of the airdrop fix. I am generally in favor of helping users with their lost tokens but it would be very unfair to make this a one time only thing and if it’s recurring I don’t see why not wait when the airdrop period is over and the volume of incorrect tokens transfers will have subdued.
I understand the point that “hey it’s basically free so let’s do this other too”. I would just have preferred to make them clearly different events.
I also wanted clarification on the matter of what possible precedent this could set. The reason it is written with such specificity is to not leave room for interpretation. The when, why, and how of the amendment are there specifically to remove ambiguity in any tangentially related hypothetical future case.
While it is a mistake on the user’s part, I think we should do everything we can to return the funds to the users. I dont mind if it even sets a precedence at this point. Accidents happen, and in ethereum those accidents rely on the receiving end to rectify those accidents.
We have the opportunity here to set a precedence, not just with ENS DAO, but for ethereum community as whole. We should do what is within our power to be honest and wholesome. We should return the user’s funds as it was an honest mistake and thus doesnt truly belong to the DAO. Keeping the funds would be dishonest, in my opinion.
I am also of the opinion that this shouldnt be a one time thing, and that we should consider performing this action as close to the expiration of the funds back into the DAO as possible, or even afterward, ensuring we return all user’s funds back to the rightful owners.
As for tx fees, there are several considerations but those are really outside the scope of this opinion piece.
In the end, it doesnt matter much how the funds are returned, but I do think it is worth it for the DAO to return the funds to the users who made honest mistakes. Often times the right thing to do is not the easy thing to do, but it should be done none-the-less.
I love the healthy discussion from differing views here. I lurk way more than I post, but I just wanted to say I enjoy reading constructive opinions even when I don’t agree.
I agree with what you said regarding mistakes and it shouldn’t be a one time thing.
I still think this shouldn’t be tagged along with EP2 and the thinking around the proposed execution has been along the lines “oh it’s convenient and cheap to do it with EP2 let’s just do this first and worry about everything else afterwards”.
It’s probably not going to be this cheap or this convenient for future cases.
I agree that this should be done because it comes at little cost to ENS DAO and does not give users unfair advantages, as they will still have to pay claiming fees. I think the social intention is clear enough from this thread that a precedent for recurring fixes is not intended to be set, and this thread can be cited when discussing future, related events.