Skip to Content
ValidatorsTestnetValidator Setup

Testnet Validator Setup

This is the one and only official guide for setting up your Chainflip Validator. This guide is officially maintained by the Chainflip team. For general information about the Chainflip protocol, we strongly recommend checking out the Concepts. We run both a Testnet and Mainnet, this guide helps you through setting up a validator on Testnet. For Mainnet please refer to this guide instead.

Tips for Inexperienced Users

If you’ve never used Linux before, you will need some help understanding the basics of how to set up your machine and use it. If you feel proficient with Linux, feel free to skip this article. For those that don’t, let’s clear some stuff up right away:

  • Do not use your home computer (or laptop) to run a Validator unless you REALLY know what you’re doing.
  • To run a Validator, you will need to rent a server (either a Dedicated Server or a Virtual Private Server (VPS). There are many places to do this. You should be willing to spend at least $50 USD to run a server for a month.
  • To access the server from your home computer, you will need to use an SSH client. This will allow you to access the server’s command line. Most of the validator setup you do will be through a terminal. It’s not as hard as it sounds but there is a learning curve, and if you can’t use Google you will struggle.
  • If all of this sounds too much to you, there’s only one way to find out if you can do it: give it a go! We would never recommend that inexperienced users risk their funds by running a mainnet node themselves, but seeing as it’s a testnet, here’s your chance to learn more about how the internet is run.

Some Handy Tips and Resources

  • There are many great hosting providers out there. In no particular order, there is Hetzner, OVH, Digital Ocean, AWS, Microsoft Azure, Kamatera, and many more. If you really have no idea what you’re doing, you can follow this guide for creating and connecting to DigitalOcean “droplets”  which is just a fancy name DigitalOcean gives its VPS offering. However, be warned that DigitalOcean is more expensive than other offerings and you will need to spend upwards of $80 per month for a good server. Renting servers is pretty easy so our recommendation would be to just ask in the 🛠︱technical-discussion channel in Discord for help choosing a provider.
  • A great guide for connecting to your server from any desktop computer using SSH . If you don’t know how to do this you aren’t going to make it.
  • You should know how to navigate folders using the command line. You will need to use a few commands to set up a validator, which can be googled individually as you need them. The way how changing directories and moving files work can be super confusing, so if you are stuck, try Googling what you need to do, even if it’s as simple as editing a file or navigating to a directory. You’ll get the hang of it. Here’s a good list of some basic commands everyone should know , many of which you’ll need. HOT TIP: You can always hit the TAB key to autocomplete a path. For example, if there’s a folder called chainflip, and you want to change to it, you can type cd c and then hit tab. Linux will autocomplete the folder or filename for you, leaving you with cd chainflip ready to go (there are some caveats, but hitting the tab key never hurt anyone )!
  • Control + C is normally how copy-paste works in windows. That is not the case here. If you use Ctrl + C in a terminal in windows, you will force exit the program you are using. To copy content from a Terminal, highlight the text you want and right-click. Similarly, if you are trying to paste content, right-click on a blank section of the terminal. Either it will just work or a context menu will appear, allowing you to “Copy” and “Paste.” This will differ depending on your operating system and SSH client. If you’re stuck, ask in Discord.
  • We’ve tried to write the instructions so that people with minimal experience will be able to figure it out and copy-paste their way through most of it. Hopefully if you’ve figured out how to connect to the server’s root account through SSH, you shouldn’t have any showstopping problems with these docs. If you’re stuck and you think there’s some key information missing from these docs, please post it in the 🙋︱help-and-support channel in Discord.
  • Don’t forget to have fun!

1. Prerequisites

This section describes what you are going to need to successfully set up a Chainflip validator node.

Ethereum Accounts

We highly advise against using a digital wallet that has any real funds in this setup. For the purposes of joining Chainflip’s or any other testnet, it is a best-practice to create new wallets.

You’ll need two Ethereum Accounts:

  1. The first one (we will refer to it as (your Wallet/Account) will be used for receiving tFLIP and Interacting with the Auctions App to add and redeem funds.
  2. The second one (we will refer to it as the (Validator Wallet/Account) will be used by the validator to send transactions to the Sepolia Ethereum blockchain (this will be automatically generated as part of Generating Keys).

sETH (Sepolia Ether)

Each Validator is also responsible for submitting transactions to the Ethereum blockchain. Since Ethereum is account-based, you are required to supply your own sETH in order to pay the up-front cost for the transactions.

Chainflip recommends that you have at least 0.1 sETH in your Validators’ account at all times. You must ensure that this sETH is loaded onto the Validators’ wallet before you try to add funds.
You’ll also need to have sETH in your wallet to cover the gas fees for Adding and Redeeming Funds operations.

Getting test assets
sETH is Sepolia Ether and can be obtained from a Sepolia faucet. Faucets are not always reliable, so if you have an issue obtaining sETH, please message the Discord 🙋︱help-and-support channel.

Faucets:

If Sepolia Ethereum Testnet is not showing on your Wallet, make sure to enable Testnets in your wallet settings.

You will need a way for your validator to monitor the Sepolia Ethereum Blockchain. The Chainflip Engine software allows you to use any endpoint you specify in its config file. You can either run a geth client  (make sure to set this up on the Sepolia testnet!), or you can rely on a third-party remote client provider such as Alchemy , Infura , or Rivet .

Please note, gas cost reimbursements are currently not implemented for Validators. Validators will need to ensure their wallets are topped up with sETH or they may run out and be unable to broadcast on behalf of the network. This is a limitation of the Vault Contract design, however, automatic reimbursement is on the future feature list.

System Requirements

OS: Ubuntu 22.04 | Our binaries are not compiled on any other OS CPU: 4GHz+ amd64/x86_64 CPU Architecture | We only support amd64/x86_64 CPU Architecture RAM: 8GB+ SSD: 300GB+ NVMe (this may increase over time) Bandwidth: Minimum 400MBps, Recommended 1GBps connection, 100 GB bandwidth combined up/down per month

We will be deprecating Ubuntu 20.04 binaries after the v1.4 release. This means v.1.4 onwards will have the binaries compiled on Ubuntu 22.04 only.

This machine must be available 24/7 and thus it is recommended that you only try this on machines with a stable and reliable internet connection, such as a VPS or Dedicated Server. If you would like some help picking a server to rent, you can come to the Chainflip Community Discord and ask for help in the 🛠︱technical-discussion channel.

Networking

Firewall

You should ensure that all connections on ports 30333 (TCP) and 8078 (TCP) are not blocked! Moreover make sure your firewall allows NTP outbound traffic on port 123 (UDP)

Some VPS providers enable an all-port firewall by default, but if this is not the case your node will not be able to participate in Keygen / Signing ceremonies and as a result will never become active.

Static IP

To ensure uninterrupted operation of your node, you should setup your server to have a static public IP address. If your server gets a new IP address, you will need to update your node’s configuration and restart it.

NTP Daemon

In some cases, the system time will drift causing the authoring or importing of blocks to fail. To prevent this, you should install and enable an NTP daemon on your server. This will ensure that your system time is always correct. Feel free to use your NTP daemon of choice, but we recommend ntp. You can install it and enable it with the following commands:

sudo apt install ntp sudo systemctl start ntp sudo systemctl status ntp sudo systemctl enable ntp

Make sure your firewall allows NTP outbound traffic (Port 123 UDP).

2. Creating a new Linux User

Using the root user to run a Validator works. However, it is a good security practice to create a separate user with limited access to run the Chainflip binaries.

You can call the new user whatever you like. In the following commands we will call it flip.

Create the user

sudo useradd -s /bin/bash -d /home/flip/ -m -G sudo flip

This command does the following:

  • Creates a user called flip
  • Creates a home directory for the new user under/home/flip
  • Sets the default shell for the new user to /bin/bash
  • Adds the flip user to the sudo group which gives the user the required access and permissions to install and configure the required software.

Add a Password

It is recommended to add a password to your newly created user. You can do that by running:

sudo passwd flip

You’ll then be prompted to enter a password then re-enter it for validation.

Congratulations, your new user is now protected with a password 🔐

Make sure to memorize this password as you’ll need it in the rest of the documentation whenever you execute a command with sudo

Setup SSH Access

To be able to login over ssh using the new user we will need to set it up by running the following commands:

mkdir /home/flip/.ssh sudo cp /root/.ssh/authorized_keys /home/flip/.ssh/authorized_keys sudo chown -R flip:flip /home/flip/.ssh/ sudo chmod 0700 /home/flip/.ssh/

The commands above do the following:

  • mkdir /home/flip/.ssh: creates a new directory called .ssh that holds the SSH config for flip user.
  • sudo cp /root/.ssh/authorized_keys /home/flip/.ssh/authorized_keys: copies the public keys whose private keys are allowed to access the machine from the root to flip user.
  • sudo chown -R flip:flip /home/flip/.ssh/: changes the ownership of the directory to flip user.
  • sudo chmod 0700 /home/flip/.ssh/: changes the permissions of the .ssh directory.

Next time you want to SSH into your server using the user you created, you can run:

ssh flip@<YOUR_SERVER_PUBLIC_IP>

But for now you don’t need to logout in order to switch users, you can do that simply by running:

su - flip

3. Getting the Validator Software

This guide describes how to download and run Chainflip’s validator software.

Download Binaries via APT Repo

Use the following commands to add Chainflip’s APT Repo to your node then use apt install to get the binaries:

Adding Chainflip’s apt Repo

We distribute our binaries as debian packages through our apt repository. To install the packages, you need to add our repo to your apt sources list.

Use the following commands to add Chainflip’s Testnet apt repo to your node:

  1. Download Chainflip Testnet GPG key from the Ubuntu Key Server:
gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys BDBC3CF58F623694CD9E3F5CFB3E88547C6B47C6
  1. Verify the key’s authenticity:
gpg --export BDBC3CF58F623694CD9E3F5CFB3E88547C6B47C6 | gpg --show-keys

Important: Make sure you see the following output from the terminal:

pub rsa3072/0xFB3E88547C6B47C6 2022-11-08 [SC] Key fingerprint = BDBC 3CF5 8F62 3694 CD9E 3F5C FB3E 8854 7C6B 47C6 uid Chainflip Labs GmbH <dev@chainflip.io> sub rsa3072/0x48249A1599E31935 2022-11-08 [E]
  1. Add Chainflip’s Testnet Repo to apt sources list:
gpg --export BDBC3CF58F623694CD9E3F5CFB3E88547C6B47C6 | sudo tee /etc/apt/trusted.gpg.d/chainflip-perseverance.gpg echo "deb [arch=amd64 signed-by=/etc/apt/trusted.gpg.d/chainflip-perseverance.gpg] https://repo.chainflip.io/perseverance/jammy jammy main" | sudo tee /etc/apt/sources.list.d/chainflip.list

Installing The Packages

To install, run the following commands:

sudo apt update sudo apt install -y chainflip-cli chainflip-node chainflip-engine

Disable Automatic Updates

Automatic updates are generally a good idea for keeping your system secure and up to date. However, for a Chainflip binaries, it is recommended to disable automatic updates to avoid interrupting operations when an update has breaking changes that need coordination with the rest of the network.

sudo apt-mark hold chainflip-cli chainflip-node chainflip-engine

Downloading Latest Chaindata Snapshot

First, download the latest chaindata snapshot and unpack it to the correct location.

mkdir -p /etc/chainflip/chaindata/chains/Chainflip-Perseverance/ wget https://snapshots.chainflip.io/perseverance/cf_chaindata_pruned_paritydb.tar.{gz.sha512.asc,gz.sha512,gz} # Verify the snapshot (Optional but recommended) gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 52535A03E3E0D0F29920EF94927F07FF64652243 gpg --verify cf_chaindata_pruned_paritydb.tar.gz.sha512.asc cf_chaindata_pruned_paritydb.tar.gz.sha512 sha512sum -c cf_chaindata_pruned_paritydb.tar.gz.sha512 tar -xzf ./cf_chaindata_pruned_paritydb.tar.gz -C /etc/chainflip/chaindata/chains/Chainflip-Perseverance/ rm -f ./cf_chaindata_pruned_paritydb.tar.{gz.sha512.asc,gz.sha512,gz}

After that, create a systemd override file for the chainflip-node service to use the correct parameters in order for the snapshot to be used.

sudo mkdir -p /etc/systemd/system/chainflip-node.service.d && \ sudo tee /etc/systemd/system/chainflip-node.service.d/override.conf > /dev/null <<EOF [Service] ExecStart= ExecStart=/usr/bin/chainflip-node \\ --chain /etc/chainflip/perseverance.chainspec.json \\ --base-path /etc/chainflip/chaindata \\ --node-key-file /etc/chainflip/keys/node_key_file \\ --validator \\ --database=paritydb \\ --sync=full \\ --blocks-pruning=300 \\ --pruning=300 EOF sudo systemctl daemon-reload

Snapshots are updated every 6 hours starting at 00:00 UTC. The snapshot holds the state and blocks of the most recent 300 blocks. The size of the snapshot is approximately 15GB. You can override the snapshot to use a different number of blocks by changing the --blocks-pruning and --pruning parameters in the systemd override file.

4. Generating Validator Keys

Validator nodes take actions on behalf of the Chainflip network, and all of these actions are authorised using cryptographic keys. Specifically, to run a validator node, you will need two private/public key pairs: an Ethereum key pair for interacting with Ethereum, and a Chainflip-native key pair for interacting with the State Chain.

Validator Keys

Generate and save the required keys using the following chainflip-cli command:

chainflip-cli generate-keys --path /etc/chainflip/keys

This should give you an output similar to the following:

Generated fresh Validator keys for your Chainflip Node! 🔑 Node Public Key: 0x5fc8ea5dd16e0bbc273eedfe5406d548cdbcdaf66fe86a2643bace5045fe2edf 👤 Node Peer ID: 12D3KooWGGGbDdkegvsc1m5vkNppHtXZJqSMNQRH7AKE7cxRuuSe 🔑 Ethereum Public Key: 0x033b48e368ae9069413d443c7a52b1e340c6aa0a8a76aac507d62b5ede51dfa368 👤 Ethereum Address: 0x6b98c154357297d0459ede9e98e586a60bee55c3 🔑 Validator Public Key: 0x685b0a76f54c25e2bf03aa8f69450eb863f2ea23b16e93a2317282485e86a723 👤 Validator Account ID: cFLEJrTKtoHDWbRb1Yc8fqhNrEd2u1WPjUemVXjZQ1THxb5p6 🌱 Seed Phrase: slender pilot fiber auction junk sting ozone push shop reduce defense stamp ❗️❗️ ❗️ THIS SEED PHRASE ALLOWS YOU TO RECOVER YOUR CHAINFLIP ACCOUNT KEYS AND ETHEREUM KEYS. ❗️ HOWEVER, THIS SEED PHRASE SHOULD ONLY BE USED IN CONJUNCTION WITH THIS UTILITY. NOTABLY, ❗️ IT CANNOT BE USED TO IMPORT YOUR ETHEREUM ADDRESS INTO METAMASK OR ANY OTHER WALLET IMPLEMENTATION. ❗️ THIS IS BY DESIGN: THIS ETHEREUM KEY SHOULD BE USED EXCLUSIVELY BY YOUR CHAINFLIP NODE. ❗️❗️ 💾 Saved all secret keys to '/etc/chainflip/keys'.
The keys above are just for demonstration purposes. DO NOT send any funds to these addresses.

Make sure to back up your Seed Phrase and make a note of the public keys and account ID. You will need the Seed Phrase if you ever need to restore your node or recover your funds if you lose access to the node. DO NOT LOSE THIS.

We recommend generating keys on the validator machine then using GPG encryption to securely transfer the ciphertext to a backup location. This is to eliminate the risk of the keys being intercepted in transit or being cached in the clipboard in the case of copying them from the terminal.

If the above command returned any errors, please ensure that the provided —path is accessible and that there are no keys already stored there! For security reasons, the files will not be overwritten automatically, so if you want to replace the stored keys, please make sure to move the old ones first, and back them up somewhere.

Take special note of the Validator Account ID beginning with cF. This is the ID that you will need to add funds and track your node.

NEVER REVEAL YOUR PRIVATE KEYS TO ANYONE.

Setting Up Your Validator’s Ethereum Account

You must ensure that the public Ethereum address generated above has at least 0.1 sETH. Make sure you send 0.1 sETH to this account’s address before trying to add funds to your validator node. This requirement is subject to change based on Sepolia Ethereum transaction fees but for now should be sufficient.

Please also note that the Ethereum key is for the exclusive use of the Validator node. Do not re-use this key elsewhere.

Update Secret File Permissions

The following commands will ensure that only the current user can read the files, and that the private keys are not available in your shell history:

sudo chmod 600 /etc/chainflip/keys/ethereum_key_file sudo chmod 600 /etc/chainflip/keys/signing_key_file sudo chmod 600 /etc/chainflip/keys/node_key_file history -c

Final Checks

The private keys generated above should have been stored at the path provided to the generate-keys command. As a sanity check, make sure they are where you expect, and have the correct permissions.

Run the following command:

ls -la /etc/chainflip/keys

This should show that there are three freshly created files:

drwxr-xr-x 2 root root 4096 Nov 14 13:28 . drwxr-xr-x 5 root root 4096 Nov 14 13:38 .. -rw------- 1 root root 64 Nov 14 13:28 ethereum_key_file -rw------- 1 root root 64 Nov 14 13:28 node_key_file -rw------- 1 root root 64 Nov 14 13:28 signing_key_file

Recovering Your Keys

In case you lose access to your keys, you can recover the private keys using the seed phrase. Using the example phrase generated above:

Please note that the Node Key cannot be recovered, a new one will be generated. This will result in a new peer id for your node.

chainflip-cli generate-keys \ --path /etc/chainflip/keys \ --seed-phrase 'slender pilot fiber auction junk sting ozone push shop reduce defense stamp'

The output should be the same as above (except the Node Key), and the keys should be written to the provided path, as above.

5. Engine Settings

We need to create the engine config file.

sudo mkdir -p /etc/chainflip/config sudo nano /etc/chainflip/config/Settings.toml

Editing the Config

Copy the following to your nano editor. You also need to replace IP_ADDRESS_OF_YOUR_NODE with the public IP Address of your server. To get the public IP of your node you can run this command: curl -w "\n" ifconfig.me.

Also you’ll need to provide the eth.rpc.ws_endpoint, eth.rpc.http_endpoint, arb.rpc.ws_endpoint, and arb.rpc.http_endpoint for whichever Ethereum client and Arbitrum client you’ve selected. It will look different depending on which client you select:

Ethereum

  • Rivet - wss://SOME_LONG_SECRET_INFORMATION.sepolia.ws.rivet.cloud
  • Infura - wss://sepolia.infura.io/ws/v3/SOME_LONG_SECRET_INFORMATION
  • Alchemy - wss://eth-sepolia.g.alchemy.com/v2/SOME_LONG_SECRET_INFORMATION

Arbitrum

  • Infura - wss://arbitrum-sepolia.infura.io/ws/v3/SOME_LONG_SECRET_INFORMATION
  • Alchemy - wss://arb-mainnet.g.alchemy.com/v2/SOME_LONG_SECRET_INFORMATION

Make sure that both endpoints (HTTP and WebSockets) are accessible for the Ethereum, Arbitrum and Polkadot nodes. Bitcoin only has HTTP. Otherwise your engine will fail to start.

Note that you can optionally provide a backup RPC endpoint for each chain. If the primary endpoint fails, the engine will attempt to connect to the backup endpoint. The engine will only attempt to use the backup endpoint if the primary endpoint fails. You should set your primary endpoint to the cheapest (and most reliable) endpoint you have i.e. a local geth node to lower your operating costs.

[node_p2p] node_key_file = "/etc/chainflip/keys/node_key_file" ip_address = "PUBLIC_IP_ADDRESS_OF_YOUR_NODE" port = "8078" [state_chain] ws_endpoint = "ws://127.0.0.1:9944" signing_key_file = "/etc/chainflip/keys/signing_key_file" [eth] # Ethereum private key file path. This file should contain a hex-encoded private key. private_key_file = "/etc/chainflip/keys/ethereum_key_file" [eth.rpc] ws_endpoint = "wss://my_local_eth_node:8546" http_endpoint = "https://my_local_eth_node:8545" # Optional # [eth.backup_rpc] # ws_endpoint = "wss://some_public_rpc.com:443/<secret_access_key>" # http_endpoint = "https://some_public_rpc.com:443/<secret_access_key>" [dot.rpc] ws_endpoint = "wss://rpc-pdot.chainflip.io:443" http_endpoint = "https://rpc-pdot.chainflip.io:443" [btc.rpc] basic_auth_user = "flip" basic_auth_password = "flip" http_endpoint = "http://my_local_btc_node:8332" # Optional (an RPC that doesn't require basic auth) # [btc.backup_rpc] # basic_auth_user = "" # basic_auth_password = "" # http_endpoint = "https://my_btc_rpc_backup.someotherprovider.xyz" [arb] # Arbitrum private key file path. This file should contain a hex-encoded private key. # Note: Here we use the same private key file as Ethereum. You can use a different key if you want. private_key_file = "/etc/chainflip/keys/ethereum_key_file" [arb.rpc] ws_endpoint = "ws://my_local_arbitrum_node:8548" http_endpoint = "http://my_local_arbitrum_node:8547" # optional #[arb.backup_rpc] #ws_endpoint = "ws://my_arbitrum_node_backup.someprovider/<secret_access_key>" #http_endpoint = "http://my_arbitrum_node_backup.someprovider/<secret_access_key>" [sol.rpc] http_endpoint = "http://my_solana_rpc.someprovider:443" #optional #[sol.backup_rpc] #http_endpoint = "http://my_solana_rpc_backup.someprovider:443" # Chainflip runs its own testnet AssetHub network. So use these endpoints for AssetHub. [hub.rpc] ws_endpoint = "wss://assethub.perseverance.chainflip.io:443" http_endpoint = "https://assethub.perseverance.chainflip.io:443" # optional #[logging] # command_server_port = 36079 # default if these settings are not set # span_lifecycle = false # default # Optional # [signing] # db_file = "/etc/chainflip/data.db"

At least one of the RPC endpoints (primary or backup) must be an archive node.

Pointing to the Ethereum Client

If you followed the instructions in Prerequisites, you will probably have an account with an Ethereum RPC provider (Alchemy, Infura, Rivet, etc.). You must change the eth.rpc.ws_endpoint and eth.rpc.http_endpoint in the above file to RPC URLs given to you by these services. You must have both a Websocket (wss) and HTTPS connection in order for the software to function.

Important: Make sure that you are not using a mainnet RPC, this will not work!

You can try other node connections as well. Geth with an open websocket server enabled  will accept connections through port 8546 by default. If it’s running on the same machine as your validator, you can use [ws|http]://127.0.0.1:854[6|5]

Pointing to the Arbitrum Client

If you followed the instructions in Prerequisites, you will probably have an account with an Arbitrum RPC provider (Alchemy, Infura, Rivet, etc.). You must change the arb.rpc.ws_endpoint and arb.rpc.http_endpoint in the above file to RPC URLs given to you by these services. You must have both a Websocket (wss) and HTTPS connection in order for the software to function.

Important: Make sure that you are not using a mainnet RPC, this will not work!

Saving the File

Once you’re happy with your configuration file and have inserted a valid endpoint address, exit and save the file by using CTRL(Control)+x and when prompted type Y then hit Enter.

6. Start the Validator

For a validator to be up you need to start both the node and the engine:

Starting the node

To start the chainflip-node, run the following command.

sudo systemctl start chainflip-node

To check on the service, we use status.

systemctl status chainflip-node

On certain cloud service providers, such as Digital Ocean, a glitch with journald prevents it from correctly reading logs from other services. To address this issue, execute the command below: sudo systemctl restart systemd-journald.service

At this point, you will need to wait for your node to catch up with the latest block. You can find the latest block on our Block Explorer. 

If you try to start your engine now it will crash. Wait for your node to sync before proceeding.

To view the live logs for the validator software, check on them via journalctl. You can quit at anytime using ctrl/control + c

Check the Node:

journalctl -f -u chainflip-node.service

At the start, you should see that your node is synchronising to the network, something like this:

2023-03-24 08:21:30 💻 Memory: 7957MB 2023-03-24 08:21:30 💻 Kernel: 5.4.0-122-generic 2023-03-24 08:21:30 💻 Linux distribution: Ubuntu 20.04.4 LTS 2023-03-24 08:21:30 💻 Virtual machine: yes 2023-03-24 08:21:30 📦 Highest known block at #0 2023-03-24 08:21:30 〽️ Prometheus exporter started at 127.0.0.1:9615 2023-03-24 08:21:30 Running JSON-RPC HTTP server: addr=127.0.0.1:9933, allowed origins=Some(["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"]) 2023-03-24 08:21:30 Running JSON-RPC WS server: addr=127.0.0.1:9944, allowed origins=Some(["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"]) 2023-03-24 08:21:30 🔍 Discovered new external address for our node: /ip4/178.128.36.211/tcp/30333/p2p/12D3KooWMDs3oyT2YpQw88V7TdmN1dJa73D1jrfQorLaBovh7Kim 2023-03-24 08:21:35 ⏩ Warping, Downloading finality proofs, 7.99 Mib (10 peers), best: #0 (0x2d00…c9b3), finalized #0 (0x2d00…c9b3), ⬇ 1.6MiB/s ⬆ 27.8kiB/s 2023-03-24 08:21:40 ⏩ Warping, Downloading finality proofs, 15.97 Mib (14 peers), best: #0 (0x2d00…c9b3), finalized #0 (0x2d00…c9b3), ⬇ 1.7MiB/s ⬆ 25.8kiB/s 2023-03-24 08:21:45 ⏩ Warping, Downloading state, 40.83 Mib (15 peers), best: #0 (0x2d00…c9b3), finalized #0 (0x2d00…c9b3), ⬇ 3.5MiB/s ⬆ 14.0kiB/s 2023-03-24 08:21:50 ⏩ Warping, Importing state, 58.00 Mib (15 peers), best: #0 (0x2d00…c9b3), finalized #0 (0x2d00…c9b3), ⬇ 2.0MiB/s ⬆ 3.1kiB/s 2023-03-24 08:21:54 Unable to author block in slot. No best block header: Chain lookup failed: Failed to get header for hash 0x0cdb…b083 2023-03-24 08:21:55 ⏩ Warping, Importing state, 58.00 Mib (15 peers), best: #1913239 (0x5b6b…c1b3), finalized #1913239 (0x5b6b…c1b3), ⬇ 9.3kiB/s ⬆ 1.3kiB/s 2023-03-24 08:21:56 Warp sync is complete (57 MiB), restarting block sync. 2023-03-24 08:21:57 ✨ Imported #1913240 (0xa922…5e2e) 2023-03-24 08:21:57 ✨ Imported #1913241 (0x3a15…012e) 2023-03-24 08:21:57 ✨ Imported #1913242 (0x0ceb…c1f8) 2023-03-24 08:21:57 ✨ Imported #1913243 (0xec83…ca57) 2023-03-24 08:21:57 ✨ Imported #1913244 (0x52c06594) 2023-03-24 08:22:00 ⏩ Block history, #4480 (11 peers), best: #1913244 (0x52c06594), finalized #1913242 (0x0ceb…c1f8), ⬇ 1.6MiB/s ⬆ 110.4kiB/s 2023-03-24 08:22:00 ✨ Imported #1913245 (0xd0b4…45a0) 2023-03-24 08:22:05 ⏩ Block history, #9152 (11 peers), best: #1913245 (0xd0b4…45a0), finalized #1913243 (0xec83…ca57), ⬇ 859.4kiB/s ⬆ 111.2kiB/s 2023-03-24 08:22:06 ✨ Imported #1913246 (0x93ad…15cd) 2023-03-24 08:22:10 ⏩ Block history, #11840 (11 peers), best: #1913246 (0x93ad…15cd), finalized #1913244 (0x52c06594), ⬇ 1.1MiB/s ⬆ 146.3kiB/s 2023-03-24 08:22:12 ✨ Imported #1913247 (0x1e1c…70df) 2023-03-24 08:22:15 ⏩ Block history, #19392 (11 peers), best: #1913247 (0x1e1c…70df), finalized #1913245 (0xd0b4…45a0), ⬇ 2.1MiB/s ⬆ 150.5kiB/s 2023-03-24 08:22:18 ✨ Imported #1913248 (0xbb749178) 2023-03-24 08:22:20 ⏩ Block history, #28800 (11 peers), best: #1913248 (0xbb749178), finalized #1913246 (0x93ad…15cd), ⬇ 2.9MiB/s ⬆ 169.1kiB/s 2023-03-24 08:22:24 ✨ Imported #1913249 (0xb062…b457) 2023-03-24 08:22:25 ⏩ Block history, #36288 (11 peers), best: #1913249 (0xb062…b457), finalized #1913246 (0x93ad…15cd), ⬇ 2.4MiB/s ⬆ 226.4kiB/s 2023-03-24 08:22:30 ⏩ Block history, #41088 (11 peers), best: #1913249 (0xb062…b457), finalized #1913247 (0x1e1c…70df), ⬇ 1.6MiB/s ⬆ 100.5kiB/s 2023-03-24 08:22:30 ✨ Imported #1913250 (0x4bc18362) 2023-03-24 08:22:35 ⏩ Block history, #43200 (11 peers), best: #1913250 (0x4bc18362), finalized #1913248 (0xbb749178), ⬇ 330.6kiB/s ⬆ 145.2kiB/s

The systemd unit file shipped with our Debian package for chainflip-node uses warp sync by default to make joining the network a faster process for new nodes. However, if you are running a docker setup or building from source, make sure to set --sync=warp CLI argument.

If you started syncing in archive mode and you wish to update to warp sync, make sure to purge the chain and start syncing using --sync=warp. The sync parameters get stored in the node’s database and simply updating the cli flag won’t take effect.

To purge the chain, check this section.

Starting the Engine

To start the chainflip-engine, we issue another command.

sudo systemctl start chainflip-engine

To check on the service, we use status.

systemctl status chainflip-engine

Check the engine logs:

journalctl -f -u chainflip-engine.service

You should see some output that looks like this:

██████╗██╗ ██╗ █████╗ ██╗███╗ ██╗███████╗██╗ ██╗██████╗ ██╔════╝██║ ██║██╔══██╗██║████╗ ██║██╔════╝██║ ██║██╔══██╗ ██║ ███████║███████║██║██╔██╗ ██║█████╗ ██║ ██║██████╔╝ ██║ ██╔══██║██╔══██║██║██║╚██╗██║██╔══╝ ██║ ██║██╔═══╝ ╚██████╗██║ ██║██║ ██║██║██║ ╚████║██║ ███████╗██║██║ ╚═════╝╚═╝ ╚═╝╚═╝ ╚═╝╚═╝╚═╝ ╚═══╝╚═╝ ╚══════╝╚═╝╚═╝ Your Chainflip account is not funded. Note, it may take some time for your funds to be detected. WAITING for your account to be funded at block: 1

In the next section, you’ll learn how to fund your node. After you do so the warnings should stop and the output will look something like this:

{"tag":"","msg":"Processing SC block 3591 with block hash: 0xe3ba3f20dc6d6d5956a88e5fcae06cdbb5c9cbf486a8db50cc5a1403bb4f0446","level":"debug","ts":"2022-11-08T15:56:13.652392888+00:00","component":"SCObserver"} {"tag":"","msg":"Processing SC block 3592 with block hash: 0x34155ced75831f45b17af9a792e057eabe148428b450ece4408f546342343669","level":"debug","ts":"2022-11-08T15:56:19.052722257+00:00","component":"SCObserver"} {"tag":"","msg":"Processing SC block 3593 with block hash: 0x50fdbb6ad0657f0d818e783330d697186d649e793046c7f67f8120559243b5d6","level":"debug","ts":"2022-11-08T15:56:25.782233200+00:00","component":"SCObserver"} {"tag":"","msg":"Processing SC block 3594 with block hash: 0xb878309015b27f7b8bc19c67ff5774841d44d9ed4ce189ebd5df32d0a90e5ae5","level":"debug","ts":"2022-11-08T15:56:31.181866542+00:00","component":"SCObserver"} {"tag":"","msg":"Processing SC block 3595 with block hash: 0xa047c1f10f595cd73148aa4866a40edb3da87ddd13ae03351c19a8d677cb99ec","level":"debug","ts":"2022-11-08T15:56:37.890330488+00:00","component":"SCObserver"} {"tag":"","msg":"Processing SC block 3596 with block hash: 0xaecccf0842c7253bbbc736baa86cebc07d5e6dc6b5b95e73d1ace73e5552fcfd","level":"debug","ts":"2022-11-08T15:56:43.274036666+00:00","component":"SCObserver"} {"tag":"","msg":"Processing SC block 3597 with block hash: 0xc4218c16ed3f6745433ec4b50dde94cb3b1a917ee8ddc35f17dc4e956380a787","level":"debug","ts":"2022-11-08T15:56:50.015185019+00:00","component":"SCObserver"} {"tag":"","msg":"Processing SC block 3598 with block hash: 0x3a79dc208b48276e7b734da0c8702f817d1a435476d09cbd972f09d3e5786851","level":"debug","ts":"2022-11-08T15:56:55.406457068+00:00","component":"SCObserver"} {"tag":"","msg":"Processing SC block 3599 with block hash: 0x49a53aa5f42190e5dc38d2e44d96235c656eec4101edd7fb26869466635216c3","level":"debug","ts":"2022-11-08T15:57:00.797006133+00:00","component":"SCObserver"}

If the engine starts crashing and reporting errors, don’t panic. Your node might be catching up and syncing blocks from the network. Give it some time and it should recover and start working. In the meantime you can head to the next section and start with the process of adding funds.

Enable systemd Services

Tell both the services to start again after a reboot:

sudo systemctl enable chainflip-node
sudo systemctl enable chainflip-engine

Anytime you make changes to your config file, don’t forget to run: systemctl restart chainflip-engine

Last updated on