George Sarris (0xcircuitbreaker) · · 4 min read
FCMP++ Explained: Full-Chain Membership Proofs, Designed for Innova
FCMP++ expands sender privacy beyond fixed rings. This article separates the published construction from Innova's proposed integration and activation target.
In this article
Status note
FCMP++ is not confirmed active on Innova mainnet. Innova's architecture documents name block 7,320,000 as a proposal target, but explicitly caution that target heights are not activation evidence. A release note, shipped consensus implementation, and observable mainnet enforcement would be required to describe it as active. Descriptions below are design goals unless a cited implementation says otherwise. See Innova's privacy architecture and the published security review.
What FCMP++ is
FCMP++ stands for Full-Chain Membership Proofs + Spend Authorization + Linkability. It is a cryptographic construction intended to let a spender prove membership in the set of eligible outputs without revealing the specific output being spent. The Monero project overview provides the canonical expansion and motivation.
Practical effect: the anonymity set can expand from a fixed ring to the full eligible-output set. A Monero ring size of 16 means one real input plus 15 decoys, not 16 decoys.
Innova's documents describe an FCMP++ Layer 2 sender-privacy proposal integrated with an epoch-anchored privacy model. The cited height of 7,320,000 is a planning target, not a confirmed activation. No automatic fallback should be treated as a safety guarantee: a consensus-invalid proof must be rejected according to the shipped validation rules.
Why this matters — the anonymity-set ceiling
Privacy in Monero-style RingCT works via ring signatures over a fixed ring. At ring size 16, Alice's real input is combined with 15 decoys selected from chain history. An observer attempts to determine which member is real.
Two problems:
- The ring is small. Over time, heuristic analysis (decoy temporal ordering, churn detection, repeated appearance patterns) can statistically narrow the probability space below 1-in-16 for well-resourced adversaries.
- Decoy selection is a policy. Wallets choose decoys from the output distribution, which is itself information the adversary can model.
Lelantus expands beyond a wallet-selected ring to a protocol-defined candidate set. FCMP++ is designed to use the eligible full-chain output set, selected by protocol rules rather than wallet decoy heuristics.
The dual-curve tree construction
Curve Trees use compatible elliptic-curve cycles to build efficient membership proofs. Innova's documents propose the following dual-curve parameters; they should not be read as deployed or externally validated implementation facts:
| Property | Value |
|---|---|
| Tree arity | 256 (each internal node has up to 256 children) |
| Maximum depth | 8 levels |
| Maximum outputs | 256⁸ = ~1.8 × 10¹⁹ (effectively unlimited) |
| Even-depth curve | secp256k1 |
| Odd-depth curve | Ed25519 |
The proposal alternates levels between two curves. Whether these exact curves and parameters are secure and performant depends on a complete implementation, benchmarks, and cryptographic review. For the peer-reviewed construction, see the Curve Trees paper; its results should not be transferred automatically to a different parameterization.
The design proposes committing an eligible-output-set root at epoch boundaries. Epoch length, timing, finality, and immutability are targets that must be verified against a specific shipped release.
# Conceptual interface from the design; not a current documented RPC
innova-cli getepochcurvetreeroot
# Or for a specific epoch
innova-cli getepochcurvetreeroot 25000
{
"epoch": 25000,
"curve_tree_root": "a3f8c1d2e4b5...",
"utxo_count": 12847392,
"tree_depth": 5,
"binding_finality": true
}
Why this has taken time to ship
Full-chain membership proofs have been theoretically known for years. The blockers are practical:
- Proving time. Naive constructions take minutes to generate — unacceptable for interactive wallet use.
- Verification cost. Each proof must verify during block propagation; slow verification throttles throughput.
- Integration surface. Retrofitting membership proofs into a privacy protocol without breaking mempool, fee economics, light-client behavior, or bandwidth budgets is brutally hard.
- Activation coordination. Consensus-critical cryptographic upgrades need soft-fork discipline, fallback paths, and operator-readiness signals — which is exactly what IIP-style activation gates provide.
Innova's proposal addresses these with logarithmic-size membership proofs, epoch roots, and a phased migration design. Those are engineering objectives, not demonstrated performance or activation guarantees. The current security review also records incomplete or unauditable proof paths, so production claims should wait for remediation and independent cryptographic review.
Where FCMP++ sits in the privacy stack
FCMP++ is the proposed sender-privacy (Layer 2) evolution of Innova's five-layer stack: it aims to move from Lelantus's protocol-defined candidate set toward an eligible full-chain output set. It does not create a new layer; it would upgrade an existing one.
| Layer | Mechanism | Status |
|---|---|---|
| 1 | Pedersen + Bulletproof | Documented current interface; verify the installed release |
| 2 | Lelantus → FCMP++ | Lelantus documented; verify the installed release; FCMP++ proposed (target 7,320,000) |
| 3 | Stealth addresses + Silent Shielding | Documented interfaces; verify the installed release |
| 4 | Dandelion++ | Configurable and documented as default-on; verify release and node configuration |
| 5 | NullStake V1/V2 | Proposed (target 9.5M / 10M) |
The proposal intends FCMP++ roots to reference finalized epochs. That property must be established by the final consensus rules and implementation; it is not demonstrated by the roadmap alone.
What this will unlock
From a user perspective, a post-activation FCMP++ spend will have:
- Anonymity set drawn from the eligible full-chain output set, subject to the final protocol definition
- Compact verification, subject to release-specific benchmarks
- Compatibility with Dynamic Selective Privacy — per-transaction privacy mode selection applies
- Explicit migration rules. Wallet-side proof-construction fallback may be possible, but consensus-invalid proofs must be rejected.
Innova documents viewing-key interfaces for shielded transaction observability, while viewing-key support for NullStake remains a proposal goal. An FCMP++ construction does not by itself preserve or define that access: the exact information exposed, stake-counting visibility, and operational procedure must be established by a shipped implementation.
A note on the Monero FCMP++ track
FCMP++ is actively researched in the Monero community. Luke "Kayaba" Parker and collaborators developed core components used in that effort, building on Curve Trees research. Monero's deployment process is separate from any Innova proposal.
Innova's documents propose migration semantics, upgrade sequencing, and integration with an epoch-anchored finality layer. These should be presented as project-specific design work until code, test vectors, audit evidence, and activation records are published.
Next up in this silo
- Five-Layer Privacy Stack — where FCMP++ fits in the broader architecture
- NullStake: Zero-Knowledge Private Staking — proposed Poseidon2 + BPAC design
- Dynamic Selective Privacy — the documented 8-mode per-transaction selector (upcoming post)
- IDAG Consensus — the four-phase migration underpinning FCMP++ and NullStake (upcoming)
Or browse the Innova product page for testnet links and the broader architecture.