The DeRec library is designed to be versatile, allowing it to protect various types of information such as cryptographic keys, photos, notes, identity credentials, and passwords. The DeRec API contains a concept called a lockbox, which represents the generic container in which secrets are stored. To enable their users to safeguard password data using decentralized recovery protocols, password managers need to integrate the DeRec API into their applications.

By incorporating DeRec, password managers can eliminate the vulnerability caused by having a centralized database of users’ passwords, which serves as a single point of failure. This integration allows encrypted fragments of their users’ passwords to be securely stored among their trusted set of helpers, thereby eliminating a single target that attackers can exploit.

The DeRec protocol allows users to freely choose their set of helpers, without any requirement for DeRec Alliance Members to be involved. In the future, institutions and organizations may offer Helper-as-a-Service, providing a trustworthy helper solution. If DeRec Alliance Members offer such a service, they would hold a share of a user’s encrypted data only if the user opts to use their service. Ultimately, it is up to each individual user to decide who assists them, whether it be friends, family, organizations, or a combination thereof.

ERC-4337 doesn’t specifically mention social recovery, although the community understands social recovery to be one of its features, albeit only for on-chain assets – DeRec is a mechanism to recover secrets of any type, such as passwords or documents. In more detail, ERC-4337 avoids introducing new protocol-level changes to the Ethereum blockchain. Instead, it defines a new higher-level pseudo-transaction called User Operation. End users send these User Operations to a higher-level alt mempool called “User Operations Mempool”. A new class of operators called Bundlers pick up these user operations and submit these to a special contract account through a singleton entry point contract. Lastly, EIP 4337 introduces the concept of Paymasters which can sponsor transactions on a user’s behalf. None of these concepts are directly related to social recovery or decentralized recovery.

Please refer to the FAQ question “How does this compare to social recovery on Ethereum?“ to understand the differences between social recovery and decentralized recovery.

When an end-user uses a DeRec Owner-enabled application or service to initiate decentralized protection of one or more secrets, those secrets are split into a minimum of three secure but dissimilar chunks called DeRec Shares. The resulting number of Shares corresponds to the number of DeRec Helpers (see What is a DeRec Helper?) that the DeRec Owner is paired with (see What is a DeRec Owner?). 

Not only are each of the DeRec Shares secure by nature of the standard quantum-resistant cryptography that’s applied to them (current and future DeRec Alliance technologies always rely on open standards where possible), it is impossible to reconstruct the end-user’s secret(s) from any individual Share. From a single DeRec Share, It is also impossible to derive any information about other DeRec Shares or the DeRec Helpers who are responsible for their safekeeping. 

A DeRec Owner must retrieve at least half of the Shares from at least half the Helpers before those Shares can be used to reconstruct the end user’s secret(s). Although it is strongly recommended that end-users pair with at least five Helpers, a minimum of three DeRec Shares, one per DeRec Helper, is all that’s needed in order to protect an end-user’s secret(s). This minimum guarantees that an end-user’s secret(s) will be split across at least two Shares in a way that those secrets can never be derived from a single Share.

On behalf of an end-user, the DeRec Owner is essentially the orchestrator of all DeRec Protocol workflows. A DeRec Owner is any new or existing app or software that, through its support of the DeRec Protocol, enables the end-user to:

1. Specify a secret to be protected. The DeRec Protocol can protect any secret. For example a password, a private key to a blockchain account, an entire wallet’s seed/mnemonic recovery phrase, recovery codes for accounts enabled for two-factor authentication, a credit card number, etc. (see What types of secrets can be protected with the DeRec Protocol?)
2. Identify and pair with the DeRec Helpers who will aid in the protection of that secret (see What is a DeRec Helper?)
3. Split the secret into three or more (one per Helper) secure but dissimilar shares of the secret. A minimum of three DeRec Helpers is necessary to protect a secret with the DeRec Protocol. (see What is a DeRec Share?)
4. Distribute the Shares to the Helpers (one Share per Helper) in order  to activate protection of the secret
5. When called upon to do so by the end-user, engages at least half of the DeRec Helpers to recover the secret. A single application can include both the DeRec Owner and DeRec Helper functionalities. But those same functionalities can also be made available on a standalone basis. It’s up to the app developer.

Behind the scenes, the DeRec Owner has other responsibilities. For example, it periodically checks-in with its Helpers over a network like the internet to confirm their continuous availability. During these check-ins, it also checks the integrity of the Shares that are stored with those Helpers. The frequency of these check-ins is also up to the developer of the DeRec Owner-enabled app. If the DeRec Owner encounters difficulty when trying to reach a Helper, the end user’s original secrets are re-split for distribution as long as the Owner can still make contact with at least three Helpers. The new DeRec Shares are then shared to the remaining DeRec Helpers in a way that sustains the protection and recoverability of the end-user’s secrets in a decentralized manner.

DeRec Owner developers are strongly encouraged to trigger warnings for their end-users when (1) a DeRec Owner is unable to make contact with one or more of its paired Helpers and (2) the number of DeRec Helpers that are protecting a secret falls below five.

Accordion

For any given instance of a Dentralized Recovery (DeRec) Protocol workflow, there are two primary participants in the process; the DeRec Owner (see What is a DeRec Owner?) and the DeRec Helper. Whereas a DeRec Owner pairs itself (on behalf of the end-user) with multiple DeRec Helpers to protect and recover an end-user’s secret(s) in a decentralized manner, a DeRec Helper primarily exists to respond to three request types that might come from a DeRec Owner (via a network like the internet):

1. A request to receive and store an encrypted DeRec Share (see What is a DeRec Share?)
2. To respond to a DeRec Owner’s periodic check-ins to make sure the Helper can properly participate in a recovery operation should one be necessary
3. To respond to the DeRec Owner’s request to retrieve a DeRec Share for the purpose of combining it with DeRec Shares from other DeRec Helpers in order to reconstruct an end-user’s secret. Such a request would happen after the end-user initiates the recovery of one or more secrets.

Like the DeRec Owner, a DeRec Helper is not necessarily a stand-alone application. Although developers are welcome to develop applications that are solely dedicated to the functionality of DeRec Owners, Helpers, or both, the Owner and Helper capability should also be incorporated into existing applications like password managers and cryptocurrency wallets that already deal with a variety of end-user secrets (see Understanding the Types of Secrets that can be Protected with the DeRec Protocol).

In terms of requirements to successfully support a specific DeRec Protocol-based workflow, a DeRec Owner must be able to pair with a minimum of three DeRec Helpers through a network like the internet. This is necessary to ensure that, when the DeRec Owner looks for at least half of the Helpers in order to recover a secret, that it never finds just one Helper. While three is the minimum number of Helpers, the DeRec Alliance’s recommendation to end-users is to pair their DeRec Owners with at least five Helpers. DeRec Owner app developers are strongly encouraged to trigger warnings for their end-users when (1) any DeRec Helper to which their Owner was paired cannot be contacted and (2) the number of reachable DeRec Helpers falls below four. 

Strictly speaking, any application or web service that includes DeRec Helper (see our FAQ: What is a DeRec Helper?) functionality is technically providing a service to DeRec Owners (see our FAQ: What is a DeRec Owner?). However, certain organizations should consider taking the idea of such service provision to an entirely different level through the provision of DeRec Helper functionality as a part of a new or existing commercial offering. For example, to make itself more appealing to existing and potential customers, a wireless carrier or internet service provider could include free DeRec Helper functionality as a part of its different tiers of service. A DeRec Helper-as-a-Service is essentially a DeRec Helper that exists solely for the purpose of serving many DeRec Clients. The DeRec Alliance has no rules regarding whether a dHaaS is offered as a free or a paid service and nothing prevents a developer from building a turnkey application that other service providers could use to launch a dHaaS.

The Decentralized Recovery (DeRec) Protocol is not an application that you download to your computer, mobile device or browser. It is a protocol that software and web service developers can support in their new and existing applications. So, in order to gain the benefit of the DeRec Protocol, end-users should look for applications that, as a result of their support of the DeRec Protocol, can work with DeRec Helpers (see our FAQ: What is a Blockchain Helper?) in order to protect and recover personal secrets such as keys to blockchain accounts, passwords, passkeys, pin codes, mnemonic recovery codes, and even documents. Such applications would include (but are not limited to) blockchain wallets, password managers and any web service that issues credentials that, if lost, could prevent future account access.