Canton Network

Rocky exchange builds on Canton Network for on-chain settlement and native-token (MTC) issuance. This page covers the core concepts, network properties, and Rocky's role inside it.

1. What is Canton Network

Canton Network is a privacy-first public network for regulated financial assets, designed by Digital Asset and built on the Daml smart-contract language.

Compared to global-shared-ledger chains:

Dimension	Ethereum / Solana	Canton Network
Data visibility	Everything public	Each contract is only visible to its stakeholders (privacy by default)
State synchronization	Whole-network consensus on a single ledger	Multiple Synchronizers each arbitrate independently; cross-app interactions settle across them
Smart contract model	EVM account model	Daml contracts (multi-signatory + explicit stakeholders)
Regulatory friendliness	Hard to comply when everything is public	Built-in privacy + auditability — friendly to financial institutions

Canton fits use cases like:

Tokenization of regulated assets (equities, bonds, funds, stablecoins)
B2B on-chain settlement (clearing houses, custodians, market makers)
Apps that need provable settlement + data isolation (Rocky is one)

2. Core concepts

2.1 Party

The basic identity unit in Canton. A Party can be a person, an institution, an application, a custodian, etc. Each has a unique id:

alice-test::1220ca15423a1b049bf8e84132360f246057aa18f5e9e36a77db535b75bd287cceff
   ^^^^^^^^^^                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    party hint                                       participant fingerprint suffix

Party hint — human-readable prefix (chosen by the app at registration, e.g. alice-test)
Suffix — fingerprint of the Participant node that hosts the party (different per validator)

Every registered Rocky user gets one Canton Party, allocated by the Validator API at signup time.

2.2 Contract

A Daml contract is a data structure with an explicit stakeholder list. Each contract must declare:

Signatory — parties that must agree on creation and archival
Observer — parties that can read but not modify
Controller — parties that can exercise a choice (action)

template MiningReward
  with
    exchange : Party       -- signatory: Rocky platform party
    miner    : Party       -- observer: the winning user party
    rewardAmount : Decimal
    orderHash : Text
  where
    signatory exchange
    observer miner

    choice Claim : ContractId Holding
      controller miner
      do
        ...

Key property: a contract is only visible to its stakeholders. Other parties on the same Synchronizer never see it. This is Canton's "privacy by default".

2.3 Synchronizer

Analogous to a "blockchain" in the Ethereum world, but multiple Synchronizers coexist. Each Synchronizer:

Orders + reaches consensus on the contract state changes that happen within it
Runs as a set of Sequencer + Mediator nodes (could be one operator, or decentralized)
Interoperates with other Synchronizers via the Canton Network Protocol

Rocky's DevNet connects to Splice / Global Synchronizer (the community-shared public sync domain).

2.4 Participant Node

A Party doesn't exist directly "on chain". Parties are hosted by a Participant node, which is the entity that actually talks to a Synchronizer.

User (Web)
  ↓ Ledger API
Participant Node ←→ Synchronizer ←→ Participant Node
  ↓                                       ↓
Party "alice-test"                  Party "bob-test"

Rocky uses the validator model: every user party is hosted on Rocky's Validator participant.

2.5 Validator

Validator = Participant + wallet app + Auth0 integration. A standardized participant deployment template provided by the Splice project.

Key capabilities:

Party allocation — POST /v0/admin/users creates a Daml User + allocates a Party in one shot
Token management — built-in wallet view that tracks Holding contracts the party owns
Auth0 integration — JWT → party identity mapping

Rocky's POST /api/register is essentially a wrapper around the Validator's POST /v0/admin/users, so the frontend never touches Canton directly.

3. The privacy model

Canton's privacy works at three levels:

Contract level — each contract's payload is only visible to its signatory + observer set
Participant level — a Participant only receives contracts where it hosts at least one stakeholder (no irrelevant data stored)
Synchronizer level — the Synchronizer only sees encrypted commitments (for ordering), not the contract content

Example: Alice completes one trade on Rocky. On-chain we write:

A TradeOrder contract — signatory: Rocky exchange + Alice — only Rocky and Alice can see it
A MiningReward contract — signatory: Rocky exchange; observer: Alice — only Rocky and Alice can see it

Bob, other users, other validators, and the Splice Synchronizer nodes cannot see this data. The Synchronizer still provides ordering + double-spend protection for both contracts.

4. Rocky's role inside Canton

4.1 Party roles

Party	Type	Responsibility
`app-provider`	Platform party	Admin authority over contract templates (e.g. signatory of `MiningReward`)
`app-user`	Participant operator	Hosts every end-user party
`dso` (Decentralized Synchronizer Operator)	Third party	Operates the Splice / Canton Sync domain
`<username>`	End-user party	Allocated at signup, hosted on the app-user participant

Detailed design: see party-model-decision.md at the repo root.

4.2 On-chain vs off-chain data

Not all trade actions go on chain. Rocky's design is off-chain matching + on-chain settlement for key events:

Data	Storage	Reason
Order book, matching state	rocky-backend (Postgres)	High frequency — chain can't keep up
User wallet balances (USDC, CC)	rocky-backend `ledger.accounts`	Updated very frequently
MTC mining rewards	Canton chain (`MiningReward` contract)	Non-repudiable, externally auditable
Daml user identity (Party)	Canton Participant	Reused across apps

4.3 User-facing on-chain interaction

Each successful perp trade triggers POST /api/perp/rewards/mint. Rocky's app-provider party creates a MiningReward contract on Canton with Alice as an observer. Alice can later exercise MiningReward.Claim to turn the reward into a Holding (the standard token contract) and either transfer it or view it in her Splice wallet.

5. Environments

Rocky currently runs on Canton DevNet:

Environment	Sample URL	Purpose
LocalNet	`http://canton:7575`	Local development; single participant, offline
DevNet	`https://canton.network.global`	Public testnet, shared with the Splice community
MainNet	(planned)	Production

The DevNet party-id suffix is a fixed value (set via the PARTY_ID_SUFFIX env var) — all users share the same participant fingerprint.

6. Further reading

Canton Network Whitepaper
Daml Documentation
Splice Documentation
Rocky internal design docs:
- party-model-decision.md — Party model selection
- Canton_Custody_Wallet_Architecture.md — Custody wallet architecture
- canton-privacy-arbitration-design.md — Privacy arbitration design

1. What is Canton Network​

2. Core concepts​

2.1 Party​

2.2 Contract​

2.3 Synchronizer​

2.4 Participant Node​

2.5 Validator​

3. The privacy model​

4. Rocky's role inside Canton​

4.1 Party roles​

4.2 On-chain vs off-chain data​

4.3 User-facing on-chain interaction​

5. Environments​

6. Further reading​