# Introducing Vaults

> A new entity in the DFNS data model. The managed, multichain account with composite balances, quarantine by default, and a ledger built for regulated finance.

- Author: Adrien Moreau (Principal Software Engineer)
- Published: 2026-07-08
- Category: Product
- Canonical: https://dfns.co/article/introducing-vaults/
- All DFNS articles: https://dfns.co/llms-full.txt

---

Today we are introducing Vaults, a new abstraction in the DFNS platform. A Vault is a managed, multichain account: one entity that holds assets across networks, exposes one balance sheet, and accounts for money the way a regulated financial institution has to, with balance states, compliance holds, reservation of in-flight funds, and an immutable audit ledger built into the data model itself.

Wallets tell you what is onchain. Vaults tell you what you can actually use, what is held for screening, what is reserved, and why, with a record of every change. That difference is the difference between a wallet and an account, and it changes what you can build.

## Why a new abstraction

A blockchain wallet has one balance: what the chain says. Real finance does not work that way. A bank account distinguishes available funds from funds on hold. A broker distinguishes settled from unsettled. A compliance team needs incoming funds held until screened, not spendable the moment they land. A settlement arrangement needs funds provably reserved. And an auditor needs every one of those state changes recorded, immutably, with a reason.

Institutions building on wallets have been reconstructing all of this themselves, in application code, on top of a single onchain number. That works until it doesn't: a race condition double-spends an amount that was already committed, a tainted deposit gets swept into treasury, an auditor asks for the history behind a balance and gets a database column that was overwritten in place. Rather than adding this complexity onto the existing Wallet API, we built the abstraction it deserves.

## What a Vault is

A Vault is a managed multichain wallet. It sits in the platform hierarchy as the account layer:

```
Tenant
└── Org
    └── Vault  (va-…)
        ├── Wallet, Ethereum   (wa-…)
        ├── Wallet, Bitcoin    (wa-…)
        └── Wallet, Canton     (wa-…)
             └── Assets: ETH, USDC, BTC, …
```

One Vault spans networks. You create a Vault, then create addresses on it per network, Ethereum, Bitcoin, Canton, and more, and DFNS provisions the underlying wallets. Cryptographically, a Vault holds one key per signature scheme (ECDSA, EdDSA, Schnorr, Stark), serving all its wallets. On networks that require activation steps, such as Canton, the API handles activation explicitly. The result is one entity with one net worth, one asset list, and one history, across every chain it touches.

Managed is the important word. The keys and wallets underneath a Vault are sealed: they are read-only to the customer, and the only way to move funds is through the Vault's own transfer API. There is no raw-signing side door, no direct wallet endpoint that could bypass the Vault's accounting, holds, or locks. This is enforced structurally, through resource ownership and managed permissions, not by convention. If the bookkeeping says funds are reserved, no path exists to spend them anyway.

## What a Vault is not

* A Vault is not a new custody model. The same MPC and HSM key infrastructure sits underneath, with the same no-single-point-of-failure guarantees, and the same deployment options.  
* It is not an onchain contract. A Vault is an off-chain control and accounting layer over real onchain wallets. Your assets sit at addresses you can verify on any explorer.  
* It is not a replacement for the Wallet API. Wallets remain the right tool for direct, programmatic control. Vaults are the managed layer for funds that need account semantics.  
* And it is not, yet, an omnibus or virtual-account system. Vaults are the foundation that omnibus and sub-account balances will be built on, but that is a later chapter, covered below.

## Balances are composite

This is the heart of the model. A Vault does not have a balance. It has a balance sheet:

```
OnChainBalance
├── AvailableBalance      what can be spent now
├── QuarantinedBalance    incoming funds held pending screening
├── LockedBalance         funds reserved by an explicit lock
└── IncomingBalance       observed onchain, awaiting confirmations

OutgoingBalance           amounts reserved for in-flight outgoing
                          transfers, carved out of Available
```

Every state is queryable per asset, per network, alongside the Vault's total net worth in fiat. And balances are not just numbers: they are composed of entries, each tied to the transaction, quarantine, or lock that created it. You can list the entries behind a locked balance and see exactly which operation reserved what.

## Two behaviors are worth spelling out.

**Quarantine by default.** When funds arrive at a Vault, they land in QuarantinedBalance, not in Available. If you run KYT through Chainalysis or Notabene, a favorable screening releases them to Available automatically; an unfavorable one keeps them held, and on UTXO networks the tainted outputs themselves are recorded and excluded from future coin selection. If you don't run KYT, policies decide: auto-release everything, release only from allowlisted addresses, or require a manual, quorum-approved release with a recorded reason. The default posture is hold first, release deliberately, the opposite of a raw wallet, and the posture a regulated business actually needs.

**Double-entry discipline on the way out.** When you transfer from a Vault, DFNS creates two reservation entries before anything signs, one for the amount, one for the estimated fee, and deducts both from Available. No concurrent operation can spend funds that are already committed. When the transaction confirms, the reservations resolve and the difference between estimated and actual fee is credited back. If it fails, the amount is released. Double-spends of committed funds are prevented by the ledger, not by hoping your application serializes correctly.

## A ledger built for auditors

Underneath, every balance change is an immutable event, and every entry is append-only: rows are never updated in place, only superseded, so the current state and its full history are the same data. When an auditor or regulator asks why a balance is what it is, the answer is not a reconstruction. It is the record. Webhooks mirror the same model, alongside the familiar transfer lifecycle events, Vaults emit balance-level events: balance updated, entry created, entry released, so your own systems can maintain a synchronized view in real time.

## Locks: reserving funds as a first-class operation

The composite model enables something wallets fundamentally cannot: provable reservation of funds. Coming here next, a Lock is an API object that will enable you to reserve an amount in a Vault, with an owner, an optional expiry, and policy-governed creation. And because the Vault's underlying wallets are sealed, a Lock is a real guarantee. 

The flagship use case is off-exchange settlement. A settlement provider will be able to lock funds in your Vault, under your quorum approval, and credits you with a matching balance on an exchange. You trade all day with your assets never leaving your custody. At the end of the session, only the net result settles: the provider triggers a transfer against its lock for what you owe, and releases the rest. Your principal was never on the exchange. The same primitive underpins escrow, collateral arrangements, and any structure where a counterparty needs certainty that funds cannot move, without taking custody of them. Because locks are open API primitives with their own ownership and permissions, rather than a closed product flow, partners and customers can build settlement arrangements we haven't thought of.

## How this compares to Fireblocks vaults

Fireblocks organizes custody around vault accounts: containers inside a workspace that group asset wallets, used to segregate clients or business units through omnibus and segregated models and KYT screening that can block or freeze suspicious flows. It is a proven way to organize wallets, and grouping assets with fiat aggregation is table stakes that both platforms provide.

DFNS Vaults start from a different question. Not "how do I organize my wallets," but "how do I account for and control money the way a regulated ledger must." The differences follow from that:

* **Default posture.** Incoming funds to a Vault are quarantined until released by screening or policy. Hold first is the default, not an exception applied when a filter matches.  
* **The ledger is the product.** Balance states are composed of immutable, per-operation entries exposed through the API, not summary fields. The audit trail is the data model, not a report generated from it.  
* **Sealed underneath.** A Vault's keys and wallets are structurally read-only, so no raw-signing or direct-wallet path can bypass holds, locks, or accounting. The guarantee is architectural.  
* **Locks as primitives.** Reservation of funds is an open API object with independent ownership and quorum governance, a building block for settlement and escrow, not only a packaged flow.  
* **Where it runs.** Like everything on DFNS, Vaults work across SaaS, hybrid, and on-premises deployments, with MPC or your own HSMs, so the same account semantics hold wherever your regulator requires the keys to live.

## What Vaults are today and where they go next

We are launching deliberately narrow-. Today: Vaults with multichain addresses, composite balances with quarantine and outgoing reservation, transfers under the same Policy Engine as the rest of the platform, full entry-level history, and webhooks. Coming up: policy-governed release.

Vaults are only available on Ethereum and Tier-1 EVM networks for now, where DFNS runs full indexing because the accounting model demands it. One wallet per network per vault, and Vaults are created new rather than assembled from existing wallets.

Next, in order of arrival: 

* Manual locks, off-exchange settlement and escrow flows built on them  
* Incoming balance state that surfaces observed-but-unconfirmed deposits  
* Vault-level velocity and transfer-count policies. 

Beyond that, two larger chapters are already designed on this foundation with portfolio views that aggregate multiple Vaults into one read-only balance sheet, and virtual wallets where many end-users hold fractions of one Vault's balance, attributed by memo or dedicated deposit addresses with automated sweeping. The account layer comes first, everything else stands on it.

For institutions building regulated financial services onchain, banks, custodians, brokers, payment companies, this is the missing piece between a wallet and an account: money you can hold, screen, reserve, and prove, on one platform.

## Get started

* Learn more about onchain core banking: dfns.co  
* Explore the platform and documentation: docs.dfns.co  
* Talk to our team about Vaults: sales@dfns.co