batchTransfer
due to high slippage, not enough liquidity, etc. In These cases, executor automatically prepares a refund and executes it on the source chain. In order for this to work, the BatchTransfer contract on the source chain needs to implement executeMessageWithTransferRefund
, so let's add it:executeMessageWithTransfer
. If the execution of this function also fails, the message execution then enters a "failed" status, and the funds will be locked in the BatchTransfer contract.executeMessageWithTransfer
on the destination chain. Since the executeMessageWithTransfer
interface is payable, this usage is supported.executeMessageWithTransfer
.executeMessageWithTransfer
to cover the fee introduced by chaining the additional message.sendMessage()
call is incurring. Let's take a look at how the message fee is calculated in the MessageBus contract: abi.encode
to encode your message, the message length is likely fixed. If you happen to have variable length fields in your message, you should add a safe margin to the add_payable_value_for_execution
to reduce the chance of having message execution reverted.