[EP3] [Social] Amend airdrop proposal to include accidentally returned funds

DAO-Wide Archived Proposals
1

Status: Passed

Summary

Amend EP2 to include funds accidentally sent back to the $ENS token contract.

Abstract

A number of users have accidentally sent $ENS tokens back to the token contract. As of December 6, this amounted to some 6,246 tokens in 49 separate transactions.

These funds are held in the same account as is used for new airdrop claims, and on May 4, 2022 when the airdrop expires, the DAO will be able to claim them back to its own account.

EP2 sends approximately 200k tokens to users who owned ENS names that were used as primary names but did not already benefit from the 2x multiplier.

This proposal suggests that EP2 be amended to include returning the mistakenly sent funds as part of the same airdrop. This minimises overhead, as the DAO will not incur transaction fees or have to set a separate system up, and enables users to get their mistakenly sent funds back promptly.

Specification

Amend EP2 as follows:

-This logic is implemented by [this series of BigQuery queries](https://gist.github.com/Arachnid/667178e854945abaecb6dfd3b6c0c279/1182eea3145394181affe4bb799d6b7858f9eb58), and shows that 1,969 accounts meet these criteria but did not qualify for the multiplier under the original criteria. The sum of the tokens these accounts would be entitled to comes to ~213,049 ENS tokens.
+This logic is implemented by [this series of BigQuery queries](https://gist.github.com/Arachnid/667178e854945abaecb6dfd3b6c0c279/106d9bc156988cf96786c71f6448f13fb11599fc), and shows that 1,969 accounts meet these criteria but did not qualify for the multiplier under the original criteria. The sum of the tokens these accounts would be entitled to comes to ~213,049 ENS tokens.

-A list of affected accounts and balances is [here](https://gist.github.com/Arachnid/d6495f57ac6a5b17cf28e01b646e99a8).
+A list of affected accounts and balances is [here](https://gist.github.com/Arachnid/e8b1a18fc19818fb00f51fbb8d90e429).

-This proposal, if executed, will transfer 213,049 ENS tokens to [a new merkle airdrop contract ](https://github.com/ensdomains/governance/pull/9) allowing affected users to claim them.
+Further, a number of users have accidentally transferred their ENS tokens to the token contract, totalling 6,246 contracts across 49 transfers. These tokens should be returned to their previous owners.
+This proposal, if executed, will transfer 219,295 ENS tokens to [a new merkle airdrop contract ](https://github.com/ensdomains/governance/pull/9) allowing affected users to claim them.

-3. Authorise the contract deployed in (1) to spend 213049736662531485206636 base ENS tokens from the ENS DAO account.
+3. Authorise the contract deployed in (1) to spend 219295650978169915391391 base ENS tokens from the ENS DAO account.

-const tx = await token.populateTransaction.approve(airdropAddress, '213049736662531485206636');
+const tx = await token.populateTransaction.approve(airdropAddress, '219295650978169915391391');

13 Likes
2

As far as I know, some users accidentally sent the ENS to the contract address due to operating errors, causing their airdrop to be received incorrectly, so I chose to support this proposal.and maybe May 4, 2021 Is fill in error? Because this time has passed

3 Likes
3

It is meant May 4, 2022

2 Likes
4

Fixed, thank you very much.

3 Likes
5

Will they also need to be claimed as in the proposal to be amended, or will they be sent back automatically to all of the effected addresses?

2 Likes
6

If both proposals are accepted, the tokens that were sent back would be added to the airdrop, so they’d need to be claimed.

4 Likes
7

I believe this is well intentioned and would reward honest mistakes.

That said, I’m holding off on voting until more discussion.

I have concerns about the precedence this sets for repeated proposals to refund users’ mistakes. If we approve this, will we create an expectation of periodically returning any funds accidentally sent to an ENS-controlled address?

I don’t see anything that ENS has done in error here, so I’m not sure if this requires action from the DAO. While the proposal is time bound, the underlying human behavior leading to it is not. The set of affected users is effectively monotonically increasing until the end of time.

My current inclination is to vote opposed, although I have not submitted that vote as I will wait for other comments.

6 Likes
8

Personally, I’m okay with that as long as it’s technically feasible, doesn’t put an undue burden on the DAO or on developers, and includes some mechanism to make the users pay the transaction costs.

Other DAOs have similar systems for this sort of error, and if it can be made low-cost for the DAO to fix, I don’t see any reason not to do it periodically.

We can of course not do it straight away - but if the DAO approves the other proposal, there’s very little overhead in rolling this into it as well; much easier than doing it separately.

7 Likes
9

I never supported original tail of this, and I kinda agree that technically it makes sense to bundle those distributions together, but this is the very echo and additional cost I was talking about

in my world immutability is the key, if we let broad userbase think, that ens team will fix every broken erroneous transaction this has a lot of consequences up to the point when some agents will start demanding to amend ledger of .eth names and we cannot let this happen, in my opinion this affects interests of broader ens community, so I’m going to vote NO

10

I share you concerns, and I really respect your conviction to be the first opposition vote.

That is why I asked for clarification about how the coins would be sent back. I believe that as long as this (and the proposal this amends) is presented as an amendment/correction to the original airdrop, requiring those affected to pay their own gas like the rest of us did to claim their tokens, it doesn’t leave the door open for any other ambiguous edge cases to expect additional amendments just for them… with the exception of correcting truly objective “mistakes.”

This proposal and the proposal it is amending have clear, cut and dry criteria for why and how they are to be executed. I feel as long as this is treated as an addendum to the original airdrop, and not another airdrop entirely, that shouldn’t leave any ambiguity for any “what about xyz” cases thereafter. I think it should be made clear that no future action will be taken to correct end user mistakes, only things that were out of their control.

That said, I think this proposal and the proposal it amends, if passed, will greatly benefit the public perception of the ENS DAO.

edit: For transparency, neither proposal in question would apply to me.

5 Likes
11

I support this. I do agree with Spike that it might be helpful to establish a limiting principle so that people don’t expect the DAO to bail them out of every mistake.

4 Likes
12

Against this as it sets precedent for the DAO fixing people’s mistakes.

I would support any proposals that can be coded into the chain, for example:

Any $ENS tokens [X minimum] sent to the $ENS token contract will be automatically returned to the sender minus some cost [%, flat fee or based on gas fees].

Of course then we have to take care of edge cases like what if the ENS funds are too low or what if bad actors just spam the contract, etc…

13

There’s not really any way to do this; the token contract is not upgradeable.

3 Likes
14

Maybe it would be wise to delay this correction until after the airdrop window closes. This way we mustn’t:

A) Do this a second time for the users who make the same mistake after we mend the issue.
B) Be forced to decide those users are SOL because they were not as quick to make the mistake.

15

We could delay both the airdrop and this to after May 4, 2022. Delaying just this doesn’t make a lot of sense, IMO - it’s very easy to roll this in with the airdrop update, and much harder to do separately. It’s also reasonable to expect that we’d see a much higher rate of these updates in early days, as people are claiming and transferring their tokens, than later.

Personally I’d suggest doing this as part of the airdrop update, and making it clear that this is not intended to set precedent, and that the DAO will consider what to do with any future accidental transfers later.

4 Likes
16

100% agreed. This amendment and the original proposal (concerning “crosslinked” primary ENS names) should be bundled into the original airdrop interface, if possible. That way the precedent set is correcting the original airdrop, not an additional event.

6 Likes
17

I just barely tipped over the edge of the fence into the support camp with this one. I am really worried about setting a precedent or expectation though, we really can’t be doing this in the future every single time someone makes a mistake.

In dealing with a lot of these support tickets it seems like part of the problem may lie with various wallet UIs and not making things crystal clear to the user. For many people this was their first airdrop, their first NFT, and maybe even their first interaction with Ethereum, Metamask, or crypto in general. In my mind this would be a one-time-only proposal just to show a bit of mercy and goodwill to our fellow newbies, but I would be hard pressed to approve such a proposal in the future I think.

2 Likes
18

I’ve updated the proposal to more formally amend EP2. If EP2 passes (which seems all but certain), I’ll move this to active and put it up for a snapshot vote in ~24 hours.

4 Likes
19

But this is a completely different issue and I fear that putting them together might make matters worst.

Users do mistake and I’m in favor of being tolerant of those. But while the airdrop is a one time thing, sending back tokens sent to the contract will be an ongoing issue, users will still send it to the contract. It’s hasn’t been a month since the contract went live and we’ll already fix that, means that some users will expect this to be a monthly occurrence.

I would prefer if there was a longer time frame: like a once every year occurrence, after the airdrop has ended and claims will be closed. I think waiting a year for your token is an acceptable consequence for having sent your tokens to the wrong place–in most other situations you’d be stuck forever.

20

In this case we’re only considering this one-time send. It’s not intended to set precedent, and it’s nearly cost-free to do alongside the other airdrop. I personally think it would be foolish to refuse to do this on principle, as long as we make it clear that it’s being done now because it’s easy, and the right thing to do.

3 Likes