Create account
Home › Features › Vaults & Vault Accounts
Features · structure

One vault. Many accounts. Clear hierarchy.

The structure that keeps 40,000 addresses manageable

A vault is a key ceremony and a policy boundary; vault accounts partition it by purpose — reserves, operations, per-client books — and addresses hang off accounts. The hierarchy is how scale stays legible.

Share the Trust, Guard the Keys

Request DemoSpeak with a digital asset expert
Create accountNow, and secure your assets
The problem

One wallet for everything is how reconciliation becomes archaeology

Flat wallet structures force you to reconstruct intent from on-chain data afterwards. Vaultody's hierarchy makes intent explicit up front: a vault carries the key material and the rules, and vault accounts under it hold the addresses and balances for a purpose, a desk, a customer or a product line.

  • The vault is the security boundaryOne MPC key, one signing scheme, one policy set. Separate mandates mean separate vaults, not separate spreadsheet tabs.
  • Accounts are the accounting boundaryAddresses and balances hang off a vault account, so per-customer or per-desk reporting falls out of the structure.
  • Addresses are unboundedDerive as many deposit addresses per account as your plan allows — an address per user per chain is a normal shape here.

How the hierarchy works

Vault — the trust boundary

Each vault has its own MPC keys (one ceremony, three shares) and its own policy set. Compartmentalization is by construction: a breach or a policy change in one vault touches nothing in another.

  • ✓Own keys, own policies, own approvers per vault
  • ✓Reshare and recovery are per-vault ceremonies
  • ✓GENERAL→DEFAULT migration handled by reshare
vaults
R
Reserves
strict policy · 2 approvers
own keys
O
Operations
fast policy · automations
own keys
C
Client funds
per-client accounts
own keys

Vault accounts — the ledger view

Accounts partition a vault by purpose or client. Internal transfers move funds between accounts under the same governance as on-chain sends — with their own webhook event, so your ledger stays exact.

  • ✓Unlimited assets under management on every plan
  • ✓Internal transfers with INCOMING_CONFIRMED_INTERNAL_TX events
  • ✓Addresses derive per account — 500 to 40,000+ by plan
hierarchy
vault operations ├─ account float · 1,240 addresses ├─ account payroll · 18 addresses └─ account client-4471 · 2,051 addresses # internal transfer: float → payroll # same policy, audit and webhook treatment
Specification

Hierarchy specification

The structure your integration will live inside for years.

VaultTop-level container. Holds MPC key metadata, signing scheme, network type and backup state — never secret key material.
Vault accountA sub-account under a vault, identified by its index, against which addresses are derived. Every vault has at least one.
AddressesDerived on demand from the vault's public key material. No gap-limit scan; the only ceiling is your plan's address count.
Network typeA vault is mainnet or testnet. Using it against the wrong network for a chain is rejected rather than silently wrong.
OrganisationFavourite and hidden flags, per-account naming, and team-member assignment for who works where.
Backup gateA fresh vault has its default account only. Additional accounts unlock once the backup ceremony has fully completed.
Asset registrationAccount-based chains need one add-asset call for a balance to show in listings; UTXO chains appear on address generation.
MonitoringIncoming-transaction detection starts as soon as an address is derived, independent of whether the asset is listed yet.

Frequently asked questions

Get answers to commonly asked questions.

How many vaults do plans include?

One active vault on standard tiers with accounts partitioning it; additional vaults and custom structures are an Enterprise conversation.

Do internal transfers hit the chain?

Between accounts of the same vault they are ledger movements with full audit treatment; cross-vault moves are on-chain transactions.

Can accounts have different policies?

Policies scope per vault; use separate vaults where regimes must differ cryptographically.

Share the Trust Guard the Keys

Structure that scales with your book, not against it.

Create accountRequest Demo