algorandfoundation · tasosbit · Jun 17, 2025 · Jun 17, 2025 · Jun 17, 2025 · cusma
diff --git a/ARCs/arc-0085.md b/ARCs/arc-0085.md
@@ -0,0 +1,74 @@
+---
+arc: 85
+title: Revocable Decentralized Recovery (ReDeRec)
+description: Revocable Decentralized Recovery protocol utilizing rekeying and multisigs instead of sharing mnemonic shards.
-description: Revocable Decentralized Recovery protocol utilizing rekeying and multisigs instead of sharing mnemonic shards.
+description: Revocable Decentralized Recovery protocol utilizing rekeying and multi-signatures instead of sharing mnemonic shards.
-description: Revocable Decentralized Recovery protocol utilizing rekeying and multisigs instead of sharing mnemonic shards.
+description: Revocable Decentralized Recovery protocol utilizing rekeying and multi-signatures instead of sharing mnemonic shards.
+author: Tasos Bitsios (@tasosbit)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/344
+status: Draft
+type: Standards Track
+category: ARC
+subcategory: Wallet
+created: 2025-06-18
+---
+
+## Abstract
+This ARC outlines a new approach to Decentralized Recovery which enables revocability. Instead of sharing private key shards with custodians, an Algorand account can be rekeyed to a specially crafted multisig so that the owner account can self-sign, and the recovery custodians can combine in a multisig threshold fashion (2/3, 3/4, etc) to help recover the account. Self-signing is enabled by repeating the owner account's key in the subsigners field, in order to satisfy the threshold requirement as a standalone signer. Revoking custodians is as simple as rekeying to another authorizer account.
-This ARC outlines a new approach to Decentralized Recovery which enables revocability. Instead of sharing private key shards with custodians, an Algorand account can be rekeyed to a specially crafted multisig so that the owner account can self-sign, and the recovery custodians can combine in a multisig threshold fashion (2/3, 3/4, etc) to help recover the account. Self-signing is enabled by repeating the owner account's key in the subsigners field, in order to satisfy the threshold requirement as a standalone signer. Revoking custodians is as simple as rekeying to another authorizer account.
+This ARC outlines a new approach to _Decentralized Recovery_, which enables revocability. Instead of sharing private key shards with custodians, an Algorand account can be rekeyed to a weighted multi-signature so that the owner account can self-sign, and the recovery custodians can combine in a multi-signature threshold fashion (2/3, 3/4, etc.) to help recover the account. Self-signing is enabled by repeating the owner account's key in the sub-signers field, to satisfy the threshold requirement as a standalone signer. Revoking custodians is as simple as rekeying to another authorizer account.
-This ARC outlines a new approach to Decentralized Recovery which enables revocability. Instead of sharing private key shards with custodians, an Algorand account can be rekeyed to a specially crafted multisig so that the owner account can self-sign, and the recovery custodians can combine in a multisig threshold fashion (2/3, 3/4, etc) to help recover the account. Self-signing is enabled by repeating the owner account's key in the subsigners field, in order to satisfy the threshold requirement as a standalone signer. Revoking custodians is as simple as rekeying to another authorizer account.
+This ARC outlines a new approach to _Decentralized Recovery_, which enables revocability. Instead of sharing private key shards with custodians, an Algorand account can be rekeyed to a weighted multi-signature so that the owner account can self-sign, and the recovery custodians can combine in a multi-signature threshold fashion (2/3, 3/4, etc.) to help recover the account. Self-signing is enabled by repeating the owner account's key in the sub-signers field, to satisfy the threshold requirement as a standalone signer. Revoking custodians is as simple as rekeying to another authorizer account.
+
+## Motivation
+Sharing private key shards for decentralized recovery purposes is a concern that is worth addressing. This ARC improves upon the irrevocable nature of "classic" decentralized recovery by introducing an "active-state" method to achieve the same result without the potential for private key compromise if enough shards are compromised over time.
-Sharing private key shards for decentralized recovery purposes is a concern that is worth addressing. This ARC improves upon the irrevocable nature of "classic" decentralized recovery by introducing an "active-state" method to achieve the same result without the potential for private key compromise if enough shards are compromised over time.
+Sharing private key shards for decentralized recovery purposes is a concern worth addressing. This ARC improves upon the irrevocable nature of "classic" decentralized recovery by introducing an "active-state" method to achieve the same result without the potential for private key compromise if enough shards are compromised over time.
-Sharing private key shards for decentralized recovery purposes is a concern that is worth addressing. This ARC improves upon the irrevocable nature of "classic" decentralized recovery by introducing an "active-state" method to achieve the same result without the potential for private key compromise if enough shards are compromised over time.
+Sharing private key shards for decentralized recovery purposes is a concern worth addressing. This ARC improves upon the irrevocable nature of "classic" decentralized recovery by introducing an "active-state" method to achieve the same result without the potential for private key compromise if enough shards are compromised over time.
+
+## Specification
+The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**", and "**OPTIONAL**" in this document are to be interpreted as described in <a href="https://www.ietf.org/rfc/rfc2119.txt">RFC-2119</a>.
+
+An active decentralized recovery signer account is a multi-signature composed the owner account and the "custodian" accounts.
-An active decentralized recovery signer account is a multi-signature composed the owner account and the "custodian" accounts.
+An active decentralized recovery signer account is a weighted multi-signature with threshold `T`, composed of the Owner and the Custodians (`C`).
-An active decentralized recovery signer account is a multi-signature composed the owner account and the "custodian" accounts.
+An active decentralized recovery signer account is a weighted multi-signature with threshold `T`, composed of the Owner and the Custodians (`C`).
+
+- The Owner Account (OA) MUST be able to sign for transactions without requiring signatures from any other party.
- The Owner Account (OA) MUST be able to sign for transactions without requiring signatures from any other party.
+- The Owner **MUST** be able to sign for transactions without requiring signatures from any other party.
- The Owner Account (OA) MUST be able to sign for transactions without requiring signatures from any other party.
+- The Owner **MUST** be able to sign for transactions without requiring signatures from any other party.
+- Custodian accounts (CAs) MUST be able to sign for transactions when enough signatures are presented to meet the recovery threshold.
- Custodian accounts (CAs) MUST be able to sign for transactions when enough signatures are presented to meet the recovery threshold.
+- Custodians' signature weight **MUST** be equal to 1.
+- A _single_ Custodian **MUST NOT** be able to sign for transactions.
+- Any group of `K` out of `C` Custodians, with `K <= C`, **MUST** be able to sign for transactions.
- Custodian accounts (CAs) MUST be able to sign for transactions when enough signatures are presented to meet the recovery threshold.
+- Custodians' signature weight **MUST** be equal to 1.
+- A _single_ Custodian **MUST NOT** be able to sign for transactions.
+- Any group of `K` out of `C` Custodians, with `K <= C`, **MUST** be able to sign for transactions.
+- The recovery threshold (T) is the number of CA signatures required to recover an account.
- The recovery threshold (T) is the number of CA signatures required to recover an account.
+Given the requirements, a ReDeRec account **MUST** be a `T` out of `N` weighted threshold multi-signature with:
+
+- `T = K > 1`;
+- `N = T + C`.
- The recovery threshold (T) is the number of CA signatures required to recover an account.
+Given the requirements, a ReDeRec account **MUST** be a `T` out of `N` weighted threshold multi-signature with:
+
+- `T = K > 1`;
+- `N = T + C`.
+- The OA is repeated in the multisig sub-signers group T times, in order to be able to self-sign.
- The OA is repeated in the multisig sub-signers group T times, in order to be able to self-sign.
+- The Owner address **MUST** be repeated (weighted) in the multi-signature sub-signers group `T` times.
- The OA is repeated in the multisig sub-signers group T times, in order to be able to self-sign.
+- The Owner address **MUST** be repeated (weighted) in the multi-signature sub-signers group `T` times.
+
+Note: Algorand allows for a single-signature account to be rekeyed to a multisig wherein the single-sig is its own sub-signer, which enables users to use this pattern without requiring a new private key (and corresponding mnemonic to save.)
-Note: Algorand allows for a single-signature account to be rekeyed to a multisig wherein the single-sig is its own sub-signer, which enables users to use this pattern without requiring a new private key (and corresponding mnemonic to save.)
+> Algorand allows for a single-signature account to be rekeyed to a multi-signature wherein the single-sig is its own sub-signer, which enables users to use this pattern without requiring a new private key (and corresponding mnemonic to save.)
-Note: Algorand allows for a single-signature account to be rekeyed to a multisig wherein the single-sig is its own sub-signer, which enables users to use this pattern without requiring a new private key (and corresponding mnemonic to save.)
+> Algorand allows for a single-signature account to be rekeyed to a multi-signature wherein the single-sig is its own sub-signer, which enables users to use this pattern without requiring a new private key (and corresponding mnemonic to save.)
+
+Example: Alice wants to add Bob, Eve and Steve as recovery custodians to her account. She wants any 2 of the 3 custodians to be able to help her recover her account.
-Example: Alice wants to add Bob, Eve and Steve as recovery custodians to her account. She wants any 2 of the 3 custodians to be able to help her recover her account.
+## Example
+
+Alice wants to add Bob, Eve, and Steve as _recovery custodians_ to her account. She wants any 2 (`K`) of the 3 (`C`) custodians to be able to help her recover her `T` out of `N` weighted multi-signature account with `T = K = 2` and `N = T + C = 5`.
-Example: Alice wants to add Bob, Eve and Steve as recovery custodians to her account. She wants any 2 of the 3 custodians to be able to help her recover her account.
+## Example
+
+Alice wants to add Bob, Eve, and Steve as _recovery custodians_ to her account. She wants any 2 (`K`) of the 3 (`C`) custodians to be able to help her recover her `T` out of `N` weighted multi-signature account with `T = K = 2` and `N = T + C = 5`.
+
+Owner Account: `ALICE234..`
+
+Custodians:
+- `BOB345..`
+- `EVE456..`
+- `STEVE567..`
+
+Threshold: 2
+
+Multisig configuration:
+
+```
+{
+    version: 1,
+    threshold: 2,
+    addrs: [
+        "ALICE234..",
+        "ALICE234..",
+        "BOB345..",
+        "EVE456..",
+        "STEVE567..",
+    ]
+}
+```
+
+## Backwards Compatibility
+This method requires a wallet that supports rekeying and multi-signature accounts. Beyond that on-chain compatibility should be 100%, as transaction signature schemes are transparent as far as Applications are concerned. Off-chain systems validating account ownership for "login" functionality must be able to support multi-sig accounts.
-This method requires a wallet that supports rekeying and multi-signature accounts. Beyond that on-chain compatibility should be 100%, as transaction signature schemes are transparent as far as Applications are concerned. Off-chain systems validating account ownership for "login" functionality must be able to support multi-sig accounts.
+
+- On-Chain: Guaranteed, as both _multisig_ and _rekey_ are native protocol features, and transaction signature schemes are transparent to Applications.
+
+- Off-Chain: Wallet **MUST** support _rekeying_ and _multisig_ accounts. Off-chain systems validating account ownership for "login" functionality **MUST** support _multisig_ accounts.
-This method requires a wallet that supports rekeying and multi-signature accounts. Beyond that on-chain compatibility should be 100%, as transaction signature schemes are transparent as far as Applications are concerned. Off-chain systems validating account ownership for "login" functionality must be able to support multi-sig accounts.
+
+- On-Chain: Guaranteed, as both _multisig_ and _rekey_ are native protocol features, and transaction signature schemes are transparent to Applications.
+
+- Off-Chain: Wallet **MUST** support _rekeying_ and _multisig_ accounts. Off-chain systems validating account ownership for "login" functionality **MUST** support _multisig_ accounts.
+
+## Test Cases
+TODO
+
+## Reference Implementation
+TODO
+
+## Security Considerations
+Note that when accounts are closed out (i.e. taken to a zero ALGO balance) their rekeying status reverts to the default, so users of active DeRec are RECOMMENDED to maintain a minimum balance requirement above the base account MBR (0.1 ALGO) as a safety precaution against accidental close-outs.
-Note that when accounts are closed out (i.e. taken to a zero ALGO balance) their rekeying status reverts to the default, so users of active DeRec are RECOMMENDED to maintain a minimum balance requirement above the base account MBR (0.1 ALGO) as a safety precaution against accidental close-outs.
+Note that when accounts are closed out (i.e., taken to a zero ALGO balance), their rekeying status reverts to the default, so users of active DeRec are **RECOMMENDED** to maintain a minimum balance requirement above the base account MBR (0.1 ALGO) as a safety precaution against accidental close-outs.
-Note that when accounts are closed out (i.e. taken to a zero ALGO balance) their rekeying status reverts to the default, so users of active DeRec are RECOMMENDED to maintain a minimum balance requirement above the base account MBR (0.1 ALGO) as a safety precaution against accidental close-outs.
+Note that when accounts are closed out (i.e., taken to a zero ALGO balance), their rekeying status reverts to the default, so users of active DeRec are **RECOMMENDED** to maintain a minimum balance requirement above the base account MBR (0.1 ALGO) as a safety precaution against accidental close-outs.
+
+Availability of the custodian account private keys is not enforced in this standard. A periodic heartbeat mechanism could be built for CA subsigners to prove that their private keys are still available.
-Availability of the custodian account private keys is not enforced in this standard. A periodic heartbeat mechanism could be built for CA subsigners to prove that their private keys are still available.
+This standard does not enforce the availability of the custodian account's private keys. It is **RECOMMENDED** to adopt a periodic heartbeat mechanism for Custodian sub-signers to prove that their private keys are still available.
-Availability of the custodian account private keys is not enforced in this standard. A periodic heartbeat mechanism could be built for CA subsigners to prove that their private keys are still available.
+This standard does not enforce the availability of the custodian account's private keys. It is **RECOMMENDED** to adopt a periodic heartbeat mechanism for Custodian sub-signers to prove that their private keys are still available.
+
+## Copyright
+Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.