Decentralized Recovery (DeRec) Protocol FAQ
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:
- 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?)
- Identify and pair with the DeRec Helpers who will aid in the protection of that secret (see What is a DeRec Helper?)
- 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?)
- Distribute the Shares to the Helpers (one Share per Helper) in order to activate protection of the secret
- 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.
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):
- A request to receive and store an encrypted DeRec Share (see What is a DeRec Share?)
- 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
- 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.
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.
The choice to include the DeRec Owner and/or Helper functionality into new or existing applications and web services is up to the developers of those applications and web services. The same application can include one or both functionalities. However, an application that supports the DeRec Owner functionality cannot be a DeRec Helper to itself. For more information about the DeRec Owner and Helper capabilities see our FAQ: What is a DeRec Owner? and our FAQ: What is a DeRec Helper?
Hyperlink to this FAQ: Can a DeRec Owner also be a DeRec Helper?
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.
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.
First of all, if you have lost access to important or valuable blockchain accounts, please know that we’d love nothing more than to be able to wave a magic wand in order to restore access to your account. But the only way the DeRec Protocol can work its magic and help you to recover a lost secret is if that secret was protected with the protocol prior to its loss or misplacement. As long as the secret was originally protected through an application or web service with DeRec Owner capability (see our FAQ: What is a DeRec Owner) and at least two of the DeRec Helpers (see our FAQ: What is a DeRec Helper?) that were used to protect the secret are active and reachable through your DeRec Owner, you will be able to recover that secret.
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.
Hyperlink to this FAQ: How can password managers participate in the DeRec ecosystem?
Decentralized recovery aims to be a more secure and versatile alternative to social recovery. In social recovery, a smart contract is created which reveals to the world that social recovery is being used, reveals how many helpers exist to help recover, and reveals the public key of each helper. This could aid attackers in targeting the helpers. However, with DeRec, it is impossible for others to determine if someone is using it or discover their set of helpers.
Also, social recovery does not check whether helpers have lost their keys. It is possible for the helpers to slowly lose their keys over time, until not enough keys remain to allow recovery. But that won’t be discovered until it’s too late, and the recovery is needed. Decentralized recovery automatically checks with each helper once a day, to ensure that they still have their share of the secret. If they fail to answer for too many days in a row, it first alerts the user, and if that doesn’t help, then it automatically redistributes the secret among the remaining helpers.
Furthermore, social recovery is restricted to only protecting signing keys on the Ethereum network, and requires users to possess a certain level of a priori cryptography and blockchain knowledge. In contrast, decentralized recovery provides solutions for protecting various types of data, including keys for any blockchain or ledger, passwords, photos, notes, identity credentials, and cryptographic keys, without requiring an extensive understanding of cryptography or blockchain. This makes decentralized recovery more user-friendly and adaptable to diverse use cases.
In-depth knowledge can be found here.
Hyperlink to this FAQ: How does decentralized recovery compare to social recovery on Ethereum?
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.
Hyperlink to this FAQ: Will DeRec Alliance Members hold any part of the keys like with Ledger?
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.
Hyperlink to this FAQ: How does decentralized recovery compare to ERC-4337?
One common area of confusion for people who are new to the idea of cryptocurrency wallets has to do with the difference between a wallet’s seed phrase, its password, and any private keys that might be associated with the wallet. Each of these is a secret that’s worth protecting and backing up. But each of them are different and it’s probably worthwhile to know the difference because then you can take the proper care to protect all of your secrets while knowing which ones matter, and when.
In this FAQ, we’ll talk about the seed phrase. The first thing to know is that the phrase “seed phrase” is often used interchangeably with other phrases such as “seed”, “secret recovery phrase” (SRP), “recovery phrase,” ‘mnemonic phrase,” and “mnemonic device.”
When you install a cryptocurrency wallet for the first time, that wallet typically generates a unique seed phrase to which it is indelibly and forever associated. In other words, every new wallet gets its own unique seed phrase. These seed phrases are typically composed of 12, 18, or 24 commonly known words that occur in random order and those words are often drawn from a standard list of English words such as the BIP39 word list that consists of 2048 words starting with “abandon” and ending with “zoo.”
Although it’s an imperfect analogy, some people metaphorically think of a wallet’s seed phrase as though it’s a wallet’s master key. Regardless of whether you’ve lost track of your wallet’s password or any private keys to blockchain accounts that are associated with a wallet’s seed phrase, as long as you know the seed phrase for a wallet, you will always be able to recover that wallet. For example, if a wallet is installed on your computer and the hard drive of that computer is lost or crashes, you can use the seed phrase to recreate that same wallet on a different computer. Typically, when you install wallet software on a computer or a phone, you are given the choice of two options. You can initialize a new wallet with a new seed phrase or import an older wallet using its seed phrase. The “import option” is the option to use in order to recreate an existing wallet and after selecting it, you will be prompted for that seed phrase.
This is why it is so important to backup your seed phrases. Although blockchain accounts can be individually recovered if you know the private keys to them, a lost or destroyed wallet cannot be recovered if all you know is its password. And because blockchains and wallets involve entirely decentralized architectures, there is no IT department or central support number to call for help. There’s no shortage of horror stories about people who wanted to recover a lost wallet but who lost track of their seed phrase.
It’s also important to understand the operational difference between a seed phrase and a private key. When a wallet is first installed, it is typically initialized with its unique seed phrase and a single blockchain account to which one unique private key is associated. However, using that wallet’s menus, that same seed phrase can be used to create additional blockchain accounts, each of which gets separately tracked in that same wallet, and each of which gets its own private key. In other words, within a wallet, there can be a single seed phrase to which multiple blockchain accounts, each with their own unique private key, can be connected. If a seed phrase is used to recover or recreate that same wallet on a different system or device, the newly recreated wallet should automatically list all of those accounts and their contents (fungible and non-fungible tokens) just as they appeared in the “old wallet.”
However, it’s also very important to know that if any blockchain accounts were imported into a wallet using just their private keys, then those blockchain accounts will not be associated with that wallet’s seed phrase. When this is the case, those accounts will not appear in a copy of the wallet that was recovered using the seed phrase.
When it comes to the different secrets that you might want to backup, there are three secrets having to do with cryptocurrency wallets and blockchain accounts that web3 users should be concerned with; a wallet’s password, a wallet’s seed phrase, and the private keys to one or more blockchain accounts. It’s very important to know the differences between each of these secrets because it’s relevant to the questions of what secrets should be backed up and then, what can be recovered once you have those secrets in hand.
When you install a wallet for the first time, you will be asked to create a password that can be later used to open that wallet. That password is only good for that installation of that wallet. If, for example, you use a wallet’s seed phrase to create a new copy of that wallet (see our FAQ: What is a seed phrase?), the password for that new copy is an entirely different password that is specific to that installation. You might set the password to be the same as the original copy. But that is effectively the same thing as using the same password for two completely unrelated services. You can create a completely different password for the second wallet and it will no way impact the password for the original.
For this reason, remembering the password for a wallet is important, but not as important as knowing the wallet’s seed phrase. However, even though you may have protected your seed phrase (eg: you have it backed up though something that supports the Decentralized Recovery protocol), the password is still worth protecting. For example, there are plenty of stories about people who lost their passwords to their wallet and, as a result, also lost access to all of their funds. If you lose your password, you should be able to recover the wallet or its individual blockchain accounts if you have the original wallet’s seed phrase or the private keys that go with each account. But if you don’t have either of those handy and you’ve lost your password to your wallet, you’ll be out of luck.
For this reason, we believe that you should consider backing up all of your secrets; passwords to any wallets, seed phrases, and the private keys to all of your blockchain accounts. In doing so, you’ll be covering yourself for pretty much anything that can go wrong.
In this FAQ, we’ll talk about the seed phrase. The first thing to know is that the phrase “seed phrase” is often used interchangeably with other phrases such as “seed”, “secret recovery phrase” (SRP), “recovery phrase,” ‘mnemonic phrase,” and “mnemonic device.”
When you install a cryptocurrency wallet for the first time, that wallet typically generates a unique seed phrase to which it is indelibly and forever associated. In other words, every new wallet gets its own unique seed phrase. These seed phrases are typically composed of 12, 18, or 24 commonly known words that occur in random order and those words are often drawn from a standard list of English words such as the BIP39 word list that consists of 2048 words starting with “abandon” and ending with “zoo.”
Although it’s an imperfect analogy, some people metaphorically think of a wallet’s seed phrase as though it’s a wallet’s master key. Regardless of whether you’ve lost track of your wallet’s password or any private keys to blockchain accounts that are associated with a wallet’s seed phrase, as long as you know the seed phrase for a wallet, you will always be able to recover that wallet. For example, if a wallet is installed on your computer and the hard drive of that computer is lost or crashes, you can use the seed phrase to recreate that same wallet on a different computer. Typically, when you install wallet software on a computer or a phone, you are given the choice of two options. You can initialize a new wallet with a new seed phrase or import an older wallet using its seed phrase. The “import option” is the option to use in order to recreate an existing wallet and after selecting it, you will be prompted for that seed phrase.
This is why it is so important to backup your seed phrases. Although blockchain accounts can be individually recovered if you know the private keys to them, a lost or destroyed wallet cannot be recovered if all you know is its password. And because blockchains and wallets involve entirely decentralized architectures, there is no IT department or central support number to call for help. There’s no shortage of horror stories about people who wanted to recover a lost wallet but who lost track of their seed phrase.
It’s also important to understand the operational difference between a seed phrase and a private key. When a wallet is first installed, it is typically initialized with its unique seed phrase and a single blockchain account to which one unique private key is associated. However, using that wallet’s menus, that same seed phrase can be used to create additional blockchain accounts, each of which gets separately tracked in that same wallet, and each of which gets its own private key. In other words, within a wallet, there can be a single seed phrase to which multiple blockchain accounts, each with their own unique private key, can be connected. If a seed phrase is used to recover or recreate that same wallet on a different system or device, the newly recreated wallet should automatically list all of those accounts and their contents (fungible and non-fungible tokens) just as they appeared in the “old wallet.”
However, it’s also very important to know that if any blockchain accounts were imported into a wallet using just their private keys, then those blockchain accounts will not be associated from that wallet’s seed phrase. When this is the case, those accounts will not appear in a copy of the wallet that was recovered using the seed phrase.
Hyperlink to this FAQ: What is a wallet password and how is it different from other passwords?
In the world of blockchain and cryptocurrency, there are three primary secrets that users should consider protecting and there are subtle differences between each of them. One of these is the password to your wallet, another is your wallet’s seed phrase, and the third are the private keys to your blockchain accounts.
Of these secrets, the reason the private key is such an important secret is that it’s literally the key that’s necessary in order to initiate or approve the transfer of any assets — primarily fungible (aka cryptocurrency) or non-fungible tokens — from the related blockchain account. If a blockchain account’s private key is lost, then the account’s user will likely lose access to the associated blockchain account and any assets attached to it.
Each of the three secrets is typically involved in the process of setting up a new wallet. Upon installation, most wallets create a default blockchain account and that account comes with a unique matched pair of keys, one of which is public and the other private. The latter of these keys – the private key – is a key that should be kept secret and, as secrets go, is a secret that’s worth protecting because of at least one scenario (the “imported account” scenario) where it’s tricky to recover if lost.
That scenario occurs when a user decides to import a specific blockchain account (along with its private key) into an existing wallet. Every time a new wallet is installed or initialized, it’s assigned a unique seed phrase (one of the other secrets that’s important to protect). According to our FAQ: What is a seed phrase?:
When you install a cryptocurrency wallet for the first time, that wallet typically generates a unique seed phrase to which it is indelibly and forever associated. In other words, every new wallet gets its own unique seed phrase. These seed phrases are typically composed of 12, 18, or 24 commonly known words that occur in random order and those words are often drawn from a standard list of English words such as the BIP39 word list that consists of 2048 words starting with “abandon” and ending with “zoo.”
Once a wallet is forever associated with its unique seed phrase, any new blockchain accounts that are created by that wallet (including the default blockchain account that was created at the moment of wallet initiation) are inextricably related to that seed phrase. If that wallet becomes lost, corrupted or otherwise inoperable, the entire wallet and any blockchain accounts that are associated with its seed phrase should be recoverable with one simple step: initiating a new wallet using the lost wallet’s seed phrase (as long as you still know what it is!). Whereas most wallet installations involve a newly generated seed phrase, they also include an option for creating a copy of a lost wallet from an existing seed phrase. This is why the seed phrase is also referred to as a “secret recovery phrase” or “SRP.” The phrase is not only a secret, it’s a secret that can be used to recover a lost wallet.
However, there is one situation where recovering a wallet with its SRP will not result in the recovery of a blockchain account that was managed with that wallet. One of the neat features of blockchain wallets is that they can also be used to manage blockchain accounts that are not associated with their own seed phrase. As long as you have the private key for a specific blockchain account – even if it comes from another wallet – you can import that account into any wallet.
Suppose you have two wallets – Wallet A and Wallet B – and you want to import one of Wallet A’s native accounts (an account that’s connected to Wallet A’s unique secret recovery phrase) into Wallet B. You can use Wallet A’s menus to discover the private key of that account. Then, using Wallet B’s menus, where the option exists to import an account, it will ask you for the private key to the account from Wallet A. Once you respond by entering that private key, the import will finish and then, you can use Wallet B to manage and transact with that imported account in the same way that you can manage and transact with any of Wallet B’s native accounts (accounts that were generated using Wallet B’s secret recovery phrase).
However, as they exist in Wallet B, imported accounts will not be associated with Wallet B’s seed phrase. And this is a key scenario where users sometimes lose access to their blockchain accounts.That’s because they mistakenly think that, as long as they have the secret recovery phrase for a wallet, they’ll be able to recover all of the accounts that are listed and managed with that wallet. But, unfortunately, the only accounts that can be recovered with a wallet’s SRP are accounts that were originally generated with that wallet’s SRP. In the Wallet A & B scenario, the imported account cannot be recovered with Wallet B’s SRP.
The only way to recover the imported account is to have the imported account’s private key or the secret recovery phrase to which it was originally associated. For these reasons, it’s also very important to not only treat the private keys belonging to your blockchain accounts as secrets, they should also be treated as secrets that must be protected from loss in the same way that you might guard any other secret.
Finally, it’s important to note that the wallet’s password is an important secret that should always provide you with access to a single installation of a wallet. If a wallet is lost or becomes otherwise inoperable and your only option is to create a new wallet, the lost wallet’s password will be of no use to you in the recovery process. To regain access to your blockchain accounts, you will need access to your secret recovery phrases or your accounts’ private keys or both.
Hyperlink to this FAQ: What is a private key to a blockchain account?
Although the open Decentralized Recovery (DeRec) Protocol was very much inspired by blockchain technology (in multiple ways), the protocol itself does not depend on blockchain or distributed ledger technology (DLT) for any part of its functionality.
Architecturally and culturally, blockchain technologies typically adhere to the concept of decentralization (see What is Decentralization and Why It Matters to the Protection and Recovery of Secrets?). In contrast to centralized systems, one of the unique selling propositions of a decentralized financial system such as the Bitcoin distributed ledger is that there’s no central operator or administrator of that system (and the same is mostly true of other public distributed ledgers).
But one side-effect of such a decentralized approach is that, unlike with centralized systems and services, that lack of a central operator or administrator also means that there’s no centrally operated safety net if something goes wrong for an end user of the system. For example, if an end-user loses access to the system because of a lost, forgotten or misplaced password, there’s no IT department or network administrator who can help that user recover or reset that password. In this respect, “decentralized” means that the responsibilities for many system functions are distributed to the users of the system. Users must be self-sufficient.
Therefore, when it comes to the credentials that are necessary for users to access their accounts on Bitcoin or any blockchain, it is the responsibility of those users to protect their own credentials from inadvertent loss. If those credentials are irrecoverably lost, then so too is access to the associated blockchain accounts and any assets (fungible or non-fungible tokens) attributed to them. There are many horror stories about people who’ve lost enormous sums of money due to the permanent loss of their blockchain credentials.
That lack of a blockchain credential safety net was one of the major inspirations for the DeRec Protocol. The protocol makes it possible for blockchain users to, in truly decentralized fashion, create their own safety nets. But, the way the DeRec Protocol works, blockchain itself plays no role in forming, supporting, or providing those safety nets. At the end of the day, the DeRec protocol is about protecting secrets from loss. In addition to the three key credentials typically used to access public blockchain accounts – wallet passwords, mnemonic phrases, and private keys – the DeRec protocol can be used to protect any secret, blockchain-related or not (see Understanding the Types of Secrets That Can Be Protected with the DeRec Protocol).
Hyperlink to this FAQ: Does the DeRec Protocol rely on blockchain technology?
Similar to everyday contracts in the analog world, a smart contract includes terms that specify what actions should be taken once certain conditions are met. However, unlike with analog contracts where it is up to humans to make sure that a contract’s obligations are met, with smart contracts, a smart contract is encoded as computer software so the terms are automatically executed and the obligations are automatically satisfied once the pre-defined conditions are met.
A smart contract is considered “smart” because it’s actually a computer program whose programming code (1) defines the contract’s conditions and (2) automates the satisfaction of the contract’s obligations. For example, suppose you and an employer agree to the following terms:
- You will get paid 5 Eth (the native token of the Ethereum blockchain) per 40 hours of work
- You will make a computerized record of your hours worked at the end of each time-block worked
- When you have recorded the 40th hour of work, your employer will initiate a transfer of 5 Eth from its Ethereum account into your Ethereum account within 1 minute
These terms involve obligations to both you and your employer. With a regular everyday analog contract, once you have met your obligations, your employer is obligated to manually satisfy their obligation(s). If that obligation is not met, you may have to remedy your employer’s breach of contract by means of arbitration or a lawsuit.
With a smart contract, the terms are pre-defined with a computer program – a smart contract – that is loaded onto a public blockchain like Ethereum. Before a smart contract program can automatically satisfy the obligations of any parties or counter-parties, at least some of those parties will use the private key to their blockchain account (see our FAQ: What is a private key to a blockchain account?) to authorize the contract’s intentions. Then, as the computerized record of your work approaches the end of each 40 hour time block worked, that program is watching and waiting for the total to reach 40 hours. Once the 40 hour condition is met, the program automatically initiates a transfer of 5 Eth from your employer’s Ethereum account to your Ethereum account without the involvement of humans or middlemen like banks (which typically play a role in traditional contracts with financial obligations).
As with all computer programs, a smart contract’s programming code must first be written (usually by a human but maybe by artificial intelligence in the future) and then, once the code is ready to be put into action, it must be loaded into a special computer that understands the programminig language in which the program was written. In the world of blockchain, most of these computers are virtual in nature and are therefore referred as virtual machines. Smart contracts that run on the Ethereum public blockchain depend on the Ethereum Virtual Machine (EVM). Other blockchains also use the EVM as their virtual machine but many chains have their own non-EVM virtual machines.
Smart contracts are relevant to the open Decentralized (DeRec) Protocol in at least two ways. First, most smart contract interactions (eg: using your private key to authorize one) take place with the help of a cryptocurrency wallet. This is yet another reason why it’s so important to protect yourself against the loss of your wallet’s seed phrase (see our FAQ: What is a seed phrase?) and the private keys that go with your blockchain accounts. Inadvertent loss of these important secrets could result in loss of access to smart contracts as well as to pre-defined in- or out-bound assets flows.
See also: Understanding what types of secrets can be protected with the DeRec Protocol
Second, smart contracts also serve as the programmable basis for smart wallets and smart wallets are key to the functionality of the ERC-4337 specification for account abstraction. Under the guise of “social login” and “social recovery,” the ERC-4337 spec is sometimes discussed in the context of using third party providers of federated identity systems as smart wallet identity management providers.
A federated identity system like those offered by Google, Facebook, X, and other social networks make it possible for you to login to other online services with your ID and password. For example, instead of establishing a new user ID and password, many websites make it possible to register and login with your existing Google user ID and password instead (thereby simplifying the number of user IDs and passwords that you have to manage). Not all providers of such federated identity capabilities are social networks. Even so, the capability is commonly referred to as a “social login.”
Although Google, Facebook and other popular federated identity providers do not support ERC-4337, the specification makes it possible for other providers and startups to act in a similar role as both federated social identity provider and a user’s proxy to an ERC-4337 compliant blockchain “account.” When you login to your federated ID with your so-called “social login,” you are also given access to your blockchain accounts, usually through a smart wallet offered by that same provider. This is different from using a regular software wallet with its seed phrase or private keys to access a blockchain account. Similar to the recovery process if you lose your Google or Facebook login, once you start using an ERC-4337 compliant social login to access your blockchain accounts, the provider of that social login (and associated smart wallet) can also help you recover your login credentials should you happen to lose them. Thus, the phrase “social recovery.”
For these reasons, the DeRec Alliance is sometimes asked about the differences between ERC-4337 style social recovery and DeRec style decentralized recovery. For more information on the differences between the two, please read our FAQ: How does decentralized recovery compare to social recovery on Ethereum?.