Recovery Overview

Recovery gives an owner back control of an account through an optional process with separate checks for identity, approval, and execution.

How Recovery Works

The owner starts recovery from the landing page without signing in, confirms the recovery address on file, and provides the destination that should receive control. The House of Stake backend coordinates the case, signs the verification proof, and records every step. Recovery replaces the key that controls an account or changes the owner of an account that holds a leased name. It does not move the account, rename it, or change what it owns.

The destination is supplied by the owner: a new owner key for an ordinary .near account or a new owner account for a leased name. That exact destination is included in the recovery request and approved by the watcher quorum; support does not choose it.

Ordinary .near Accounts

Ordinary .near accounts use a separate recovery path. Recovery must be enabled in advance by granting an MPC recovery key FullAccess. If the owner loses access, MPC can sign an AddKey transaction to restore control. This path does not apply to leased TLA accounts, which have no access keys.

Recovery Is Opt In

Recovery is optional. An account either has recovery turned on or has no recovery at all. There is no default, and support cannot turn it on later. That keeps an account that cannot be recovered from being taken over through support.

Three Independent Gates

There is one recovery path, not a tier or an escalation path. Every case runs the same three gates, and no two gates are held by the same party.

1. Attestation is the verification proof that shows the request came through the approved recovery flow, rather than from someone who only knows an account name.
2. Timelock gives the notified owner a waiting period in which to stop the recovery.
3. Watcher quorum is the independent approval of the specific destination.

The server holds the verification key and cannot approve. Independent watchers approve and cannot open a request. The owner can stop the process before the transaction is sent.

Responsibility by Layer

This separation gives each layer clear responsibility:

• The website handles verification without signing in. If a new key is needed, it creates it in the browser and sends only the public key; the private key stays on the owner's device.
• The House of Stake backend tracks the case, signs the attestation, gathers watcher approvals, and sends the final transaction.
• Contracts (mpc-recovery, hos-extension) enforce the checks, count recovery attempts, and apply the final owner change on NEAR.
• Independent watcher services approve one specific destination and nothing else.
• The MPC network signs the recovery transaction without ever assembling the complete private key.

Recovery Architecture

Deployment Notes

• The recovery flow described here is the mainnet target. The currently reviewed deployment is testnet; watcher services and the mail provider must be configured for the deployment being used.
• The console fallback does not deliver messages.

See Recovery Reference for feature-level implementation responsibilities and status.