# Upgradability (Canton)
Source: https://docs.chain.link/ccip/concepts/canton/upgradability
Last Updated: 2026-07-09

> For the complete documentation index, see [llms.txt](/llms.txt).

> **CAUTION**
>
> Addresses shown may change due to upgrades since Canton contracts are immutable. Confirm party IDs and contract addresses with [Chainlink CCIP](https://chain.link/ccip-contact).

On Canton, CCIP logic ships as **Daml packages** packaged in **DAR** files. Participants load and **vet** packages on their nodes before they can interpret transactions. CCIP evolves by publishing new DAR versions — see the [chainlink-canton](https://github.com/smartcontractkit/chainlink-canton) repository for contract sources.

For participant operations (uploading DARs, vetting, and unvetting packages), see the [Canton Network documentation](https://docs.canton.network/) — for example [Manage Daml packages and archives](https://docs.canton.network/global-synchronizer/production-operations/manage-packages).

## Upgrade-compatible changes

**Upgrade-compatible** changes are **non-breaking** updates within existing packages. They require affected participants to upload the new DAR on their validator — no new contract deployment or interface migration.

Examples:

| Change                                     | Who uploads the new DAR                                                                                                                   |
| :----------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------- |
| OnRamp or similar send-path update         | Parties that interact with the updated package (including Chainlink operators and affected users)                                         |
| Core CCIP package update                   | All participants that use CCIP — token pool operators, Committee Verifier operators, executors, users, and Chainlink operators            |
| Shared ticket or dependency package update | All **downstream** packages must be rebuilt; those new DARs are then uploaded (for example token pool DARs after a ticket-package change) |

### Typical rollout

1. Chainlink builds the new DAR and communicates it to affected parties.
2. Chainlink uploads the DAR on its validators.
3. After a coordination window, parties upload the DAR on their own participants.
4. Depending on urgency, operators may **unvet** the previous package version so validators still on the old DAR can no longer interpret new transactions.

For low-impact enhancements, step 4 may be skipped — both versions can coexist until participants choose to upgrade.

Upload new DARs on your participant using the process in [Upload a DAR](https://docs.canton.network/global-synchronizer/production-operations/manage-packages#upload-a-dar).

## Breaking changes

**Breaking changes** affect **Daml interfaces**. Interfaces cannot be upgraded in place — a **new package** with the revised interface is required, and every **downstream** package must be rebuilt and released against it.

The rollout follows the same communicate → build → upload → coordinate → optionally unvet pattern as upgrade-compatible changes. Breaking interface changes are avoided when possible, especially for third-party contracts such as **token pools**, because every custom pool implementation must be updated.

### Token pools

For breaking changes that require a new pool release, **deploy a new token pool**, register it in the [Token Admin Registry](/ccip/concepts/canton/token-pools#registering-on-the-token-admin-registry), and retire the old pool once traffic has moved.

> **NOTE: No liquidity migration on Canton**
>
> Canton token pools do **not** custody liquidity on-ledger — LockRelease pools use the pool owner's holdings; BurnMint pools mint and burn against instrument supply. As long as there are **no pending cross-chain messages** for the old pool, there is no on-ledger liquidity to migrate. Coordinate the cutover using the [CCIP Explorer](/ccip/tools-resources/ccip-explorer) and complete or execute any in-flight transfers before switching TAR registration to the new pool.

See the [BurnMint](/ccip/tutorials/canton/cross-chain-tokens/burn-mint-token-pool) and [LockRelease](/ccip/tutorials/canton/cross-chain-tokens/lock-release-token-pool) deployment guides for pool setup and TAR registration.

## Staying current

- Monitor communications from Chainlink CCIP operations for required DAR versions on your lanes.
- Confirm your participant has the CCIP and Registry DARs your workflows need before sending or executing — see [Key Concepts](/ccip/concepts/canton/key-concepts) and [source prerequisites](/ccip/tutorials/canton/source/prerequisites).
- Confirm party IDs and contract addresses with [Chainlink CCIP](https://chain.link/ccip-contact) when deployments change.