Chainlink Rebuilds Its Bridge Software to Let Banks Run Their Own Transfer Checks

Chainlink has shipped an updated version of its cross-chain messaging system that changes who is trusted to approve a transfer. Under CCIP 2.0, an asset issuer can run its own Cross-Chain Verifier, a separate attestation that must be present before a message executes on the destination chain. Issuers can operate that verifier themselves or contract it out to firms such as Infosys or Nethermind, and the release adds built-in controls for identity checks, anti-money-laundering screening, sanctions lists and per-transfer limits.

The design answers a specific failure mode. The largest bridge losses of the past two years have come from a destination contract accepting a message that the source chain never authorized, whether through a forged proof, a compromised validator set or a signature-verification gap. CoinDesk frames the release against the $292 million hack earlier this year that affected a rival bridge design. Requiring a second, issuer-controlled signature means a single compromised verification path is no longer sufficient to mint or release assets.

Separately, Chainlink is connecting banks to Swift's blockchain ledger through its Chainlink Runtime Environment, with institutions keeping the keys that authorize transactions while the runtime coordinates workflows across a bank's own tokenized-deposit ledger and Swift's. Seventeen banks across six continents are preparing live pilots on that ledger.

The trade-off is explicit. Adding a permissioned verifier raises the cost of an exploit and also gives named parties the ability to stop a transfer. For a tokenized deposit issued by a regulated bank, that is the point. For a permissionless asset, it moves the security model from cryptographic verification toward institutional approval, and the two are not the same guarantee.