# Vaults & Vault Accounts

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.

## 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 boundary** — one MPC key, one signing scheme, one policy set. Separate mandates mean separate vaults, not separate spreadsheet tabs.
- **Accounts are the accounting boundary** — addresses and balances hang off a vault account, so per-customer or per-desk reporting falls out of the structure.
- **Addresses are unbounded** — derive 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.

### 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 specification

The structure your integration will live inside for years.

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

## FAQ

**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.

## Related

- [Key Management](/features/key-management)
- [Policy Engine](/features/policy-engine)
- [Roles & Permissions](/features/roles-and-permissions)
- [Webhooks](/features/webhooks)
- [Pricing](/pricing)