monerod Commands and Flags Reference

monerod is the Monero node software. It downloads and checks the blockchain and exchanges blocks and transactions with peers. Wallets and other applications query the daemon for blockchain data. It can also solo mine using the built-in CPU miner.

A wallet holds your keys and identifies your funds. The daemon supplies blockchain data. You do not need to give monerod your seed phrase or private spend key to run a node.

This reference covers 122 distinct registered option names across Unix and Windows, including the hidden positional-command option, and all 51 console commands in Monero v0.18.5.4, including obsolete options, testing controls, and Windows service switches. The source baseline is commit 85f036ba7019cd36f08e8a38a27c37ea7b522618, verified on 2026-11-08 UTC. Different releases can add, remove, or change options. Check your own executable before copying a configuration:

./monerod --version
./monerod --help

The inventory check compares this reference with argument registration and command parsers in the tagged source. The examples illustrate syntax and were not all executed against a live node. This covers the daemon's command-line interface, not every HTTP or JSON-RPC API method.

How to read the examples

Startup flags follow the executable:

./monerod --prune-blockchain --out-peers 16

Console commands go into the terminal where an interactive daemon is already running:

status
sync_info
print_cn

One-shot commands use a separate invocation to contact an already running daemon over RPC:

./monerod status
./monerod --rpc-bind-ip 127.0.0.1 --rpc-bind-port 18081 sync_info

The second invocation is a client for that command. It does not start a second synchronizing node. Restricted RPC can refuse administrative commands. Point administrative requests at an endpoint you control.

In the tables, <value> means a required argument and [value] means an optional argument. Replace placeholders such as <TXID> and <PRIMARY_ADDRESS>. Do not type the angle brackets. Addresses under 192.0.2.0/24, 198.51.100.0/24, and names under .example are documentation placeholders, not working peers.

Values in examples illustrate syntax, not recommended performance settings. Peer count and bandwidth limits depend on your connection and workload.

Configuration files

Most persistent settings can go in a configuration file. Remove the leading -- and use name=value. Boolean switches use 1 or 0 in configuration files. Repeat list settings, such as add-peer, on separate lines.

# Example: a pruned node with local administrative RPC.
data-dir=/srv/monero
prune-blockchain=1
rpc-bind-ip=127.0.0.1
rpc-bind-port=18081
no-zmq=1
out-peers=16
log-level=0

Start it with:

./monerod --non-interactive --config-file /etc/monerod.conf

Use a directory writable by the account running the daemon. Under a process supervisor, keep the process in the foreground and use --non-interactive. On FreeBSD, a service may supply its own backgrounding through daemon(8). On Linux, systemd normally tracks the foreground process.

Not every startup action belongs in the configuration file. Help, version output, --non-interactive, --detach, --pidfile, platform service actions, and the hidden positional command mechanism are command-line controls. This release rejects non-interactive=1 inside the configuration file. Explicit configuration paths avoid confusion about defaults and service accounts.

Default network ports

P2P connects nodes to nodes. HTTP RPC connects wallets and applications to the daemon. ZMQ RPC is a separate interface, and ZMQ publication uses the endpoint you explicitly configure.

A separate restricted HTTP RPC port has no enabled default in this release. You choose it with --rpc-restricted-bind-port. Port 18089 is commonly used in examples, but it is not automatically created.

Startup flags: basic operation and logging

The usual Unix data directory is ~/.bitmonero. Service packages often choose another location. Explicit paths are easier to audit than assumptions about which user's home directory a service uses.

Sources: daemon arguments, startup handling, Unix daemonization.

Network selection and testing flags

The daemon uses mainnet unless you select another network. This release has no --mainnet flag. Test coins are not mainnet XMR.

Do not combine test-network flags or put test-only controls in a production configuration. They exist to support development, not to speed up a production node.

Source: core option definitions and registration.

Blockchain synchronization, storage, and checkpoints

What db-sync-mode means

The first component controls database write behavior. The optional second component selects sync or async. The third sets a flush threshold as a block count, optionally suffixed blocks, or a byte count suffixed bytes.

The registered default is:

fast:async:250000000bytes

safe uses its own durability handling. The parser does not apply the later components in that mode. Faster write modes trade crash resilience for throughput. Do not treat fastest as a harmless tuning recommendation, particularly on machines that can lose power. See database sync modes for the durability tradeoffs.

Pruning and actual disk space

Starting with pruning on an empty data directory avoids growing a full historical database first. Enabling it on an existing database frees pages for reuse inside LMDB, but the operating system may still report a large file.

To compact an existing full database into a smaller pruned database, stop the daemon and consult the separate monero-blockchain-prune tool. That conversion needs temporary disk space. This tool has its own options and is outside this daemon reference.

Sources: core synchronization and storage handling, database options, pruning command behavior.

P2P listeners, peers, and bandwidth

The source uses 1,024-byte units for the bandwidth limiter despite displaying kB/s. Treat the values as approximate application-level rate controls, not a precise cap on every byte on the wire.

An IPv6-capable node might start with:

./monerod --prune-blockchain --p2p-use-ipv6

Opening P2P to other nodes does not require opening administrative RPC.

Sources: P2P option definitions, P2P option handling.

Tor, I2P, and proxy flags

The tx-proxy format is:

network-type,proxy[,max_connections][,disable_noise]

Supported network types are tor and i2p. The proxy accepts the SOCKS syntax supported by this release. disable_noise turns off the associated noise traffic. Do not copy it as an automatic performance improvement.

With an existing Tor SOCKS listener:

./monerod --tx-proxy tor,127.0.0.1:9050

To accept onion P2P connections, replace YOUR_SERVICE.onion below with a real hidden-service address, and configure Tor to forward its chosen external port to 127.0.0.1:18083:

--anonymous-inbound YOUR_SERVICE.onion:18083,127.0.0.1:18083

An onion P2P endpoint is not an onion wallet RPC endpoint. They are different services. A transaction proxy is not a guarantee that every daemon action, external notification script, listener, or DNS query is anonymous. See Monero transaction relay over Tor and I2P for the connection paths.

Sources: proxy flags, P2P proxy parsing, daemon proxy setup.

HTTP RPC: wallets, administration, and public access

The normal RPC listener supports administrative functions. Keep it on loopback or a controlled private network. A separate restricted listener is the appropriate interface when intentionally providing remote wallet access.

Restricted RPC removes administrative methods and limits sensitive responses. It does not mean every allowed request is read-only. Wallets can still submit transactions. The remote-node glossary entry explains what a wallet requests from a daemon.

Example: local administration plus public restricted RPC

rpc-bind-ip=127.0.0.1
rpc-bind-port=18081
rpc-restricted-bind-ip=0.0.0.0
rpc-restricted-bind-port=18089
public-node=1

This intentionally exposes the restricted endpoint on IPv4. Permit that port in your firewall only if you want to serve remote wallets. Keep port 18081 private. Add transport encryption or an appropriate protected network path when needed. Binding a port does not encrypt it.

Do not add restricted-rpc=1 to this example if you want the main local endpoint to remain administrative.

Sources: RPC listener settings, daemon RPC registration and initialization, RPC method restrictions.

RPC encryption and certificate flags

These options configure RPC TLS. They also affect certificate verification when monerod acts as a one-shot RPC client. A certificate file and a CA trust file serve different purposes.

Example TLS identity settings:

rpc-ssl=enabled
rpc-ssl-private-key=/etc/monero/tls/node.key
rpc-ssl-certificate=/etc/monero/tls/node.crt

Source: RPC TLS parsing.

Bootstrap daemon flags

A bootstrap daemon answers supported wallet requests while your own daemon is still catching up. Your daemon still builds its own blockchain database while using that temporary remote data source.

Source: bootstrap configuration.

RPC payment flags

This release includes a proof-of-work credit system for RPC access. Despite the help text's "micropayment" wording, this is not an ordinary wallet transfer for each request. Clients receive credits for submitted work. Sufficiently good work may also produce a valid Monero block.

These settings require compatible clients. They are not necessary for a private node or a conventional free public node.

Sources: payment options and handlers, RPC payment implementation.

ZeroMQ flags

ZMQ RPC and ZMQ publication are different interfaces. P2Pool deployments commonly use publication notifications. That does not require exposing ZMQ RPC to the internet.

For a local notification consumer, leave ZMQ enabled and keep its RPC listener on the default loopback address:

./monerod --zmq-pub tcp://127.0.0.1:18083

Port 18083 here is an example publication port. Do not reuse the same local IP and port for an anonymous inbound P2P listener.

Sources: ZMQ arguments, daemon interface construction.

Built-in mining flags

The daemon's miner performs solo mining. It does not become an XMRig pool client or a P2Pool miner simply because mining is enabled. For pooled mining with your node, see getting started with P2Pool.

Example startup, after replacing the address placeholder:

./monerod --start-mining <PRIMARY_ADDRESS> --mining-threads 2

Idle detection and power-state support vary by platform. Inspect mining_status rather than assuming identical behavior on Linux, FreeBSD, and Windows.

Source: miner options and implementation.

Notification hooks

These flags execute a program when an event occurs. Use absolute paths and a script that handles its arguments safely. Give the daemon account permission to execute it.

A notification hook can receive the block hash:

./monerod --block-notify '/usr/local/bin/monero-block-hook %s'

The hook could update monitoring or send an ntfy notification. It should return quickly. A block-rate alert indicates a statistical deviation. Other evidence is needed to identify an attack.

Source: notification definitions and invocation.

Windows service flags and internal options

Windows also has --non-interactive, although it is registered among hidden options there. Unix --detach and --pidfile are not Windows service options.

The parser registers a hidden daemon_command argument, internally represented as --daemon_command. It collects positional command words such as status or print_block 1000000. Use the documented positional form, not the hidden switch, in normal operation.

Source: Windows daemonization, positional command registration.

All console commands

This release registers the following commands. Type them into an interactive daemon, or invoke them through a separate monerod process where supported. The syntax shown here describes v0.18.5.4, not unreleased development changes.

Sources for this entire command reference: command registration, argument parsing, command execution.

Help, status, and shutdown

Peer inspection and network controls

print_pl accepts at most three arguments in this parser, even though its help lists more optional selectors. pruned filters for pruned peers. publicrpc filters for advertised public RPC services. A numeric limit controls how many entries are printed.

For runtime bandwidth commands, -1 restores the built-in default, while 0 leaves that direction unchanged. Use a positive value to set a specific throttle.

Runtime tuning is not automatically written back into your configuration file. Make a separate configuration edit to retain a setting after restarts.

Blocks, transactions, and chain statistics

The parser also supports print_bc -10 for the last ten blocks. alt_chain_info >3 filters for branches longer than three blocks, and alt_chain_info -100 filters by recent branch start heights. Quote the >3 argument when issuing a one-shot command from a shell, so it is not interpreted as output redirection.

These commands inspect public chain data. They do not decode hidden RingCT amounts, reveal destination addresses, or identify the actual spent member of a ring.

Transaction pool and relay

The transaction pool, or mempool, holds pending transactions known to this node. Different nodes can temporarily have different pools.

Mining commands

For background mining, the full form can look like:

start_mining <PRIMARY_ADDRESS> 2 true false

This requests two mining threads with background behavior enabled and battery-ignore disabled.

Maintenance, diagnostics, and testing commands

For bootstrap changes, accepted forms are auto [proxy], none, host[:port] [proxy], and host[:port] username password [proxy]. With a host and just one additional argument, that argument is the proxy, not a username.

pop_blocks is not a routine fix for every synchronization problem. First inspect status, sync_info, storage availability, and logs. Run state-changing recovery commands only when the diagnosis calls for them.

Practical command sequences

Check a node that appears stuck

In the running console:

status
sync_info
print_cn
print_net_stats

No connected peers points toward connectivity or peer-selection trouble. Active downloads with slow progress can instead point toward disk or processing limits. Compare several observations rather than drawing conclusions from one snapshot.

Inspect a pending transaction

Replace the transaction ID:

print_pool_stats
print_tx <TXID> +json

A transaction absent from this node may still be present at another node. A transaction in the pool is not yet confirmed in a block.

Diagnose noisy logs temporarily

set_log 1

Collect the relevant interval, then return to:

set_log 0

Before sharing logs, check them for IP addresses, local paths, credentials, or other operational information.

Shut down cleanly

./monerod --rpc-bind-ip 127.0.0.1 --rpc-bind-port 18081 stop_daemon

When a service manager owns the process, use that service's stop action so its restart policy does not immediately launch the daemon again.

Keep the reference matched to your binary

The startup and console interfaces evolve separately. A flag found in a development branch may not exist in a release binary, while a deprecated flag can remain accepted long after its function disappears.

For your installed version, use monerod --help for startup options and help inside the console for commands. If the help text and observed behavior disagree, inspect the parser for that exact release. In v0.18.5.4, the inactive UPnP controls and the flush_cache bad-txs help entry are examples of why that last check matters.

Source notes

The inventory follows the Monero v0.18.5.4 source tag. Source links beside each section identify the definitions and implementation checked.

Additional documentation: official monerod reference, configuration-file syntax, and daemon RPC documentation.