DFNS now supports Canton allocations. These are the token standard’s settlement commitments, distinct from DFNS Allocations, our yield product. Wallets issued by DFNS can commit assets to a settlement and act as a leg in atomic, multi-party transactions on Canton, with every policy, approval and governance control applied at the moment of commitment. The support covers both versions of the Canton Network Token Standard, CIP-56 and CIP-112, the second version approved in June, whose defining addition is the committed allocation, which locks the Canton leg of a trade until an agreed settlement deadline. It is the natural next step after our token standard support, and it brings the full allocation workflow, including CIP-112 committed allocations, under DFNS policy control.
What Canton allocations are
Canton’s token standard defines two ways to move an asset. Free of Payment transfers move an asset directly from one party to another. Delivery versus Payment transfers settle several assets at once, coordinated by an application, so that every leg completes together or none does. Allocations are what makes the second one work.
In a DvP settlement, each party commits its assets before anything executes. An allocation is that commitment. A party reserves specific assets for a specific settlement, and once every leg has been allocated, the application executes the whole transaction atomically. Delivery and payment happen in the same instant. There is no window in which one side has paid and the other has not, which is what removes counterparty risk from settlement.
The standard exposes this through three uniform interfaces. An Allocation Request API lets an application ask wallets for assets in a standard way. An Allocation API lets registries provide assets to settlement workflows through standard interfaces. An Allocation Instruction API lets wallets create allocations in a consistent format. Before these existed, every token pair needed custom logic and every DvP needed a bespoke integration. The model proved itself in production in October 2025, when CantonSwap executed the first atomic swap between Canton Coin and CBTC, two tokens from two issuers, using only the standard interfaces.
What CIP-112 adds
CIP-112 was approved by the Canton Foundation in June 2026 as a backwards-compatible evolution of CIP-56. It introduces new versions of allocation instructions, allocation requests and allocations, alongside holdings and transfer instructions, with improvements for privacy, performance and traditional accounting.
Its defining addition is the committed allocation. Under CIP-56, an allocation reserved assets for a settlement, but the party could in principle withdraw it before the settlement executed. A committed allocation locks the allocated assets until a settlement deadline. The counterparty knows the party cannot withdraw the Canton leg before that deadline, which is what allows a settlement to be coordinated with a leg somewhere else, on another network, in a payment system, or on paper. The timelock turns a promise into a commitment, and that is the difference between a trade a counterparty can rely on and one it has to trust.
How DFNS supports allocations
DFNS implements the wallet side of the allocation workflow, for CIP-56 and CIP-112 alike. When an application asks a DFNS-secured party to commit assets to a settlement, DFNS does four things.
- It resolves the assets to allocate, working on the key and token model the standard defines rather than imposing abstractions of its own.
- It applies the full Policy Engine to the allocation itself. Approval quorums, amount limits, time locks, screening, passkey authentication and organizational safeguards all apply, so committing assets to a settlement is governed exactly like any other movement of value. Under CIP-112, this includes committed allocations, where the policy decision is made knowing the assets will be locked until the deadline.
- It creates and signs the allocation through DFNS key management, with the party’s key held as MPC shares or in an HSM, hosted by DFNS or the institution’s own, and never on the node, and returns it so the settlement can proceed once every leg is committed.
- It indexes the allocation and the settlement, with real-time balance updates and webhooks for each state, including requested, created, settled and expired, so operations and reconciliation follow the full lifecycle. If a settlement does not execute by its deadline, the allocation expires and the assets return to the party’s available balance.
The critical point is where the controls sit. The allocation is the moment an institution puts real assets at stake. By enforcing policy at that step rather than only on a generic transfer, DFNS gives institutions governance over the exact action that carries the risk.
Just as important is what DFNS does not do. It does not coordinate the settlement, manage validator topology or act as a registry. Those responsibilities stay with the application, the registries and the validators. DFNS secures the keys, governs the commitment and signs. The support runs on validators DFNS operates and on an institution’s own validator connected through Bring Your Own Validator.
What this unlocks
- Atomic DvP for securities and cash. A DFNS-secured wallet can supply either leg of a delivery-versus-payment settlement, a tokenized security against tokenized cash, with both settling at once. This is the settlement model behind the institutional activity already on Canton, from Broadridge’s Distributed Ledger Repo platform, which processes more than $7 trillion a month in repurchase agreements by settling the cash and collateral legs together, to the tokenized securities now delivered through the DTCC Tokenization Service.
- Settlements coordinated beyond Canton. With committed allocations, the Canton leg can be locked while the other leg is arranged elsewhere. A repo dealer can commit collateral until the settlement deadline while the cash side is confirmed. A tokenized fund can be committed to a subscription that settles against an external payment. A cross-chain trade can proceed because one leg is guaranteed not to move.
- Cross-token swaps without bespoke integration. Because allocations are standardized, a DFNS wallet can take part in multi-asset, multi-leg swaps across tokens from different registries, once each token is enabled on DFNS, the same workflow CantonSwap used, without anyone building logic per asset pair.
- Repo, FX and multi-currency settlement. Canton is asset-agnostic and currency-agnostic. The same atomic mechanism serves a Treasury trade, a repo or a cross-currency swap, and a DFNS-secured party can hold a governed leg in any of them.
- Governed institutional settlement. An institution’s existing controls, the approval chains, limits and audit trails it already runs on DFNS, now apply directly to the act of committing assets to a Canton settlement. Settlement stops being an ungoverned edge and becomes part of the same control plane as the rest of the institution’s onchain operations.
What it means for clients
For existing DFNS users on Canton, allocations are an addition, not a change. Wallets and token support keep working as they do today, and applications on either version of the standard are supported from the same wallet, with no migration, key rotation or operational change.
For Canton application and registry developers, DvP and multi-leg settlements involving DFNS-secured parties can be orchestrated through the standard allocation APIs, in either version, treating DFNS as one governed signing and custody option, with no DFNS-specific integration.
For institutions evaluating Canton, the settlement leg is now covered by infrastructure they already trust, including the committed allocations that repo and collateral markets have been asking for.
Next steps
DFNS will keep working with settlement and registry partners validating end-to-end atomic settlement in production, and will track Token Standard V2 as applications adopt it beyond allocations. Combined with our Canton Wallet Gateway and Bring Your Own Validator support, institutions can run keys, policies, approvals, settlement and validator infrastructure across Canton from a single governed environment.
Today we also publish the third post in our network series, a full look at Canton, its privacy and settlement model, every capability DFNS supports on it, and the markets already running there.
- Learn more about onchain core banking: dfns.co
- Explore the platform and documentation: docs.dfns.co
- Start building today on DFNS: app.dfns.io/get-started
