XMRig config.json: Pools, Threads and Donate Level

XMRig reads almost everything from one file: config.json. The command line covers the basics, but the JSON file is the way the developers recommend, and it is the only place for per-algorithm thread profiles, backup pools and the HTTP API. This guide is for people who run XMRig on their own CPU and want a config they understand: which pool options matter, how threads are chosen, what the donate level does and how to monitor the miner.

Short answer: start from the official wizard at xmrig.com/wizard or from the config.json that ships in the release archive, fill in url and user for your pool, leave the cpu object on automatic, and do not touch donate-level unless you rebuild the miner from source. Everything else is tuning.

Checked: 28 October 2026 against the official XMRig configuration documentation and the example config in the XMRig repository, for XMRig 6.26.0 (released 28 March 2026). Tested: Not tested yet. We have not run these configs on our own hardware, so we report what the documentation says and give no hashrate figures. Soft4Mining Editorial.

Where XMRig looks for config.json

The documentation lists the search order. The miner uses the first file it finds:

1. the path given with --config or -c on the command line;
2. config.json in the same directory as the miner executable;
3. .xmrig.json or .config/xmrig.json in the user’s home directory;
4. a built-in embedded config.

Every release archive contains an example config.json; the same file is kept in the repository as src/config.json. Two settings decide how the file behaves after you start mining. "watch": true (the default) makes the miner reload the file when it changes on disk, so you can edit pools or thread counts without restarting. "autosave": true (also the default) writes the file back when XMRig generates a new mining profile, for example the first time it meets an algorithm and builds a thread layout for it. If you keep the config under version control or copy it between rigs, be aware that the miner itself edits it.

A minimal working template

This is a trimmed version of the official example with placeholders. Replace YOUR_WALLET_ADDRESS with the string your pool expects in the user field, and the pool address with the one from your pool’s getting-started page. Keep it valid JSON: double quotes, no comments, no trailing comma after the last item.

{
    "autosave": true,
    "cpu": {
        "enabled": true,
        "huge-pages": true,
        "hw-aes": null,
        "priority": null,
        "max-threads-hint": 100
    },
    "opencl": { "enabled": false },
    "cuda": { "enabled": false },
    "donate-level": 1,
    "log-file": null,
    "pools": [
        {
            "url": "POOL_HOST:PORT",
            "user": "YOUR_WALLET_ADDRESS",
            "pass": "x",
            "rig-id": "rig01",
            "keepalive": true,
            "tls": false,
            "enabled": true
        },
        {
            "url": "BACKUP_POOL_HOST:PORT",
            "user": "YOUR_WALLET_ADDRESS",
            "pass": "x",
            "rig-id": "rig01",
            "keepalive": true,
            "enabled": true
        }
    ],
    "print-time": 60,
    "health-print-time": 60,
    "retries": 5,
    "retry-pause": 5,
    "http": {
        "enabled": false,
        "host": "127.0.0.1",
        "port": 0,
        "access-token": null,
        "restricted": true
    }
}

Compared with the shipped example, this template only changes the pool entries and turns keepalive on. The GPU backends stay disabled because this guide is about CPU mining; the NVIDIA backend also needs the separate CUDA plugin.

The pools section

pools is an array. The documentation states that the first enabled pool is the primary one and the rest are backups, and that at least one enabled, valid pool is required. If the primary pool stops answering, XMRig retries retries times (default 5) with a retry-pause of 5 seconds between attempts, then moves to the next pool. The options of one pool object, with the defaults from the documentation:

Three practical notes. First, use the pool’s TLS port and "tls": true when the pool offers one; it costs nothing on a CPU miner. Second, rig-id only works if the pool supports it; many pools read the worker name from pass or from a suffix in user instead, so follow the pool’s own instructions. Third, never put a second miner’s wallet in a backup pool entry by accident: a copied template with the wrong user mines for someone else when the primary pool fails.

Pool-specific user strings

• Classic Monero pools: user is your wallet address, sometimes followed by a dot or plus sign and the worker name. Check the pool’s help page for the exact separator.
• unMineable: the RandomX endpoint is rx.unmineable.com, port 3333 for plain TCP and 443 for SSL, and the service builds the user string for you on its Advanced Setup page, because it encodes the payout coin and your address. The service takes a 1% platform fee on top of what the miner itself does.
• Kryptex Pool: Kryptex publishes pool addresses and the account-based user value in its own instructions for third-party miners; the desktop app does not need a config.json at all.
• NiceHash: set "nicehash": true in that pool entry only. Leaving it on for an ordinary pool breaks the connection.

Threads: let XMRig generate them, then adjust

On first start XMRig builds a thread layout for the algorithm it is about to mine and, with autosave on, writes it into the cpu object. The layout appears under a key named after the algorithm, for example "rx" for RandomX, "cn" for CryptoNight, and "*" as a fallback for anything without its own profile. Two formats are documented:

• Short array: one number per thread, each number being the CPU core that thread is pinned to, -1 for no affinity. Example: "rx": [0, 2, 4, 6]. This is the default form for RandomX and Argon2, whose maximum intensity is 1.
• Array of pairs: [intensity, affinity] per thread, intensity 1 to 5. Used by CryptoNight variants that can run more than one hash per thread.

The shared options in the cpu object are what most people need to touch:

• "max-threads-hint": 100 is a percentage hint used only when the miner generates a profile; it has no effect once the profile exists. Lower it, delete the generated "rx" block and restart to get a smaller layout.
• "priority": null sets thread priority from 1 (lowest) to 5. The documentation warns that values above 2 can make the PC unresponsive. null leaves priority alone.
• "yield": true favours system responsiveness; false favours maximum hashrate.
• "huge-pages": true and "huge-pages-jit": false control large memory pages; if the log shows huge pages at 0% see our guide to XMRig huge pages and MSR.
• "hw-aes": null auto-detects hardware AES. Forcing it on a CPU that lacks it crashes the miner.
• "asm": true picks assembly optimisations automatically; it accepts "intel", "ryzen" or "bulldozer" to override.

Two things the documentation makes clear. The default generated layout uses fewer threads than you have cores on many CPUs, because RandomX is sized by cache, not by core count: that is expected. And a thread count set on the command line with -t is a quick test, not a tuning tool, because it ignores affinity; for a permanent layout, edit the array in the config.

Donate level: what it is and what you can change

"donate-level": 1 is the developer donation. The command-line documentation describes the default as 1%, which XMRig implements as one minute of mining for the developers in every 100 minutes. The configuration documentation is explicit about the floor: official binaries do not allow a donation level below 1%, and if you want zero donation you must edit the donate.h file and recompile the miner from source. Setting "donate-level": 0 in the config of an official build does not give you 0%.

"donate-over-proxy": 1 matters only if you run XMRig behind xmrig-proxy; it moves the donation handling to the proxy. If you do not use the proxy, leave it at the default.

Two honest points for people who are annoyed by the fee. Builds that advertise “0% dev fee” from unofficial sources cannot be verified by checksum against the project’s releases, and modified miners are a common way to spread malware; our XMRig page explains how to verify the official SHA-256 sums. And the fee does not change which pool or wallet is in your file: donation mining happens on the developers’ pool for that minute, then returns to yours.

HTTP API for monitoring

The built-in API is off by default. The http object has five keys: enabled (default false), host (default 127.0.0.1, local access only; 0.0.0.0 binds to every IPv4 address), port (default 0, which means a random port on every start, so set a fixed one), access-token (default null) and restricted (default true). Full access, including changing the config over the API, is only possible when an access token is set. The api object adds id and worker-id; without a worker ID the miner reports its hostname. For a rig you monitor from another machine, bind to the LAN address, set a port and a long token, and keep restricted at true unless you need remote config changes.

Logging and behaviour options worth knowing

• "print-time": 60 prints the hashrate report every 60 seconds; "health-print-time": 60 does the same for the health report.
• "log-file": null writes all output to a file when you give a path. "verbose": 0 raises log detail when set above 0; "colors": true can be turned off for plain log files. "syslog": false sends messages to the system log on Linux and is ignored on Windows.
• "background": false runs the miner in the background instead of the console.
• "pause-on-battery": false and "pause-on-active": false pause mining on battery power or while someone is using the computer; the second accepts a number of idle seconds, and true means 60 seconds. It works on Windows and macOS only.
• "dmi": true reads motherboard and memory information for the startup summary; disable it if you prefer the miner not to read SMBIOS data.

Mistakes we see most often

1. Invalid JSON. A trailing comma, a missing quote or a comment line stops the miner from reading the file, and it falls back to the next location in the search order, sometimes the embedded config. Validate the file in any JSON checker before starting.
2. Two sources of truth. Mixing command-line flags with a config file makes it hard to know which setting is live. Pick the file and start the miner with no extra flags.
3. Wrong worker field. Putting the worker name into pass when the pool expects it in user, or the other way round. The pool’s dashboard will show an unnamed rig or none at all.
4. Donate level edited to 0. It does nothing in official builds, see above.
5. A random API port. "port": 0 changes on every start, so your monitoring tool loses the miner. Set a fixed port.
6. Autosave surprises. The miner rewrites the file with the generated thread profile. If you edit max-threads-hint afterwards, nothing changes until you delete the generated profile.

For GPU rigs the picture is different: miners such as Rigel or OneZeroMiner use their own command-line syntax, and one-click tools in our GPU mining software guide hide the config entirely. XMRig’s config.json is specific to XMRig and xmrig-proxy.

FAQ

Where is the XMRig config file on Windows?

Unless you pass -c, it is config.json next to xmrig.exe. If that file is missing, XMRig checks .xmrig.json and .config/xmrig.json in your user folder, then uses its embedded defaults.

Is there an official XMRig config generator?

Yes. The configuration wizard at xmrig.com/wizard produces an initial minimal config file; the documentation links to it from the config overview. Download the result and complete it by hand if you need the API or thread tuning.

How do I add a backup pool?

Add a second object to the pools array with "enabled": true. The first enabled entry is the primary; XMRig switches to the next one after the number of failed attempts set in retries.

Can I set donate-level to 0?

Not in the official binaries. The documented minimum is 1%; zero requires editing donate.h and compiling XMRig yourself.

How many threads should XMRig use?

Let it generate the profile first. RandomX threads are sized by CPU cache, so the generated count is often below the core count. Use max-threads-hint to shrink the layout, or edit the affinity array directly, and change one thing at a time.

Why does my config.json keep changing by itself?

Because autosave is on. XMRig writes generated mining profiles back to the file. Set "autosave": false if you want the file left exactly as you wrote it.

Sources: xmrig.com/docs/miner/config (overview and search order), and its Network, Pool, CPU, API, Logging and Misc pages; github.com/xmrig/xmrig: src/config.json example and release 6.26.0 (28 March 2026); xmrig.com/docs/miner/command-line-options; unmineable.com RandomX endpoints. Fee and pool details are as published by each service on 28 October 2026 and may change.

Last updated: 28 October 2026 · soft4mining editorial team. Licence, version and platform details are checked against each developer's official documentation.