George Sarris (0xcircuitbreaker) · · 6 min read
Innova's Five-Layer Privacy Stack, Explained Layer by Layer
A release-aware guide to Innova's documented privacy layers, separating current transaction mechanisms from the proposed FCMP++ and NullStake roadmap.
In this article
Why five layers?
A transaction on a public ledger leaks information on at least five distinct axes: the amount, the sender, the receiver, the network origin of the broadcast, and (on a Proof-of-Stake chain) the staker's position in consensus. A privacy protocol that hides only one of these is not private — it's obfuscated on one axis and legible on the others.
Innova treats each leak as a separate problem and stacks a purpose-built primitive against each. The result is a defense-in-depth design. The layers are not perfectly independent: metadata can correlate across transaction, wallet, network, and staking boundaries, so failure in one layer can reduce overall privacy.
Overview
| Layer | Protects | Core mechanism | Status |
|---|---|---|---|
| 1 | Amount | Pedersen commitments + Bulletproof range proofs | Documented current interface; verify the installed release |
| 2 | Sender | Lelantus one-out-of-many proofs (+ FCMP++ proposal) | Lelantus documented; verify the installed release; FCMP++ target 7,320,000 is unconfirmed |
| 3 | Receiver | Stealth addresses + Silent Payments + Silent Shielding | Documented interfaces; verify the installed release |
| 4 | Network origin | Dandelion++ relay protocol | Configurable and documented as default-on; verify release and node configuration |
| 5 | Staked amount | NullStake V1/V2 zero-knowledge kernel proofs | Proposed; target heights 9,500,000 / 10,000,000 are unconfirmed |
The design separates mechanisms by privacy objective, but a weakness in one can still create correlations across the stack. Dynamic Selective Privacy (DSP) documents eight transaction modes; supported modes must be checked against the RPC reference and release in use.
Documented today vs. proposed
Innova's architecture documents describe Pedersen amount hiding, Lelantus sender privacy, stealth-address mechanisms, Dandelion++ propagation, and transparent staking. Avoid treating that list—or z_send mode 7—as a universal availability or “full privacy” guarantee without checking the current release, RPC reference, wallet behavior, peer topology, and threat model.
Proposed: FCMP++ target 7,320,000; NullStake V1 target 9,500,000; and NullStake V2 target 10,000,000. The staking privacy model and privacy architecture explicitly say target heights are proposals, not activation evidence.
Layer 1 — Pedersen commitments + Bulletproofs
What's hidden: transaction amounts.
Pedersen commitments replace public amounts with C = v·H + r·G, where v is the amount, r is a blinding factor, and G, H are independent elliptic curve generators. The commitment hides v but is additively homomorphic, so the chain can verify sum(inputs) - sum(outputs) = fee algebraically — proving value conservation without learning any individual amount.
Bulletproofs address the range problem. A malicious spender could otherwise commit to an out-of-range value. Bulletproof range proofs demonstrate the committed value lies within an allowed interval, non-interactively. Proof size varies with construction, aggregation, and output count; ~672 bytes is not a universal per-transaction figure.
This follows the same general commitment-and-range-proof family used in privacy systems such as Monero; exact parameters and implementation details remain chain-specific.
Layer 2 — Lelantus, with FCMP++ as the evolution
What's hidden: the sender's input among many candidate inputs.
Lelantus one-out-of-many proofs. The spender proves membership in a defined candidate set without revealing which member is spent. The effective set size depends on the shipped implementation and eligible-set rules; it should not be described as the entire shielded pool without code- and release-specific evidence.
FCMP++ — the proposed full-chain evolution. FCMP++ means Full-Chain Membership Proofs + Spend Authorization + Linkability. It is designed to use the eligible full-chain output set rather than a wallet-selected ring. Innova documents a dual-curve parameter proposal, but those parameters and their performance are not confirmed deployed facts. See Monero's FCMP++ overview.
The IDAG documents name block 7,320,000 as a proposal target. A target height does not establish activation.
Layer 3 — Receiver privacy
What's hidden: the receiver's identity and address association.
Three mechanisms compose at this layer:
Stealth addresses. The recipient publishes a meta-address (S, B) with scan and spend keys. The sender generates ephemeral r, derives shared secret ss = r·S, and computes a one-time destination P = Hash(ss)·G + B. Each transaction produces a unique, unlinkable on-chain output. The receiver scans with their scan key and detects matches.
Silent Payments. An evolution of stealth addresses that eliminates the need for the ephemeral key R in the transaction. The sender derives the one-time output from the sum of input public keys plus the recipient's reusable silent-payment address. The address is published once and reused indefinitely without creating on-chain linkage between payments.
Silent Shielding. A single atomic operation that combines silent-payment address derivation with a direct transfer into the shielded pool. Eliminates the two-step pattern (generate address, then shield) that creates a brief visible window in other implementations.
Layer 4 — Dandelion++ network privacy
What's hidden: the IP origin of the transaction broadcast.
Cryptographic transaction privacy can still leak network-origin metadata if an adversary watching peer-to-peer gossip identifies the originating node. Dandelion++ is intended to reduce that signal with two-phase propagation; it does not defeat every network observer or topology attack:
- Stem phase: the transaction is forwarded to exactly one randomly selected peer, which forwards to one peer, with a biased coin flip at each hop deciding whether to continue the stem.
- Fluff phase: when the stem ends, the transaction is broadcast to all peers via standard flood-fill.
The goal is to make the transaction appear to originate near the point where fluff began rather than directly at its creator. Innova's documentation describes rotating stem relay partners at randomized intervals to make long-term path analysis harder.
Dandelion++ is a configurable network-layer control. Operator documentation exposes dandelion=0|1 and describes it as enabled by default, so it is not an always-on consensus property. The published v2 security review also reported that mandatory stem routing for shielded transactions was not enforced in ShouldFluff. Operators should verify the exact release, configuration, peer diversity, and relay behavior; an anonymity network such as Tor can be part of a broader posture under its own threat model.
Layer 5 — NullStake private staking (proposed)
What will be hidden: stake amounts and staker identity in consensus.
On a public-stake chain, every validator's balance is visible. Adversaries enumerate validators by stake size to target whales for coercion, bribery, or regulatory action. Public balances also expose governance weight directly.
NullStake proposes replacing public stake disclosure with zero-knowledge kernel proofs. The intended proof obligations are that the committed stake exceeds the minimum threshold, the UTXO is mature and unspent, the stake hash meets the difficulty target, and the nullifier is fresh — without revealing amounts. Those properties require a shipped implementation and review.
Two versions are specified:
- NullStake V1 — proposed Sigma-protocol design; target size ~1.8 KB and target height 9,500,000 (IIP-0009).
- NullStake V2 — proposed Poseidon2 + BPAC design; target size ~720 bytes and target height 10,000,000 (IIP-0010). The claimed relative verification cost is an unverified design estimate.
The current published RPC reference does not expose z_stake or z_getstakingstatus; do not present those commands as current client functionality. Current shielded-staking documentation uses the name Zarcanum. NullStake interfaces remain conceptual until shipped and documented.
Both proposals name viewing-key observability as a design goal. That does not establish that private-staking observability is solved: the exposed fields, operator workflow, and privacy boundaries must be verified against a released implementation.
How the layers compose — Dynamic Selective Privacy
The mechanisms are designed to be selectable via Dynamic Selective Privacy (DSP). Eight documented modes cover the combinations:
| Mode | Bits (S·R·A) | Sender | Receiver | Amount | Use case |
|---|---|---|---|---|---|
| 0 | 0·0·0 | Off | Off | Off | Transparent (compliance reporting) |
| 1 | 1·0·0 | On | Off | Off | Sender-only privacy |
| 2 | 0·1·0 | Off | On | Off | Receiver-only privacy |
| 3 | 1·1·0 | On | On | Off | Sender + receiver hidden |
| 4 | 0·0·1 | Off | Off | On | Amount-only privacy |
| 5 | 1·0·1 | On | Off | On | Sender + amount hidden |
| 6 | 0·1·1 | Off | On | On | Receiver + amount hidden |
| 7 | 1·1·1 | On | On | On | All three transaction controls enabled |
DSP modes select the three transaction controls represented by the S·R·A bits; they do not force Layer 4. Dandelion++ is configured separately and applies relay behavior when enabled. NullStake (Layer 5) is orthogonal to DSP; it applies to the staking path rather than the transaction path.
How this compares to established privacy stacks
| Chain | Amount | Sender | Receiver | Anonymity set | Trusted setup | Private staking |
|---|---|---|---|---|---|---|
| Monero (RingCT) | Yes | Yes (ring of 16) | Yes (stealth) | 16 | No | No |
| Zcash Sapling | Yes | Yes (shielded pool) | Yes (shielded pool) | Full pool | Yes (ceremony) | No |
| Innova (documented interfaces; verify release) | Documented | Lelantus documented | Stealth + Silent documented | Implementation-defined | None claimed | Transparent baseline; Zarcanum documented |
| Innova (proposal target) | Designed | Lelantus + FCMP++ | Stealth + Silent | Eligible full-chain set target | None claimed | NullStake proposed |
The distinctive properties of the post-activation target: whole-chain anonymity set path (via FCMP++), no ceremony trust dependency, and native privacy on the staking side — not just the transaction side.
What's next in the Innova silo
- FCMP++ Explained
- NullStake: Zero-Knowledge Private Staking
- Dynamic Selective Privacy: the 8 modes in practice (upcoming)
- IDAG consensus: GHOSTDAG, DAGKNIGHT Phase 4, PoS finality (upcoming)
Or browse the Innova product page for testnet and architecture.