ISMP modules are applications that want to leverage ISMP as their transport layer for cross-chain messaging. These modules could either be pallets, EVM contracts, or rust ink! contracts.
pallet-ismp provides a dispatcher API to these modules allowing them to send outgoing requests & responses.
🚀 Sending Requests & Responses
IsmpDispatcher interface is used for dispatching requests & responses. It can be used to dispatch both POST & GET requests.
📞 Accepting Requests & Responses
In order to receive & process requests from other blockchains, it’s necessary to implement the
IsmpModule interface. This can look very different depending on if your module is a pallet, an evm contract or an ink! contract.
IsmpModule is simply a list of callbacks that should be implemented by modules that want to send & receive ismp requests & responses:
on_accept: This callback is called by the ismp router after a POST request has been successfully verified. This verification consists of both consensus & state proof verification. By design, the method does not return a response. This is to allow modules process requests asynchronously, and dispatch a response at a later block if necessary using the
on_response: This callback is called by the ismp router after a response has been successfully verified. This verification consists of both consensus & state proof verification. The response object in this case maybe a POST response, or a GET response.
on_timeout: This callback is called by the ismp router after a timeout message has been successfully verified. This verification consists of both consensus & state proof non-membership verification. This non-membership verification confirms that the destination state machine has no knowledge of this request past the specified timeout in the request. Allowing modules to handle the consequences for timeouts like for instance revert actions that had been taken, prior to dispatching a request.
⚠️ Important Note
When implementing the
on_accept module callback in either contracts or pallets, it is recommended that you avoid making any storage changes until execution reaches a stage where no errors can occur. Receipts are not stored for requests that fail to execute correctly. This is done so that inexecutable requests can be timed out on the source chain.
It is the responsibility of your module to revert any storage changes made during a failed callback execution.palletsismp-evmismp-contracts