How to Set Up Guardian-Based Recovery, and What the App Currently Gets Wrong

Guardian recovery means a group of people you choose can restore your access without any of them being able to take it alone. Setting it up is three decisions and one on-chain write.

First, a correction, because you will hit it in the first minute

The add-guardian dialog says that identifier-based guardians accept automatically in about four seconds, so you can watch the status change.

They do not. We read the invite handler: it writes a row whose status column defaults to pending, and the only thing that sets it to confirmed is a separate function the invited party calls. There is no timer.

Two controls make that a measurement rather than a guess. Timers exist in seven files of this interface, so a search finds them, and the only one in the recovery area drives the drill animation rather than the invite. And the confirm function exists as its own export, so it would have been found in the invite handler if it were there.

The note is left over from an earlier mock version of the screen. Expect pending to stay pending until a real person accepts, and do not read the delay as a bug in your setup.

The three decisions

Who. People who can be reached independently of your phone and who are unlikely to lose access at the same time as you. Choosing them badly is the most common way this fails.

How many. The chain enforces a minimum of three, verified live: a policy naming two is rejected with a message saying a recovery policy needs at least three guardians. The interface surfaces that floor so you do not discover it as a failed transaction.

How many must agree. Your threshold. Lower is easier to recover with and easier to abuse; higher is safer and easier to lock yourself out of. The arithmetic of that trade has its own page.

The setup, in order

Invite each guardian. Name plus either their identifier or an email address. An identifier-based invite pre-links the relationship if they already have a wallet here; an email invite has no identifier attached until they accept.

Wait for real confirmations. Only guardians who are both confirmed and identifier-backed count toward your threshold. An email invite that has never been accepted counts for nothing, which is correct and is also the thing people miss.

Write the policy on-chain. This is the step that matters. It signs an identity-document update naming the confirmed guardians and the threshold, and relays it.

Without that write, you have a contact list and not a recovery policy. Invitations alone protect nothing.

How the policy is signed

The signature uses your identity key, which means entering your recovery phrase for that one operation. The phrase is used ephemerally and never stored, consistent with the rest of the wallet, where keys live in memory only and a reload locks everything.

So setting a policy costs you one phrase entry. That is a small friction protecting a large decision, and it is the right place for it.

After you set it

Test it. A recovery policy nobody has exercised is a belief rather than a capability, and testing it is its own guide.