On EOS lost key cases

Introduction

The EOSIO whitepaper promised that the EOSIO software would include some form of lost key recovery, however as at the time of writing this does not exist in the software.

There are a lot of proposals being made for such key recovery services that include solutions where people “opt-in" to some kind of private key custodian, insurance solution or provide additional proofs (e.g. biometric) of their identity and ownership. Ideally, there would exist a multitude of such services so that users have a choice of whom to trust with their recovery credentials. Unfortunately, though, these solutions do not currently exist and even if they did, they typically require users to register in advance to offer any protection. These are not services that ECAF can neither do nor is interested to do; ECAF’s focus is to provide dispute resolution. Therefore ECAF encourages developers and entrepreneurs to build those key recovery systems and to deploy them.

What then for those who lost their keys prior to the existence of these services? For example, there are a vast number of people who lost the keys to their genesis EOS accounts after registration but before the EOS network launched. How would such users regain access to their accounts?

Should ECAF examine lost key cases?

We should preface the rest of this section with a disclaimer. ECAF does not believe that it should be the preferred entity to resolve lost key cases. If there existed lost key recovery options, like those mentioned in the earlier section, then that would leave ECAF as the exceptional path to be used when 1) all other avenues are exhausted and/or 2) disputes arise with the use of alternate key recovery methods.

In the current Constitution ECAF functions as a form of "catch-all" (or catch-a-lot) as long as there are no specific solutions to which people can and do opt into. At present, without the existence of key recovery solutions, to which claimants have already opted in, there is no other recourse for the claimant. These claimants only recourse is to file a claim with ECAF. But is this a valid dispute? It is instructive to view the purported owner of the lost keys as one party asking the Community, as another party, to accept their rights to the property. Lost key cases are therefore still “peer to peer” dispute resolution and within the jurisdiction of ECAF.

ECAF will, therefore, continue to examine lost key cases with the expectation that the number of these cases reduces over time as those affected genesis accounts have their cases resolved and as the Community builds alternative solutions.

Are lost key cases simple?

Given that ECAF will examine lost key cases, what is the process for doing so?

While lost key recovery may sound like a problem that people are used to getting resolved easily in other contexts (e.g. with their email service password) it's actually a delicate decision. After all here is somebody who asks to gain control to an account. Somebody who cannot provide the major credential (i.e. the private keys) for the ownership.
While that party claims to have lost the key, it could also be somebody who tries to steal the account of somebody else. And arbitration is always expecting a second party, who until the case is decided has to get the same fair chance to prove that they are right and the claim is wrong. So some waiting time to let another party come forward is reasonable. And would likely be so even for a lot of other recovery approaches.

And then the evidence to prove their ownership of the account may not be easily provable by solely on-chain means.

These last complications are ones that other recovery systems possibly don't have. Others would possibly start with the expectation that their paying customers are actually the owners of the account. And they likely will design their solutions based on that starting point.

So the Arbitrator needs to review the case and evaluate a variety of factors for example:
is it an ERC-20 based account, so can ownership be proven via ERC-20? Was there some activity in the account, when last? If yes, were there transactions? Can the claimant provide some information around those transactions? Payment slips or whatever? Can some transaction partner confirm this? Is the story that the claimant provided fitting or does it sound incomplete? How did the claimant claim to have stored the keys? Are there other persons/systems where the claimant has stored their keys? Can the claimant show ownership to another account, maybe on another chain that is linked to the account via some or multiple transactions?

How can this process be scaled?

First, we need some rulings to set out how to resolve a category of cases as such. Those rulings will include some criteria for why, how and when to identify cases that fall into the same category as ruled.

Secondly, once a category is identified, automation of the handling of cases that fall into that category can be performed. This may include the collection of evidence, the sending out of notices etc. Any cases that have discrepancies that don’t match the category will need to be treated differently.

Finally, if we have a public, transparent set of criteria for how to be granted a new key to an account, then it is possible that people will provide false data that matches those criteria. We then need to be very careful that the material is genuine. And this is the point where we likely will not get away with full automation. It is likely there will need to be a final check of the gathered material before a ruling is made.

However, those checks will typically not require a full arbitration process. Most of the heavy work can go through automation and so it should be faster and cheaper to do than manually conducting the process.

To execute the rulings these will need to be passed to Block Producers pushing the bottleneck from Arbitration to the BPs. We welcome discussion on how best to streamline this process. For example batching of rulings, on chain data formats that will ease the transfer of information etc.

Conclusion

Whilst lost keys account resolution is not an activity that ECAF thinks it should be doing in the long term, in the short, to medium term, there is no other recourse for claimants (and for claimants who do not have access to their accounts, no recourse will ever be possible as they cannot opt-in to anything). ECAF will, therefore, hear lost key cases. We call on the EOS Community to build and deploy viable account recovery alternatives to allow token holders to “opt-in” to a service.

Now that the first ruling for a lost key case has been delivered, the throughput for similar cases should be greatly increased. In keeping with its goals to pursue automation once manual rulings are done, ECAF will come out with criteria that will enable increased automation of lost key cases that meet certain attributes. This will give a roadmap for those currently lodged cases that meet the criteria to be swiftly resolved.