OmniApp
1.To determine the contract version and project name.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "@openzeppelin/contracts/access/Ownable.sol";
contract OApp is Ownable {
}2.Importing the "@mapprotocol/mos" module and importing the "IMOSV3.sol" interface would look like this:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "@openzeppelin/contracts/access/Ownable.sol";
import "@mapprotocol/mos/contracts/interface/IMOSV3.sol";
contract OApp is Ownable {
}For contract details, please look this
3.Sure, let's add some code to ensure that our MOS can function correctly.
4.In the above, when deploying, we need to add the correct MOS contract address. Now, let's complete the DAPP required method. Our requirement is: to send a number on the source chain, and after execution on the target chain, the result will be accumulated with this number.
5. Now let's try how to complete a cross-chain transfer through MOSV3
5.1 First, let's take a look at the standard interface of IMOSV3 as shown below.
5.2 Through the standard interface, we can observe that transferOut requires three parameters. toChain represents the target chain's chainId, messageData is the encoded form of the struct MessageData, and feeToken is the token you wish to use for covering the execution fee on the target chain during cross-chain operations. All that's needed is for us to complete a pre-payment on the source chain.
In our demonstration, we are exclusively using native tokens of the current chain. Therefore, for feeToken, we consistently input address(0). Now, let's explore the explanation below to determine the payment required for each cross-chain operation.
Having read the comments for the getMessageFee interface in IMOSV3, we understand that the fee for each payment is determined by tochain and gasLimit. Given that the execution complexity on the target chain is not extensive, an estimated gasLimit of 500,000 is more than sufficient. Let's proceed to create a straightforward method for accurately obtaining _getTransferOutFee.
5.3 Continuing to review the standard interface of IMOSV3, we discern that there are two cross-chain modes, selected based on the MessageType enumeration. When opting for transferOut, it is necessary to accurately encode the struct MessageData. Let's begin by examining the construction of MessageData for cross-chain using the CALLDATA mode.
5.3.1 Preparations are complete, and now we proceed to finalize the cross-chain message method in the CALLDATA mode.
5.3.2 When the source chain initiates a cross-chain request through the sendCalldataCrossChain method, the crossChainAdd on the target chain will be invoked by the MOS contract to fulfill the cross-chain accumulation requirements. Upon closer observation during the construction of the MessageData, we utilize the encodeWithSelector of the crossChainAdd method. This constitutes the entire process of initiating a cross-chain message from the source chain to executing it on the target chain under the CALLDATA mode.
5.4 Above, we've completed cross-chain functionality in the CALLDATA mode. Now, let's proceed to construct the MessageData for the MESSAGE mode.
MessageData for the MESSAGE mode.Note: The cross-chain identifier is a bytes32, resembling something likekeccak256("Message(bytes32,bytes)"), and its content is arbitrary.
5.4.1 Similarly, we finalize the cross-chain message method in the MESSAGE mode.
5.4.2 Take note, now we move on to accomplish the execution of cross-chain using the MESSAGE mode on the target chain. Employing the MESSAGE mode for cross-chain necessitates the implementation of a specific method within the target contract. For more details, please refer to IMapoExecutor
5.4.3 When you utilize the MESSAGE mode for cross-chain transactions from the source chain, while constructing the MessageData, only encode the data required by the target chain. Consequently, on the target chain, the mapoExecute method will be invoked by MOS in a predetermined manner. In this method, you can incorporate your unique logic and conditions. The above explanation provides a basic demonstration of the complete process of cross-chain using the MESSAGE mode.
6.In step 5, we've individually completed two distinct forms of cross-chain methods. Now, let's attempt to use a single method to achieve selectable cross-chain modes. Previously, the cross-chain transaction fees had to be provided alongside the cross-chain process. This time, we will explore an alternative approach.
Note: When using this method for cross-chain transactions, you only need to provide a small fee to the contract in advance. There's no need to include transaction fees during the actual cross-chain process.
7.It seems that we have completed a cross-chain DAPP contract, but don't rush, there is one more crucial step. MOS has a clever permission verification process, which requires each cross-chain contract to autonomously grant permissions to the source chain addresses. Let's complete this step.
8.We have completed the development of a cross-chain DAPP contract. Now, let's take a look at the complete contract code.
8.1Let's take a look at the contract on the source chain responsible for sending cross-chain requests.
8.2 Below is the contract on our target chain responsible for receiving and executing cross-chain messages.
9.Great! Above, we have completed the implementation of a simple cross-chain DAPP contract for accumulation. Let's now go through the complete process of interacting with the contract.
Last updated
Was this helpful?