# MPC Key Recovery: Your Exit Plan If Your Vendor Disappears > How Vaultody MPC key recovery works if the vendor disappears: RSA-wrapped shares, an offline MIT-licensed tool, both curves, and four limits to document. Published: Oct 22, 2026 Categories: Platform Updates Source: https://vaultody.com/blog/635-mpc-key-recovery-your-exit-plan-if-your-vendor-disappears --- **TL;DR:** If Vaultody disappears, you recover funds with a public, MIT-licensed, offline tool. It decrypts your backup using an RSA (Rivest-Shamir-Adleman) private key only you hold, then derives the master private key for both supported curves. A vendor-exit section in a risk file has to answer one question. Can the firm move its assets if the provider stops operating, without the provider's help? For Vaultody, the answer is yes, with conditions that belong in writing. This post sets out the mechanism, the limits and the documentation the mechanism supports. Open-source recovery is table stakes. Fireblocks and BitGo also publish recovery tools. The useful test is not whether a tool exists. It is what your team must hold, run and rehearse for the tool to work on the day it is needed. ## A 3-of-3 signing scheme makes the backup your exit path Vaultody is non-custodial MPC (multi-party computation) wallet infrastructure. Every vault key is split 3-of-3. Two shares sit on Vaultody nodes. One share is held by you, and that share is mandatory for every signature. Vaultody cannot move funds alone and never holds your funds. You are the custodian of record. The same property cuts the other way. A 3-of-3 scheme needs all three shares to sign. If Vaultody's nodes go offline permanently, your share alone cannot produce a signature through the normal MPC flow. The exit path is therefore not the signing protocol. It is the backup. For reference, signing uses DKLS23 for ECDSA (Elliptic Curve Digital Signature Algorithm) and FROST (Flexible Round-Optimized Schnorr Threshold signatures) for EdDSA (Edwards-curve Digital Signature Algorithm). During normal operation, key material sits in HSMs (hardware security modules). ## The backup is encrypted to a key pair Vaultody never sees The backup wraps each key share to an RSA public key that you supply. The RSA key pair is generated only on your machine, inside the recovery tool. Vaultody does not generate, issue or hold the RSA private key. The backup covers both curves in use: secp256k1, which underlies ECDSA signing, and ed25519, which underlies EdDSA signing. Your recovery plan therefore covers both signing algorithms with a single procedure. Vault accounts stay locked until the backup is finalized. You cannot operate a vault account before its recovery path exists. For a compliance file, that is a control enforced by the product rather than one that depends on internal policy being followed. For setup detail, see the wallet backup walkthrough. ## Recovery runs offline from code your team can read The recovery tool is public and MIT-licensed. The maintained repository is `Vaultody-com/vaultody-wallet-recovery-tool`. Reference that exact repository name in your exit documentation and source the tool from there. The tool runs offline and works on an air-gapped machine. Given the encrypted backup and your RSA private key, it derives the master private key for secp256k1 and ed25519. No call to Vaultody or its nodes is part of that path. Because the code is public, your security team or an external reviewer can read it, build it and archive a copy alongside your own recovery records. The recovery step then has no dependency on Vaultody continuing to operate. ## Four limitations belong in your exit documentation 1. **Recovery assembles a full private key.** MPC exists so that no complete key is present during normal operation. Running recovery ends that property for the recovered keys. Treat it as break-glass: a documented trigger, named approvers, an air-gapped machine, and a plan to move funds to fresh keys immediately afterwards. 2. **The RSA private key is the only secret.** Lose it and the backup is useless. Vaultody cannot reissue it because Vaultody never had it. Your key-management policy must cover where it is stored, who can access it and how access passes on when staff leave. 3. **Installers are unsigned.** Your operating system (OS) will show warnings during installation. Record the expected warning in the runbook so operators do not treat it as an incident. Teams that want stronger provenance can build from the public source on the recovery machine. 4. **There is no verify-only dry run yet.** The tool cannot currently confirm that a backup and RSA key decrypt correctly without performing a full recovery. A test is therefore a full break-glass rehearsal on an isolated machine, and the resulting key must be handled as live. Set your test cadence with that cost in mind. ## Each exit-plan control can be mapped to an owner The table below translates the mechanism into line items a risk or compliance lead can carry into a vendor file. Exit-plan item | Mechanism | Owner | Recovery path independent of the vendor | Public, MIT-licensed tool that runs offline and air-gapped | Your security team | Decryption secret | RSA private key generated only on your machine | Your firm alone | Backup completeness | Vault accounts locked until backup is finalized | Enforced by the product | Curve coverage | secp256k1 and ed25519 | Your risk function, checked against your asset list | Tool provenance | Maintained repo `Vaultody-com/vaultody-wallet-recovery-tool`; installers unsigned | Your IT and security teams | Testing | No verify-only dry run yet; full rehearsal required | Your risk function | Ask every provider on your shortlist to fill in the same table. Differences show up in who generates the decryption secret, whether backup is enforced before use and how testing works. For how supervisors read MPC arrangements in general, see the regulatory view on who holds control. ## Vendor exit questions buyers ask about MPC key recovery ### what happens to my crypto if my mpc wallet provider shuts down With Vaultody, you run the public recovery tool offline, decrypt the backup with your RSA private key and derive the master private key for secp256k1 and ed25519. You then move funds to new keys. The provider's nodes are not needed for this step. ### does vaultody have a copy of my rsa recovery key No. The RSA key pair is generated only on your machine, inside the recovery tool, and you supply the public key. Vaultody never holds or issues the RSA private key, which is why losing it makes the backup unusable. ### can i test mpc key recovery without exposing the private key Not yet. There is no verify-only dry run, so any test performs a full recovery and assembles a complete private key. Run rehearsals on an isolated, air-gapped machine and treat the output as live key material. ### is an open source recovery tool enough for vendor due diligence It is a baseline, not a differentiator. Fireblocks and BitGo also publish recovery tools. Due diligence should focus on who controls the decryption secret, whether backup is enforced before accounts operate and how your team will test the procedure. ## This exit model fits firms that accept custodian-of-record duties If your mandate requires assets to be held by a qualified custodian, this architecture is not built for you. With Vaultody, your firm remains the custodian of record, and the RSA key, the runbook and the rehearsals are your responsibility. If that model fits your policy, review the recovery mechanics on our [key shards and recovery feature page](/features/key-shards-and-recovery) before you draft the exit section of your vendor file.