(origin, sender, router, ISM)
. This means that for every contract making interchain calls, there is a corresponding account on the destination chain that executes those calls.
ICA is currently supported only on EVM chains.
InterchainAccountRouter
). We use CREATE2 to compute the deterministic OwnableMulticall contract address for you, which serves as a proxy for your cross-chain calls. You can explore this here.
Here’s how it works:
msg.value
for each call, batched together in an array.(uint32 origin, address owner, address remoteRouter, address remoteISM)
tuple a unique ICA address. The sender owns that ICA on the destination chain, and can direct it to make arbitrary function calls via the InterchainAccountRouter.callRemote()
endpoint.
For core chains supported by Hyperlane, you are able to use the defaults that are set by the owner of the router contract. See the #overrides section to see how to make calls to any chain.
InterchainAccountRouter
out of the box - ICA routers have already been
deployed to core chains. Please refer to
addresses.
Try using the callRemote
method to do a call via your wallet’s interchain
account.callRemote
, the function parameters must be encoded into an array of Call
structs.
Each Call
struct contains:
to
: The target contract address (converted to bytes32).value
: The ETH or native token amount to send with the call.data
: The function call data, which can be encoded using abi.encodeCall.Call.data
can be easily encoded with the abi.encodeCall
function.
callRemote
on the origin chain:
getRemoteInterchainAccount
function can be used to get the address of an ICA given the destination chain and owner address.
An example is included below of a contract precomputing its own Interchain Account address.
InterchainAccountRouter
.
These are useful for:
InterchainAccountRouter
.InterchainAccountRouter
callRemoteWithOverrides
function looks similar to the callRemote
function, but takes three additional arguments.
First, developers can override _router
, the address of the InterchainAccountRouter
on the remote chain. This allows developers to control an ICA on remote chains that have not been configured on the local InterchainAccountRouter
.
Second, developers can override _ism
, the address of the remote interchain security module (ISM) used to secure their ICA. This ISM will be used to verify the interchain messages passed between the local and remote InterchainAccountRouters
. This allows developers to use a custom security model that best suits their needs.
Third, developers can override _hookMetadata
, the StandardHookMetadata metadata passed to the message hooks for each ICA call (for example, overriding the gas limit for the IGP payment).