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 currently builds and is exercised by an in-memory test suite against mock token interfaces. Importing the real Canton Token Standard packages, promoting the primitive into the general library, and running it against a live network are tracked as follow-on work. See OpenZeppelin/canton-specs for the current engine, its threat model, and its audit-readiness notes.
Related
- Reference Implementations, which compose settlement into complete applications.
- Library, the access-control, ownable, and pausable primitives settlement builds on.