Skip to main content
The DFNS Vaults API lets you create and operate vaults: managed, multichain custody primitives that hold assets under a single balance sheet with institutional accounting. A vault groups managed wallets across networks, segregates holdings into available, incoming, quarantined, and locked balances, and records every change in an immutable, append-only ledger. Incoming funds land quarantined until you release them, and funds move only through the vault’s transfer endpoints, never by signing the underlying wallets directly. Vaults are managed by organization users and service accounts, not delegated end users, and vault addresses are available on EVM networks, Bitcoin, and Solana. For the concepts, see Vaults, wallets & keys; for the dashboard walkthrough, see Manage vaults. If you have feedback on the Vaults API, please reach out to our .

​
Quarantine

Incoming funds land in the vault’s quarantined balance and stay out of available until released. Release them with Release Quarantine (POST /vaults/{vaultId}/quarantines/{quarantineId}/release) — manually, or gated by a quarantine-release policy. Requires the Vaults:Quarantines:Release permission.

​
Locks

A lock reserves funds from the vault’s available balance, so a counterparty can trust they are set aside — for off-chain settlement, escrow, or collateral. Locked funds move from available to locked and cannot be spent until the lock is released, at which point they return to available.
  • Create a lock with Create Vault Lock (POST /vaults/{vaultId}/locks): specify the network, the asset tid (for example native:eth or erc20:0x...), and an amount in the asset’s minimum denomination. An optional externalId is unique per vault and cannot be reused, even after the lock is released.
  • Release a lock with Release Vault Lock (POST /vaults/{vaultId}/locks/{lockId}/release), returning the funds to available. Only the lock’s creator can release it. List and inspect locks with List Vault Locks and Get Vault Lock.
  • Locks are EVM-only today; the endpoint rejects other networks (vault addresses themselves also support Bitcoin and Solana).
  • Lock creation can be gated by a balance-lock policy; when one applies, creation returns 202 and the lock isn’t created until the approval completes.
Permissions: Vaults:Locks:Create, Vaults:Locks:Release.

​
Policies for vaults

Two vault activities can be governed by the Policy Engine, using the same approval-quorum framework as transfers and scoped by vault tags:
  • Vaults:ReleaseQuarantine — governs moving funds from quarantined to available. Rule: AlwaysTrigger (require approval), or ChainalysisQuarantineScreening (evaluate the KYT result recorded with the quarantine, then approve or block). Action: RequestApproval or Block.
  • Vaults:CreateLock — governs lock creation. Rule: AlwaysTrigger. Action: RequestApproval or Block.
See the policies reference for the activity and rule definitions.

​
Webhooks

Vaults emit vault.created, vault.updated, vault.tags.modified, and vault.event.created events. Because a vault’s addresses are managed wallets, the same activity also emits the underlying wallet.* events — a deposit emits wallet.blockchainevent.detected and wallet.blockchain_event.transfer.included, and a vault transfer emits the full wallet.transfer.requested → broadcasted → confirmed sequence. If you subscribe to both, expect both, and key off the wallet or transfer id to avoid double-counting. See Webhook Events.

​
Vault object

Vault object.

​
id
string
required

Vault id.

Required string length: 1 - 64
Pattern: ^vlt-[a-z0-9]{5}-[a-z0-9]{5}-[a-z0-9]{14,16}$
Example:

"vlt-5vbsp-u62g1-ostmunqgds5o9tc2"

​
orgId
string
required
​
tags
string[]
required
​
dateCreated
string<date-time>
required
​
dateUpdated
string<date-time>
required
​
name
string
​
externalId
string
​
addresses
object[]

The vault's addresses.

Last modified on August 27, 2026