# Platform

One MPC core. Three shares. Yours is mandatory. Every Vaultody vault runs 3-of-3 threshold signing: two shares on independent Vaultody nodes, one share in your hands — on your phone or your own server. All three participate in every signature, so Vaultody structurally cannot move your funds. Architecture, not a promise.

- **3-of-3** threshold signing, your share mandatory
- **17** blockchains, 34 networks
- **DKLS23 + FROST** — ECDSA and EdDSA
- **0** Vaultody-only signing paths

## A vendor that can sign alone is a vendor you have to trust

Every custody vendor promises segregation, insurance and process. None of that changes who can produce a signature. Vaultody splits that question into arithmetic: the MPC committee on your vault includes a party you operate, and Vaultody never holds more than two parties at any threshold. Our nodes cannot reach a signing quorum without you — not by policy, by roster.

- **The key that never exists** — shares 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 optional** — a 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.
- **Policy enforced at the signature** — approval quorums gate the signing ceremony itself. A transfer that fails your rules is never signed, so there is no UI-only control to bypass.

## How Vaultody MPC technology works

A complete private key never exists — not at Vaultody, not on your device, not anywhere. DKLS23 (ECDSA) and FROST (EdDSA) protocols compute one standard signature from three shares.

- **Vaultody node 1** — hardened, independent.
- **Vaultody node 2** — hardened, independent.
- **Your share** — phone or your server, mandatory on every signature.

## The four capabilities, included in every plan

No add-on SKUs. The platform is the same on Entry and on Enterprise — plans scale capacity, not security.

### Key Management

Keys are generated distributed and stay distributed across the three parties. Backup wraps each share to an RSA key only you hold; recovery runs in an open-source, offline desktop tool — you can inspect the exit door before you move in.

- DKLS23 + FROST — ECDSA and EdDSA, so all 17 chains are first-class.
- Reshare ceremonies rotate shares while keeping every address unchanged.
- Thresholds extend to 3-of-4 and 3-of-5 — the extra parties are always yours.

### Policy Engine

Amount-tiered rules per vault with named approvers. Below the threshold, transfers flow; above it, every listed approver must confirm — and one rejection kills the request. Enforced at the MPC signature, not in the UI.

- 10 amount tiers, from $0–10k to $10M+.
- 26 sensitive actions approval-gated beyond transfers — API keys, webhooks, team changes.
- Policy edits are themselves approval-gated.

### Roles & Permissions

Five roles — owner, admin, operator, developer, viewer — with additive permissions and no super-admin bypass. Signing power comes from holding a key share, never from a checkbox.

- ~50 granular dashboard permissions.
- Viewer: full read, zero transaction rights — auditors without attack surface.
- Role changes are approval-gated actions.

### Security Architecture

Independent hardened nodes, hardware-backed key storage on mobile, HMAC-authenticated APIs, and an append-only audit log on every fund and key action — an invariant, not a feature flag.

- Mobile share in Keychain / Keystore behind biometrics + PIN.
- Inter-party traffic encrypted end-to-end (AES-256-GCM envelopes).
- Append-only audit trail on every transaction state transition.

## Why teams standardize on the core

The parts that survive due diligence.

- **Non-custodial, provably** — none of the major competitors claims non-custodial, verified against their own sites. We claim it because 3-of-3 signing with your mandatory share makes it a property of the math, not the marketing.
- **Auditable exit** — backups encrypted to your RSA key; recovery in a public MIT-licensed tool that runs offline. Your auditors can read the exit path on GitHub before you deposit a cent.
- **17 chains, both curves** — 6 Bitcoin-family + 11 account chains including Ethereum, Tron, Solana and XRP. ECDSA and EdDSA native — no chain is second-class.

## From key generation to a broadcast transaction

Four stages, each with a party you control inside it.

1. **Distributed keygen** — your vault's key material is generated by the committee in an interactive ceremony. Each party ends up holding a share and the public key material — nothing else.
2. **Request and evaluation** — a transfer becomes a transaction request. The governance layer evaluates your rules for the vault: amount band, named approvers, quorum.
3. **Threshold signing** — once the request clears, the parties run the signing protocol — DKLS23 for ECDSA chains, FROST for EdDSA — and produce one ordinary on-chain signature.
4. **Broadcast and settlement** — the signed transaction is broadcast, tracked through its state transitions, and pushed to your backend as signed webhook events.

## Platform specification

The parts a security review asks about, stated once.

- **MPC topology** — 3-of-3 today: two Vaultody server nodes plus your party. Vaultody's party count is fixed at two at every threshold.
- **Protocols** — DKLS23 (ECDSA) and FROST (EdDSA); both curve families are first-class, so no chain is a second-class citizen. 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.
- **Key rotation** — reshare rotates every share while preserving the public key; your addresses never change and nothing moves on-chain.
- **Party changes** — add 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.
- **Extended thresholds** — flexible thresholds (3-of-4, 3-of-5) split your side further. They never add a Vaultody party.
- **Backup** — every share is exported wrapped to an RSA public key you generate on your own machine. Vaultody never holds your RSA private key.
- **Recovery** — a public, MIT-licensed, offline desktop tool reconstructs your keys for both curves with Vaultody entirely out of the loop.
- **Coverage** — 17 blockchain protocols across 34 networks; 10,000+ assets with USD pricing.

## What the platform 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.
- **It does not simulate transactions** — policy decides who may sign what. There is no transaction-simulation or destination allow-list layer today; plan your controls around approvals and roles.
- **It is not a custodian of record** — you remain custodian. If your regulator mandates a qualified custodian, that is a different product category — we will say so rather than sell around it.

## FAQ

**Is Vaultody a custodian?**
No — structurally. Signing is 3-of-3 and your share is mandatory at key generation and at every signature. Vaultody's two nodes cannot sign alone. You remain custodian of record; we are the co-signing infrastructure.

**What happens if we lose our key share?**
Two designed paths: restore from your RSA-encrypted backup, or run a reshare ceremony that rotates all shares while keeping the same addresses. A lost phone is an inconvenience, not an incident.

**Which MPC protocols do you run?**
DKLS23 for ECDSA (secp256k1) and FROST for EdDSA (ed25519) — an in-house Go implementation, with inter-party traffic end-to-end encrypted. That covers every chain family we support natively.

**Can approvals be automated?**
Yes — the API signer approves under rules you predefine, and a self-hosted server co-signer signs hands-off for high-throughput flows. Everything above your thresholds still waits for humans.

## Related

- [Vaultody MPC](/multi-party-computation)
- [What We Support](/what-we-support)
- [Features](/features)
- [Vaults & Vault Accounts](/features/vaults-and-accounts)
- [Pricing](/pricing)