WEAVER
Mend · 06 · Recover>Live

Recovery & Migration Readiness

MEND helps users and integrated protocols prepare recovery and migration paths before an emergency. Registration alone never guarantees recovery — readiness must be tested.

00Your checklist

Four steps before you need them

Connect a wallet or paste an address. Each step is read live from Robinhood Chain — nothing is assumed done.

Your protection · read from Robinhood Chain

— / 4

Steps 1–3 are read live from the chain. Step 4 is remembered only in this browser (key hash only, never the key). A full checklist means the steps are done — not that the account is safe from a quantum attack. Not independently audited.

01Readiness lookup

Check an account's recovery readiness

Reads MendRegistry on Robinhood Chain Testnet. No wallet needed to look up — writes stay with the account owner.

Check readiness · read-only, no wallet needed

What MEND does — and does not

  • Records your recovery plan and testnet rehearsals on-chain so integrators and you can check readiness.
  • Stores only a commitment hash of the recovery key — never key material.
  • Does not move funds, custody keys or execute recovery. Your wallet / smart account performs recovery.
  • Does not change Robinhood Chain's native signature scheme or make any wallet quantum-resistant.

Writes (register / attest) are done by the account owner from their own wallet — e.g. with cast send or a Safe transaction. WEAVER never asks for keys.

02Readiness path · 4 checkpoints

Readiness is proven, not registered

Each checkpoint maps to one MendRegistry call. Changing the plan resets the proof.
  1. 01 / 04

    Register a recovery plan

    Commit a hash of your recovery key (never the key), pick guardians, a threshold and a 1–90 day timelock.

    registerPlan(commitment, guardians, threshold, delay)
  2. 02 / 04

    Rehearse on testnet

    Run your wallet's actual recovery flow on Robinhood Chain Testnet, then record the tx or report hash.

    attestSimulation(ref)
  3. 03 / 04

    Review PQ migration

    Track post-quantum signature options (e.g. ML-DSA) for your wallet stack and self-attest the review.

    attestMigrationReview(true)
  4. 04 / 04

    Re-test after changes

    Any plan change wipes the previous simulation attestation — readiness must be proven again.

    readinessScore(account)

03Ark · post-quantum recovery path · testnet

A second key that quantum attacks on ECDSA don't reach

ArkVault holds ETH behind two paths: your normal wallet (blocked by WARD from Verified up) and an ML-DSA-44 key generated in your browser, which can always move the balance to a fresh address.

1 · Post-quantum key (ML-DSA-44, FIPS 204)

2 · Deposit (normal ECDSA wallet, gated by WARD)

Connect a wallet (top right) to deposit or recover. Key generation works without one.

3 · Recover with the PQ key (works at any WARD level)

What Ark guarantees — and what it does not

  • The key is generated and used only in this tab. WEAVER's server never sees it; losing the recovery kit loses the PQ path.
  • On-chain the vault stores only keccak256 of the public key. An attacker who derives your ECDSA key from a revealed public key still does not know the ML-DSA key.
  • Recovery is commit → reveal across blocks, bound to owner and destination, so a watcher cannot redirect it.
  • The ML-DSA signature is not verified on-chain — Robinhood Chain has no ML-DSA precompile. It is published in the Recovered event for anyone to check. On-chain authority is knowledge of the hashed public key.
  • Testnet only, ETH only, internal review only. Does not change Robinhood Chain's signature scheme or protect assets outside this vault.
Previous · ProtectWARDQuorum-signed threat state integrators can opt into.IntegrateDevelopersRead WARD state from your own contracts.