The Solo daemon solod keeps your computer synced up with the Solo network.
It downloads and validates the blockchain from the p2p network.
solod is entirely decoupled from your wallet.
solod does not access your private keys - it is not aware of your transactions and balance.
This allows you to run solod on a separate computer or in the cloud.
In fact, you can connect to a remote solod instance provided by a semi-trusted 3rd party. Such 3rd party will not be able to steal your funds. This is very handy for learning and experimentation.
However, there are privacy and reliability implications to using a remote, untrusted node. For any real business you should be running your own full node.
./solod [options] [command]
Options define how the daemon should be working. These are passed at startup. Their names follow the --option-name pattern.
Commands give access to specific services provided by the daemon. Commands are executed against the running daemon.
Their names follow the command_name pattern.
Go to directory where you unpacked Solo.
Testnet | Stagenet
The testnet or stagenet is used for learning and experimentation.
Testnet coins are XSV (not XSL). Testnet is not always running, and generally is a temporary network that starts at block 0 when needed.
The mainnnet is when you want to deal with the real XSL.
Options define how the daemon should be working. Their names follow the --option-name pattern.
The following groups are only to make reference easier to follow. The daemon itself does not group options in any way.
Help and version
| Option | Description |
| --help | Enlist available options.|
| --version | Show solod version to stdout. Example: Solo 'Han' (v188.8.131.52-release)|
| --os-version | Show build timestamp and target operating system. Example output: OS: Linux #1 SMP PREEMPT Fri Aug 24 12:48:58 UTC 2018 4.18.5-arch1-1-ARCH. |
Run on stagenet. Remember to run your wallet with --stagenet as well.
Run on testnet. Remember to run your wallet with --testnet as well.
Full path to the log file. Example (mind file permissions): ./solod --log-file=/var/log/Solo/mainnet/solod.log
0-4 with 0 being minimal logging and 4 being full tracing. Defaults to 0. These are general presets and do not directly map to severity levels. For example, even with minimal 0, you may see some most important INFO entries. Temporarily changing to 1 allows for much better understanding of how the full node operates. Example: ./solod --log-level=1
Soft limit in bytes for the log file (=104850000 by default, which is just under 100MB). Once log file grows past that limit, solod creates the next log file with a UTC timestamp postfix -YYYY-MM-DD-HH-MM-SS.
In production deployments, you would probably prefer to use established solutions like logrotate instead. In that case, set --max-log-file-size=0 to prevent solod from managing the log files.
Limit on the number of log files (=50 by default). The oldest log files are removed. In production deployments, you would probably prefer to use established solutions like logrotate instead.
solod defaults are adjusted for running it occasionally on the same computer as your Solo wallet.
The following options will be helpful if you intend to have an always running node — most likely on a remote server or your own separate PC.
Full path to data directory. This is where the blockchain, log files, and p2p network memory are stored. For defaults and details see data directory.
Full path to the PID file. Works only with --detach. Example: ./solod --detach --pidfile=/run/Solo/solod.pid
Go to background (decouple from the terminal). This is useful for long-running / server scenarios. Typically, you will also want to manage solod daemon with systemd or similar. By default solod runs in a foreground.
Do not require tty in a foreground mode. Helpful when running in a container. By default solod runs in a foreground and opens stdin for reading. This breaks containerization because no tty gets assigned and solod process crashes. You can make it run in a background with --detach but this is inconvenient in a containerized environment because the canonical usage is that the container waits on the main process to exist (forking makes things more complicated).
Disable UPnP port mapping on the router ("Internet Gateway Device"). Add this option to improve security if you are not behind a NAT (you can bind directly to public IP or you run through Tor).
Set maximum transactions pool size in bytes. By default 648000000 (~618MB). These are transactions pending for confirmations (not included in any block).
The emergency checkpoints set by SoloPulse operators will be enforced. It is probably a good idea to set enforcing for unattended nodes.
If encountered block hash does not match corresponding checkpoint, the local blockchain will be rolled back a few blocks, effectively blocking following what SoloPulse operators consider invalid fork. The log entry will be produced: ERRORLocal blockchain failed to pass a checkpoint, rolling back! Eventually, the alternative ("fixed") fork will get heavier and the node will follow it, leaving the "invalid" fork behind.
By default checkpointing only notifies about discrepancy by producing the following log entry: ERRORWARNING: local blockchain failed to pass a SoloPulse checkpoint, and you could be on a fork. You should either sync up from scratch, OR download a fresh blockchain bootstrap, OR enable checkpoint enforcing with the --enforce-dns-checkpointing command-line option.
The SoloPulse checkpoints set by core developers will be discarded. The checkpoints are apparently still fetched though.
The following options define how your node participates in Solo peer-to-peer network.
This is for node-to-node communication. The following options do not affect wallet-to-node interface.
The node and peer words are used interchangeably.
Network interface to bind to for p2p network protocol. Default value 0.0.0.0 binds to all network interfaces.
TCP port to listen for p2p network connections. Defaults to 18080 for mainnet, 28080 for testnet, and 38080 for stagenet. You normally wouldn't change that. This is helpful to run several nodes on your machine to simulate private Solo p2p network (likely using private Testnet). Example: ./solod --p2p-bind-port=48080
TCP port to listen for p2p network connections on your router. Relevant if you are behind a NAT and still want to accept incoming connections. You must then set this to relevant port on your router. This is to let solod know what to advertise on the network. Default is 0.
solod will still open and listen on the p2p port. However, it will not announce itself as a peer list candidate. Technically, it will return port 0 in a response to p2p handshake (node_data.my_port = 0 in get_local_node_data function). In effect nodes you connect to won't spread your IP to other nodes. To sum up, it is not really hiding, it is more like "do not advertise".
Connect to a node to retrieve other nodes' addresses, and disconnect. If not specified, solod will use hardcoded seed nodes on the first run, and peers cached on disk on subsequent runs.
Manually add node to local peer list.
Specify list of nodes to connect to and then attempt to keep the connection open.
To add multiple nodes use the option several times. Example: ./solod --add-priority-node=184.108.40.206:18081 --add-priority-node=220.127.116.11:18081
Specify list of nodes to connect to only. If this option is given the options --add-priority-node and --seed-node are ignored. To add multiple nodes use the option several times. Example: ./solod --add-exclusive-node=18.104.22.168:18081 --add-exclusive-node=22.214.171.124:18081
Set max number of outgoing connections to other nodes. By default 8. Value -1 represents the code default.
Set max number of incoming connections (nodes actively connecting to you). By default unlimited. Value -1 represents the code default.
Set outgoing data transfer limit [kB/s]. By default 2048 kB/s. Value -1 represents the code default.
Set incoming data transfer limit [kB/s]. By default 8192 kB/s. Value -1 represents the code default.
Set the same limit value for incoming and outgoing data transfer. By default (-1) the individual up/down default limits will be used. It is better to use --limit-rate-up and --limit-rate-down instead to avoid confusion.
Do not listen for peers, nor connect to any. Useful for working with a local, archival blockchain.
Allow adding local IP to peer list. Useful mostly for debug purposes when you may want to have multiple nodes on a single machine.
Node RPC API
solod node offers powerful API. It serves 3 purposes:
provides network data (stats, blocks, transactions, ...)
provides local node information (peer list, hash rate if mining, ...)
provides interface for wallets (send transactions, ...)
This API is typically referred to as "RPC" because it is mostly based on JSON/RPC standard.
The following options define how the API behaves.
IP to listen on. By default 127.0.0.1 because API gives full administrative capabilities over the node. Set it to 0.0.0.0 to listen on all interfaces - but only in connection with one of *-restricted-* options and--confirm-external-bind.
TCP port to listen on. By default 18081 (mainnet), 28081 (testnet), 38081 (stagenet).
TCP port to listen on with the limited version of API. The limited API can be made public to create an Open Node. At the same time, you may firewall the full API port to still enjoy local querying and administration.
Confirm you consciously set --rpc-bind-ip to non-localhost IP and you understand the consequences.
Restrict API to view only commands and do not return privacy sensitive data. Note this does not make sense with --rpc-restricted-bind-port because you would end up with two restricted APIs.
Specify username[:password] required to connect to API. Practical usage seems limited because API communication is in plain text over HTTP.
These are network notifications offered by solod. There are also wallet notifications like --tx-notify offered by solo-wallet-rpc Work in Progress
Run a program for each new block. The <arg> must be a full path. If the <arg> contains %s it will be replaced by the block hash. Example: ./solod --block-notify="/usr/bin/echo %s"
Block notifications are good for immediate reaction. However, you should always assume you will miss some block notifications and you should independently poll the API to cover this up.
Mind blockchain reorganizations. Block notifications can revert to same and past heights. Small reorganizations are natural and happen every day.
Run a program when the number of blocks received in the recent past deviates significantly from the expectation. The <arg> must be a full path. The <arg> can contain any of %t, %b, %e symbols to interpolate:
%t: the number of minutes in the observation window
%b: the number of blocks observed in that window
%e: the ideal number of blocks expected in that window
The option will let you know if the network hash rate drops by a lot. This may be indicative of a large section of the network miners moving off to mine a private chain, to be later released to the network. Note that if this event triggers, it is not incontrovertible proof that this is happening. It might just be chance. The longer the window (the %t parameter), and the larger the distance between actual and expected number of blocks, the more indicative it is of a possible chain reorg double-spend attack being prepared.
Recommendation: unless you run economically significant Solo exchange or operation, do not act on this data. It is hard to calibrate and easy to misinterpret. If this is a real attack, it will target high-liquidity entities and not small merchants.
Run a program when reorganization happens (ie, at least one block is removed from the top of the blockchain). The <arg> must be a full path. The <arg> can contain any of %s, %h, %n symbols to interpolate:
%s: the height at which the split occurs
%h: the height of the new blockchain
%d: the number of blocks discarded from the old chain
%n: the number of blocks being added
The option will let you know when a block is removed from the chain to be replaced by other blocks. This happens when a 51% attack occurs, but small reorgs also happen in the normal course of things. The %d parameter will be set to the number of blocks discarded from the old chain (so if this is higher than the number of confirmations you wait to act upon an incoming payment, that payment might have been cancelled). The %n parameter wil be set to the number of blocks in the new chain (so if this is higher than the number of confirmations you wait to act upon an incoming payment, any incoming payment in the first block will be automatically acted upon by your platform).
Recommendation: unless you run economically significant Solo exchange or operation, you do not need to bother with this option. Simply account for reorganizations by requiring at least 10 confirmations before shipping valuable goods.
The following options configure solo mining using CPU with the standard software stack solod.
Specify wallet address to mining for. This must be a standard address! It can be neither a subaddress nor integrated address.
Specify mining threads count. By default ony one thread will be used. For best results, set it to number of your physical cores.
Specify file for extra messages to include into coinbase transactions.
Enable unobtrusive mining. In this mode mining will use a small percentage of your system resources to never noticeably slow down your computer. This is intended to encourage people to mine to improve decentralization. That being said chances of finding a block are diminishingly small with solo CPU mining, and even lesser with its unobtrusive version. You can tweak the unobtrusivness / power trade-offs with the further --bg-* options below.
If true, assumes plugged in when unable to query system power status.
Specify min lookback interval in seconds for determining idle state.
Specify minimum avg idle percentage over lookback interval.
Specify maximum percentage cpu use by miner(s).
Testing Solo itself
These options are useful for Solo project developers and testers. Normal users shouldn't be concerned with these.
For net tests: in download, discard ALL blocks instead checking/saving them (very fast).
Like test-drop-download but discards only after around certain height. By default 0.
Run in a regression testing mode.
Fixed difficulty used for testing. By default 0.
Sleep time in ms, defaults to 0 (off), used to debug before/after locking mutex. Values 100 to 1000 are good for tests.
Save data for dr Solo.
These options should no longer be necessary. They are still present in solod for backwards compatibility.
Relay compact blocks. Default. Compact block is just a header and a list of transaction IDs.
Relay classic full blocks. Classic block contains all transactions.
Official docs say "Show time-stats when processing blocks/txs and disk synchronization" but it does not seem to produce any output during usual blockchain synchronization.
IP for ZMQ RPC server to listen on. By default 127.0.0.1. This is not yet widely used as ZMQ interface currently does not provide meaningful advantage over classic JSON-RPC interface. Unfortunately, currently there is no way to disable the ZMQ server.
Port for ZMQ RPC server to listen on. By default 18082 for mainnet, 38082 for stagenet, and 28082 for testnet.
Specify database type. The default and only available: lmdb.
Commands give access to specific services provided by the daemon.
Commands are executed against the running daemon.
Their names follow the command_name pattern.
The following groups are only to make reference easier to follow.
The daemon itself does not group commands in any way.
See running for example usage.
You can also type commands directly in the console of the running solod (if not detached).
Help, version, status
Show help for <command>.
Show version information. Example output: Solo 'Han' (v126.96.36.199-release)
Show status. Example output: Height: 186754/186754 (100.0%) on stagenet, not mining, net hash 317 H/s, v9, up to date, 8(out)+0(in) connections, uptime 0d 3h 48m 47s
Show the full peer list.
Show the full peer list statistics (white vs gray peers). White peers are online and reachable. Grey peers are offline but your solod remembers them from past sessions.
Show connected peers with connection initiative (incoming/outgoing) and other stats.
ban <IP> [<seconds>]
Ban a given <IP> for a given amount of <seconds>. By default the ban is for 24h. Example: ./solod ban 188.8.131.52.
Unban a given <IP>.
Show the currently banned IPs. Example output: 184.108.40.206 banned for 86397 seconds.
Set the <max_number> of incoming connections from other peers.
Set the <max_number> of outgoing connections to other peers.
Get or set the download and upload limit.
Get or set the download limit.
Get or set the upload limit.
Flush specified transaction from transactions pool, or flush the whole transactions pool if was not provided.
Print the transaction pool using a verbose format.
Print the transaction pool using a short format.
Print the transaction pool's statistics (number of transactions, memory size, fees, double spend attempts etc).