Cross-Chain Contract Calls

Cross-chain contract calls let a smart contract on one blockchain trigger a function in a smart contract on a different blockchain. Instead of only moving tokens between networks, a cross-chain call carries an instruction, such as "deposit these funds into a lending pool" or "record this governance vote", and has it executed on the destination chain. The capability is often called general message passing, and it builds on cross-chain communication protocols.

Ordinary contract calls happen within one chain and complete in a single transaction: if any step fails, the whole transaction is reversed. Cross-chain calls cannot work this way, because two chains do not share a transaction. They are asynchronous, completing across separate transactions on each network, often minutes apart. That makes them powerful but harder to design safely. They are a key building block for multi-chain applications and for chain abstraction.

Within one blockchain, calling another contract is like asking a colleague at the next desk to do something: you ask, they do it straight away, and if anything goes wrong the whole task is cancelled as if it never happened. A cross-chain call is like posting a letter to an office in another city asking them to do something.

The letter takes time to arrive. Meanwhile, your own office carries on. The other office may do what you asked, may not be able to, or may reply later. You need a plan for each outcome, because you cannot simply undo everything if the far office runs into trouble.

Most protocols follow a similar pattern:

1. Request. The source contract calls the messaging protocol's contract, passing the destination chain, the target contract address and the encoded function call, and usually prepays fees.
2. Transport. The protocol's validators, relayers or proof system confirm the request on the source chain and deliver it to the destination chain.
3. Execution. A receiving contract on the destination chain verifies the message, checks that it comes from an approved source and calls the target function.
4. Optional callback. The destination contract can send a message back reporting success, failure or results, which the source contract handles in a later transaction.

Fees for destination-chain execution are usually estimated and paid upfront in the source chain's token, with the protocol converting them; if the estimate is too low, delivery can stall until more is paid.

Several systems offer cross-chain calls. The Inter-Blockchain Communication protocol (IBC), used among Cosmos networks, includes interchain accounts that let one chain control an account on another. Polkadot's cross-consensus messaging format serves chains secured by its relay chain. General messaging services, including LayerZero, Wormhole, Axelar, Hyperlane and Chainlink's Cross-Chain Interoperability Protocol, support calls between many networks, including chains built on the Ethereum Virtual Machine and others. Rollups also use native messaging to call contracts on Ethereum and back.

Cross-chain calls enable a range of applications:

• Cross-chain swaps and deposits. A user on one chain can buy an asset on another or deposit into a pool there in one step.
• Multi-chain governance. A DAO can vote on one chain and update contracts deployed on several others.
• Lending and collateral. Protocols can let collateral on one chain back a loan on another.
• Unified token supply. Token issuers can keep one supply across chains by burning on one network and minting on another, avoiding wrapped tokens.
• Games and NFTs. Items or actions on one chain can trigger effects on another.

Because a cross-chain call cannot be rolled back atomically, applications must handle partial failure, for example funds locked on the source chain while the destination step reverts. Developers must check that incoming messages come from the correct contract on the correct chain, guard against replayed messages and consider that state on the destination chain may change between the request and its execution. The security of every call also depends on the messaging protocol's verification model; if its validators are compromised, an attacker can forge calls and drain contracts, as several bridge hacks have shown. Applications therefore often limit which functions can be called remotely, add rate limits and use more than one verification system for high-value actions. The general property of systems working together is described under blockchain interoperability, and the wider category under cross-chain protocol.