I submit to you a request to rectify mistakes made in transferring ENS tokens, where they were inadvertently sent “back to the ENS DAO contract”.
I did this immediately after claiming my tokens, and I have found that another forum member did the same. We had both copied the ENS contract address (I did so in adding the token to metamask) and then pasted it instead of my intended destination address when trying to send to my “savings” wallet.
I know the transactions cannot be “reversed”. And I know my claims cannot be “reset”. I am asking that the tokens which we have “returned” to the DAO be gifted back to us.
Details of my mistake are here (including the transaction and screenshot evidence):
Details of the other member’s mistake are here:
I am a big fan and supporter of ENS, and hope that this request be considered by the DAO delegation.
5,689 ENS tokens have been transferred back to the ENS contract by users in 39 separate transactions.
These will be able to be swept back to the DAO wallet once the airdrop expires on May 4, 2022.
The DAO can of course choose to reimburse users before then, knowing that it’ll get the tokens back eventually anyway. At current prices 39 transfers would cost about 2.5M gas (0.25 ETH @ 100 GWEI), though it’d be most effective to send the tokens to an external wallet that can accomplish the redistribution manually.
Thank you @nick.eth ! I very much appreciate your investigation (top skills!). I am not surprised that many users made the same mistake, however did not expect such a huge volume.
To rectify the gas, perhaps the DAO could reduce the reimbursement to offset the impact. I for one think this would be fair, as it was my mistake.
Could you please advise if there is any action I can take to help bring this request to decision?
Cheers
Slacker, aka “baggage.eth” (now finding that quite ironic)
If the DAO makes one lump transfer to an appropriate L2 this and many other transfers can be done there at a huge gas savings, which I think will prove worthwhile many times over.
This is a good example of a situation where a medium number of users are affected and the issue is totally remediable. I think it would be helpful for us to work up some kind of “triage policy” which lets us prioritize amongst these types of tasks as the total “todo list” for the DAO increases. Maybe we could work up some kind of system where a small number of helpers speculatively resolve issues like this which are assessed in the helpers’ view to be easily remediable, and then the DAO can just do a one step “check up and compensate” for the helper later on? Just thinking of the fiddly stuff like collecting up the list of affected users and amounts, etc.
But since this is not a mistake on the team/DAO but on the user side I would suppose this should have a lower priority.
Additionally if there is already 39 such transactions by the time the airdrop expires I expect a lot more.
So I would say we wait until then and then do a lump reimbursement of all of them alltogether at that point in time.
From that point and on if anyone sends token to, say the DAO, by mistake I am not so sure how much we should spend time on any further cases. At some point a line should be drawn.
Personally think this would be a really nice “humanising” gesture for the DAO, which is a very good thing. Parts of ethereum are very unforgiving of mistakes, so where they can be reversed relatively easy (as in this case), I really think it is our (in the widest sense of the word!) duty to do so.
Solving a problem like involving an external wallet and manually redistributing would also be a good way to establish a process that will be useful to the DAO in future (if it doesn’t already exist).
It’s easy enough to build a query that catches these cases, and we could add the cases that have occurred so far to any airdrop for the 2x multiplier if that gets approved.
And think of the gas savings! Very few people use ENS names longer in length than an address which could save a ton on storage, though I feel like there are even more clever ways to really golf it down.
So this is about users who mistakenly send the token to the token contract? I think that in general ERC20 tokens should have a check before transfer that prevents this situation:
require(recipient != address(this), "ERC20: do not transfer to itself");
Help me on the technical details here: so the DAO, after the airdrop date, can claim any amount of tokens from the token contract? That’s clever. This makes me fear that then this will be an annual occurrence: people will keep accidentally locking up their tokens and asking us for it to be sent back. I would suggest that we did it in certain limitations:
One time after the airdrop
Every N years if the locked token balance exceeds a value of Y
Optionally the DAO can keep a % of the tokens as a fee
This would allow these reimbursements to be infrequent enough that each one can be checked to be correct.
BTW, looking at the contract now and found this interesting bit:
- Support for the owner (the DAO) to mint new tokens, at up to 2% PA.
I wasn’t aware of this capability. It’s actually interesting. I would prefer avoiding using it, but I like that we have that possibility.
I’m onboard with all the restrictions you suggest, though I’d say that making people wait years is a little over the top. And we should expect this to happen most at the start; given there’s another proposal that involves sending tokens it would make sense to add these users to that proposal if it passes.
If this exists as a factor, folks with stuck tokens might campaign for others to send ENS tokens to the the smart contract so that threshold can be met and they can get their original tokens back
