Monero’s privacy model has undergone significant changes in 2025 and 2026, with the introduction of new transaction protocols and the upcoming FCMP++ hard fork fundamentally altering how the network protects user data. If you are running a wallet, a node, or mining XMR, understanding these changes matters because they affect transaction size, fee structures, and the privacy guarantees your transactions actually provide.
This guide breaks down the current state of Monero’s transaction privacy stack, what changed with the recent protocol upgrades, and what the FCMP++ fork means for users and operators in practical terms.
The foundations: ring signatures and stealth addresses
Monero’s privacy has always relied on three cryptographic primitives working together. Understanding what each does is necessary to understand what the recent changes actually improved.
Ring signatures are the mechanism that obscures which output in a transaction is the real sender. When you spend XMR, your wallet selects a set of decoy outputs from the blockchain to mix with your real input. An observer cannot determine which of the ring members is the actual spender. The ring size — the number of decoys — directly affects the strength of this protection. Monero has adjusted this parameter multiple times, and the current implementation uses a ring size that balances privacy against transaction size.
Stealth addresses protect the recipient. When someone sends you XMR, the transaction is recorded on the blockchain against a one-time public key derived from your address. Only you can produce the private key that corresponds to that one-time address. This means that even someone watching the blockchain cannot link transactions to your public address — every payment to you appears to go to a different, unlinkable address.
Pedersen commitments and range proofs hide the transaction amount. The network verifies that the inputs equal the outputs (conservation of value) and that all amounts are positive (no negative outputs), but the actual values are hidden behind cryptographic commitments. The range proof is the mathematical proof that the amounts are within a valid range, without revealing the amounts themselves. This is where the 2025 changes had the biggest impact.
What changed in 2025: the transaction size reduction
In early 2025, Monero activated a protocol upgrade that reduced transaction sizes by approximately 28% while maintaining the same privacy guarantees. The change came from improvements to the range proof construction — specifically, moving to a more efficient proof system that produces smaller proofs for the same level of privacy.
The practical effects were:
- Lower fees per transaction — because transaction size directly drives fee cost (fees are calculated per byte), smaller transactions cost less to send
- Higher effective throughput — more transactions fit in each block, reducing mempool congestion during high-usage periods
- Reduced blockchain bloat — slower growth of the blockchain on disk, which lowers the barrier to running a full node
What did not change was the privacy level. The ring size, the stealth address mechanism, and the unlinkability of transactions remained the same. The upgrade was a pure efficiency improvement — the same privacy for fewer bytes. This is an important distinction because some users assumed that smaller transactions meant weaker privacy, which is not the case.
FCMP++: what the upcoming hard fork changes
The FCMP++ (Full Chain Membership Proofs) upgrade is the most significant change to Monero’s privacy model since the original implementation of RingCT. It is scheduled for mid-2026 and is already running on testnet. Understanding what it changes requires understanding the limitation it addresses.
The current ring signature model has a fundamental weakness: the privacy provided by ring signatures is statistical, not absolute. If an adversary can eliminate decoys through side-channel analysis — for example, by analyzing the timing of transactions, by correlating outputs across multiple transactions, or by using chain analysis tools that track wallet behavior over time — the effective anonymity set shrinks. With a ring size of 16, sophisticated analysis can sometimes reduce the real probability of identifying the sender from 1/16 to something significantly higher.
FCMP++ addresses this by replacing ring signatures with a different cryptographic construction: full chain membership proofs. Instead of selecting a small ring of decoys, the proof system demonstrates that the transaction input is one of all outputs in the blockchain, without revealing which one. The anonymity set becomes the entire set of outputs ever created — not a small ring of 16.
This is a qualitative change, not a quantitative one. The privacy guarantee moves from “one of sixteen, modulo side-channel analysis” to “one of all outputs, with no meaningful way to narrow the set.” The cryptographic cost is real — the proofs are larger and take longer to generate — but the privacy improvement is fundamental.
For users, the practical implications are:
- Transaction generation will take longer — the proof construction is computationally heavier, meaning wallet software will take more time to create a transaction. This is typically seconds, not minutes, but it is noticeable on low-power devices.
- Transaction size will increase — the proofs are larger than current ring signatures, even with the 2025 efficiency improvements. This means higher fees per transaction, at least until further optimization.
- Node operators must upgrade — the hard fork requires all nodes to update to compatible software. Nodes running old software will be forked off the network. If you are running a node, you should track the testnet and upgrade when the stable release is published.
- Wallet software must be updated — wallets need to implement the new proof generation. Monero’s reference wallet (monero-wallet) and the major third-party wallets (Feather, Cake Wallet) have indicated support, but you should verify your wallet is compatible before the fork.
What this means for node operators
If you are running a Monero node — whether a full node, a pruned node, or a node on dedicated hardware like a Raspberry Pi — the FCMP++ fork requires preparation.
Software upgrade: The monerod daemon will require an update to handle the new transaction format. Running an outdated node after the fork means you will be on a different chain, which is useless. The Monero development team publishes release candidates well in advance of the fork height — you should test your node against testnet before the fork, not on the day of.
Storage requirements: The blockchain size has been a growing concern for node operators. As of mid-2026, the Monero blockchain is approximately 180 GB for a full node and 90 GB for a pruned node. The FCMP++ proofs will increase the rate of blockchain growth, because the new transactions are larger. If you are running a full node, you should plan for at least 250 GB of free space. Pruned nodes are less affected but should still plan for growth.
Network configuration: Node operators should verify that their network configuration is correct before the fork. This includes the standard P2P port (18080 for mainnet), the RPC port (18081, which should be restricted to localhost), and any broadcast or relay settings. After the fork, the network will go through a period of adjustment as nodes upgrade — during this period, peer connectivity may be lower than normal.
Tor and I2P: If you are running your node with Tor hidden services or I2P for transport privacy, you should verify that the configuration is compatible with the new daemon version before the fork. The Tor/I2P integration has changed in recent monerod releases, and the configuration files are not always backward-compatible.
Wallet security in the FCMP++ transition
The period around a hard fork is when users are most vulnerable to theft, scams, and loss of funds. The reasons are predictable: users update wallet software, move funds to new wallets, or follow instructions from fake “upgrade guides” that are actually phishing attempts.
Security measures to take before the fork:
- Back up your seed phrase — not on a computer, not in a cloud service, not in a password manager that syncs to the cloud. Paper or metal, stored offline, in a location you control. If your wallet software is compromised during the upgrade, your seed phrase is the only way to recover your funds.
- Verify wallet software from the official source — download wallets only from the official Monero website (getmonero.org) or the official GitHub repository. Verify the GPG signature of the download. The Monero project signs all releases with a GPG key that is published on the project’s website. If you cannot verify the signature, do not install the software.
- Do not enter your seed phrase into any “upgrade tool” or “migration assistant” — the official wallet software will never ask you to enter your seed phrase into a web form. Any site that asks for your seed phrase is a scam, full stop.
- Test with a small amount first — after upgrading your wallet, send a small test transaction to verify that the new software works correctly before moving larger amounts.
Mining considerations
The FCMP++ fork does not directly change the mining algorithm — Monero uses RandomX, which is a CPU-oriented proof-of-work algorithm designed to be resistant to ASIC mining. However, there are second-order effects that miners should be aware of.
Block reward: Monero’s block reward follows a fixed emission curve that decreases over time. The fork does not change the emission schedule, but transaction fees may change because the new transaction format affects the fee market. Miners should monitor the fee structure on testnet to understand the post-fork economics.
P2Pool: If you are mining through P2Pool (the decentralized mining pool), you should verify that your P2Pool node is compatible with the new monerod version before the fork. P2Pool relies on the daemon’s RPC interface, and changes to the RPC API can break compatibility. The P2Pool development team typically releases a compatible version in sync with monerod releases.
ASIC resistance: RandomX has proven effective at keeping ASICs off the Monero network, and the FCMP++ fork does not change the proof-of-work algorithm. However, the fork does change the transaction validation logic, which means that ASIC manufacturers who had built transaction-validation hardware (rather than pure hash-rate hardware) may need to update their firmware.
Practical recommendations for the transition period
Based on past Monero hard forks (there have been several), the following timeline is typical:
- 4-8 weeks before fork: Testnet is active and the new wallet software is available for testing. This is the time to test your setup — node, wallet, mining configuration — on testnet. Do not wait until the fork.
- 2-4 weeks before fork: Exchanges, pools, and service providers announce their upgrade plans. If you use a custodial service, verify their upgrade timeline. Withdraw funds to a non-custodial wallet before the fork if you have any concern about the service’s upgrade readiness.
- 1 week before fork: Stop making transactions if you do not need to. The fork will happen at a specific block height, not a specific time. After the fork, there is a period of reduced liquidity and peer connectivity as the network converges.
- Fork day: Do not transact. Wait for network convergence. Verify that your node is on the correct chain. Check block explorers and community resources to confirm the fork proceeded smoothly.
- 1-2 weeks after fork: Network stabilizes. Liquidity returns to exchanges. At this point, resume normal transaction patterns.
What stays the same
Some things do not change with FCMP++. Your seed phrase works the same way. Your private keys are the same. Your addresses are the same. The network is the same network. The fork changes the transaction format and the proof system, not the wallet infrastructure or the key management.
What also does not change is the fundamental advice for Monero users: run your own node, use a non-custodial wallet, keep your seed phrase offline, verify your downloads, and do not trust any service that asks you to surrender your private keys.
The FCMP++ upgrade is a meaningful improvement to Monero’s privacy model, but it is not a panacea. Transaction analysis will continue to evolve. Network-level surveillance is a real threat. And the most common way users lose their XMR is not through a cryptographic break — it is through social engineering, phishing, and poor operational security. The cryptographic privacy is the easy part. The hard part is the human layer, and no protocol upgrade fixes that.
For the latest information on the FCMP++ fork timeline, testnet status, and wallet compatibility, check the official Monero project channels: the getmonero.org website, the Monero GitHub repository, and the moderated Monero community channels. Do not rely on secondary sources for fork-related information — verify everything against the official project channels.