Running monerod for Integration

Every Monero integration — a payment processor, an exchange, a tipping bot, a block explorer — ultimately rests on one piece of software: monerod, the Monero daemon. It's the program that talks to the network, validates the blockchain, and answers the questions your application asks ("has this payment arrived?", "how many confirmations?"). In this lesson you'll learn what monerod does, why you must run your own, and how to configure it for a production integration.

What monerod actually does

The daemon has three jobs. First, it downloads and validates the blockchain — every block, every transaction, checked against consensus rules so it can independently confirm what is true without trusting anyone. Second, it participates in the peer-to-peer network, gossiping new blocks and transactions with other nodes. Third, it exposes the Daemon RPC API, the HTTP interface your code calls to query chain state and (together with a wallet) to detect and verify payments.

The first sync is the part that surprises people: the daemon must validate the entire chain from genesis, which takes anywhere from several hours to a couple of days depending on your disk and CPU, and consumes a large amount of disk space. A fast SSD makes an enormous difference. As we'll see, pruning cuts the storage requirement dramatically while keeping full validation intact.

Run your own node — never trust a stranger's

You can point a wallet at a public remote node for casual use, but for an integration that handles money this is a mistake. A remote node you don't control can lie to you: it can report a fake block height, claim a transaction has more confirmations than it really does, or feed you stale data — all of which can be turned into a double-spend or a "free money" attack against your service. It can also log every query and link your activity together.

The entire value proposition of Monero is "don't trust, verify." Your own monerod validates every block itself, so it cannot be fooled by a malicious peer. For any integration, run your own node. The rest of this lesson assumes you are.

Restricted vs. unrestricted RPC

The Daemon RPC comes in two flavors, and the distinction matters for security:

• Unrestricted RPC — the admin interface, served on default port 18081. It exposes the full method set, including commands that can reconfigure or stress the node. This is what your integration talks to, and you must bind it to localhost only so nothing on the open internet can reach it.
• Restricted RPC — the public-safe interface on port 18089, enabled with --restricted-rpc. It exposes only a safe subset of methods and is what you'd offer to other people's wallets if you were running a public node.

For your own integration you run an unrestricted RPC, locked to 127.0.0.1, and let your application connect to it locally.

Useful flags

A typical integration node is launched with something like these options:

• --rpc-bind-ip 127.0.0.1 and --rpc-bind-port 18081 — keep the unrestricted RPC on localhost. If you must bind to a non-local address you'll also need --confirm-external-bind, but think hard before doing so.
• --rpc-login user:pass — adds HTTP digest authentication to the RPC, a sensible extra layer even on localhost.
• --restricted-rpc — serve only the safe public subset (for a public-facing node, not your private admin one).
• --zmq-pub tcp://127.0.0.1:18083 — publish new blocks and transactions over ZeroMQ so your app can subscribe instead of polling.
• --prune-blockchain — run a pruned node (covered below).
• --out-peers — cap outgoing connections to control bandwidth.
• --no-igd — disable UPnP port-mapping, which you don't want on a server.
• --detach — run the daemon in the background.
• --proxy 127.0.0.1:9050 — route the node's P2P traffic through Tor for privacy.

Running over Tor and as a service

Routing monerod through Tor with --proxy hides your node's network traffic and IP from the peers it talks to — the same privacy idea covered in connecting over Tor, applied to the daemon itself. For an integration that must stay up, don't launch the daemon by hand: run it as a systemd service so it starts on boot, restarts on crash, and logs cleanly. A small unit file with Restart=on-failure and a dedicated monero user is the standard production setup.

ZMQ vs. polling

Your application needs to know when something changes on chain. There are two ways to find out. The simple way is polling: call get_info or refresh your wallet on a timer and look for new blocks. It works but wastes cycles and adds latency. The better way is ZeroMQ: with --zmq-pub enabled, the daemon pushes a notification the instant a new block or transaction appears, so your wallet or app can react immediately instead of waiting for the next poll. For responsive payment detection, prefer ZMQ.

Monitoring sync — don't process payments early

This is critical: do not credit any payment until your node is fully synced. A half-synced node hasn't seen recent blocks, so it can't possibly know whether a payment confirmed. Call get_info and compare height against target_height. While the node is catching up, target_height reports where the network is and height trails behind it; once synced, target_height reads 0 and height equals the network tip. Gate your payment logic behind "fully synced" and you avoid a whole class of confirmation bugs.

Pruning

A pruned node (via --prune-blockchain) discards roughly two-thirds of the old block data while still fully validating the chain and serving everything your integration needs. It keeps enough to verify new transactions and check confirmations; it just drops historical ring-signature data it no longer needs to keep. For the vast majority of integrations — payments, confirmations, balance watching — a pruned node is the right default and saves you a great deal of disk.

With a properly configured, fully synced monerod running on localhost, you have a trustworthy foundation. Next you'll learn to actually talk to it.

Next: The Daemon RPC API