[daedaluscoder]

Summary

• align SDK IBC support with the Carbon sunset policy in Switcheo/carbon#1239 / #1236: exact support for Axelar (axelar-dojo-1), Osmosis (osmosis-1), and Noble (noble-1), with every other counterparty deprecated
• preserve each canonical on-chain bridge.enabled value while exposing Carbon lifecycle separately through carbonLifecycleStatus and deriving isTransferAvailable
• resolve registry identity from exact chain_id matches or maintained supported-chain identity instead of deriving directory names from revisioned chain IDs
• prevent Carbon-deprecated or Cosmos-registry-killed chains from becoming transfer-available when metadata is missing, stale, or reports live
• remove deprecated chains from the transfer whitelist, channel overrides, and embedded live endpoint/fee metadata while retaining chain IDs and blockchain display mappings for historical consumers

Lifecycle contract

IBCModule.getChainInfoMap() retains bridge entries for historical/display consumers, but:

• Carbon-deprecated chain: carbonLifecycleStatus: "deprecated", isTransferAvailable: false
• Carbon-supported + registry killed: carbonLifecycleStatus: "supported", literal registryStatus: "killed", isTransferAvailable: false
• Carbon-supported + bridge disabled: literal bridge.enabled: false, isTransferAvailable: false
• only Carbon-supported + non-killed + bridge enabled is transfer-available

Deprecated/killed entries are returned without reusable RPC/REST, fee, feature, explorer, or currency metadata. Remote registry failures cannot override Carbon's lifecycle result.

Evmos regression

evmos_9001-2 is Carbon-deprecated before any per-chain lookup. The SDK therefore never requests the invalid .../evmos_9001/chain.json path, never revives embedded Evmos endpoints after a 404, and always reports the entry unavailable even if the on-chain bridge remains enabled or a remote response says live.

Tests

• yarn test --runInBand — 237/237 passed (includes lint, CJS/ESM type builds, entrypoint checks, packed-artifact tests, and 13 IBC lifecycle regressions)
• node scripts/audit-side-effects.cjs — passed; reviewed fingerprints updated
• packed this branch and installed it into Switcheo/switcheo-disco@69c286882; yarn check:typescript and VITE_DEPLOY_ENV=staging yarn build both passed

Downstream Demex adaptation

This PR deliberately does not rewrite/filter canonical TokenClient.bridges.ibc state. Demex currently has paths that gate only on bridge.enabled and then consume chainInfoMap for wallet/provider setup, fee estimation, and transfer execution. Before rollout, Demex should require chainInfoMap[bridge.chain_id_name]?.isTransferAvailable === true when:

• building active IBC chain/route selections
• registering Keplr/Leap chain metadata
• estimating IBC fees
• constructing or broadcasting IBC deposits/withdrawals

Historical balance and transaction displays can continue using the retained chain ID / blockchain identity mappings.

[daedaluscoder]

Code review: PASS\n\nReviewed exact head ce65f027a7735583a44df5474e7f2b5599d82f21 (tree 8baabedcd0034cffd81b057f998378b8a61b2f44, base-to-head binary diff SHA-256 3f779f60cb4fd7d3b6034a65d349c45e281bde95a713e26f22bf7bf04ac94e53).\n\nNo blocking correctness, lifecycle-safety, compatibility, security, or test findings remain. Verified exact supported-chain membership, deny-first deprecated/killed precedence, literal raw bridge state, canonical registry naming, fail-closed metadata behavior, retired transfer-data removal, prototype-key allowlist hardening, and v0.11.83 release-manifest alignment. Node 24 CI is green, including lint, generated-output checks, side-effect audit, full tests, build, package validation, and installed-package verification.