Settlement (CIP-112)
The settlement primitive is an interface-shaped engine for atomic, value-moving delivery-versus-payment (DvP) on Canton, aligned with the Canton Token Standard and the CIP-112 settlement design.
Experimental. The settlement engine is a preview surface built against stand-in token interfaces while the upstream Canton Token Standard packages stabilize. It is not audited and not intended for production use. Interfaces and behavior may change.
What It Does
Settlement coordinates the atomic exchange of assets across multiple parties. A settlement batch groups several legs (each leg moves value from one party to another) and either commits all of them together or none of them, so no party is left partially settled.
At a high level the primitive covers:
- Atomic multi-leg settlement: settle a batch of legs as a single all-or-nothing operation.
- Value-moving settlement: on settlement, receiver legs are credited, rather than only recording a receipt.
- Allocation lifecycle: a request, instruction, and allocation flow, with cancel and withdraw paths.
- Compliance hooks: fail-closed reference hooks for node-level attestation, and a controlled seizure path for lawful process, gated behind explicit authority.
Status
This primitive builds and is exercised two ways: an in-memory test suite against mock token interfaces, and a set of interoperability exemplars (an ERC-20-style facade, a wallet-driven settlement lifecycle, and app-provider activity attribution) that run against a local Canton ledger over the Ledger API. Importing the real Canton Token Standard packages and promoting the primitive into the general library are tracked as follow-on work. See OpenZeppelin/canton-specs for the current engine, its threat model, and the interop exemplars.
Related
- Reference Implementations, which compose settlement into complete applications.
- Library, the access-control, ownable, and pausable primitives settlement builds on.