How it works
A non-technical, step-by-step journey in creating and using dEOAs
Distributed Externally Owned Accounts: The result of the protocol, it's a unique type of externally-owned account with no private key
Proposers and Participants: Any end-user or account included in a dEOA are considered participants. Participants are still identified by a traditional EOA - they use existing accounts, managed by wallets, to use the account. Any participant can also propose actions for the dEOA. Participants may be part of a group - like a DAO - or several accounts held by one individual.
No Private Key: The dEOAs created by the protocol have no private key. The ownership is cryptographically distributed across participants with "key shares"
Key Shares: dEOA participants hold Key Shares. These are cryptographically linked to the dEOA, but individually cannot compromise the dEOA. They are used together with other shares to form signatures for the dEOA, authorizing actions like transactions, smart contract interactions, and messages.
Threshold Signatures: In order to use a dEOA, participants form Threshold Signatures. It's like a multisig, but better. A threshold - a % of participation - to form valid signatures. This threshold is adjustable for each dEOA, but typically is a simple majority. Unlike multisigs, threshold signatures are cryptographic, can be formed offline, and can be used on any compatible network.
Storage, Encryption, Communication, Verification, and more: Participants don't need to worry about storing their key shares, they're backed up on-chain and are fully encrypted. As long as a participant has their identifying account, they can recover their key share for the dEOA.
The protocol also assumes all communication are public and unsecured. The default is on-chain, but developers can choose to use other decentralized channels like LibP2P, or other channels like SMS or chat applications. All information for verification is stored on-chain using a system of smart contracts.
Pre-registration & Pre-requisites
Each participant in a dEOA must have an existing standard EOA as their identity. This can be as simple as a browser wallet account, and can be provided to end-users by developers using the SDK. The public address of each intended participant is required to propose a new account. Before creating a new dEOA, participants must confirm their participation via standard message, provided by the SDK. Participant addresses are used for communication, encryption, and storage.
Proposing a new account
Anyone can propose a new dEOA. To do so, they provide the public addresses of other participants, and set initial settings for the new dEOA, such as signing threshold. Once other participants have confirmed their participation, the protocol handles the rest, and the resulting public address for the dEOA is returned. Participants never interact directly with their keyshares.
Participating in a new account
Other participants will receive an invitation to join in any INTU-enabled application, such as Intu's interface. As a developer using the SDK, this can be built in natively to your dapp or application. Once participants agree to join, the protocol handles the rest. Qualified, intended participants will receive the new dEOA public address, and have a key share associated to their account.
Proposing a new transaction, message, or signature
In order to use a dEOA - send funds, interact with dapps, etc - participants need to form signatures. The protocol uses Threshold Signatures, which means that 100% participation is not required, and signatures can be formed offline/off-chain. These signatures, in turn, can be used to authorize transactions, messages, or smart contract interactions.
In order to start a signature, a participant must propose a signature, and include the transaction, message, or interaction which must be authorized. These can be formed by an external dapp or service, or within an Intu-enabled wallet or dapp.
The proposal is signed using the proposer's key share, and shared with other participants for approval.
Co-signing a proposed transaction, message, or signature
Other participants in the dEOA will receive a notification to co-sign a proposed signature.
If they disagree, no action is required.
If they approve, the protocol will recover, decrypt, and use their key share to form a partial signature, which is automatically shared with the dEOA.
Once enough partial signatures have been created - once threshold has been met - any participant can aggregate the partial signatures and broadcast the approved signature on-chain.
Brief introduction to "Key Resharing"
One of the most exciting parts of the dEOA protocol is key resharing. This means that key shares for individual participants are not permanent, and can be revoked, re-issued, and otherwise be used freely in Web3 with more confidence. Key resharing requires nothing more than simple approval from participants of a dEOA. Once enough participants have agreed, new shares will be issued and existing shares will be revoked
Key Resharing provides a means for several key benefits of dEOAs, including:
- Account Recovery, or using other participant shares to revoke and re-issue a lost share. If all shares are lost, there is no straight-forward recovery, but in most cases dEOAs are resilient up to the loss of a simple minority of shares
- Dynamic Ownership, or being able to add and remove participants all together. When adding or removing participants, existing shares are revoked, re-generated, and distributed across the new group of qualified participants
- Proactive Security, or a regular re-issuing of key shares, "just in case". It's typically understood that the longer a password or key has been in use, the more likely it has been compromised. Key Resharing-enabled Proactive Security protects the dEOA and resets the threat counter to zero.
Proposing a new "Key Resharing"
Proposing a Key Resharing is similar to forming a transaction - in fact, the approval is a threshold signature. The proposal specifies the conditions of the resharing - whether to add or remove a participant, refresh all existing keyshares, or issue a new share.
Once the proposal is formed, the proposer signs using their key share, and shares with other participants for approval.
Once approval has been made, approving participants and new participants are provided new key shares by the protocol. It's worth noting that the key resharing threshold is different than the signature threshold. This allows dEOAs to enjoy a certain degree of governance, and require greater consensus before adding/removing participants, or otherwise modifying key shares.
Participating in a new "Key Resharing"
For other participants, the experience is similar to approving transactions. They will receive a notification, and either approve or deny the Key Resharing. Once approved, no further action is required from the end-user.
The protocol also allows for some basic account management. At the moment, the following options can be changed with dEOA participant approval:
- Adjusting Signature Threshold
- Adjusting Resharing Threshold
- View Current and Past Participants
Last modified 1mo ago