CCIP-9735: Removing LBTC validation in set candidate changeset

[b-gopalswami]

This pull request simplifies the validation logic for LBTC handler configuration in the cs_ccip_home.go file. The main change is the removal of the previously implemented LBTC config validation, which was deemed unnecessary and potentially misleading. Now, the code relies on user-provided addresses and clear plugin failure in case of misconfiguration, rather than preemptive validation.

Validation logic changes:

• Removed the validateLBTCConfig function, eliminating checks for LBTC source pool addresses against the on-chain state and EVM client. This avoids giving users a false sense of security, since there is no standard Lombard token or pool stored in state.
• Updated the validateExecOffchainConfig function to skip LBTC-specific validation and return nil directly, with explanatory comments about the rationale.

Dependency cleanup:

• Removed the unused import of token_pool from the file, as it is no longer needed after removing LBTC validation.

Jira: https://smartcontract-it.atlassian.net/browse/CCIP-9735

[github-actions]

👋 b-gopalswami, thanks for creating this pull request!

To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team.

Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks!

[github-actions]

✅ No conflicts with other open PRs targeting develop

[Copilot]

Pull request overview

Risk Rating: MEDIUM (changes validation behavior in deployment changeset config paths)

This PR removes LBTC-specific pre-validation from the CCIP home changeset, aiming to avoid misleading “validation” against non-canonical on-chain state and to rely on plugin failure for misconfiguration detection instead.

Changes:

• Removed the LBTC handler config validation (validateLBTCConfig) and its dependency on token_pool.
• Updated validateExecOffchainConfig to skip LBTC-specific validation with an explanatory comment block.

[trunk-io]

     

View Full Report ↗︎ ⋅ Docs

[cl-sonarqube-production]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

[winder]

This doesn't make sense. The validation you're disabling would allow misconfigurations to be deployed on production.

The source pool address is defined outside of the durable pipeline:
https://github.com/smartcontractkit/chainlink-deployments/blob/a02e2006d0372493794bca721aa53847f875a1e2/domains/ccip/shared/configs/mainnet/config.go#L751

[b-gopalswami]

This doesn't make sense. The validation you're disabling would allow misconfigurations to be deployed on production.

The source pool address is defined outside of the durable pipeline: https://github.com/smartcontractkit/chainlink-deployments/blob/a02e2006d0372493794bca721aa53847f875a1e2/domains/ccip/shared/configs/mainnet/config.go#L751

@winder The existing validation doesn't really adds any value. It just gives us false hope that there is a validation. It just loads the given address as token pool and trying to call GetToken method. This validation will pass for any pool and there is no specific validation that this is valid Lombard pool.
https://github.com/smartcontractkit/chainlink/pull/21583/changes#diff-3ab7b3159b26540efd60b40eba7d0ed3fdb5667d285694c850c11b17185d0962L251-L268

We are not storing their pool or token address in our AddressBook or Datastore either. Not just one token like USDC, they have more than one token at this point and may have more in the future as well.

I have a ticket to expand LBTC for Solana and the existing validation doesn't supports non-evm. I was trying to enable a support for Solana but the existing validation itself doesn't makes much sense to me.