One MPC core. Three shares. Yours is mandatory.
Non-custodial MPC wallet infrastructure, enforced by threshold math
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.
Share the Trust, Guard the Keys
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 existsShares 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.
- Policy enforced at the signatureApproval 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.
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.
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.
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.
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.
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.
A transfer becomes a transaction request. The governance layer evaluates your rules for the vault: amount band, named approvers, quorum.
Once the request clears, the parties run the signing protocol — DKLS23 for ECDSA chains, FROST for EdDSA — and produce one ordinary on-chain signature.
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.
Non-custodial is a property of the roster, not a promise in a contract. Count the parties, then decide.The one claim none of our competitors makes
What the platform does not do
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.
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.
Policy decides who may sign what. There is no transaction-simulation or destination allow-list layer today — plan your controls around approvals and roles.
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.
Frequently asked questions
Get answers to commonly asked questions.
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.
Share the Trust Guard the Keys
Pick the wallet type that fits your use case — the platform underneath is identical.