Canton Token Standard V2: What CIP-0112 Means for Settlement and Privacy

On March 31, 2026, Digital Asset engineers Bernhard Elsner and Simon Meier submitted CIP-0112 — the Canton Network Token Standard V2. The proposal is still in Draft status, but its implementation is already live on a preview branch of the Splice repository. For any institution running settlement, custody, or trading infrastructure on Canton, this CIP rewrites the rules on what the sub-transaction privacy model can do at the application layer.

V2 is not a replacement for CIP-0056. It is a strictly additive upgrade — the V1 interfaces remain fully supported, and the compatibility matrix is unusually thorough. But V2 unlocks three things V1 cannot do: privacy-preserving batch settlement across multiple trading parties, single-signature authorization flows for trusted venues, and account-based holdings that match how custodians actually work in traditional finance. Every one of these has direct implications for canton coin settlement, institutional wallet UX, and how trading venues integrate with the canton network token standard.

Account-Based Architecture: The End of Party References

The most structurally significant change in CIP-0112 is the replacement of Daml Party references with an Account data structure across the entire holding and transfer model. In CIP-0056, ownership was expressed as a party identifier — a flat cryptographic reference to a single ledger participant. That worked for basic token transfers, but it cannot express the custody relationships that dominate institutional finance.

V2 introduces the Account type with three fields: owner (the beneficial owner as a Party), provider (an optional custodian or account keeper), and id (an optional account number). The basicAccount convenience function maps a plain Party to a V2 Account with no provider and no account ID — so existing V1 implementations retain identical behavior. But for assets that require custodian authorization, the provider field allows the asset registry to define whether the provider must co-sign transfers, whether the provider can execute on the owner's behalf, or whether the provider is purely an observer.

The custodial implications are direct. A custody chain where Client A holds through Custodian B who holds at DTCC can now be expressed natively in the token standard rather than in application-layer metadata. The AllocationSpecification now carries an authorizer: Account field instead of a bare Party, so settlement systems can validate that the correct account hierarchy authorized each leg before it executes. For BNY Mellon's custody infrastructure and similar custodial platforms building on Canton, this removes a significant amount of off-standard plumbing.

Multi-Leg Allocations and What They Mean for Atomic Settlement

CIP-0056 allocations were one-to-one: one Allocation per transfer leg. If Alice, Bob, and Carol were trading in a three-way ring — Alice selling to Bob, Bob selling to Carol, Carol selling back to Alice — each trader needed separate allocations for each leg, and the settlement system had to collect and coordinate all of them with full sender and receiver authorization at settlement time. This meant traders had to sign multiple times, and the settlement engine saw every leg of every party's position.

V2 changes the allocation unit. A single Allocation now covers all transfer legs for a given settlement and asset admin where the authorizing account appears as sender or receiver. In the three-trader example from the CIP, Alice creates one allocation covering her two X legs and three USD legs — the full economic picture of her participation in the trade. She signs once. The settlement factory receives her single Allocation and the matching Allocations from Bob and Carol, and batch-settles everything atomically in a single transaction.

The privacy enhancement emerges directly from this structure. Because the executor calls SettlementFactory_SettleBatch with only the executor as actor — not sender and receiver — the settlement transaction is not visible to Alice, Bob, or Carol. Each trader saw exactly their own legs when creating their Allocation. During settlement, they see nothing. The asset admin (X or USD) sees all legs for its instrument. The App executor sees all nine legs. This mirrors how traditional multi-tier account settlement actually works: each party sees their debit and credit, the settlement processor sees the full netting, and nobody sees the other side's book.

For venues building on Canton — particularly those integrating with the Global Synchronizer for atomic cross-asset settlement — this is the architecture that makes Super Validator settlement guarantees meaningful at the application layer.

Section 4.3.5.3: The 10-to-7 View Optimization for Canton Coin

Canton's on-wire efficiency and synchronizer cost are primarily a function of the number of views generated per transaction. A view is created whenever a Daml choice calls another choice that adds informees — parties who need to see the result. Reducing views reduces bandwidth, reduces mediator work, and reduces per-transaction costs on the Global Synchronizer.

Section 4.3.5.3 of CIP-0112 targets assets that do not require confidentiality between trading parties — specifically Canton Coin. Because CC transaction data is public by design, the settlement factory can set all transfer leg senders and receivers as choice observers on SettlementFactory_SettleBatch, collapsing what would otherwise be separate child views into a single top-level view. In the three-trader example, the baseline settlement transaction generates 10 views. With the 4.3.5.3 optimization applied to the USD leg, it drops to 7.

That 30% view reduction compounds. In a high-volume settlement session — the kind Broadridge's DLR processes for its $280 billion in daily repo — the difference between 10 views and 7 views per settlement transaction represents a meaningful reduction in Global Synchronizer load. For Canton Coin specifically, the CIP confirms that CC will implement these optimizations as part of its V2 upgrade. The preview branch implementation is already available in the Splice repository on the meiersi/ts2/preview branch.

The fully optimized flow, when combined with the CIP-0103 dApp connectivity optimization (which eliminates the AllocationRequest broadcast transaction entirely) and elision of allocations for settlement authorizers, collapses the six-transaction baseline to just two transactions with four views total. For venues that have pre-established trust relationships — the common case in institutional trading — this is the target performance envelope.

Single-Signature UX for Traders

One of the clearest UX improvements in V2 is the flow change for settlement venues that execute trades off-chain. Under CIP-0056, a trader interacting with an off-chain matching engine still had to sign twice on Canton: once to agree to the trade, and again to create the allocation that authorized settlement. This friction exists because V1 allocations required both sender and receiver authorization at settlement time, so the venue could not settle without collecting fresh signatures from both parties after the trade was matched.

V2 changes this. Because the executor field is now a list and SettlementFactory_SettleBatch can be called with only executor authorization, a trading venue can structure the flow so that creating an Allocation is the authorization. The venue posts the matched trade on-chain (or requests signatures via the CIP-0103 dApp API). Each trader signs once to create their Allocation. The venue calls batch settlement with executor-only authority. Traders see the result in their wallets — no second signature required.

For wallet developers integrating with canton network token standard V2, the implication is that the wallet must display the full SettlementInfo and all transfer legs when presenting an AllocationRequest for user approval. The CIP is explicit: wallets MUST show the complete settlement context so users understand what they are authorizing. The single-signature improvement does not reduce the information shown — it reduces the number of separate approval steps.

V1/V2 Backward Compatibility: The Safe Migration Path

CIP-0112 includes one of the most detailed backward compatibility specifications in any Canton improvement proposal. The compatibility matrices in Sections 5.4 and 5.5 enumerate every combination of V1/V2 app, wallet, and asset — and specify exactly what works, what works partially, and what is explicitly incompatible.

The headline finding: transfers are almost fully cross-version compatible. A V1 wallet sending to a V2 wallet on a V2 asset works in both directions. The only partial case is a V1 wallet sending to a V2 wallet where the sender cannot set receiver account information (provider/ID). Assets can handle this by resolving the receiver account in their factory or accept choices, so the incompatibility is manageable at the asset layer rather than requiring wallet upgrades.

For allocations, the matrix is more nuanced. V2 settlement (executor-only authorization) on V1 assets is not possible — V1 assets simply do not implement the SettlementFactory interface. V2 settlement on V2 assets with V1 wallets is possible via the dApp API (CIP-0103) path: the app requests the V2 AllocationFactory_Allocate choice directly without writing an AllocationRequest to the ledger. This path saves one transaction while maintaining compatibility with wallets that have not yet upgraded their Allocation UI.

The practical migration path for an existing V1 asset implementation follows a clear sequence. First, implement the V2 interfaces in parallel with V1 interfaces — the standard supplies upcast/downcast utility functions in the new splice-token-standard-utils package. Second, advertise V2 compatibility via the registry/metadata/v1/instruments API so that V2 apps can discover which assets support the new flows. Third, set showAccountInputFields: false in the metadata API if the asset uses only implicit basic accounts (like Canton Coin). The token metadata YAML file gets a backward-compatible extension for this field — no version bump required.

For assets that currently implement CIP-0056 and are evaluating the upgrade timeline, the V1 interfaces remain fully supported. The Canton Coin implementation — the reference implementation for V2 — will run both V1 and V2 interfaces simultaneously, demonstrating that the upgrade is genuinely additive. The compatibility rules ensure that a V1 app interacting with a V2 asset gets exactly the V1 behavior it expects, with no behavioral surprises from the upgrade.

What Changes for Validators and the Network

CIP-0112 is a Daml-layer standard. It does not modify the Global Synchronizer consensus protocol, Canton Coin emission schedules, or validator economics. The changes are entirely in the application-layer token standard packages that assets, wallets, and apps implement. Super Validators running Global Synchronizer nodes do not need protocol-level changes to support V2 assets — V2 settlement transactions look like any other batch of Daml choices to the synchronizer layer.

The economic effect on Canton Coin flows from the view reduction. Fewer views per settlement transaction means lower per-transaction cost on the Global Synchronizer — potentially meaningful for high-frequency venues. The CIP-0112 grant proposal (linked in Section 7 of the CIP) includes a milestone for integration test validation of the performance optimization claims, so the view count improvements will be verified against the Splice implementation before the CIP advances from Draft to Approved status.

For the broader Canton ecosystem, the CIP signals that the protocol's focus in 2026 is on institutional workflow compatibility rather than new consensus mechanisms. The account-based architecture, the multi-leg allocations, and the timing parameter changes (mandatory settleBefore replaced by flexible settleAt plus optional settlementDeadline) all address the specific friction points that TradFi settlement venues encounter when they try to map their existing workflows onto the V1 standard. CIP-0112 is the protocol meeting institutional finance where it actually operates.