Upgradability (Canton)
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 repository for contract sources.
For participant operations (uploading DARs, vetting, and unvetting packages), see the Canton Network documentation — for example Manage Daml packages and archives.
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
- Chainlink builds the new DAR and communicates it to affected parties.
- Chainlink uploads the DAR on its validators.
- After a coordination window, parties upload the DAR on their own participants.
- 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.
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, and retire the old pool once traffic has moved.
See the BurnMint and LockRelease 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 and source prerequisites.
- Confirm party IDs and contract addresses with Chainlink CCIP when deployments change.