Skip to main content
Any data, such as a token transfer or an arbitrary instruction, can be encoded as bytes and delivered to a destination chain with LayerZero. This also applies to the Canton Network, where applications are written in Daml.
If you’re new to LayerZero, read “What is LayerZero?” before you continue.

A Canton OApp communicates with OApps on EVM, Solana, and the other chains that LayerZero supports. The messages, the packet format, and the DVN verification model are the same as on other chains. The Canton side is different in how identity, authorization, state, and fees work. This page describes those differences.

Differences from the Ethereum Virtual Machine

Canton’s own documentation has a full comparison for EVM developers:
Skip this section if you already know the Canton ledger model and Daml.

Comparison Table

Parties, Not Addresses

On Canton, an identity is a party. A participant node hosts the party. The participant node stores the contracts the party can see and submits transactions for it. A party ID has the form hint::fingerprint, for example Alice::1220f2fe…. Canton’s documentation tells you to treat party IDs as opaque identifiers. A party ID is longer than the 32-byte address field in a LayerZero message, so a party is not used directly as a bytes32 peer or receiver.

Signatories, Controllers, and Observers

Daml declares authorization in the template, not in runtime checks on msg.sender. Canton’s authorization model has three roles:
  • Signatory: must authorize the creation of a contract and always sees it.
  • Controller: can exercise a specific choice on a contract.
  • Observer: can see a contract but cannot act on it unless it is also a controller.
The participant nodes that host the signatories and actors of a transaction must confirm it. Observers’ nodes receive their part but do not confirm. If a confirming party’s hosting nodes cannot reach its confirmation threshold, for example because its only node is offline, the transaction cannot complete.

Privacy and Explicit Disclosure

Canton is private by default. A party can only use a contract that it can see. To use a contract that it is not a stakeholder of, the submitter attaches the contract to the command as a disclosed contract. The contract’s stakeholders share it off-ledger. A LayerZero send uses contracts that the sender is not a stakeholder of. The sender’s submission must include those contracts as disclosed contracts.

Immutable Contracts and Changing Contract IDs

A Daml contract never changes. A consuming choice archives the contract. If the choice creates an updated contract, that contract has a new contract ID. Do not store a contract ID as a permanent identifier for a token, an OApp, or a configuration. Look up the current contract when you need it.

Holdings Are UTXO-Style

A CIP-0056 token balance is a set of holding contracts, similar to Bitcoin UTXOs. A transfer consumes input holdings and creates new ones. Only the stakeholders of a holding, such as its owner and the token administrator, can see it on the ledger. Canton Coin is an exception: the DSO party is a stakeholder of every Amulet holding, and Scan publishes Amulet holdings by owner. For a LayerZero send, the sender’s wallet still supplies the holding contracts to spend.

DAR Packages and Package Vetting

Daml code ships as a DAR (Daml Archive) package. Before a participant node can take part in a transaction that uses a package, it must upload and vet the package. This includes the participant nodes of your wallet providers. Package upgrades follow the same rule: every participant node involved in a transaction must vet the package version that the transaction uses.

Fees in Amulet

Canton charges traffic for each transaction, bought with Amulet (Canton Coin), and the protocol fee for a send is also paid in Amulet. See Fee Model.

What a Canton Integration Requires

A LayerZero integration on Canton needs the following. For the full procedure, see Deploying an OFT on Canton.
  1. A participant node for your parties. This can be your own validator node or a party hosted on another operator’s node. To join the Global Synchronizer, a validator needs a Super Validator sponsor.
  2. A CIP-0056 token for the asset that you want to move crosschain.
  3. The LayerZero DAR packages, which LayerZero provides. Upload and vet them on your participant node and on the participant nodes of your users’ wallets.
  4. Amulet to pay for traffic, LayerZero messaging fees, and the fee on each endpoint configuration request.
  5. Disclosed contracts from LayerZero. Each send must attach LayerZero-signed contracts that the sender cannot see. LayerZero provides these as part of an integration.
  6. Endpoint configuration. You submit the send and receive libraries, DVNs, and executor settings for your OApp as requests. The lzowner party accepts each request after VER processes it. lzowner is the LayerZero protocol party that commits VER results (see Protocol Overview).
  7. A Canton 3.x application. The LayerZero endpoint on Canton targets Canton 3.x. An application built on Daml 2.x cannot integrate directly. It must upgrade first.
  8. An OApp or OFT on each remote chain. You deploy and configure these with the standard LayerZero tooling for that chain, for example the EVM OFT quickstart.

Get Help

LayerZero on Canton is not yet open for self-service integrations. To discuss integrating, contact the LayerZero team.

Next Steps

OFT Deployment

Deploy an OFT adapter for a CIP-0056 token on Canton and wire it to an EVM chain, step by step.

Technical Overview

The Canton model in detail, and how each part affects a LayerZero OApp.

Protocol Overview

How the Virtual Endpoint Rollup processes sends and receives on Canton.