- Wallet: a blockchain address you can transact with
- Key: what signs transactions for that wallet, secured by our MPC infrastructure
Wallets across many chains
A single Key can power wallets on Ethereum, Bitcoin, Solana, and any other supported network. 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.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)
- Access transaction history
- Receive webhook notifications when activity occurs so you can take appropriate actions
- Broadcast transactions to the network and know when they confirm
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 or when creating multichain wallets via API. When a transaction needs reviewer approval under a policy, 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. 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 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
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.
Today, vault addresses and transfers are available on EVM networks. Vaults are managed by organization users and service accounts, not by delegated end users.