Skip to main content
Timed recovery lets a user recover their wallet using a 24-word recovery phrase with a mandatory 30-day lockdown before the transfer executes. See Recovery for the user-facing overview and UX guidance. At recovery start, the user provides a recipient wallet address. The system queues a deterministic transfer bundle to move inventory to that recipient after the delay. Finalization is not automatic: once the countdown completes, the user returns and executes the queued transactions using an EOA wallet. The recovery request is visible onchain throughout the window.

​
Design goals and security properties

  • Enforced delay: recovery cannot finalize before 30 days, removing instant silent takeover paths common with mnemonic-only recovery modes.
  • Deterministic effect: the queued payload is a fixed transfer plan to a user-specified recipient. Auditors and operators can pre-compute and monitor the exact outcome.
  • Onchain observability: the queued request is public. Watchtower sends escalating email notifications to the recovery email throughout the window.
  • Sequence independence: contracts are self-sufficient. Users can run the standalone recovery tool. Session metadata is continuously backed up to Arweave for permanent storage. The only requirement is that the target EVM chain must be live.

​
Prerequisites

  • 24-word recovery phrase: created for the wallet via UI or SDK. Used only for recovery authorization.
  • Recovery notifications email: bound to the recovery key at phrase creation. Used by Watchtower.
  • Optional encrypted backup: store an encrypted form of the phrase in a reputable password manager, protected by a memorized decryption password not stored with the encrypted blob.

​
Recovery flow

​
Step-by-step

  1. User creates the recovery signer phrase and adds the signer to the wallet with the existing session.
  2. At a later date, user initiates recovery from the main auth screen.
  3. User enters the recovery phrase. The wallet derives the recovery EOA, fetches wallet session metadata, and shows an inventory preview.
  4. User provides a target recipient wallet address (must differ from the source wallet). The wallet constructs and queues a transfer bundle.
  5. User initiates recovery. The UI shows the exact date and time to return. The request is recorded onchain and Watchtower notification cadence begins.
  6. User can return at any time to see the live countdown.
  7. If local state is not available, the user re-enters the recovery phrase. The wallet detects the active recovery and shows the countdown.
  8. After 30 days, the user triggers execution of the queued transfer bundle using an EOA wallet. Inventory moves to the recipient.

​
Notifications

  • On queue, Watchtower emails the recovery email registered at phrase creation.
  • Frequency increases as T+30 approaches.
  • If email infrastructure is unavailable, onchain visibility remains. Integrators can run independent watchers.
  • The user can cancel the recovery request at any time before finalization.

​
FAQ

Do users regain interactive access to the original wallet at T+30? No. The model moves inventory to the specified recipient. Users proceed with the recipient wallet. Can an active recovery be stopped? Yes, at any time before finalization. Stopping or rotating configuration invalidates the queued payload. What if Sequence services are offline? Recovery still works. Users run the standalone recovery tool, which reads session metadata from Arweave and submits the same onchain steps. The only requirement is that the EVM chain must be live. What are the costs? Gas to queue the payload, gas to finalize, and gas for the transfer bundle. What if the user loses their 24-word phrase? If both main access and the recovery phrase are lost, recovery is not possible. If the user still has at least one open session on a device, they can start recovery using that active session.