Integration Guide
Last updated
Last updated
This tutorial shows how to run the with your own executor. As an overview, our app does the following things:
User calls on the source chain Goerli Testnet, which triggers the sending of tokens along with a message through the Celer IM infrastructure
Executor polls Celer's SGN and submits SGN-signed messages to the MessageBus
contract on the destination chain BSC Testnet.
BatchTransfer
contract on BSC Testnet receives the message and distributes the fund to the receivers specified in the message
Following this tutorial, you will need to deploy BatchTransfer
contracts on Goerli and BSC Testnets, and an Executor node for this test dApp.
Solidity Knowledge
Wallet
Node.js 12 installed
Typescript installed
Experience with basic Unix commands
This tutorial uses to deploy and verify the contract.
Modify the config file .env
. Set up your account's private key at DEFAULT_PRIVATE_KEY
.
Deploy the contracts and remember to record the addresses of the deployed contracts as we will need them in the next step
You should now have the contract addresses on both networks.
Now run the hardhat verify
tasks. Note the last param is our contract's constructor param used when deploying the contract, which is the address of the message bus.
In this section, we will learn what the executor is and how it should be configured and deployed
The executor is a simple program: it polls SGN for available messages sent by the BatchTransfer
contract and calls MessageBus
on the destination chain which in turn calls our BatchTransfer's executeMessageWithTransfer
on the destination chain.
Note: "available messages" are messages that
have been verified by enough SGN validators
have their corresponding token transfer verified
In addition, the executor also doesn't submit the message until the transfer associated with the message is executed on-chain.
Now let's start deploying the executor for our app.
Let's create a home folder for the executor first, this is where the config files will live
Unzip it and move it to a directory on $PATH
. We will use /usr/local/bin
Make sure the binary runs
It won't actually run since we haven't setup any configs yet, but good to know it at least starts. If it doesn't, make sure you got the right distribution for your system arch.
Since the executor monitors on-chain events and keeps track of message execution, we'll need a database. In theory, the executor supports any databases that support any Postgresql dialect database, but it's only tested with CockroachDB for now
Start a single node instance in the background
Test connection
If you see this prompt then everything is right
I know that's a lot of steps ... but thankfully that's all for the database. We are almost done here, just a little more configs, then we are off!
The config is simple, you only need two config files and an ETH keystore file.
First, let's create the folders and files in the executor home
Now we have the files in place, let's take a look at each individual file and what they do.
Since the job of the executor is to submit messages on-chain, a signer keystore is required. Eventually, you may want to delegate the gas cost of the transactions the executor makes to your users, but that's outside of the scope of this tutorial. We will discuss this topic in later chapters.
This config file houses information about app contract, connectivity, and keystore location. A standard executor.toml
looks like this. Remember to fill in the contract addresses and the keystore passphrase.
Executor relies on multiple on-chain events to do its job. This config file is where we configure on-chain event monitoring behaviors. The only things we need to care about for now is the address of the contracts and RPC endpoint URLs
Sometimes executor start might fail because of failures to dial either SGN node or SGN gateway gRPC. It's probably because we are deploying something. Just wait a while and it'll most likely resolve.
That's it, the entire app stack is fully functional now. We've come a long way, and now is the moment of truth, will it work or not?
For testing, we are using test CELR on Goerli. Please add it to your wallet 0x5d3c0f4ca5ee99f8e8f59ff9a5fab04f6a7e007f
Now we are ready to call our MsgExampleBasic contract on Goerli to initiate the whole cross-chain batch transfer process.
Note: the first param payable amount is the fee for this cross-chain transaction, we are omitting this for now.
After calling the contract, it may take around 30 ~ 120 seconds or so for SGN to monitor, verify and sign the transfer and the message. The executor will automatically pick up the message. The logs should look like this
We are going to deploy on goerli and bsc testnet.
Woot, that's quite some work, if everything went right, you should be able to see your contracts on and . Now we are just one component short of making an inter-chain app. Let's look into how to deploy the executor in the next section.
Download the executor binary from , or use curl
You can visit their for more detailed instructions. Below is an example for running CockroachDB on macOS via Homebrew
Now with the configs and database out of the way, running the executor is as simple as a line of command (we'll discuss more reliable deployment methods in )
To make the BatchTransfer App more production-ready, there are some advanced functionalities that need to be added, which are covered in the .