Home › Features › Key Management

Features · the MPC core

The key that never exists

One MPC core under every vault, included in every plan

Keys are generated distributed and stay distributed. No machine, at any point in the protocol, assembles a full private key — not during keygen, not during signing, not during backup.

Share the Trust, Guard the Keys

Create accountLive on testnet in an afternoon

Compare PlansIncluded in a plan, not an add-on

3-of-3threshold signing, your share mandatory

DKLS23 + FROSTECDSA and EdDSA, both first-class

0Vaultody-only signing paths

MIT-licensedrecovery tool, offline and public

The problem

A key that exists somewhere is a key someone can take

Classical custody protects a private key by putting it somewhere hard to reach — an HSM, a safe, a signed procedure. Vaultody removes the thing being protected: key material is generated in shares, used in shares and backed up in shares, and the committee holding them includes a party you operate. Vaultody runs two of the three parties and never more, so our nodes cannot reach a signing quorum without you.

Nothing assembles the whole keyShares are generated distributed and stay distributed. No machine, at any point in the protocol, assembles a full private key — not during keygen, not during signing, not during backup.
Your party is mandatory, not optionalA vault runs the two Vaultody server nodes plus your party — your phone, or a co-signer you host. Remove your party and the vault stops signing.
The same core on every planNo add-on SKUs. The platform is the same on Entry and on Enterprise — plans scale capacity, not security.

What the core actually does

Generated distributed, used distributed

Your vault's key material is created by the committee in an interactive ceremony. Each party ends up holding a share and the public key material and nothing else. Every later signature is computed from those shares — DKLS23 for ECDSA chains, FROST for EdDSA — and what reaches the chain is one ordinary signature against one ordinary address.

✓Both curve families are native, so no chain is a second-class citizen
✓One public key and one set of addresses per vault
✓Hardware-backed key storage on mobile; inter-party traffic encrypted end to end

vault committee — 3-of-3

Vaultody node 1

hardened, independent

server share

Vaultody node 2

hardened, independent

server share

Your party

your phone, or a co-signer you host

mandatory

Backed up to a key only you hold, rotated without moving funds

Each party's share is exported wrapped to an RSA public key you generate on your own machine, and recovery runs in a public, MIT-licensed, offline desktop tool that reconstructs your keys with the company entirely out of the loop. When a device or a colleague changes, a reshare rotates every share while preserving the public key — so every address stays exactly as it was and nothing moves on-chain.

✓Vaultody stores the public half of your RSA key and never sees the private one
✓Reshare rotates shares with zero on-chain footprint
✓Thresholds extend to 3-of-4 and 3-of-5 — the extra parties are always yours

recovery — offline, open-source

$ vaultody-recovery \ --backup shares.zip \ --rsa-key ./recovery-key.pem ✓ shares decrypted (3/3) ✓ key reconstructed — ECDSA + EdDSA ✓ ran fully offline # MIT-licensed · inspect it on GitHub

How it works

The life of a key, start to exit

Five ceremonies. You are inside every one of them.

01Distributed key generation

The committee runs an interactive ceremony. Each party ends up holding a share and the public key material — no machine ever holds the whole key.

02Threshold signing

Once a request clears its policy, the parties run DKLS23 or FROST and produce one ordinary on-chain signature.

03Backup

Every share is exported wrapped to an RSA public key you generate on your own machine. Vaultody holds only the public half.

04Reshare

Rotate every share while preserving the public key. Addresses do not change, and nothing moves on-chain.

05Recovery

With your backup package and your RSA private key, the open-source offline tool reconstructs the keys for both curves without Vaultody in the loop.

Specification

Key management specification

The parts a security review asks about, stated once.

Topology3-of-3 today: two Vaultody server nodes plus your party. Vaultody's party count is fixed at two at every threshold.

ProtocolsDKLS23 (ECDSA) and FROST (EdDSA). DKLS23 is a three-round threshold ECDSA protocol; a vault keeps one public key and one set of addresses, and the backup you already hold stays valid.

Your partyThe mobile co-signer on a phone you hold, or a server co-signer you run yourself. Either way it is mandatory on every signature.

Extended thresholdsFlexible thresholds (3-of-4, 3-of-5) split your side further. They never add a Vaultody party.

StorageHardware-backed key storage on mobile behind biometrics and a PIN; inter-party traffic is encrypted end to end.

BackupEvery share is exported wrapped to an RSA public key you generate on your own machine. Vaultody never holds your RSA private key.

RecoveryA public, MIT-licensed, offline desktop tool reconstructs your keys for both curves with Vaultody entirely out of the loop.

Party changesAdd or remove client-side parties by ceremony. Removing a party from a full n-of-n committee takes two reshares: lower the threshold, then remove.

AvailabilityPart of every plan. Plans scale capacity — vault accounts, team members, rules — not the security model underneath them.

Straight answers

What key management does not do

It does not sign for you

If your party is offline, the vault does not sign. That is the guarantee working, not an outage — run a server co-signer alongside the mobile app when you need hands-off flows.

It does not hold your recovery secret

There is no escrow and no recovery-as-a-service. Lose the RSA private key that wraps your backup and Vaultody cannot restore it for you.

There is no verify-only dry run

Nothing today proves a backup is recoverable without assembling the key, and there is no fingerprint of your RSA public key to compare against. Both are on the roadmap; neither is pretended away.

The desktop installers are unsigned

macOS and Windows warn on first launch. Verify the download against the published checksum rather than clicking through the warning.

Frequently asked questions

Get answers to commonly asked questions.

Which MPC protocols do you run?

DKLS23 for ECDSA and FROST for EdDSA. Both curve families are native to the same core, so an approval on Solana behaves like one on Ethereum.

Can Vaultody move funds on its own?

No. A vault runs two Vaultody nodes plus a party you hold, so our nodes cannot reach a signing quorum without you. That is a roster, not a policy — and approving is an organisational act while signing is a cryptographic one, so neither substitutes for the other.

What happens if we leave?

Your backup package plus your RSA private key reconstructs the keys in the open-source offline tool, with Vaultody entirely out of the loop. You can read the tool before you onboard.