Manual Execution (Canton)

On Canton, manual execution is required when Canton is the destination chain. This is different from EVM-style CCIP, where manual execution is usually a fallback when automatic execution fails.

Why Canton requires manual execution

Canton enforces data privacy: parties only see contracts they are stakeholders on. Incoming messages may involve private receiver contracts, token DARs, and token pool contracts that Chainlink operators cannot access on your participant.

Chainlink does not provide automatic execution of receiver contracts on Canton. The receiver party (or a party the receiver authorizes via explicit disclosure) must execute each message after Committee Verifier proofs are aggregated on the indexer.

When manual execution applies

Plan every inbound integration for: send on source → wait for verification → manual execute on Canton.

Execution workflow (remote chain → Canton)

Figure 1. Execute flow when Canton is the destination (receiving) chain.

1. Wait for the message to be ready

1. Track the message in the CCIP Explorer or CCIP API.
2. Committee Verifier operators (for the default verifier, Chainlink NOPs) validate the source CCIPMessageSent event, generate proofs, and submit them to the indexer.
3. Once all required Committee Verifiers have submitted proofs, the message is ready for you to execute on Canton.

2. Prepare disclosures and proofs

Before submitting to the ledger, gather:

• Proofs from the indexer for the target transaction
• Explicit disclosures from the Global CCIP EDS for CCIP contracts
• Your PerPartyRouter (or create one via PerPartyRouterFactory on first use)
• For custom Committee Verifiers: disclosures from the verifier's EDS
• For token transfers: disclosures from the asset's Token Standard Registry and the token pool operator's EDS

See Explicit Disclosure API for EDS endpoints.

3. Execute on Canton

Using the CCIP CLI or ccip-starter-kit-canton any2canton:manual-exec, interact with CCIPReceiver:

1. Deploy and configure a CCIPReceiver if needed. Set receiverFinalityConfig to match how you handle finality (FTF, FCR, or default — the sender's requested finality must be allowed).
2. Call the receiver with the message and message proof.
3. The receiver validates proofs via each Committee Verifier and calls PerPartyRouter_Execute.
4. On success, the OffRamp marks the message executed (preventing double execution).

The SDK finds or creates a compatible CCIPReceiver on the default path — see Canton as Destination tutorials.

4. Token transfers — accept holdings

If the message included a token transfer:

1. The token pool creates a TransferInstruction to the receiver party.
2. The receiver party must accept the TransferInstruction to take custody — this is separate from the CCIP execute step.

For programmable token transfers, your receiver logic runs after tokens are available.

Tooling

Scripts use @chainlink/ccip-sdk with canton-config.json and ledger auth — the same model as ccip-cli without --wallet.

Tutorials

Step-by-step walkthroughs:

• Arbitrary Messaging (destination)
• Token Transfers (destination)
• Programmable Token Transfers (destination)

Complete Canton as Destination prerequisites before running them.