ARC-85: Revocable Decentralized Recovery (ReDeRec) by tasosbit · Pull Request #344 · algorandfoundation/ARCs

tasosbit · 2025-06-17T22:46:55Z

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 accounts ("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 keys in the subsigners field, in order to satisfy the threshold requirement as a standalone signer. Revoking custodians is as simple as rekeying to another account.

For those unfamiliar with GitHub, you can view an easily readable version of the proposal here: https://github.com/tasosbit/ARCs/blob/arc85-active-derec/ARCs/arc-0085.md

TODO:

[ ] Test cases
[ ] Reference Implementation?

tasosbit · 2025-06-18T22:47:53Z

Validated the proof of concept with goal and documented it here: https://gist.github.com/tasosbit/493a4cd82c4d950efb463ad11a2efa02

cusma · 2025-06-19T09:35:08Z

ARCs/arc-0085.md

+---
+
+## 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.


Suggested change

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.

cusma · 2025-06-19T09:36:05Z

ARCs/arc-0085.md

+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.
+
+## 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.


Suggested change

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.

cusma · 2025-06-19T09:36:33Z

ARCs/arc-0085.md

+## 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.


Suggested change

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`).

cusma · 2025-06-19T09:36:54Z

ARCs/arc-0085.md

+
+An active decentralized recovery signer account is a multi-signature composed the owner account and the "custodian" accounts.
+
+- The Owner Account (OA) MUST be able to sign for transactions without requiring signatures from any other party.


Suggested change

- 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.

cusma · 2025-06-19T09:37:10Z

ARCs/arc-0085.md

+An active decentralized recovery signer account is a multi-signature composed the owner account and the "custodian" accounts.
+
+- The Owner Account (OA) 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.


Suggested change

- 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.

cusma · 2025-06-19T09:39:54Z

ARCs/arc-0085.md

+
+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.)
+
+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.


Suggested change

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`.

cusma · 2025-06-19T09:42:19Z

ARCs/arc-0085.md

+
+- The Owner Account (OA) 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.
+- The recovery threshold (T) is the number of CA signatures required to recover an account.


Suggested change

- 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`.

cusma · 2025-06-19T09:47:03Z

ARCs/arc-0085.md

+```
+
+## 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.


Suggested change

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.

cusma · 2025-06-19T09:47:43Z

ARCs/arc-0085.md

+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.


Suggested change

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.

cusma · 2025-06-19T09:48:52Z

ARCs/arc-0085.md

+## 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.
+
+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.


Suggested change

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.

cusma · 2025-06-19T14:25:46Z

ARCs/arc-0085.md

+---
+arc: 85
+title: Revocable Decentralized Recovery (ReDeRec)
+description: Revocable Decentralized Recovery protocol utilizing rekeying and multisigs instead of sharing mnemonic shards.


Suggested change

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.

acfunk · 2025-06-24T01:45:59Z

When discussing wallets in the Backwards Compatibility section, it may be worth mentioning that while Multi-Sig support is required, an additional feature of bypassing the signature collection step when the signer has enough weight is highly encouraged to make the UX bearable.

cusma · 2026-03-27T15:59:07Z

@tasosbit: is there any intention or plan to push this ARC forward?

arc85: active DeRec

eb56792

github-actions bot added c-new s-draft t-arc labels Jun 17, 2025

arc85: rename, minor grammar, link to discussions

4f2455b

tasosbit changed the title ~~ARC-85: Active DeRec (Revocable Decentralized Recovery)~~ ARC-85: Revocable Decentralized Recovery (ReDeRec) Jun 17, 2025

arc85: fix: link to discussions

d717936

cusma reviewed Jun 19, 2025

View reviewed changes

	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.

	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.

		- 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.

-- 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.


		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.)

		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`.

-- 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`.

-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.

	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.
	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.

	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.

Conversation

tasosbit commented Jun 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tasosbit commented Jun 18, 2025

Uh oh!

cusma Jun 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cusma Jun 19, 2025

Choose a reason for hiding this comment

Uh oh!

cusma Jun 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cusma Jun 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cusma Jun 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cusma Jun 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cusma Jun 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cusma Jun 19, 2025

Choose a reason for hiding this comment

Uh oh!

cusma Jun 19, 2025

Choose a reason for hiding this comment

Uh oh!

cusma Jun 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cusma Jun 19, 2025

Choose a reason for hiding this comment

Uh oh!

acfunk commented Jun 24, 2025

Uh oh!

cusma commented Mar 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

tasosbit commented Jun 17, 2025 •

edited

Loading

cusma Jun 19, 2025 •

edited

Loading

cusma Jun 19, 2025 •

edited

Loading

cusma Jun 19, 2025 •

edited

Loading

cusma Jun 19, 2025 •

edited

Loading

cusma Jun 19, 2025 •

edited

Loading

cusma Jun 19, 2025 •

edited

Loading

cusma Jun 19, 2025 •

edited

Loading