Monero’s current sender-privacy mechanism is based on ring signatures. When a user spends an output, the transaction points to a group of 16 possible outputs: one is the real one, and the others are decoys. The network verifies that the signature is valid, but should not learn which member of the ring was actually spent.
This scheme has given Monero privacy by default, but it has a fundamental limitation: the anonymity of each spend relies on a relatively small set of candidates and on how well the decoys are selected. Researchers can look for statistical patterns in their age and distribution. FCMP++ proposes changing the underlying approach: instead of selecting a limited group of plausible candidates, the spender proves that the output being spent belongs to a large set of outputs in the blockchain, without revealing which one it is.
Imagine a library where every book has a unique mark. Under Monero’s current scheme, the owner proves: “My book is one of these 16.” The verifier sees all 16 candidates but does not know which one is the real book.
With a full-chain membership proof, the claim would instead be: “I own one of the books in this large library, and I’m authorized to use it.” The verifier is not told which book it is. For Monero, this would remove the reliance on a small, fixed ring and on the decoy-selection algorithm.
“Full chain” does not mean that users become protected against every kind of analysis. It refers to a large set of outputs against which the proof of membership is made. Practical privacy still depends on the protocol as a whole: how the network verifies the right to spend funds, prevents double-spending, and processes transactions.
FCMP stands for Full-Chain Membership Proofs. The “++” indicates that Monero’s proposal includes not only a membership proof but also related functions: Spend Authorization, which confirms the right to spend funds, and Linkability, which allows the network to detect an attempt to spend the same output twice.
This distinction matters because it would be misleading to describe the system simply as “proving that a coin exists somewhere in the blockchain.” A membership proof alone is not enough. The protocol must also verify that the spend is authorized and prevent the same coin from being spent twice. FCMP++ is designed as a replacement for the ring-based mechanism while preserving these essential properties.
The FCMP++ proposal uses a construction based on Curve Trees, a structure for proving membership in large sets. The project description also discusses a technique involving divisors of elliptic curves to make proofs more practical in terms of size and computation. The idea is not to include “a huge list of outputs” in every transaction. The challenge is to prove membership in a large set compactly, without revealing the position of the output being spent.
FCMP++ is not synonymous with Monero’s entire future architecture. The initial direction for full-chain proofs was tied to Seraphis, a broader redesign of the transaction system and key formats. A later version of FCMP++ was proposed as a way to move toward full-chain membership proofs without requiring an immediate migration to Seraphis. This would allow the project to focus on improving sender privacy while developing some additional features—such as new types of view keys and transaction chaining—separately.
That is why it is important to distinguish three things: the cryptographic idea, the specific proposal for Monero, and a finished feature in a wallet. Even if the base protocol can verify a new kind of proof, wallets still need to create transactions correctly, scan the blockchain, and support different ways of storing and signing funds.
The main expected change is the potential for a much larger set of outputs to conceal the real spend. But a larger set does not make privacy “absolute.” It changes one important part of the threat model: instead of a small ring, there would be a proof of membership in a broader set. Transaction timing, network metadata, wallet behavior, and other external information would remain separate concerns.
The new construction also makes implementation more complex. Developers need to verify not only the mathematical correctness of the scheme, but also the code, its behavior during chain reorganizations, the load on nodes, memory requirements, transaction creation in wallets, and compatibility with hardware and multisignature wallets. The project materials also emphasize that additional features may not arrive at the same time as the basic replacement for rings.
It is useful to distinguish the size of the proof from the cost of the system as a whole. Even if a proof is relatively compact, nodes still need to maintain the state required to verify it, and wallets need a way to obtain the data needed to construct it. The FCMP++ proposal describes different options: a wallet could obtain the necessary data from a node or build the relevant structure locally. Each approach involves trade-offs in synchronization speed, network traffic, data storage, and reliance on infrastructure.
As of November 5, 2026, FCMP++ has not been activated on the Monero mainnet. It is being tested on a separate beta stressnet, an experimental network intended to test the code and its behavior under load. In the Monero repository, work on the FCMP++ hard-fork milestone was marked as 73% complete on October 19; in early November, open tasks and changes awaiting review remained. These figures indicate development progress, but do not mean the protocol is ready to launch on mainnet.
The distinction matters: a working test network is a real engineering milestone, but it does not show that the update is already being used by Monero participants. Audits, completion of the integration, wallet testing, and the community’s decision on upgrade rules are also important before a mainnet transition.
Related ideas have appeared in other blockchains, but they are best described as related approaches, not exact copies of FCMP++.
Zcash is one of the closest examples in terms of the general cryptographic idea. In its shielded pool, a transaction uses a proof that a hidden coin belongs to a set of commitment records in a tree, without revealing which record it is. To prevent double-spending, the transaction publishes a special identifier called a nullifier. This scheme became a practical implementation of the approach described in the Zerocash research. But Zcash’s model differs from Monero’s: its privacy relies on proofs within a shielded pool and hides more transaction details, while FCMP++ is intended specifically to replace Monero’s ring-based spending mechanism.
Tornado Cash used a similar cryptographic technique at the Ethereum application level. A smart contract stored commitments in a tree, and a user could prove in zero knowledge that their commitment was in the tree without revealing which one. But this is not privacy built into the base blockchain, nor is it the same problem FCMP++ addresses. Tornado Cash is a separate contract-based pool with its own deposit and withdrawal model, not a new spending mechanism built into the rules of an entire currency.
Firo Lelantus Spark is another close example from the privacy-coin ecosystem. It uses one-out-of-many proofs: a user proves that their funds belong to a set without identifying the specific member. Firo research materials also discuss using Curve Trees to scale membership proofs to much larger sets. This is a related direction, but it is not FCMP++: the constructions, protocol details, and the parts already implemented or still planned are different.
the particular member” is not unique to Monero. What makes FCMP++ notable is the attempt to integrate this approach into Monero’s existing model, replacing limited rings while preserving spend authorization and protection against double-spending.
FCMP++ is not a magic switch that provides unlimited anonymity; it is a substantial change to the cryptographic construction. It aims to remove an important limitation of ring signatures—the small set of possible sources—and relies on proofs of membership in a much larger set. But its success will depend on more than the mathematics: audits, resistance to implementation errors, node and wallet performance, and the system’s behavior after launch will all matter.
For now, FCMP++ is best described as a promising project under active testing, but not yet enabled on Monero’s mainnet. And when comparing it with Zcash, Tornado Cash, or Lelantus Spark, it is worth specifying what is being compared: the cryptographic idea, the architecture of a privacy pool, or a deployed network upgrade.
What do you think: could FCMP++ become a practical step forward for Monero’s privacy, or will the complexity of integrating it prove just as challenging as the cryptography itself?
This scheme has given Monero privacy by default, but it has a fundamental limitation: the anonymity of each spend relies on a relatively small set of candidates and on how well the decoys are selected. Researchers can look for statistical patterns in their age and distribution. FCMP++ proposes changing the underlying approach: instead of selecting a limited group of plausible candidates, the spender proves that the output being spent belongs to a large set of outputs in the blockchain, without revealing which one it is.
Imagine a library where every book has a unique mark. Under Monero’s current scheme, the owner proves: “My book is one of these 16.” The verifier sees all 16 candidates but does not know which one is the real book.
With a full-chain membership proof, the claim would instead be: “I own one of the books in this large library, and I’m authorized to use it.” The verifier is not told which book it is. For Monero, this would remove the reliance on a small, fixed ring and on the decoy-selection algorithm.
“Full chain” does not mean that users become protected against every kind of analysis. It refers to a large set of outputs against which the proof of membership is made. Practical privacy still depends on the protocol as a whole: how the network verifies the right to spend funds, prevents double-spending, and processes transactions.
FCMP stands for Full-Chain Membership Proofs. The “++” indicates that Monero’s proposal includes not only a membership proof but also related functions: Spend Authorization, which confirms the right to spend funds, and Linkability, which allows the network to detect an attempt to spend the same output twice.
This distinction matters because it would be misleading to describe the system simply as “proving that a coin exists somewhere in the blockchain.” A membership proof alone is not enough. The protocol must also verify that the spend is authorized and prevent the same coin from being spent twice. FCMP++ is designed as a replacement for the ring-based mechanism while preserving these essential properties.
The FCMP++ proposal uses a construction based on Curve Trees, a structure for proving membership in large sets. The project description also discusses a technique involving divisors of elliptic curves to make proofs more practical in terms of size and computation. The idea is not to include “a huge list of outputs” in every transaction. The challenge is to prove membership in a large set compactly, without revealing the position of the output being spent.
FCMP++ is not synonymous with Monero’s entire future architecture. The initial direction for full-chain proofs was tied to Seraphis, a broader redesign of the transaction system and key formats. A later version of FCMP++ was proposed as a way to move toward full-chain membership proofs without requiring an immediate migration to Seraphis. This would allow the project to focus on improving sender privacy while developing some additional features—such as new types of view keys and transaction chaining—separately.
That is why it is important to distinguish three things: the cryptographic idea, the specific proposal for Monero, and a finished feature in a wallet. Even if the base protocol can verify a new kind of proof, wallets still need to create transactions correctly, scan the blockchain, and support different ways of storing and signing funds.
The main expected change is the potential for a much larger set of outputs to conceal the real spend. But a larger set does not make privacy “absolute.” It changes one important part of the threat model: instead of a small ring, there would be a proof of membership in a broader set. Transaction timing, network metadata, wallet behavior, and other external information would remain separate concerns.
The new construction also makes implementation more complex. Developers need to verify not only the mathematical correctness of the scheme, but also the code, its behavior during chain reorganizations, the load on nodes, memory requirements, transaction creation in wallets, and compatibility with hardware and multisignature wallets. The project materials also emphasize that additional features may not arrive at the same time as the basic replacement for rings.
It is useful to distinguish the size of the proof from the cost of the system as a whole. Even if a proof is relatively compact, nodes still need to maintain the state required to verify it, and wallets need a way to obtain the data needed to construct it. The FCMP++ proposal describes different options: a wallet could obtain the necessary data from a node or build the relevant structure locally. Each approach involves trade-offs in synchronization speed, network traffic, data storage, and reliance on infrastructure.
As of November 5, 2026, FCMP++ has not been activated on the Monero mainnet. It is being tested on a separate beta stressnet, an experimental network intended to test the code and its behavior under load. In the Monero repository, work on the FCMP++ hard-fork milestone was marked as 73% complete on October 19; in early November, open tasks and changes awaiting review remained. These figures indicate development progress, but do not mean the protocol is ready to launch on mainnet.
The distinction matters: a working test network is a real engineering milestone, but it does not show that the update is already being used by Monero participants. Audits, completion of the integration, wallet testing, and the community’s decision on upgrade rules are also important before a mainnet transition.
Related ideas have appeared in other blockchains, but they are best described as related approaches, not exact copies of FCMP++.
Zcash is one of the closest examples in terms of the general cryptographic idea. In its shielded pool, a transaction uses a proof that a hidden coin belongs to a set of commitment records in a tree, without revealing which record it is. To prevent double-spending, the transaction publishes a special identifier called a nullifier. This scheme became a practical implementation of the approach described in the Zerocash research. But Zcash’s model differs from Monero’s: its privacy relies on proofs within a shielded pool and hides more transaction details, while FCMP++ is intended specifically to replace Monero’s ring-based spending mechanism.
Tornado Cash used a similar cryptographic technique at the Ethereum application level. A smart contract stored commitments in a tree, and a user could prove in zero knowledge that their commitment was in the tree without revealing which one. But this is not privacy built into the base blockchain, nor is it the same problem FCMP++ addresses. Tornado Cash is a separate contract-based pool with its own deposit and withdrawal model, not a new spending mechanism built into the rules of an entire currency.
Firo Lelantus Spark is another close example from the privacy-coin ecosystem. It uses one-out-of-many proofs: a user proves that their funds belong to a set without identifying the specific member. Firo research materials also discuss using Curve Trees to scale membership proofs to much larger sets. This is a related direction, but it is not FCMP++: the constructions, protocol details, and the parts already implemented or still planned are different.
the particular member” is not unique to Monero. What makes FCMP++ notable is the attempt to integrate this approach into Monero’s existing model, replacing limited rings while preserving spend authorization and protection against double-spending.
FCMP++ is not a magic switch that provides unlimited anonymity; it is a substantial change to the cryptographic construction. It aims to remove an important limitation of ring signatures—the small set of possible sources—and relies on proofs of membership in a much larger set. But its success will depend on more than the mathematics: audits, resistance to implementation errors, node and wallet performance, and the system’s behavior after launch will all matter.
For now, FCMP++ is best described as a promising project under active testing, but not yet enabled on Monero’s mainnet. And when comparing it with Zcash, Tornado Cash, or Lelantus Spark, it is worth specifying what is being compared: the cryptographic idea, the architecture of a privacy pool, or a deployed network upgrade.
What do you think: could FCMP++ become a practical step forward for Monero’s privacy, or will the complexity of integrating it prove just as challenging as the cryptography itself?