Build 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 {
}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.
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.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.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.
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