Skip to main content

Setting up a Node

Server Requirements

A production-ready server typically requires:

  • 8-core x86 CPU
  • 64 GB RAM - Cosmos apps typically use less than 32 GB under normal conditions, but during events such as chain upgrades, up to 64 GB is usually needed.
  • 4 TB NVME SSD - Hard drive I/O speed is crucial! Validators who run on HDD or SATA SSD often find themselves missing blocks. The requirement for disk space can depend on your pruning settings, but generally, at least 2 TB is recommended.
  • Linux or macOS operating system
  • Go v1.19+

Note that hardware requirements may be significantly lower for Mars during the chains early stages. As the blockchain matures, a higher performing server will be needed.

Compile the Mars App Daemon

Visit the Marsd docs to learn more.

Initialize your Node

After installing marsd, you can initialize a Martian node by running the following command:

marsd init yourmoniker --chain-id <chain-id>

Replace yourmoniker with any string you’d like. This is the name to identify your server. For prospective Validators, this is NOT your validator's moniker, which we will create later.

Running this command also creates your consensus and node keys, as well as a .mars folder under your home directory with some config files for your node:

├─┬ config
│ ├── app.toml
│ ├── client.toml
│ ├── config.toml
│ ├── genesis.json
│ ├── node_key.json
│ ├── priv_validator_key.json
└─┬ data
└── priv_validator_state.json

Let's walk over each file created:

  • app.toml - Used to specify application-level settings, such as gas price, API endpoints to serve, and so on
  • client.toml - The config for the app’s command line interface. This is where you can set defaul parameters, such as a default --chain-id.
  • config.toml - Used to specify settings for the underlying Tendermint consensus engine, which handles networking, P2P connections, and consensus.
  • genesis.json - Contains the initial set of transactions that defines the state of the blockchain at its inception.
  • node_key.json - Contains a private key that is used for node authentication in the peer-to-peer (p2p) protocol. priv_validator_key.json - Contains the private key for Validators, which is used to sign blocks and votes. You should back up this file and don't show anyone else its content.
  • priv_validator_state.json - used to store the current state of the private validator. This includes information such as the current round and height of the validator, as well as the latest signed vote and block. This file is typically managed by the Tendermint consensus engine and used to prevent your node from double-signing.

Sync Genesis state

Before we run our node, we need to replace our genesis.json file in our .mars folder with the genesis file for our specific network. For mainnet (mars-1), this can be done with the following command:

wget -O ~/.mars/config/genesis.json

For more information about the genesis file for testnet, visit the Networks repo.

Set Seed Nodes

In order to join the network, a node first needs to know a few peers to connect to. A seed node is a type of node that connects to a large number of peers and informs new nodes of available peers in the network. A list of available seed nodes can be found in the Cosmos chain registry. For mainnet (mars-1), configuring seed nodes can be done with the following command:

export SEEDS=`,`
sed -i.bak -e "s/^seeds *=.*/seeds = \"$SEEDS\"/" ~/.mars/config/config.toml

For testnet (ares-1), configuring seed nodes can be done with the following command:

export SEEDS=`2ee39b7648d17f90fab0f9800faa9374e7573fc6@,`
sed -i.bak -e "s/^seeds *=.*/seeds = \"$SEEDS\"/" ~/.mars/config/config.toml

You can also configure seed nodes directly under the config.toml file in the .mars folder.

Run the Node

You can now launch the network with marsd start!

However, running the network this way requires a shell to always be open. You can, instead, create a service file that will manage running the network for you. To learn more about this topic, visit the docs.

Once you’ve started your node, you will need to wait for the node to sync up to the latest block. To check the node's sync status, you can run the following command:

marsd status 2>&1 | jq

jq formats the output into a more readable format. 2>&1 is necessary because of a bug where Cosmos SDK mistakenly outputs the status to stderr instead or stdout.

The output should include the following data (only fields relevant to this section here are shown):

"NodeInfo": {
"id": "...", // derived from node_key.json
"moniker": "yourmoniker", // defined in config.toml
"SyncInfo": {
"latest_block_height": "4834328",
"latest_block_time": "2022-06-21T12:31:40.747935942Z",
"catching_up": false // important
"ValidatorInfo": {
"Address": "...", // derived from priv_validator_key.json
"PubKey": { ... }, // same as above
"VotingPower": "0" // zero if the node is not a validator

Your node is synced up if SyncInfo.catching_up is false.

Snapshots (Optional)

Syncing up-to-date to an existing network may take time. Luckily, some validators like Polkachu are kind enough to share their snapshots with us. A snapshot is basically compressed pack of the .mars/data folder. To use the snapshot, go to and follow the instructions.


You can use the pruned snapshot to bootstrap your node, even if you plan to use other pruning settings (e.g. "default" or "nothing").

State-sync is another approach for quickly bootstrapping a new node, but does not take care of the wasm folder on Mars Protocol, so you need to preserve your own current wasm folder. It is best to just use the Mars Protocol snapshot service since it is more reliable.

Set up Cosmovisor (Optional)

cosmovisor is a small process manager for Cosmos SDK application binaries that monitors the governance module for incoming chain upgrade proposals. If it sees a proposal that gets approved, cosmovisor can automatically download the new binary, stop the current binary, switch from the old binary to the new one, and finally restart the node with the new binary.

We recommend that validators monitor the governance module and restart their nodes manually to eliminate third-party exposure. This tutorial will assume a standard set up, but if you'd like to install Cosmovisor you can continue here.

Configure System Service (Optional)

As a node operator, you probably want your node software to run persistently in the system background. Linux distros each have their own way of managing background services, but most (e.g. Ubuntu and Arch) use the systemd software.

To create a system service for marsd, create a file as follows (you will need sudo privilege):

sudo vim /etc/systemd/system/marsd.service

Enter the following, and save:

Description=Mars Daemon
ExecStart=/home/demo-user/.go/bin/marsd start

Replace the marsd path in ExecStart with the actual path of your marsd binary.

Two key points here are:

  • By setting the Restart and RestartSec params, we instruct systemd to automatically restart the marsd process in case it fails for some reason;
  • With the LimitNOFILE param, we allow marsd to access up to 65,535 files simultaneously. This is necessary because Cosmos nodes do need to access more files than what systemd allows by default.

Run the following command to register the system service:

sudo systemctl daemon-reload

If you want the node software to start automatically on each server reboot, run the following command to mark it as "enabled":

sudo systemctl enable marsd

You can start your system service for your node by running the following command:

sudo systemctl start marsd