docs(canton): fix CCT prerequisites, BurnMintFactory coverage, and ApplyChainUpdates example

[SyedAsadKazmi]

• Prerequisites (all CCT guides): DAR bullets now link the contracts/dars/released folder, require upload and vetting (link to Upgradability), and add the CommitteeVerifier DAR required for executing incoming transfers.
• BurnMint guide, factory coverage: new sections for custom tokens:
  • Pin the BurnMintFactory on the TAR via SetBurnMintFactory (LinkRegistry as the reference implementation)
  • Factory contract shape: top-level instanceId create argument required for EDS ACS indexing
  • Serving the factory from EDS: address vs url mode; testnet token-standard backend is https://api.utilities.digitalasset-staging.com (not a validator scan-proxy URL); url mode resolves registry instruments only
• Both guides: full ApplyChainUpdates JSON example: remoteChainSelectorsToRemove + chainsToAdd (list of ChainUpdate records, each carrying its own remoteChainSelector), not the pool's remoteChainConfigs create field.
• EDS concept page: fix dead lzrnd TAR address in the batch example (live: nbehb); add [factory].type row to the config reference.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
documentation	Ready	Preview	Oct 17, 2026 12:50am UTC

[Giuliano-1]

@SyedAsadKazmi can we also be more specific in https://docs.chain.link/ccip/canton/concepts/manual-execution that the manual exec using the SDK the accept holding si implicit to the manual exec command

[Giuliano-1]

Maybe we can add an example config like this one I had shared with a customer (review it to make sure its good):

[server]
  host = "0.0.0.0"
  port = 8088

[node]
  url = "FILL THIS"
  max_retries = 10

[node.auth]
  type = 'clientCredentials'
  user_id = 'FILL THIS'
  # Keycloak realm only serves openid-configuration (no RFC 8414 oauth-authorization-server),
  # so use the explicit token endpoint instead of discovery.
  token_url = 'FILL THIS'
  client_id = 'FILL THIS'
  # client_secret is injected via CANTON_LEDGER_CLIENT_SECRET env var
  # (Vault -> ExternalSecret -> secretKeyRef). Do not set it here.

# ccip_api, ccv_api, and executor_api are not needed for the USD1 token pool use-case.
# token_pool_api is enabled (Phase 2) — BurnMintTokenPool is registered on the TAR.
[ccip_api]
  enabled = false

[ccv_api]
  enabled = false

[executor_api]
  enabled = false


[token_pool_api]
  enabled = true

  # instance_address is the Keccak256 hash of the raw instance address string "<pool_instance_id>@<pool_owner_party>"
  [token_pool_api.token_pools."FILLTHIS"]
    party_id         = "FILLTHIS"
    instance_address = "FILLTHIS"
    type             = "burnMint"
    pool_owner       = "FILLTHIS"

    # Factory resolution via DA's utility-registry backend.
    [token_pool_api.token_pools."FILLTHIS".factory]
      type               = "url"
      token_standard_url = "https://api.utilities.digitalasset.com" # mainnet one 
      # token_standard_auth is NOT set — DA's endpoint is public (security: [])

[Giuliano-1]

Also its not the DA registry that resolves it but our TP EDS that's resolving the Registry EDS. Unless I'm misunderstanding what you're saying, but its a bit confusing.

[SyedAsadKazmi]

Added the example, with three corrections verified against the EDS code: token_url doesn't exist (auth_url + RFC 8414 discovery is the supported path), there's no CANTON_LEDGER_CLIENT_SECRET env var (secrets go in a layered config_secrets.toml via CONFIG_FILE), and chain_selector is required.

Wording fixed too: the EDS is now the actor ("EDS calls the DA registry backend's getBurnMintFactory endpoint").

Refs: auth config, secrets pattern

[Giuliano-1]

This is also bundled within the releases. Should always just say upload the official release, your Canton node will automatically resolve the correct versions to vet.

[SyedAsadKazmi]

De-pinned the links, thanks!

Two corrections:

1. The CCV package is not bundled in the pool DARs (PACKAGE_INFO.md shows it as a separate release), so the separate upload bullet stays.

2. And dars.upload defaults to vetAllPackages = false (Canton docs), so the docs keep saying "uploaded and vetted" rather than promising automatic resolution.

[Giuliano-1]

Link token isn't currently a registry issued asset btw. That's still a tod this month by John.

[SyedAsadKazmi]

Good context. The docs never claimed LINK was registry-issued, so nothing to fix, but the wording is sharper now: custom tokens = "any instrument not created via the Registry utility," and LinkRegistry is described as a custom-token factory.

[Giuliano-1]

Here too should just point to the official release. Like you did for TP.

[SyedAsadKazmi]

Done: package names (ccip-burn-mint-token-pool-v2 / ccip-lock-release-token-pool-v2
/ ccip-committee-verifier-v2) + a link to the contracts/dars/released folder, no version pins.

[Giuliano-1]

Do we need to be repeating this so many times? Is there maybe a hierarchy of docs that this rolls up into?

[SyedAsadKazmi]

Agreed. The DAR guidance now lives once in the CCT index's "Prerequisites (all CCT
guides)" section; both guides link to it with a single line.

[SyedAsadKazmi]

@SyedAsadKazmi can we also be more specific in https://docs.chain.link/ccip/canton/concepts/manual-execution that the manual exec using the SDK the accept holding si implicit to the manual exec command

@Giuliano-1, verified in code: the SDK never calls accept. The release runs inside the same Execute transaction (CCIPReceiver.daml). BurnMint pools (the default testnet pool) mint holdings directly via BurnMintFactory, so no TransferInstruction exists. LockRelease pools complete immediately with a preapproval; without one a pending TransferInstruction remains, and the SDK does not accept it for you.

Docs now say "holdings arrive with execution" instead of the old separate-accept-step claim.