Is rekeying non-custodial?

General
1

Can someone help me resolve an internal debate with my team?

Does rekeying render a wallet custodial? Any comments as to why or why not would be hugely appreciated!

2

Hi @Brad,

When you rekey the Account A to Account B you are basically declaring to the consensus protocol that: “from now on any action by Account A must be be signed and authorised by Account B”, whatever the type of authorisation of Account B is (single signature, multi signature, smart signature).

So, to specifically address your question, this does not imply directly a switch between custodial or non-custodial key management.

The question should be reframed as: “Is the owner of Account A also in charge of Account B’s signatures?”, if yes then the rekey is non-custodial, if no then the rekey is giving to someone else the “custody” of Account A’s signatures.

1 Like
3

Thanks so much for the reply. Just one more question. Can rekeying be controlled solely by the owner of Account A without intervention of an administrator?

I am asking because we are building an application that will be used in rural areas in developing countries, starting in Uganda. We want wallets to be non-custodial but compromised wallets and lost seed phrases are expected. In theory, rekeying could be a solution to allowing users to regain or restore control of their public addresses while keeping the wallets non-custodial.

However, when a user is unable to access their account (e.g. lost phone), wouldn’t there need to be an administrator to manage the rekeying process? And would the ability of an administrator to rekey a wallet render it non-custodial?

Again, any feedback would be welcome!
Thanks,
Brad

4

The rekey must be executed by who is currently in charge of Account’s authorisation.

So, if User A is in charge of Account A’s authorisation then only User A can execute the rekey, external accounts (e.g. a system admin) can not rekey Account A on User A’s behalf.

If you want an account recovery strategy you have to deal with a Trusted Parties, with different approaches. Here three possible scenarios (there could be others):

  1. Account A is a single signature account. The Trusted Custody Party has the custody of User A’s private key directly. In this scenario the corruption of the Trusted Custody Party damages User A.

  2. Account A is a 1 out of 2 multi-signature, in which User A controls key 1 while the recovery key 2 is safely held by the Trusted Recovery Party, encrypted, with no access to it. In this scenario you don’t need cooperation between User A and Trusted Recovery Party to sign actions for Account A, while only User A has access to the recovery key 2, safely custodied by the Trusted Recovery Party. This scenario is not too different form the previous one, since a corruption of the Trusted Recovery Party is equivalent to the corruption of the Trusted Custody Party in scenario 1.

  3. Account A is a 2 out of 3 multi-signature, in which User A controls key 1, the Trusted Custody Party controls key 2, while the recovery key 3 is safely held by the Trusted Recovery Party, encrypted, with no access to it. In this scenario you need cooperation between User A and Trusted Custody Party to sign actions for Account A, while only User A has access to the recovery key 3, safely custodied by the Trusted Recovery Party. In this scenario the corruption of the Trusted Custody Party alone dose not damage User A.

5

Thanks so much for this. It’s very helpful! I’ve passed your comments on to the development team.