Locks

Vaults now support Locks: commit funds to a counterparty without moving them. Off-exchange settlement, collateral management, and escrow, with custody that never leaves.

Thierry Janaudy
Thierry Janaudy
| 5 min read

A great deal of institutional finance consists of proving a commitment. A trading venue needs certainty you can settle. A lender needs certainty the collateral is there. A counterparty in a transaction needs certainty the funds exist and will not disappear before delivery.

In digital assets, that certainty has almost always been purchased the same expensive way: by handing over the assets. Pre-fund the venue. Post collateral into the lender’s custody. Wire the escrow to a third party. In every case, capital leaves your control to prove a point, and sits under someone else’s operational risk until the point no longer needs proving. The industry has learned the true price of that arrangement more than once.

Today, we are shipping the primitive that changes it on DFNS. Locks let a counterparty reserve funds inside your vault, under rules neither side can bend. The funds never move. The commitment is enforceable anyway. Locks arrive on Vaults, the programmatic container for wallets we introduced earlier this year, and they serve three needs at once: off-exchange settlement, collateral management, and escrow.

The guarantee is the hard part

The idea of committing funds without moving them is not new. Making the guarantee real for both sides is. A lock the committer can quietly undo is worthless to the party relying on it. A lock the beneficiary can impose or enlarge at will is dangerous to the party granting it. Locks on Vaults are built so that neither side has to take the other’s word for anything.

What a lock is

A lock is a reservation on funds inside your vault. The funds do not move. No transaction is broadcast, no address changes, custody stays exactly where it was. What changes is what the balance can do.

Vault balances are composite, and every state is a first-class number. Alongside the available balance, what can be spent, and the incoming balance, detected onchain but not yet confirmed, a vault now carries a locked balance: funds committed to a counterparty that cannot be spent. Every figure decomposes into entries, and each locked entry ties to a specific lock. When your auditor asks why the spendable balance is smaller than the onchain balance, the answer is not a narrative. It is a list.

The mechanics of trust

Locks work because ownership and approval are split between the two parties, and the split is enforced below the API.

  • Nothing locks without you. Your counterparty, operating a service account you granted, creates the lock: an amount, an asset, an expiry. That request clears the Policy Engine before it takes effect, which means your own quorum approves every lock. Increases to the amount or the expiry route back through the same approval. Enforced below the API, none of this can be bypassed with credentials alone.
  • Nothing unlocks without them. Once a lock is active, only the lock owner can release it, reduce it, or settle against it. You cannot unlock unilaterally, and you cannot spend locked funds. That is the entire value of the guarantee your counterparty is accepting, and the platform holds you to it.
  • And nothing unwinds it from the side. While a lock is active, the owning service account cannot be deleted or edited, its permissions cannot be removed, and key export stays disabled for the vault. The obvious workarounds are closed by construction, not by contract.

The result is a commitment that is stronger than a promise and cheaper than a transfer. Your counterparty gets certainty. You get custody that never moved.

Three use cases, one primitive

  1. Off-exchange settlement. You want to trade up to 5 BTC on an exchange that settles against DFNS Vaults. The exchange locks 5 BTC in your vault; your approvers confirm; the exchange, seeing the lock active, credits you 5 BTC of trading power. You trade all day without a single satoshi leaving your custody. By close, you have sold 2 BTC. A settlement transfer of 2 BTC is drawn against the lock, initiated by the exchange or by you, and the exchange releases the remaining 3 BTC to your available balance. One session, one onchain transfer, zero pre-funded exposure.
  2. Collateral and loan management. You borrow against digital assets. Instead of transferring collateral into the lender’s custody, the lender locks it in your vault. Your quorum approves the terms. For the life of the loan, the collateral cannot be spent by you and cannot be moved, rehypothecated, or lost by the lender, because it never left your vault. A margin call is a lock increase, routed back through your approval so it cannot be imposed unilaterally. Repayment is a release. A default is a settlement drawn against the lock. The lender holds an enforceable claim; you hold custody; the record shows exactly which funds secured which obligation, every day of the term.
  3. Escrow. Two parties transact, and one must be certain the funds exist before delivering. The buyer’s vault holds the funds; the escrow agent, or the seller directly, owns the lock. Delivery triggers settlement against it. Failure to deliver, or a dispute, ends in release, and the lock’s expiry ensures that a transaction which simply goes silent unwinds on schedule. No third-party custody, no wire out and wire back, no counterparty holding money that was never theirs.

The three look different on a term sheet and identical to the platform: an amount reserved, an owner who can settle or release, an approval the committing party controls, and an expiry. That is the point of a primitive.

The books stay honest

The same entry model runs your ordinary outflows. Every outgoing transfer reserves two entries before it signs, one for the amount and one for the fee, so concurrent operations can never double-spend the same funds. On confirmation, the entries settle and the difference between estimated and actual fees reconciles back to available. Every balance you see is the sum of entries you can list, and every entry points at the operation that created it.

Getting started

The surface is small and deliberate:

  • POST /vaults/{vaultId}/locks creates a lock, quorum-approved by you.
  • POST /vaults/{vaultId}/locks/{lockId}/replace updates amount or expiry, owner only, re-approved by you.
  • POST /vaults/{vaultId}/locks/{lockId}/release releases a lock, owner only.
  • POST /vaults/{vaultId}/locks/{lockId}/transfer settles against a lock.

Whether you are an institution that wants its exchange balances and collateral to stay home, a lender that wants enforceable claims without custodial risk, or a venue that wants to offer off-exchange settlement to everyone building on DFNS, the conversation is short.

Contact us