The Lost Key Situation in EOS, a comprehensive overview

(中文翻译 / Chinese translation)
( Русский перевод / Russian translation )

What is the issue?

Some members of the EOS community either lost or failed to receive their private EOS keys. Since launch, they’ve been waiting for a way to recover their funds.

(For the sake of completeness, there is another group also waiting to be rescued. These are people who never registered their Ethereum keys, and do not want to use EOS Authority’s fallback process. The reason for them not wanting to use EOS Authority’s fallback process is most likely because their ETH keys are stored on a hardware device, like a Ledger, and the owner either can’t or doesn’t want to get the key. This group is probably extremely small.)

How big is the issue?

A list of lost key cases compiled by one community member has 273 accounts whose balances total 891,361.74514 EOS.

Should something be done at all?

The argument against helping:

  • It’s not the job of EOS governance structures or Block Producers to fix user errors.
  • Rescuing users who lost their keys will create a “moral hazard” and an endless flow of careless people using EOS governance and/or Block Producers as their password recovery.
  • Recovering keys creates opportunities for malicious actors to steal keys.
    It is an over-reach of block producer powers and would stir centralization concerns.
  • By routinely transacting on behalf of accounts which BPs don’t explicitly or normally control, we risk undermining the perceived security and integrity of the blockchain.

The argument for helping them:

  • The sign up process was somewhat confusing. Apparently, there was a small window of time when the email’s generated from the sign up process were not working.
  • We (EOS governance / Block Producers) should help because we can.
    The counter measures against malicious claims are simple and effect.
    The scope of this is limited to keys which have never been used on the EOS Mainnet.
  • As Kedar of Liberty block pointed out: “There is no adverse party.”

ECAF Case # 27

On Dec 14, ECAF ruled on case # 27. It was intended to be precedent setting. They asked block producers to create new keys for the account ​hezdqnjxgmge. It seemed that the idea was for other lost-key cases to pass through ECAF after this one.

Only four Block Producers approved to the ruling, and it expired, much to the exacerbation of some members of the lost-key community who saw this ECAF order as long awaited progress on their issue.

Though the order has now expired without being passed, the arguments for approving this ruling included:

  • Community members believed ECAF was the correct forum to resolve lost keys and paid ECAF fees. According to a community member, 151 ECAF claims have been made. Some (the community estimates 5 to 10) have paid filing fees. I know one filing fee was 93 EOS.
  • (Rumor) Some community members were told by block producers to file cases with ECAF.
  • The ECAF ruling was a timely solution. The lost key community has waited long enough. As Kedar from LibertyBlock said: “the ECAF solution is available now. if a user wants to take advantage of it until our solution is available, they should be free to.”
  • Having ECAF collect 15% from all lost key recoveries was a means of funding the organization ECAF.
  • Ian Grigg (aka Sun Tzu) who has been involved with EOS governance since the beginning, just published these arguments for following ECAF’s rulings. His arguments include preserving a balance of power, good faith, limiting BP liability, and division of labor.

Arguments against passing the order included:

  • Changing keys sets a dangerous precedent. A community member wrote “IMO, complying with orders like this severely undermines EOS and the definition of an immutable blockchain. For only 1,000 EOS too, with ECAF taking 15% of it (LMAO). I’m sure my EOS tokens will depreciate by more than $2,500 if this order is executed. Also, get ready for tens of thousands of these cases. You guys better hire some new staff. Horrible precedent IMO.”
  • “I dont think ecaf requesting key changes is legitimate.” (Michael Yeats EOS Dac)
  • Out of scope, as expressed by Myles Snider of Aurora EOS: “The problem with this is that ECAF has no defined scope. The only thing the constitution says ECAF should handle is dispute resolution. For them to take money from people and tell them that they can help them regain access to lost accounts is borderline dishonest. Now that BPs aren’t blindly following ECAF orders, they are putting out thinly veiled threats of legal recourse (get your GC on a call?!). What happens when they issue an order saying X BP must unreg? Or saying that x account’s funds should be burned? Because ECAF has no defined scope, I think it now means that BPs must assess ECAF decisions and go to 15/21 vote. If BPs vote against an ECAF order that token holders actually want, they can vote out those BPs. But giving ECAF widespread, undefined authority is super dangerous
  • Concerns that BPs should not use their power to effect the keys of any individual account unless we are sure we have the community’s support.

These arguments as summarized by David of EOS 42:

  • Outright not believing in ECAF as an arbitrator for the system so refusing to comply.
  • ECAF needs to be ratified formally by referendum along with the Constitution before passing more than account freezes.
  • This current process is too slow and unwieldy to scale and that an alternative way of processing needs to take place
  • Believing this system exposes users to risks from wrongful decisions

ECAF sent a message to block producers which was perceived as heavy handed and authoritative. This was the message:

Urgent message to Block Producers

This is a request to the top 21 block producers. Please arrange for your General Counsel’s to make themselves available for a zoom conference call with myself and the claimant of the below listed case on Thursday the 27th of December at 13:00 UTC. The other 9 BPs which make up the top 30 are permitted to have their General Counsel’s in attendance as observers.
The meeting ID will be provided closer to the time.
Meeting topic: ECAF-Ruling-Case-0027–2018–12–14-AR-002
Yours sincerely,
Ben Gates
ECAF Arbitrator

After harsh criticism of their tone and heavy-handed language, ECAF softened their tone and rescheduled the meeting for January 2nd. And then they cancelled the meeting altogether and asked for an explanation from the BPs. Perhaps this document can serve as that explanation.

Software Solution

Independent of ECAF, a software solution to the lost key situation is being built. The effort is led by members of several BPs including: Michael Yeates of eosDAC, Kedar of Liberblock, and Rohan of EOS Authority, Daniel Keyes of EOS Nation.

Kedar notes: “We acknowledge that DPOS is working as intended, and are now committed to creating a technical solution to assist users.”

Here is a video of their kick-off meeting on the subject of a software solution for lost key recovery.

In general, the process being pursued would look like this:

  1. Create an on-chain record of lost keys for the sake of auditability.
  2. Verify no none of the keys have been active on the EOS main net. (the best method of verification is being researched)
  3. Allow ETH token holders to sign something with their ETH key.
  4. Allow allow active BPs to independently approve that a key has no transactions.

There is a procedural question about whether it is better to for BPs to process batches of key recoveries or individual ones via msig approval. (This is a question of procedure and convenience without big political consequences.)

In the author’s estimation, there are two main questions before the community:

  1. What is the status of ECAF? And if they are seen as legitimate, should lost key recovery fall under their purview.
  2. If BPs proceed with a technical solution, should they proceed of their own initiative or should they wait for a referendum to ensure the community supports this.

Addendum: There’s a petition with 1726 signatures requesting that the issue of lost keys be addressed.