[ralph-bitgo]

Description

Add Canton CCIP bridge request support and USD1 EVM↔Canton client examples:

• sdk-core: optional CantonCommandParams.disclosedContracts and payload-aware resolveContracts.createArgumentFilter; export the EDS disclosure shape.
• sdk-coin-canton: serialize disclosures through CantonCommandBuilder / CantonCommandRequest.
• Inbound Execute and outbound Send examples collect global/CCV/token-pool/executor disclosures, avoid ACS lookup of the cross-party router factory, and select receivers by finality or explicit CID.
• Custodial wallets need no passphrase/unlock. Outbound requests pass tokenName. Setup halts on pending approval and supports router-only resume. Dry runs read the actual wallet party but never submit. Conflicting finality overrides fail early.
• Production requires --laneConfig with independently verified identities/URLs; the draft production constants are not treated as verified.
• README documents onboarding prerequisites and deferred operational acceptance.

Why: external clients cannot prepare custodial CCIP Execute/Send without cross-party disclosures and correct receiver finality. The examples expose the existing sendMany flow while avoiding validator credentials and preventing dependent setup steps from racing pending approval.

Issue Number

SCAAS-11643

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

• CantonCommandBuilder suite: 32 passing (cd modules/sdk-coin-canton && npx mocha --grep CantonCommandBuilder). Scoped SDK builds completed/current after workspace installation; ESLint passed for sdk-core and sdk-coin-canton, and sdk-coin-canton formatting passed.
• Both example scripts pass node --check. Seven offline CLI scenarios exercised dry-run party handling, finality filtering, approval halting, router-only resume, outbound disclosures/tokenName, production gating and conflicting-finality rejection. External responses were fixtures; no live signing or ledger execution was exercised.
• The broader Canton suite has pre-existing BITGOJS_TEST_PASSWORD-gated setup; those suites were not locally verified.
• Cross-repo validation note: type-check deferred to CI (sandbox OOM, exit 137 at concurrency 1) — wallet-platform follow-up only; IMS type-check ran locally. This does not describe an SDK type-check failure. Wallet-platform Biome/DB checks are also deferred with engineer approval. If sandbox resources become available, rerun deferred checks before leaving draft; no further environment workarounds are planned.
• Reviewer priority in the related wallet-platform change: runtime disclosure codec validation replaces a cast and now rejects malformed input; instrument↔intent-token binding and decimal-precision checks are additional client-input validations.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• My code compiles correctly for both Node and Browser environments — scoped Node builds checked; browser build not exercised
• I have commented my code, particularly in hard-to-understand areas
• My commits follow Conventional Commits and I have properly described any BREAKING CHANGES — none
• The ticket or github issue was included in the commit message as a reference
• I have made corresponding changes to the documentation and on any new/updated functions and/or methods — JSDoc and examples README
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes — builder suite passes; broader secret-gated suites deferred

Related delivery and remaining acceptance

The IMS draft provides server-side disclosure/factory resolution and pending-input metadata. Wallet-platform provides Send locks and validation. Live custodial lane execution, production constants verification, validator onboarding and the party-preflight API product ask remain outstanding; this draft does not close operational acceptance.

Pre-PR ACI gate skipped: no .github/ai-checks/pr-risk on the base branch.

Cross-repository drafts

• indexerdb-microservice
• bitgo-microservices
• BitGoJS

[linear-code]

SCAAS-11643

[github-actions]

⚠️ Unit tests are failing on Node 26.x (Current release line, non-blocking). This is not an LTS version yet, so it does not block merge, but it signals an incompatibility to fix before Node 26.x becomes LTS.

View run

[zeeshanamjad-eng]

Closing without merging — per review, no BitGoJS changes are needed for the CCIP Canton flow:

• The released SDK already supports everything the client scripts need: the cantonCommand intent (sdk-core mpcUtils / recipientUtils) and the CantonCommandBuilder with command/actAs/resolveContracts/token were shipped before this PR. The one field this PR added to the SDK types (createArgumentFilter) reaches IMS at runtime without an SDK change (spec objects pass through the builder into the IMS request JSON, and indexerdb-microservice#2372 decodes it server-side).
• All ledger disclosures are now resolved server-side: indexerdb-microservice#2372 resolves the Execute/Send disclosure blobs (global/CCV/token-pool/executor) from the EDS and injects the derived contexts, contract ids, fee token config, and token transfer into the choice argument. Clients pass no disclosedContracts — which is why the SDK disclosedContracts() surface added here is being dropped.
• The two example scripts were relocated out of BitGoJS (they are standalone client tooling, not SDK code) — preserved on the local working branch SCAAS-11590-ccip-wallet-scripts in ccip-starter-kit-canton (bitgo/ethers deps added there), adapted to the server-side disclosure resolution.

Companion changes: indexerdb-microservice#2372 + bitgo-microservices#63639 carry the IMS/wallet-platform side. This branch stays as a reference for the scripts' history.