Skip to content

Deploying an Observation Node#

Observation Nodes#

Flare network is based on the Federated Byzantine Agreement (FBA) consensus algorithm, which is enforced by validator nodes. In first stage of Songbird life cycle, the set of core validators for producing blocks is run by Flare. Anyone can add an external node to observe the network and submit transactions. The observation node connects directly to the core validators and offers you fast access to the network. This is faster than using publicly provided nodes which usually enforce rate limiting.

Why do I need an observation node?#

Running an observation node is not mandatory. A price provider can utilize public interfaces, AKA public RPC nodes. Alas, running your own observation nodes provides a safer, faster and more robust connection, for submitting transactions and for reading events or other network data. Your own node for submitting transactions (submitHashes) enables sending those a few seconds later compared to public nodes. These few precious seconds can be used for getting more price data before submitting your transaction.

Setting up the node#

Set up a local instance of peering node to have a more stable connection. To set up a node follow the instructions provided on the Flare node repository. Make sure to have enough disk space to allow for db resizes.


To set up the observation node, you need to whitelist your peering IP. Submit a whitelisting request here. You will be notified about the whitelisting process via your submitted email. You can also check the status of whitelisting by running the command:

curl -m 10 -sX POST --data '{ "jsonrpc":"2.0", "id":1, "method":"info.getNodeIP" }' -H 'content-type:application/json;'

Which will return a JSON containing node IP-s if your IP is whitelisted.

Running the node#

After cloning and compiling the songbird node, adjust the necessary configurations in so that the database location points to the external disk. Run ./cmd/ to start bootstrapping. The first bootstrap needs quite a long time to complete and a large amount of disk space (depends on the network size, it can be up to 2TB). Be sure to have sufficient hardware to run the node efficiently, the current minimum specifications are: 8 CPU cores, 16 GB of RAM and at least 2 TB disk space.

After the bootstrap completes the query curl | jq . the query will return healthy and you can start using the node.

If you need to restart the node, use the flag --existing to reuse the existing downloaded database. This will enable much faster resync on restart.


Do I need to re-whitelist my peering node IP?#

No, you do not need to re-whitelist the IP address.

I want to have greater redundancy and would like to whitelist multiple nodes, can I do that?#

You can whitelist multiple IPs per single provider.

Can an unhealthy node cause my TXs to revert?#

Yes, at times, not enough connected peers can cause your transactions to revert. Make sure your node state is healthy and that it has enough connected peers.

What is the required number of connected peers?#

If the number of peers falls below 19, there is a good chance that some peers have disconnected from your node, try to restart it.


The node does not sync after a long time and dies abruptly, what to do?#

Make sure, that the database location has sufficient disk space (database size might change a lot during bootstrapping).

I'm getting strange errors on submission and revert messages are cryptic#

This might be a symptom of node connection error. Try to restart node and make sure you have enough disk space.

I am getting a strange error failed to send GetAcceptedFrontier(MtF8bVH241hetCQJgsKEdKyJBs8vhp1BC, 11111111111111111111111111111111LpoYY, NUMBER) when bootstrapping the node, what should I do?#

It seems, that your node got disconnected during the bootstrapping. Restart the node, but to speed up the process, use --existing flag to reuse the data and don’t do the bootstrap from zero.

I have synced the node but it does not become healthy. What can I do?#

It often happens that a new node gets synced but stays unhealthy for no apparent reason. A restart with --existing flag usually helps.

Last update: 2022-06-29
Back to top