Glossary

Key terms used across the Canton DEX docs and code. Start with Canton and Daml foundations if this is your first Canton application; the second section is a lookup for the Token Standard and exchange design. Where useful, entries link to the defining Daml module, an executable test, or a deeper concept page.

For a connected explanation rather than isolated definitions, read the Canton and Daml primer.

Canton and Daml foundations

Active Contract Set (ACS)

The contracts that have been created and not archived, as visible to the party making the query. The ACS is current ledger state, not a globally readable table: two parties can see different subsets. The backend indexer projects ACS and transaction events into its off-ledger read model.

Canton

The distributed-ledger system on which this application runs. Canton connects participant nodes through synchronizers while preserving party-scoped visibility; Daml defines the contracts and transactions participants process.

Canton DevKit

An optional, separately distributed development tool that can manage a persistent Docker-based Splice LocalNet. It is not required by the DEX source, DARs, backend, or default live proof. If DevKit is unavailable, use the repository’s DPM sandbox proof.

Choice

A named operation defined on a Daml template or interface. Exercising a choice can fetch, create, archive, or exercise other contracts in one transaction, but its controller must authorize it. A choice is consuming by default; a nonconsuming choice leaves its target contract active.

Command

A client’s request to create a contract or exercise a choice. One submission can contain multiple commands; the resulting Daml transaction either commits atomically or fails as a whole.

Contract / contract ID (CID)

An immutable on-ledger instance of a template. Its contract ID identifies that exact active instance. When a consuming choice archives a contract and creates its successor, the successor has a new ID. Values such as #mock-…:0 returned by Mock Wallet are UI placeholders, not Canton contract IDs.

Controller

The party or parties whose authority is required to exercise one Daml choice. For example, DexPair_SetActive is controlled by the DEX operator. A party that can see the contract is not necessarily its choice controller.

Daml

The smart-contract language and ledger model used by this reference. A Daml template declares contract data, stakeholders, and choices; the engine checks authorization and atomic transitions.

Daml Script

A Daml library and runner for allocating test parties, submitting commands, querying contracts, and asserting results. dpm test runs this repository’s Script declarations in a Daml ledger engine. It enforces Daml semantics but does not, by itself, start a Canton participant, backend, or browser.

DAR (Daml Archive)

The build artifact containing compiled Daml packages and dependencies. Running dpm build in trading/ produces the DEX DAR. Uploading a DAR makes its code available to a participant; it does not create application contracts or seed liquidity.

DPM sandbox

The real Canton sandbox process bundled with the Daml SDK selected by DPM. The repository’s default live proof starts it temporarily, uploads the package closure, runs a JSON Ledger API DvP driver, and removes its state after success. It is a one-process proof, not a persistent Splice LocalNet. See Local Canton.

JSON Ledger API

The HTTP/JSON API used by this repository’s live backend adapter to submit Daml commands and read ledger updates from a Canton participant. The local dev server replaces this adapter with a TypeScript InMemoryLedger, so it does not exercise the JSON Ledger API.

LocalNet

A local network used for Canton/Splice development. In these docs, DevKit LocalNet means the optional persistent Docker-managed environment; it is distinct from the default throwaway DPM sandbox. Neither is a production topology.

Observer

A contract stakeholder explicitly granted visibility without being required to authorize its creation. Observing a contract does not automatically grant authority to exercise its choices.

Package / package ID

A compiled unit of Daml code with a content-derived package ID. Template IDs on a live ledger include the package identity. The repository’s package name and version help humans find the DAR, but deployments must use the package IDs actually uploaded and vetted on their network.

Participant

A Canton node that hosts parties, exposes Ledger APIs, validates submissions, and stores the ledger data visible to its hosted parties. A participant is infrastructure; it is not the same thing as a party.

Party

A logical on-ledger identity that can authorize Daml actions and be named as a stakeholder. Traders, the DEX operator, the asset admin, and the LP registrar are parties. Real Canton party IDs normally include a fingerprint such as alice::1220…; trader-demo is only a local seed label.

Signatory

A party that authorizes a Daml contract’s creation and remains a stakeholder with visibility while it is active. Signatories are declared in the template’s where block.

Synchronizer

Canton infrastructure that coordinates transaction sequencing and confirmation between connected participants. It does not turn every participant into a public full node or make every contract visible to everyone.

Template

A Daml definition containing the fields, signatories, observers, and choices for one kind of contract. PoolState is a template; each live pool-state contract is an instance with its own contract ID.

Transaction

The atomic result of one submission: all creates, exercises, nested choices, and archives commit together or none commit. A pool swap relies on this so Token Standard settlement, reserve-slice updates, and PoolState replacement cannot partially succeed.

Token Standard and DEX terms

Allocation

A Token Standard V2 contract that locks a holder’s holding for one specific settlement, so the batch can settle it atomically later. The DEX never moves trader assets directly — the trader authors allocations and the venue settles a batch. Template Allocation; see Allocation Surface.

AllocationFactory / AllocationFactory_Allocate

The registry factory choice a holder exercises to turn holdings into an Allocation. It runs under the holder’s own authority, which is why funding an order or adding liquidity must go through the trader’s wallet. Implemented in Registry.V2.

AllocationRequest

A V2 contract that publishes the allocation specifications a settlement needs and the actions available to the target party. Liquidity funding composes request acceptance with AllocationFactory_Allocate; order funding uses the request as a correlation record and consumes it when the resulting allocation is bound. The DEX’s variants are OrderAllocationRequest, LiquidityAllocationRequest, and TradeAllocationRequest.

Choice context / disclosure

The extra arguments (ExtraArgs) and disclosed contracts a registry requires when its factory choices are exercised. The operator backend fetches these and attaches them to each submission. See Choice Context.

CIP-0056

The Canton Network Token Standard: the base standard (holdings, transfers, metadata) that CIP-0112 revises.

CIP-0103

The dApp Standard: the wallet-interaction standard behind prepare/sign/execute. The dApp hands trader-authority commands to a wallet over CIP-0103.

CIP-0112

The Canton Network Token Standard V2: the privacy / performance / traditional-accounting revision of CIP-0056 that adds the allocation + settlement surface this DEX is built on. Often written “Token Standard V2” or “TSv2”.

Boundary slice

The last reserve slice in the ordered set that a swap or liquidity removal draws on to cover an amount. Earlier slices in the set are consumed in full; the boundary slice is usually only partially drawn, so its unused remainder is re-wrapped into a fresh PoolSlice. Selecting an ordered prefix this way keeps each swap touching only a few slices rather than the whole pool.

Committed allocation

An allocation authored with committed = True, so the authorizer cannot unilaterally withdraw it before its deadline and the executor has an availability guarantee. Pool reserve slices are committed. Expiring order collateral is committed through its deadline; GTC order collateral is uncommitted to preserve a trader-controlled exit. Field on AllocationSpecification; see PoolSlice.

DexPair

The operator’s listing record for one market: base + quote instrument ids, the fee model (maker/taker/pool bps), the trading mode (TM_OrderBook, TM_Pool, or TM_Both), and an active flag. Template DexPair.

DvP (delivery-versus-payment)

An atomic exchange where both legs settle together or not at all. Swaps, LP add/remove, and matched trades all settle as DvP through SettlementFactory_SettleBatch. See Liquidity & Custody; proven in PoolLiquidityRulesTests (an add funds base+quote and mints LP tokens in one flow).

FinalizedAllocation

The V2 settle-time structure that carries a match’s concrete leg sides (extraTransferLegSides) and the roll-forward funding (nextIterationFunding) for iterated settlement. Built by mkFinalizedAllocation and consumed by OrderMatchExecution.

Holding

A V2 contract representing a party’s balance of one instrument. Base assets, quote assets, and LP tokens are all holdings. Template Holding.

InstrumentId

The {admin, id} pair that identifies a V2 instrument. Two instruments with the same id but a different admin are different instruments. The DEX stores the id component per pair/pool and pins its admin alongside.

Iterated settlement

Settling in steps, where each step rolls the remaining backing forward to the next iteration via nextIterationFunding. Pool reserve slices and partial order fills use it so one allocation can back many settlements; the trader’s swap allocation is terminal and signs its exact input and output sides. Iteration is independent of whether an allocation is committed. Enforced in Registry.V2; proven in RegistryConservationTests (roll-forward stays within the locked backing).

LP token / LPTokenPolicy / lpRegistrar

The pool’s liquidity-provider share is a V2 instrument (the LP token), administered by the lpRegistrar and governed by the LPTokenPolicy contract, which tracks only supply and knows nothing about pools or orders. See LP Tokens.

MatchedTrade

The venue-signed trade contract Rfq_Accept emits: it carries the transfer legs plus an optional operator-signed PolicyReceipt and settles via a per-admin SettleBatch. Template MatchedTrade; its allocation and batch-settlement behavior is proven in RfqSettlementTests.

Mint / burn account

Special Token Standard accounts with owner = None, the counterparty for LP-token mint (issuance) and burn (redemption) legs. Registry.V2 recognizes exactly these two as admin-authorized mint/burn sources:

mintAccountId = "cip-112/mint"
burnAccountId = "cip-112/burn"
...
mintAccount = HoldingV2.Account None None mintAccountId
burnAccount = HoldingV2.Account None None burnAccountId

Defined in Trading.Utils; the mint/burn mechanism is proven as part of atomic add/remove settlement in PoolLiquidityRulesTests.

Operator

The venue operator: it orchestrates matching, binds orders, and submits the settlement batches it is authorized to submit. It cannot settle a trader’s holdings without that trader’s allocation. The operator-mediated RFQ path is a separate authority model in which the backend ledger user is explicitly granted act-as rights for configured parties; it is not a public relay supplied by the repository.

Over-lock

Locking more backing than a settlement strictly needs. Token Standard V2 accepts have >= needed; the surplus is returned as unlocked change when the batch settles. Proven in RegistryConservationTests (surplus backing returns to the authorizer).

PolicyReceipt

An operator-signed record of the ranking/whitelist policy applied to an RFQ, folded into SettlementInfo.meta so the decision travels on-ledger and stays auditable. Type PolicyReceipt; proven in PolicyReceiptTests.

Pool / PoolState / PoolSlice

The constant-product pool is split three ways: Pool (immutable config), PoolState (the hot reserves / LP supply / status), and PoolSlice (one committed allocation per side). Slices are operator-authored inventory units, not per-LP entitlement. Swap and remove use only a covering slice set, while every reserve-changing operation still updates the singleton PoolState. Reserves↔slices integrity is proven in PoolStateInvariantTests.

prepare / sign / execute

The three steps of CIP-0103 interactive submission: the dApp prepares a transaction, the wallet signs it, and it is executed on the ledger. CIP-0103 does not itself limit the number of top-level commands; some wallet gateways do.

Registry / Registrar

The component that defines instrument semantics and supplies choice context. It is external to the DEX; this repo ships a reference Registry.V2, but Token Standard V2 does not require that exact one. See Registry Integration.

RFQ (request-for-quote)

The bilateral block-trade flow: a trader posts an Rfq, whitelisted dealers post RfqQuotes, and a joint Rfq_Accept (trader + operator) emits a MatchedTrade. Source Rfq; see Workflows.

SettlementFactory / SettlementFactory_SettleBatch

The registry factory that atomically settles a batch of allocations, enforcing per-instrument conservation (total sent equals total received) across the batch. Implemented in Registry.V2; conservation proven in RegistryConservationTests.

Token Standard V2 (TSv2)

See CIP-0112.

---

Where to read next: Canton and Daml primer · AMM-first walkthrough · Architecture · Workflows · Allocation Surface · All docs