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 recovery model is configurable for each identity, so an owner can match the safeguards to what the identity protects.

Recovery is the path for keys that are gone. An owner who still holds their keys does not need it. They rotate instead: the current keys sign a replacement set into place in one operation, with no delay and no recovery agents. A rotation can change the ownership model too, collapsing a multi-sig arrangement (6C) to a single key or expanding a single key to a quorum, so long as the current owners sign the change. Rotation is the answer to a suspected compromise while the owner still controls a device. Recovery exists for the day the keys cannot sign anything.

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); 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 owner picks their recovery agents when they set up the identity, and can choose to have none.

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) 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), 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's software can 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.

If a malicious recovery completes without being canceled, the legitimate owner can start a new recovery back to themselves and undo it. A completed theft of the identity does not lock the owner out for good.

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.

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

Recovery 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. A single-agent configuration asks the user to trust one company with the recovery path, a position users already take with their bank or their email provider. 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:

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 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)), 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) 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) 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) covers the recovery and add-a-device experience from the user's side.

Security Model (Doc #8) 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) is the implementer-facing reference for the on-chain recovery operations, complementary to the conceptual treatment here.

View this page as Markdown