Monero Mining

What Mining Actually Costs You in Privacy

Mining is usually framed as an accounting question. Hashrate in, electricity out, profit or loss. The accounting is the easy part. The part that follows you around is that joining a pool hands one company a durable link between the address your coins land in and the network you sent work from.

The pool sees your payout address and your IP on the same connection

This is not an inference from how pools behave. It is an assignment statement in the pool software. SupportXMR states in its own site footer that it runs nodejs-pool, and SupportXMR was 32.53% of Monero's hashrate on the verification date. That project's lib/pool.js builds a per-connection log string:^[1]

this.logString = this.address + " ID: " + this.identifier + " IP: " + this.ipAddress;

The address comes out of the stratum login. The code comments the username field as <address in BTC or XMR>.<Difficulty> and assigns this.address and this.payout from it. The IP arrives separately from the socket's remote address. Both end up on the same object, in the same line.^[1]

It is stored, not only printed. The shipped schema in deployment/base.sql defines a bans table whose rows pair ip_address with mining_address and an insert timestamp, and the schema contains no retention policy of any kind. The users table stores the username, which is the payout address, plus an email address whenever a miner supplies one in the password field.^[2]

Be precise about the scope, because over-claiming here is easy. In the base schema, bans is the only table that persists a miner's IP address. The ip_address column on the ports table is the pool's own bind address, not yours.^[2]

A third identifier nobody warns you about

XMRig's stratum login carries an agent field next to the address. It is assembled from the build environment and reports the miner name and version, the operating system, the CPU architecture, the libuv version, and the compiler and its version.^[3] nodejs-pool reads that field on login, in the same session that already holds your address and your IP.^[1] Three identifiers, one connection, one operator. The agent string is stable until you upgrade something, which makes it a decent reconnection fingerprint on its own.

The two largest pools publish no privacy policy

SupportXMR and Nanopool together accounted for 56.75% of network hashrate. On both sites, /privacy, /privacy-policy and /terms return 404, and the rendered navigation carries no legal links at all. No policy was found for C3Pool or MoneroOcean either. HashVault was re-checked directly on 2026-08-05: its /privacy, /privacy-policy, /terms and /tos paths all return the application shell rather than a document, none of its seventeen locale files contains a legal string, and its footer carries no legal link. No policy was found there either.

Kryptex is the exception in the top five, and reading it is more sobering than finding nothing. The policy, last updated 2024-07-09, says it collects "Your Device's Internet Protocol address (e.g. IP address)" and "unique device identifiers", commits to no retention period at all, and states that it "may be required to disclose Your Personal Data ... in response to valid requests by public authorities".^[4] A published policy does not buy you a better outcome. It documents the same one.

Three pools hold most of the network

Shares at 2026-08-05T04:25:43Z, cross-checked three ways: an aggregator feed, each pool's own API, and on-chain block attribution. The three methods agreed within 0.4 to 2.7 percentage points, and SupportXMR's share of the last thousand blocks (34.0%) matched its reported hashrate share.^[5]

• SupportXMR: 32.53%
• Nanopool: 24.22%
• HashVault: 10.38%
• P2Pool (main sidechain): 8.22%
• Kryptex: 8.86%
• MoneroOcean: 3.45%
• C3Pool: 3.29%

Top three combined: 67.14%. All P2Pool sidechains combined: 8.70%.

The 30% line, from Monero's own issue tracker

The number everyone repeats is 51%. Monero's own research contributor Rucknium, in an issue opened on the monero-project repository on 2025-08-31 and still open, puts the practical bar much lower:^[6]

"An attacker with minority hashpower can still occasionally cause deep blockchain re-organizations. For example, a determined attacker with 30% hashpower share could cause a 10-block re-org about three times per day."

SupportXMR is above that share today, on its own, without doing anything hostile. Concentration is not a future risk on this chain. It is the current configuration.

The same issue shows how few parties set policy. The emergency defense it proposes would need Nanopool, MoneroOcean, SupportXMR and HashVault to enforce DNS checkpoints, and it concedes that "Monero's blockchain consensus protocol would temporarily be less decentralized" if they did.^[6] Those four pools held 70.59% between them.

What a concentrated chain looks like when it breaks

In August 2025, Qubic announced it had taken 51% of Monero. Monero's own orphan-inclusive measurement disputes the headline: "The maximum share of blocks mined by Qubic in any 6-hour period was about 40 percent".^[6] The damage is documented separately and is not in dispute. On 2025-09-14 a 20-block alternate chain orphaned 18 blocks; by 2025-09-17 the reconstruction counted 115 invalidated transactions and 58 detected double-spends.^[7] Qubic wound down its Monero mining on 2026-04-15.^[8]

Note what that means for a miner rather than for a trader. A re-org does not just move price. It un-pays blocks, and pool shares mined against an orphaned chain are shares you worked for and did not get.

This has happened before

MineXMR reached roughly 50% of Monero's hashrate in February 2022. The Block reported it at 44%, with "almost twice as much mining power as the second and third largest Monero pools combined".^[9] The pool's entire mitigation was raising its fee from 1% to 1.1% to nudge miners elsewhere. It shut down in August 2022, pointing its users at P2Pool.^[10] HashVault ran a similar spike in February 2023, climbing from around 650 MH/s to roughly 1.8 GH/s (Monero Observer) before settling near a third of the network.

getmonero.org's own mining page is blunt about why any of this matters: "Too many people mining on a single pool might lead on the pool having >50% of the total hashrate, which is dangerous". The same page encourages solo mining and P2Pool.^[11]

P2Pool is a different trade, not a strictly better one

P2Pool deletes the custodian. Its README says there is no pool wallet and funds are never in custody, and describes what a centralized pool holds over you: "the pool admin gets full power over your hashrate and your unpaid funds".^[12]

It also costs you something the custodial pools do not. From the same README: "It is highly recommended to create a new mainnet wallet for P2Pool mining because wallet addresses are public on P2Pool."^[12] On a centralized pool, one operator learns your address and your IP. On P2Pool, your address sits in a public sidechain that anyone can read, and your node talks to peers directly rather than to one endpoint. That is a different exposure, aimed at a different adversary. Pick the one that matches who you are actually worried about, and use a wallet you created for this and nothing else either way.

Estimate Your Hashrate Before You Spend Anything

The single most expensive mistake in mining is buying hardware against a number you did not measure. Monero makes this easier than most chains, because the algorithm removes almost all the hardware choices for you.

RandomX is a CPU algorithm on purpose

Monero activated RandomX on 2019-11-30.^[13] The reference implementation describes it as "a proof-of-work (PoW) algorithm that is optimized for general-purpose CPUs" which "uses random code execution (hence the name) together with several memory-hard techniques to minimize the efficiency advantage of specialized hardware", and adds that "GPUs are at a disadvantage when running RandomX since the algorithm was designed to be efficient on CPUs".^[14]

Note the careful phrasing there. The Monero Project sometimes states this more strongly, but the algorithm's own documentation claims to minimize the advantage of specialized hardware, not to make it impossible.

The design document explains the mechanism better than any summary of it: conventional hashes are a fixed sequence of operations, and "typical cryptographic hashing functions do not represent suitable work for the CPU because their only input is data, while the sequence of operations is fixed and can be performed more efficiently by a specialized integrated circuit". RandomX generates a different program for every hash, so there is no fixed circuit to etch.^[15]

The economics follow from that. An ASIC would need more than 2 GiB of on-chip SRAM, which the design document calls "questionable, at least in the near future", and the cheaper 256 MiB light mode is deliberately poisoned: "SuperscalarHash was designed to burn as much power as possible while the CPU is waiting for data to be loaded from DRAM".^[15] FPGAs are excluded for a separate reason: "RandomX generates multiple unique programs for every hash, so FPGAs cannot dynamically reconfigure their circuitry".^[14]

Four independent teams (Trail of Bits, X41 D-SEC, Kudelski Security and QuarksLab) reviewed RandomX between May and August 2019, and none reported a critical vulnerability.^[14]

Practical consequence: your existing desktop CPU is the correct hardware to test with. There is nothing to buy first.

Correct the 2 GB per thread myth first

The most repeated error on this topic is that RandomX needs 2 GB of memory for every mining thread. It does not. Fast mode allocates a 2080 MiB dataset once, as shared memory that every thread reads.^[14] What is genuinely per-thread is cache: 16 KiB of L1, 256 KiB of L2 and 2 MiB of L3.^[16]

That last figure is the one that decides your thread count.

Total L3 cache divided by 2 MiB is your realistic thread count. On most modern CPUs that number is lower than the core count, which is why a miner left on defaults will refuse to use every thread. XMRig says so in as many words: "CPU cache requirements is the main reason why the miner not use all threads on most CPUs (very popular question)".^[17]

The rest of the requirements come from the same reference: a 64-bit CPU, an IEEE-754 floating point unit, hardware AES, large page support, and at least 2.5 GiB of free memory per NUMA node. Memory bandwidth then caps the result, because "DDR3 memory is limited to about 1500-2000 H/s per channel" while "DDR4 memory is limited to about 4000-6000 H/s per channel".^[14]

Two settings worth more than any hardware upgrade

Huge pages. XMRig's documentation puts the typical gain at 20-30%, and "for RandomX it can increase performance up to 50%". On Linux 5.2.0 and later the miner configures them automatically when run as root; otherwise reserve them yourself with sudo sysctl -w vm.nr_hugepages=1280. On Windows, run the miner as Administrator once and then reboot. Confirm it worked by looking for huge pages 100% in the startup output.^[18]

The MSR mod. RandomX defeats the CPU's prefetchers by design: "RandomX accesses memory randomly, so prefetchers just don't work". XMRig writes model-specific registers to compensate, and configures this automatically with root or administrator rights. The success line is msr register values for "intel" preset has been set successfully.^[19]

Read the second one as a trade, not a free win. On some systems it requires disabling Secure Boot, which is a genuine reduction in your machine's boot integrity, not a checkbox. If that machine also does anything you care about, do not disable it for a hashrate percentage.

Measure instead of guessing

No hardware numbers are published here on purpose. They rot within months and the live databases are both free and better.

• Other people's results: xmrig.com/benchmark is server-rendered, needs no account and no JavaScript. Filter to your own thread count and prefer entries backed by many samples rather than a single submission.^[20]
• Your own result: run xmrig --bench=1M offline, or xmrig --bench=1M --submit to contribute it. XMRig's own caveat applies first: confirm huge pages 100% and the MSR line, or the "result will be far from the best".^[21]
• Revenue model: whattomine.com takes your hashrate, watts and electricity price and returns difficulty, network hashrate, revenue and cost.^[22] One warning: the XMR page's hardware selector was observed defaulting to "Bitmain Antminer X9". There is no Monero ASIC. Clear it and enter your own H/s and your own measured watts.
• P2Pool sizing: p2pool.observer/api/pool_info and its /api/network/stats and /calculate-share-time endpoints work without JavaScript.^[23] Most of that site's HTML answers non-JavaScript clients with status 418, so use the API paths rather than the front page.
• Live difficulty: localmonero.co/blocks is server-rendered and quick to read, but treat it as fragile. LocalMonero closed its marketplace in 2024, and the block explorer is a leftover.

Outbound vendor link. We are not currently an affiliate.

The four inputs, and why no profit figure belongs here

Profitability is four numbers and one calculator: your measured hashrate, your measured wall-socket watts, your electricity price per kWh, and the network's difficulty against the coin price. Everything else is someone else's hardware and someone else's tariff.

One structural point survives every price move. Your revenue is a share of a denominator that other people keep adding to, so it falls whenever the network grows faster than your rig does. Your electricity cost per kWh does not fall at all. Mining at home is a bet on the ratio between those two, not on the coin.

Laptops are the wrong tool, and here is the honest version of why

The documented reasons are enough on their own. RandomX's reference implementation notes that "efficient mining requires more than 2 GiB of memory, which also disqualifies many low-end machines", and XMRig warns that on Windows "4GB memory may not enough system and miner".^[14][17] Mobile CPUs also tend to ship with fewer MiB of L3 cache than they have cores, which by the divide-by-2 MiB rule above leaves threads idle.

One like-for-like pair, published in 2019, is kept here as a ratio and not as a current figure: a mobile i7-8550U produced 1,700 H/s on four threads while a desktop i9-9900K produced 5,770 H/s on eight. Both numbers are from 2019, measured on 2019-era silicon. Benchmark your own machine before you trust either.

What is not documented anywhere primary: thermal damage, accelerated hardware wear, battery degradation, or any specific throttling figure from sustained mining. Plenty of guides state those confidently. None of them cite anything. What can be said from first principles is narrow and still useful: RandomX holds its threads at full load continuously, while laptop cooling is designed around bursts, so a laptop will spend the session at its thermal limit. Draw your own conclusion from that rather than from a number somebody invented.

Get a Wallet Before You Get a Miner

Mining pays into an address. Choose that address badly and you find out months later, when the coins are already there.

Hardware wallets that actually handle Monero

Device support verified 2026-08-05 against vendor documentation and open issue trackers. Re-check before purchase.

Neither vendor supports Monero in its own desktop application. Trezor states that "Native support in Trezor Suite is currently not available".^[24] Ledger's own coin page tells you to "Connect your Ledger hardware wallet to a compatible third-party wallet".^[25] Whichever device you buy, a third-party wallet is part of the setup.

The Trezor Safe 7, stated accurately

Trezor's learn page still carries a banner saying Monero on the Safe 7 is not yet possible. That banner is out of date: Cake Wallet 6.2.0, released 2026-06-05, added Trezor hardware support for Monero, letting you pair the device to manage, view and sign XMR transactions.^[26]

The open-source desktop toolchain has not followed. Monero GUI cannot support the Safe 7 without implementing Trezor Host Protocol v2, and the maintainer wrote on 2026-07-19 that "so far I have not seen a good solution how we can implement the Trezor host protocol in our C++ codebase". That issue is still open.^[27] Feather's hardware list covers the Model T, Safe 3 and Safe 5, and does not include the Safe 7.

Two open Cake Wallet bugs matter directly to anyone using a Safe 7 as a payout destination. One reports the Safe 7 with XMR behaving like a broken view-only wallet.^[28] The other, filed 2026-08-03, reports a Trezor XMR wallet displaying another wallet's balance and receive address until the app is restarted.^[29] The second is disqualifying for a mining payout address until it is closed. A receive address you cannot trust on screen is not a receive address.

Receiving is safer than sending, and mining is mostly receiving

The known breakages cluster on the signing path, not the receiving path. Ledger Stax has an open issue in which Monero transactions cannot be signed, failing with "Wrong Channel".^[30] The Safe 7's Cake-only path has the problems above. Both break spending. If your hardware wallet exists to accumulate payouts and you plan to move them later from a device you have tested, your exposure is lower than the bug list suggests. That is a reason to plan the spending path deliberately, not a reason to ignore it.

One item to report accurately rather than dramatically: a single reporter alleged that Ledger's Monero app factory-reset a Stax. Another participant could not reproduce it and Ledger never responded. That is an unresolved single-reporter allegation, and it should be treated as one.

Also check vendor documentation, not just getmonero.org. The Monero project's downloads page lists devices in both stale directions: it omits the Stax, Flex and Nano Gen5, which do appear in Ledger's own Monero app manifest, and it still lists the original Nano S, which does not.^[31]

What to buy

Trezor Safe 5, or Safe 3 on a budget. Both work with the open-source desktop wallets, both are current products, and neither depends on the Cake-only path. Buy direct: trezor.io (supply-chain tampering on resold hardware wallets is real; affiliate link, see the disclosure). Longer breakdown: Trezor review. Remember the SLIP10 constraint above before you commit a long-running payout address to it.

Ledger Nano S Plus or Nano X if the SLIP10 lock-in is the dealbreaker for you, accepting Ledger's closed firmware as the trade. Background: Ledger review and hardware wallet comparison.

Outbound vendor link. We are not currently an affiliate.

Software wallets, by platform

Platform and license coverage verified 2026-08-05. Current versions on that date: Monero GUI 0.18.5.2, Monero CLI 0.18.5.1, Cake Wallet 6.4.0, Feather 2.8.1 (released 2025-04-14, with 2.9.0 and 2.9.1 tags pushed and a release imminent).

Feather is the strongest fit for a Linux mining box, on documented attributes rather than taste. Its documentation states that "Feather works with Tor out of the box. You don't have to manually install Tor to use it" and that "Feather releases are bundled with a Tor binary". Keep the nuance the same page states: "By default, Feather routes all network traffic over Tor, except for wallet synchronization".^[32] There is an official Tails AppImage. It is desktop only. The project's domain is featherwallet.org; the hyphenated feather-wallet.org is not the project.

Outbound vendor link. We are not currently an affiliate.

Point payouts at a view-only wallet

This is the single highest-value configuration choice on the page, and it is free. A view-only wallet is "a special type of wallet that can only see incoming transactions. Since it doesn't hold your mnemonic seed and private spend key, it can't sign transactions".^[33]

Set it up so the hardware wallet holds the keys and the mining machine runs only the view-only copy. The mining box can then confirm payouts arrived without holding anything that can spend them, which matters because a mining rig is an always-on, internet-facing machine running a binary you downloaded. View-only wallets are supported in Monero GUI, Monero CLI and Feather.^[33][34]

View-only support for Cake Wallet, Monerujo and Stack Wallet was not verified for this guide. Do not assume it exists because the wallet is otherwise capable.

Install the Miner, Verification First

Mining software is one of the most heavily trojanized categories on the internet, for the obvious reason that a backdoored miner pays someone else while looking exactly like a working one. Verification comes before the download link, deliberately.

Verify the signature, then the hash, in that order

XMRig does publish GPG signatures. Guides that say otherwise are wrong: every release ships a SHA256SUMS file and a detached SHA256SUMS.sig, consistently across recent releases. The public key is published in two places that must agree, at xmrig.com/docs/gpg-key and in the repository, and the documentation's own instruction is that "the public key below must equal to key placed on github". The fingerprint is 9AC4 CEA8 E66E 35A5 C7CD DC1B 446A 5363 8BE9 4409.^[35]

Download the release archive, SHA256SUMS and SHA256SUMS.sig from the GitHub releases page, which is the only official distribution channel. There is no apt repository and no Homebrew formula.^[36] Then:

gpg --verify SHA256SUMS.sig SHA256SUMS
sha256sum -c SHA256SUMS --ignore-missing

A successful run looks like this, and the scary-looking second line is expected:

gpg: Good signature from "XMRig <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
xmrig-6.26.0-linux-static-x64.tar.gz: OK

Learn the difference between the two alarming strings. A WARNING: This key is not certified that accompanies a Good signature is harmless. It only means you have not personally signed the key in your own keyring. A failure looks completely different:

gpg: BAD signature from "XMRig <[email protected]>"
xmrig-6.26.0-windows-x64.zip: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

Either of those means stop and delete the file. Order matters more than most guides admit: verify the signature on SHA256SUMS first, then check the binary against it. Checking a hash whose signature you never verified proves nothing, because whoever replaced the binary could replace the hash file too. The Monero project's own advanced verification guide walks through the same reasoning if you want a second phrasing of it.^[37]

The current XMRig release at the verification date was v6.26.0, published 2026-03-28.^[36]

P2Pool signs its releases too, but differently

P2Pool publishes a single clearsigned sha256sums.txt.asc rather than a detached signature. Its key appears in three independent locations that all agree on the fingerprint 1FCA AB4D 3DC3 310D 16CB D508 C47F 82B5 4DA8 7ADF: the Monero project's gitian signing keys, p2pool.io and the maintainer's GitHub key endpoint.^[38]

One trap that makes people think verification failed when it did not: the clearsigned format is not compatible with sha256sum -c, which reports no properly formatted checksum lines found. Verify the signature with GPG, then compare the hashes by eye. Pre-releases ship no signed sums at all, so stick to tagged releases.

Worth knowing when you compare the two projects: P2Pool has had reproducible builds since v4.9, so independent parties can rebuild a release and confirm the binary matches the source. XMRig has no equivalent. That is a real supply-chain asymmetry between the two downloads on this page.

Linux

Use the static build, xmrig-6.26.0-linux-static-x64.tar.gz. It avoids the glibc and libssl version mismatches that break dynamically linked builds across distributions, and it is the build P2Pool's own documentation names.

The MSR mod needs root for a concrete reason rather than a cosmetic one. XMRig loads a kernel module with modprobe msr allow_writes=on and then writes to /dev/cpu/N/msr. That is direct access to model-specific registers, which is exactly the privilege it sounds like. Decide whether this machine should have that enabled before you type sudo.

A minimal first run, with no configuration file and therefore no braces to get wrong:

xmrig -o POOL_HOST:PORT -u YOUR_WALLET_ADDRESS --dry-run

--dry-run tests the configuration and exits, which is the right way to find a typo in a wallet address before it becomes a payout you never receive. Drop the flag once it reports what you expect.^[39]

Windows

Use xmrig-6.26.0-windows-x64.zip from the same releases page and run the same verification. XMRig publishes both an MSVC and a GCC Windows build; which one a typical user should prefer is not documented anywhere official, so this guide does not assert one.

Expect antivirus alerts. XMRig itself publishes no statement about false positives, but P2Pool's release notes address it directly: "Some antiviruses and firewalls may flag any Monero-related executables and archives, including P2Pool, as malware... always check SHA256 sums".^[38] Note what that advice does and does not say. It says verify the hash. It does not say add an antivirus exclusion, and neither does this guide, because a blanket exclusion on the directory where you keep downloaded binaries is a bad trade in every other respect.

The Windows MSR mod carries a specific risk worth stating plainly: it uses WinRing0, a signed third-party kernel driver that grants arbitrary model-specific register access. Signed vulnerable drivers are a known attack technique, and installing one to gain a hashrate percentage is a security decision, not a tuning decision.

Separately, a scheduler bug in Windows 10 build 1903 and later can collapse RandomX hashrate. The documented workaround is to stop pinning threads to specific cores.

macOS

XMRig's macOS documentation endorses the prebuilt binary rather than building from source, so verify and run that.^[40]

Apple Silicon is structurally slower at RandomX and no amount of tuning fixes it. XMRig's documentation is explicit: "Enforced Hardened Runtime, it means RandomX JIT compiler can work only in slow secure mode. Any kind of CPU affinity not supported. Huge pages not supported." All three of the optimizations that matter are unavailable.^[40] Benchmark before you plan anything around a Mac.

Gatekeeper handling for the downloaded binary is not documented by the project, so no command is given here. Treat it as ordinary macOS quarantine behavior and use whatever approach you already trust for unsigned tools.

The donation you cannot turn off

XMRig mines for its developers by default and the floor is not zero: "Official binaries don't allow donation level below 1%". Removing it means editing donate.h and recompiling, which also means giving up the signed binary you just verified. Budget the 1% and move on, or accept the trade of building yourself.

Solo, Pool or P2Pool

Solo

Solo mining means your own monerod finds blocks and the whole reward is yours. Nobody learns your payout address, because nobody is between you and the chain. getmonero.org encourages it.^[11] The catch is arithmetic rather than privacy: rewards arrive only when you actually find a block, so a home CPU is buying a lottery ticket with a very long expected wait. It is the right answer for privacy and the wrong answer for cash flow, and you should decide which one you are optimizing before you start. If you go this route, start with a fully synced node: see the Monero node setup guide.

Centralized pools

A pool smooths the variance by paying you for shares instead of blocks, and the price is everything in the first section of this page. The mechanics are the same everywhere: point the miner at the pool's host and port, put your wallet address in the user field, and the pool credits shares against it.^[41][42]

If you use one, use a wallet address created for mining and nothing else, so the address the pool logs never touches anything else you do.

P2Pool

P2Pool pays you from the Monero block itself. Payouts are coinbase outputs, so there is no pool wallet, no balance held on your behalf and no withdrawal step. The PPLNS window runs up to 2,160 blocks, roughly six hours, and the minimum payout works out to about the block reward divided by that window, near 0.00027 XMR.^[12]

It requires your own synced monerod, v0.18.0.0 at the floor and v0.18.5.1 or later recommended by the current release notes. The setup order matters:^[12][43]

1. Reserve huge pages: sudo sysctl vm.nr_hugepages=3072
2. Open port 18080 for the node, plus the P2Pool port for your sidechain (37889, 37888 or 37890)
3. Start the node with ZMQ, which "is required for P2Pool to work properly": monerod --zmq-pub tcp://127.0.0.1:18083 --out-peers 32 --in-peers 64, using --out-peers 8 --in-peers 16 instead if your upload is under 10 Mbit
4. Start P2Pool: ./p2pool --host 127.0.0.1 --wallet YOUR_ADDRESS --mini
5. Wait five to ten minutes for it to sync the sidechain
6. Point the miner at it: ./xmrig -o 127.0.0.1:3333

Which sidechain to join is a sizing question. P2Pool's documentation states that "if P2Pool doesn't have enough hashrate to find Monero blocks faster than every 6 hours on average (~15 MH/s), not all your pool shares will result in a payout".^[12] At the verification date the main chain sat around 451 MH/s and clears that comfortably, mini was around 22.6 MH/s and is close to the line, and nano was around 3.68 MH/s and is below it.^[23] Main or mini, then, not nano.

What is not documented: any per-miner minimum hashrate for P2Pool, and any hashrate cutoff for choosing between main, mini and nano. Various blogs quote precise thresholds. None of them are in the project's documentation, so treat sidechain choice as your own judgement call against the pool-wide figure above.

Two instructions from the project that are easy to skip and expensive to skip. First: "It is highly recommended that you create a separate restricted user account (in your OS) for mining." Second: "It is strongly recommended to synchronize your system clock before you start mining!"^[12]

Running either over Tor

XMRig has supported SOCKS5 natively since v5.7.0, via -x HOST:PORT on the command line, pointing at 9150 for Tor Browser's proxy or 9050 for a Tor daemon.^[44] Three details that are true in the source but absent from the documentation: the miner sends SOCKS5 address type 0x03, so the proxy resolves the pool hostname and there is no DNS leak; authenticated SOCKS5 proxies are not supported, because the client offers only the no-authentication method, so a commercial authenticated endpoint fails with an unexplained connection close; and the mandatory donation traffic goes through the same proxy rather than connecting directly around it.

P2Pool has its own Tor documentation with flags for --socks5, --socks5-proxy-type tor, --no-dns, --no-upnp, --onion-address and --no-clearnet-p2p, and the hidden service must be reachable on port 28722.^[45] It also carries the strongest warning in either project, and it is a warning about metadata rather than about traffic:

"Attention: this also links the onion address with the Monero wallet you use for mining. Create a new onion address when mining through TOR, don't use your existing onion addresses to avoid meta-data leaks."

If you already run hidden services for anything else, that sentence is the whole point. Reusing one turns a mining setup into a link between your mining wallet and everything else that address serves.

VPNs are not covered by any primary documentation in these projects, so no configuration is recommended here. The mechanism is worth reasoning about though: P2Pool accepts inbound peer-to-peer connections, and a VPN without port forwarding leaves you with the same unreachability problem as any other NAT. The project documents --p2p-external-port for exactly that class of setup.^[43]

The pools, side by side

^d Nanopool now contradicts itself: its help article, updated 2026-06-04, states a two hour PPLNS window while its home page still advertises three. The table prints the documented figure. Fees, minimum payouts and hashrate shares verified 2026-08-05 against each pool's own site and API. Pool terms change without notice; re-check before you point hashrate at one.

a. SupportXMR contradicts itself. Its help page states a 0.1 XMR default minimum payout while its own api/config endpoint reports 0.3 XMR. The help page figure is printed above; treat 0.3 XMR as the possible real floor until the pool reconciles them.
b. HashVault's API returns a fee of zero in an unpopulated field, and aggregators repeat that zero. The site itself advertises 0.9%, which is the figure printed above.
c. Kryptex accounts are optional for mining, but account mode enables fiat, card and gift-card withdrawal, which implies an identity-bearing account. Its KYC policy was not verified for this guide.

Two of these pools publish v3 onion services. Both addresses below are well-formed and checksum-valid, and neither was reachability-tested for this guide:

• HashVault: hashvaultsvg2rinvxz7kos77hdfm6zrd5yco3tx2yh2linsmusfwyad.onion
• MoneroOcean: mo2tor2amawhphlrgyaqlrqx7o27jaj7yldnx3t6jip3ow4bujlwz6id.onion

One last reading of that table. The fee column is the number miners compare, and it varies by less than a percentage point across the whole list. The custodial column and the share column are the ones that decide what happens to your address and to the chain, and they vary enormously. Optimizing the first column while ignoring the other two is how a network ends up with three pools holding 67.14% of it.

Related Guides

• Run Your Own Monero Node: the prerequisite for solo mining and for P2Pool
• Monero Setup Guide: wallets and first transactions from scratch
• How Monero Works: ring signatures, stealth addresses and what they hide
• Hardware Wallet Comparison: the device choice in more detail
• Open Source Crypto Wallets: verifiable key storage across vendors
• Blockchain Privacy Reality: what chain analysis actually sees
• Bitcoin to Monero Atomic Swaps: moving value without an exchange account
• Tor Explained: what the SOCKS5 settings above are actually doing

References

1. nodejs-pool: lib/pool.js (stratum login, address and IP handling)
2. nodejs-pool: deployment/base.sql (bans and users tables)
3. XMRig: stratum client source, login agent field
4. Kryptex: Privacy Policy, last updated July 2024
5. MiningPoolStats: Monero pool hashrate distribution feed
6. monero-project/monero issue #10064: mining pool centralization and re-org risk
7. Monero Timeline Sep 14: reconstruction of the September 2025 re-org
8. Qubic: All Hands recap, April 2026
9. The Block: concerns grow over the Monero pool holding 44% of hash rate
10. Monero Observer: MineXMR to shut down, August 2022
11. getmonero.org: Get started mining
12. P2Pool: README (setup, payouts, sidechain thresholds)
13. Moneropedia: RandomX
14. RandomX: README (requirements, memory, audits)
15. RandomX: design notes
16. RandomX: configuration constants (cache and dataset sizes)
17. XMRig: RandomX optimization guide
18. XMRig: huge pages
19. XMRig: MSR mod
20. XMRig: public RandomX benchmark database
21. XMRig: built-in benchmark documentation
22. WhatToMine: XMR RandomX calculator
23. P2Pool Observer: pool_info API endpoint
24. Trezor Learn: Monero (XMR) on Trezor
25. Ledger: Monero wallet support
26. Cake Wallet: release notes, Trezor Monero support added in 6.2.0
27. monero-gui issue #4517: Trezor Host Protocol v2 support
28. Cake Wallet issue #3460: Trezor Safe 7, XMR behaves as view-only
29. Cake Wallet issue #3479: Trezor XMR wallet shows another wallet's address
30. LedgerHQ/app-monero issue #182: Stax cannot sign XMR transactions
31. getmonero.org: downloads and hardware wallet list
32. Feather Wallet docs: Tor support
33. getmonero.org: view-only wallets
34. Feather Wallet docs: create a view-only wallet
35. XMRig: GPG signing key and fingerprint
36. XMRig: official releases and checksums
37. getmonero.org: advanced binary verification guide
38. P2Pool: releases, signed checksums and antivirus notes
39. XMRig: command line options
40. XMRig: macOS build and prebuilt binary notes
41. getmonero.org: how to mine to a pool
42. XMRig: pool configuration reference
43. P2Pool: command line reference
44. XMRig: mining over Tor
45. P2Pool: running over Tor