Contract Framework
Last updated
Last updated
We provide a , which implements the common process of Celer IM. By inheriting the app framework , the cross-chain smart contract developers only need to focus on the app-specific logic.
To send cross-chain messages, the dApp contract needs to interact with the Celer IM on the src chain.
The dApp contract should use the of the inherited MessageSenderApp contract to send a cross-chain message.
The message will be typed as MsgType.MessageOnly
, and will be identified in Celer SGN through its messageId, which is computed as a hash of <msgType, sender, receiver, srcChainId, srcTxHash, dstChainId, message>
. The caller needs to make sure of the uniqueness of the messageId. If multiple messages with the same Id are sent, only one of them will succeed at the destination chain.
The dApp contract should use the of the inherited MessageSenderApp contract to send messages with associated cross-chain token transfers.
The message will be typed as MsgType.MessageWithTransfer
, and will be identified in Celer SGN through the returned transferId
Do not forget to use the onlyMessageBus
modifier, as message execution functions should only be called by the MessageBus
contract.
If the function above got reverted for any reason. The dApp contract can optionally implement a fallback function to decide what to do with the received tokens.
A cross-chain token transfer could fail due to bad slippage or other reasons. In this case, the Celer SGN will refund the token to the dApp contract on the source chain, which should implement a message execution function to handle the possible refund.
The could be Liquidity, PegDeposit, PegBurn, PegV2Deposit, PegV2Burn, PegV2BurnFrom
.
For both function calls above, message fees are charged in the native gas token. Here is how to .
To receive cross-chain messages, the dApp contract needs to implement (some of) the message execution
functions defined in the inherited .
These functions return ExecutionStatus
, which could be Success
, Fail
, or Retry
. The which calls the dApp's message execution functions will ensure that each message will be executed exactly once if the function returns Success
or Fail
or is reverted. If the function returns Retry
, the message can be executed again later.
The dApp contract should implement the to receive a message without associated token transfer.
The dApp contract should implement the to receive a message with an associated cross-chain token transfer.
The will guarantee that the correct amount of tokens have already been received by the dApp contract before calling the dApp's message execution functions.