# **Recovery**

A not.bot™ identity is controlled by cryptographic keys the user holds. Keys get lost. A phone falls in a lake or gets stolen. An identity that cannot survive the loss of its keys is not usable.

Recovery has to do two things that work against each other. It restores control to the legitimate owner when their keys are gone, and it denies that same path to an attacker trying to seize the identity. A recovery mechanism loose enough to be convenient is also an attack surface for theft and for denial of service. The `did:julia` protocol makes recovery configurable per identity; today, every not.bot identity runs the standard configuration Julia Social operates, and the owner sets up nothing beyond a recovery password.

This document covers recovery in two parts. The first describes what recovery looks like for an owner: the one password they choose in advance, what happens when their keys are gone, and what protects them along the way. The second goes under that surface to the `did:julia` protocol and the infrastructure that carry it out.

## **Recovery from the owner's side**

The only recovery setup an owner does is choosing a recovery password at enrollment. There is nothing else to configure, designate, or arm; every enrolled user has recovery from the moment they enroll. The app has no recovery-agents screen, no delay setting, and no recovery configuration of any kind. Unlike a social-recovery crypto wallet, not.bot does not ask the user to designate guardians or set a timelock. The multi-agent arrangements described later in this document are protocol infrastructure that arrives with third-party recovery agents, not settings in the app.

### **Backing up user data for recovery**

When the user first sets up not.bot, they will select a recovery password. The recovery password protects the data backup used to restore the user's data after recovery. The backup is encrypted using a key derived from that password, and whoever holds the backup, Julia Social today, cannot read it without the password. The same backup brings the identity onto a new device when the owner adds one, so the password has to outlast the phone. [The not.bot App (Doc #5)](https://not.bot/learn/the-app/) covers adding a device.

The app guards against a forgotten password in two ways. It asks the user to re-enter the recovery password from time to time, so a lapse surfaces while a device is still in hand. And it lets the user set a new password after a biometric or device passcode check, without knowing the old one. Both serve the same end: the owner has to know the password on the day recovery needs it.

The data backup includes all of the user's aliases and contacts, but does not include their history of signatures created and scanned. The backup does not include the cryptographic keys that control the not.bot identity and aliases.

### **Getting the identity back**

Recovery starts on a new device. The app generates fresh keys, the owner proves their identity by re-scanning their passport, and Julia Social records the initiated recovery process onto the blockchain. Once that happens, the recovery blocks any other device that still has access to the identity. From there the not.bot identity waits through a fixed delay before control passes to the new device. Julia Social has set that delay at 48 hours.

Imagine an attacker gets hold of an owner's passport and initiates a recovery onto the attacker's own phone. The owner might hand the passport to someone believing they need it for a legitimate purpose, and that person initiates a recovery before handing it back. The recovery is visible on the blockchain; future "watchtower" services could monitor an owner's not.bot for recoveries and alert the owner when one starts. During the 48-hour delay, the recovery can be canceled by the legitimate owner scanning the passport again. Even if the false recovery succeeds, the legitimate owner can recover the not.bot identity with another passport scan. A completed theft does not lock the owner out for good.

When the wait ends, the app downloads the encrypted backup, the recovery password unlocks it, and the app begins recovering all of the aliases. Each alias is its own distinct on-chain identity, so each one also takes 48 hours. The app becomes usable as soon as the first of those aliases finishes, and marks anything still in progress as pending. Recovering an identity end to end takes around five days. The technical section below sets out the exact sequence.

### **Common questions**

**What happens if I lose my phone?**

Install the app on a new phone, re-scan your passport, and enter your recovery password. Your root identity recovers 48 hours later if no one cancels, your aliases follow, and end to end the process takes around five days.

**Do I need to set up recovery agents?**

No. There is nothing to set up. Choose a strong recovery password at enrollment; that is the whole of recovery setup.

**Where is the recovery screen in the app?**

There isn't one. Recovery starts on the new phone, not from a settings screen: install the app, re-scan your passport, and enter your recovery password. The recovery password can be changed in the app; nothing else about recovery appears there.

**What if I forget my recovery password?**

Change it in the app. Setting a new password takes a biometric or device passcode check and does not require the old one. The app also asks you to re-enter the password from time to time, so a forgotten password surfaces while you still have a device to fix it on.

**What if someone steals my passport?**

A recovery they start is visible on the blockchain and waits 48 hours before completing, and you can cancel it during that window by scanning your passport again. Even if a false recovery completes, you can recover the identity back with another passport scan. A stolen passport does not cost you the identity for good.

## **How recovery works underneath**

Recovery operates at two levels. The `did:julia` protocol defines recovery for a single DID: the agents who may authorize it, the delay it waits through, and the configuration it commits. A not.bot identity is a root DID and its alias DIDs ([6A](https://not.bot/technology/identity-architecture/)); recovering it means running the protocol's recovery across the whole set, and that sequence sets the timeline a user sees.

### **Recovery on a single DID: the protocol**

Each `did:julia` DID carries its own recovery configuration in its on-chain state: the recovery agents, the delay, and an optional pre-rotated key. The blockchain enforces the rules in this section for any DID, whether it anchors a person, an alias, or an organization.

#### **Recovery agents**

A recovery agent is a DID that the owner has authorized to vouch for a recovery. When the owner needs to recover, each agent confirms the owner is who they claim to be and signs a one-time, time-limited authorization. The identity names its recovery agents in its on-chain configuration when it is created, and can name none. Today the app assigns Julia Social as the recovery agent for every not.bot identity; the user makes no selection, and choosing other agents waits on other agents existing.

For an identity that represents something that cannot act for itself, an animal or a physical asset, the person behind it is the natural recovery agent. The custodian role ([6C](https://not.bot/technology/delegation/)) carries no recovery rights, so an owner who custodies such an identity holds the two roles as separate grants: custodian for day-to-day control, recovery agent for the day the identity's keys are lost.

Recovery agents are named by DID, not by key. An agent can rotate its own keys, or run its own recovery, without breaking any configuration that names it. The owner sets their agents once and does not track the agents' key changes.

#### **Assisted recovery: the delay and what a recovery resets**

To recover, the owner's new device generates a fresh keypair. The owner proves their identity to each recovery agent and collects a one-time, time-limited authorization from each. Once a quorum of authorizations is in hand, the owner submits them to the blockchain together, naming the new public key as the DID's owner. The submission starts the recovery.

From that moment the DID is locked for a delay set in the recovery configuration. During the delay no operation on the DID is possible, with one exception: the recovery can be canceled. When the delay passes, the recovery completes and the new key on the owner's device controls the DID.

A recovery resets more than keys. The configuration a recovery commits can reset the ownership keys, set or clear custodian relationships ([6C](https://not.bot/technology/delegation/)), change the recovery delay, and change the set of recovery agents. All of it is committed when the recovery is initiated and takes hold when the recovery completes, so every part of it sits behind the same delay and the same cancellation.

#### **Malicious recovery and countermeasures**

The delay exists to defend against a recovery that should not be happening. The danger in assisted recovery is a recovery started by a compromised or dishonest agent. The risk is sharpest with a single agent, because no other agent has to agree.

The delay window is the first defense. A recovery is visible on the blockchain from the moment it starts and does not complete until the delay passes. The legitimate owner can run software or hire a service (when one exists) to watch the chain for a pending recovery against their DID and act inside that window. The watch only holds while that software runs; a watchtower service could keep it on the owner's behalf, and the Future state section covers why none exist yet.

The owner can cancel a recovery during the delay with the assistance of a quorum of the recovery agents. An owner who made a valid, timely request to cancel can show they made it. An agent that ignored the request and let the recovery proceed cannot later claim it acted in good faith.

#### **Multiple agents: M-of-N and multi-class**

A single agent is a single point of failure. An agent that is compromised, compelled, or tricked can start a malicious recovery, and an owner who has lost their keys leans on that one agent to cancel it. Spreading recovery across several agents removes the single point of failure.

Assisted recovery supports a quorum of agents in an M-of-N arrangement, or several classes of agents, each class with its own quorum.

- A 2-of-3 arrangement across three commercial recovery agents recovers even if one agent is unavailable or compromised, and no single agent can recover the identity alone.
- A "2-of-2: 2-of-3, 2-of-3" social-recovery model requires two of three friends and two of three family members, acting together. A malicious recovery would need many trusted people to collude. The same group can recover the identity after the owner's death without the legal documentation a commercial agent would wait for.
- Agents in different legal jurisdictions raise the cost of compelling them as a group.

More agents also make an identity harder to attack at the outset. An attacker has to find and compromise a quorum before acting, and an owner who keeps their agent set private gives the attacker nothing to start from.

#### **Instant recovery: pre-rotated keys**

A pre-rotated key is a replacement key the owner commits to in advance, while the current key still works. The commitment can name a full ownership model rather than a single key, so a multi-sig identity can hold a pre-rotated arrangement of its own. If the active key is lost or compromised, the owner swaps in the pre-rotated key in a single operation, with no delay and no agents. The swap commits the next pre-rotated key at the same time, so the instant-recovery path stays armed, and it cancels any recovery already in progress, so a pre-rotated key also stops a malicious assisted recovery before it can complete. The pre-rotated key carries one risk: someone compromises it before it is needed. A stolen pre-rotated key gives no warning, since nothing uses it until a recovery happens. The property that creates the risk also limits it. A key that stays unused until it is needed can be kept in stronger storage than a key in daily use. The Future state section illustrates cold-wallet and hardware-signer storage.

### **Recovering a not.bot identity: the root, the aliases, and the Recovery Server**

A not.bot identity is a root DID and the associated alias DIDs ([6A](https://not.bot/technology/identity-architecture/)). The root is the recovery anchor: it never signs content or presents credentials, and it controls the aliases. Recovery operates on the root first. Once the root recovers under new keys, the aliases follow.

Recovery splits into two jobs. Authorizing the recovery process belongs to the recovery agents, as the protocol defines. The mechanical side, holding the user's encrypted backup and putting each recovery transaction on the blockchain, belongs to the **Recovery Server**. A Recovery Server holds an encrypted backup of the user's identity state (the "recovery bundle"), and submits recovery transactions to the blockchain. The bundle is encrypted using a key derived from the user's recovery password. The Recovery Server operator does not have the password and cannot read the bundle. The recovery bundle is the same backup the app uses to bring an identity onto a new device, so recovering an identity and adding a device draw on the same stored data. [The not.bot App (Doc #5)](https://not.bot/learn/the-app/) covers adding a device.

A recovery of the root runs the assisted-recovery sequence the protocol defines. With control of the root restored, the device downloads the recovery bundle from the Recovery Server. Downloading the bundle requires proving control of the root DID, which the device can now do. The bundle decrypts with the owner's recovery password, and the app rebuilds the identity. The new keys come from the device; the bundle carries the rest of the identity's state. The aliases recover after the root, in the sequence and on the schedule that the Recovery Server provides.

### **The configuration and schedule today**

Julia Social operates the only Recovery Server in service today and is the only recovery agent available. One Julia Social service fills both roles, authorizing recoveries and holding every user's recovery bundle. A personal identity that uses assisted recovery uses a single-agent configuration with Julia Social. The multi-agent and multi-class arrangements the protocol supports wait on other agents to exist. The current app does not expose pre-rotated keys, so instant recovery is a protocol capability a user cannot yet reach.

Recovery runs on the root DID first, then the aliases. Julia Social's configuration uses a 48-hour delay, and the schedule is deterministic:

| Step | Timing |
| --- | --- |
| Root DID submitted for recovery | t = 0 |
| Root DID recovery completes, if not canceled | t + 48h |
| Alias DIDs submitted | at random over the 24h after the root completes |
| Each alias completes | 48h after that alias was submitted |

The app becomes usable again as soon as the first alias completes. The app marks aliases still in flight as pending until they finish. End to end, recovering an identity with many aliases takes around five days.

## **Future state**

Three changes will widen the recovery model, and Julia Social expects the ecosystem to supply a fourth.

**Recovery services other than Julia Social.** Julia Social plans to open-source the Recovery Server, and the open-source design splits the two roles its service combines today. A user can run their own Recovery Server, keeping their recovery bundle under their own control and submitting their own recovery transactions. Authorization moves to the recovery agents the owner chooses: commercial services that hold recovery DIDs and authorize recoveries, friends and family, or a self-hosted agent. Commercial services can offer defined ownership-proof processes, including posthumous recovery with the right legal documentation. The 2-of-3 and multi-class arrangements above become usable once there are more agents to fill them.

**The app exposes pre-rotated keys.** The protocol supports pre-rotation today; the app does not expose it. A future version of the app will let a user arm the instant-recovery path and keep the pre-rotated key in storage of their own choosing.

Two storage choices show what arming the instant-recovery path will look like once the app exposes it.

A cold wallet keeps the pre-rotated key offline. The owner generates a future keypair, records its seed as a written mnemonic or stamps it into a steel backup plate that resists fire and water, and pre-rotates the identity to that key's public half. The seed never touches a connected device until the day recovery is needed, when the owner enters it by hand. Nothing reads the key until then, so the offline seed stays out of reach of any digital theft.

A hardware signer holds the pre-rotated key in a secure element that does not release it. The owner reads the public key off the device, registers it as the pre-rotated key, and stores the device wherever they keep valuables. The private key stays on the device and never copies out. Recovery means producing one signature from that device, which swaps the identity to the key the device holds.

**The verification-level ratchet.** Every enrollment today is notbot0, a passport scan at home. As higher enrollment levels arrive (notbot1 for partner enrollment, notbot2 for first-party facilities, both planned and defined in [Credentials, Presentations, and Selective Disclosure (6B)](https://not.bot/technology/credentials/)), a recovery agent will be able to require that the identity verification used to recover or cancel meet or exceed the level used to enroll. The rule blocks a downgrade attack: without it, an attacker who could clear a low-assurance check would seize an identity its owner had protected with a high-assurance enrollment. This is a recovery agent's policy, not a property of `did:julia`. Each agent will set its own, and a user weighing agents should read those policies as part of the choice. Julia Social will hold recovery to the level the owner enrolled at.

**Watchtower services.** A watchtower monitors the chain for pending recoveries against the identities of its subscribers and alerts each owner inside the delay window, even when the owner's app is not running. Julia Social cannot run one. An alert has to reach the user through an email address or a phone number, either of which identifies the user, and Julia Social will never hold that data. Watchtowers wait on third parties willing to hold that contact information.

## **What lives where**

**[Identity Architecture (6A)](https://not.bot/technology/identity-architecture/)** covers the structure recovery acts on: the root DID as recovery anchor, the alias DIDs beneath it, and the identity's on-chain state.

**[Delegation and Organizational Identity (6C)](https://not.bot/technology/delegation/)** covers the custodian capability. A recovery can set or clear custodians, but a custodian cannot start or take part in a recovery, one of the three restrictions that keep ultimate control with the owner.

**[The not.bot App (Doc #5)](https://not.bot/learn/the-app/)** covers the recovery and add-a-device experience from the user's side.

**[Security Model (Doc #8)](https://not.bot/technology/security/)** covers the recovery threat model and its known weaknesses, including the single-operator risk (SW1) and the offline attack on recovery bundles (SW6).

The **[did:julia Technical Specification (Doc #15)](https://not.bot/technology/did-julia-specification/)** is the implementer-facing reference for the on-chain recovery operations, complementary to the conceptual treatment here.