batchTransferat source chain, which internally calls app framework's
sendMessageWithTransferto send message and tokens.
executeMessageWithTransferinterface to handle the batch transfer message, and distribute tokens to receiver accounts according to the message content. It also internally calls app framework's
sendMessageto send a receipt to the source app.
executeMessageinterface to handle the receipt message.
transferWithSwapNativeare called by a user to initiate the entire process. These functions takes in a
SwapInfostruct that specifies the behavior or "route" of the execution, and execute the process in the following fashion:
SwapRequestas a "message", which indicates the swap behavior on chain2
sendMessageWithTransferis then called internally to send the message along with the tokenB through the bridge to chain2
executeMessageWithTransferis automatically called when the bridge determines that the execution conditions are met.
SwapRequeststruct, then executes the swap using the tokenB received to gain tokenC. (Note: when
executeMessageWithTransferis called, it is guaranteed that tokenB already arrives at the TransferSwap contract address on chain2. You can check out this part of verification logic in MessageBusReceiver.sol's
executeMessageWithTransferof TransferSwap contract on chain2 reverts, or if the
false, then MessageBus would call
executeMessageWithTransferFallback. This is the place where you implement logic to decide what to do with the received tokenB.
sendMessageWithTransferis called with a nonce that is unique for every transaction at a per-contract per-chain level, meaning your application should always call
transferWithSwapwith a different nonce every time. A duplicated nonce can result in duplicated transferIds. Checkout how a transferId is computed here.
executeMessageWithTransferRefundwill be called by your executor automatically on the source chain when it finds out that there is any available refund for your contract in SGN. Like in
executeMessageWithTransfer, you can expect that the tokens are guaranteed to arrive at the contract before the function is called. The
_messageyou receive in this function is exactly the same as it was sent through