> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dfns.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Vaults, wallets & keys

> How DFNS separates keys, wallets, and vaults: a key signs, a wallet is an address, and a vault groups wallets under one managed balance sheet with institutional accounting.

Most blockchain tools bundle the address and the private key into a single object they call a "wallet". DFNS splits them in two:

* **Wallet**: a blockchain address you can transact with
* **Key**: what signs transactions for that wallet, secured by our [MPC infrastructure](/core-concepts/how-mpc-wallets-work)

This split lets a single Key power wallets on as many blockchains as you need.

## Wallets across many chains

A single Key can power wallets on Ethereum, Bitcoin, Solana, and any other [supported network](/networks). You create the Key once, then open wallets with it on each chain you need.

On EVM chains, every wallet sharing the same Key gets the same address. At DFNS we call these [multichain wallets](/guides/multichain-wallets).

```mermaid theme={null}
flowchart TD
    %% Styling definitions
    classDef keyNode fill:#0052FF,stroke:#333,stroke-width:2px,color:#fff,rx:10,ry:10;
    classDef walletNode fill:#fff,stroke:#e5e7eb,stroke-width:2px,color:#374151,rx:5,ry:5;
    classDef blockchainNode fill:#F3F4F6,stroke:#e5e7eb,stroke-width:1px,color:#6B7280,stroke-dasharray: 5 5,rx:2,ry:2;

    %% --- Layer 1: The Cryptographic Key ---
    Key(<strong>The Master Key</strong><br/>MPC Protected<br/>ID: key-123)

    %% --- Layer 2: The DFNS Wallets (Addresses) ---
    subgraph DfnsWallets [" "]
        direction LR
        EthWallet[<strong>Ethereum Wallet</strong><br/>Address: 0x71C...9A]
        SolWallet[<strong>Solana Wallet</strong><br/>Address: Hv2...xP]
        BtcWallet[<strong>Bitcoin Wallet</strong><br/>Address: bc1q...xy]
    end

    %% --- Layer 3: The Actual Blockchain Networks ---
    subgraph Blockchains [" "]
        direction LR
        EthNet[Ethereum Mainnet]
        SolNet[Solana Mainnet]
        BtcNet[Bitcoin Network]
    end

    %% Connections: Key powers Wallets
    Key --> EthWallet
    Key -- Signs transactions for your DFNS Wallets--> SolWallet
    Key --> BtcWallet

    %% Connections: Wallets exist on Networks
    EthWallet --> EthNet
    SolWallet -- Broadcasts to and indexes from the networks --> SolNet
    BtcWallet --> BtcNet

    %% Apply Styles
    class Key keyNode;
    class EthWallet,SolWallet,BtcWallet walletNode;
    class EthNet,SolNet,BtcNet blockchainNode;
    style DfnsWallets fill:transparent,stroke:none;
    style Blockchains fill:transparent,stroke:none;

```

## What each object does

### Wallet

A Wallet is your address on a specific blockchain. It's the object you'll spend most of your time with: it's what holds funds, what you tag and apply policies to, and what shows up in the dashboard.

DFNS indexes the blockchain to track the wallet's activity, so you can:

* View asset balances (native tokens and fungible tokens on [Tier-1 networks](/networks))
* Access transaction history
* Receive [webhook notifications](/api-reference/webhook-events) when activity occurs so you can take appropriate actions
* Broadcast transactions to the network and know when they confirm

The DFNS dashboard lets you track and manage your assets, and the API lets you do the same programmatically: transfer native tokens, fungible tokens, and NFTs, sign and broadcast custom transactions, and interact with smart contracts to integrate with any feature of the chain.

### Key

A Key is what signs transactions for your wallets. Every transfer, contract call, or message a wallet produces is signed by its Key. The Key itself stays inside the DFNS MPC network, so the underlying cryptographic material is never exposed, not even to you.

In practice, you rarely interact with a Key directly. Creating a wallet creates its Key automatically. You only deal with a Key explicitly when [signing a message off-chain](/guides/developers/signing-requests) or when [creating multichain wallets via API](/guides/multichain-wallets).

When a transaction needs reviewer approval under a [policy](/core-concepts/policies), reviewers don't sign with the wallet's Key. They sign their approval with their own login credential (their passkey), the same one they use to access DFNS.

With a Key, you can:

* Open wallets on any blockchain that uses a compatible [key format](/networks/supported-key-formats). On EVM chains, every wallet sharing a Key shares the same address.
* Sign transactions or arbitrary messages, even on blockchains DFNS doesn't natively support, as long as the chain uses a compatible key format. That lets you extend DFNS security to private chains or networks we haven't integrated yet.
* [Delegate signing](/advanced/delegated-wallets) so your end users hold full authority over their own Keys.

## Vaults: managed custody on top of wallets

A **Vault** groups wallets into a single **managed balance sheet** with institutional accounting. Where a wallet exposes one on-chain balance, a vault splits holdings into available, incoming, quarantined, and locked balances, and records every change in an immutable, append-only ledger.

The wallets and keys under a vault are **managed**: read-only to you, with funds moving only through the vault's transfer API, never by signing the underlying wallet directly. That sealed model is what lets a vault enforce compliance holds (incoming funds are quarantined until released) and reserved amounts.

Wallets tell you what is on-chain. Vaults tell you what you can actually use, what is held for screening, what is reserved, and why.

### Wallet vs. vault

|                    | Wallet                                       | Vault                                                             |
| ------------------ | -------------------------------------------- | ----------------------------------------------------------------- |
| **Model**          | Direct, programmatic control of a key        | Managed custody with institutional accounting                     |
| **Balance**        | The on-chain balance                         | Split into available, incoming, quarantined, and locked           |
| **Incoming funds** | Immediately spendable                        | Quarantined until released                                        |
| **Signing**        | You control the wallet and sign transactions | Underlying wallets are sealed; you move funds via vault transfers |
| **Delegation**     | Can be delegated to end users                | Managed by organization users and service accounts                |
| **Audit**          | On-chain history                             | Immutable, entry-level ledger built into the data model           |

**Use a vault** when you need institutional custody semantics: segregated balances, compliance holds on incoming funds, reserved amounts, and an audit trail — for example regulated custody, off-exchange settlement, or escrow. **Use a wallet** when you want direct, programmatic control of assets and don't need balance-sheet accounting on top of the on-chain balance.

### Balance states

A vault's holdings for each asset are split into four balances:

* **Available** — funds you can transfer out now.
* **Incoming** — inbound funds detected on-chain but not yet credited.
* **Quarantined** — funds held pending your review; accepting them (or an automated screening policy) moves them into the available balance.
* **Locked** — funds reserved by a pending outgoing transfer.

<Note>
  Today, vault addresses and transfers are available on **EVM networks**. Vaults are managed by organization users and service accounts, not by delegated end users.
</Note>

To create and operate vaults from the dashboard, see [Manage vaults](/guides/manage-vaults).