NullStake: Zero-Knowledge Private Staking Designed for Innova

Status note

NullStake is a proposal, not confirmed mainnet functionality. IIP-0009 (V1) and IIP-0010 (V2) name target heights, but Innova's staking privacy model explicitly says those targets are not activation evidence. A shipped release, documented RPC surface, consensus enforcement, and independent review would be required before describing it as active.

What is NullStake?

NullStake is Innova's proposed zero-knowledge private-staking design. Its goal is to let participants prove staking eligibility over committed values without publishing individual stake amounts in plaintext. Whether hidden stake weights can be used safely and deterministically is a consensus-critical implementation and audit question, not an established result here.

Two versions are specified:

• NullStake V1 — Sigma-protocol proposal with a target height of 9,500,000 (IIP-0009).
• NullStake V2 — Poseidon2 + Bulletproof Aggregate Commitment (BPAC) proposal with a target height of 10,000,000 (IIP-0010).

Published v2/v3 reports are internal automated static analyses, not independent cryptographic audits. They must not be described as external review. Target heights alone do not ensure upgrade coordination, and verification failure must not be presented as automatic transparent fallback.

Why private staking is hard

Privacy-preserving staking is more constrained than privacy-preserving transactions. Four obligations the NullStake circuit must satisfy:

1. Stake-weight proof integrity. The committed stake must exceed the minimum threshold — provable over a Pedersen commitment without revealing the amount.
2. Consensus determinism. Every full node must arrive at the same validity decision for every block. ZK proofs must verify in bounded time with deterministic outcomes.
3. Operator observability. Collateral node operators (25,000 INN collateral threshold) need a way to verify that stake is recognized. Viewing keys are a proposed part of that design, but the current documentation does not establish a released NullStake interface or prove that transaction viewing keys expose consensus stake-counting state.
4. Novel attack vectors. Privacy obscures double-staking UTXOs and grinding attacks — each addressed by specific proof obligations (nullifier set, VRF lottery binding).

The two generations, as specified

NullStake V1 — Sigma Protocol

Proposed target: block 9,500,000 (IIP-0009). The design has the staker construct a Sigma-protocol ZK proof over the Pedersen commitment binding their stake UTXO. The proof demonstrates:

1. The committed amount exceeds the minimum stake threshold
2. The UTXO satisfies maturity requirements (75 blocks, ~10 hours minimum age)
3. The stake hash meets the difficulty target for the committed weight
4. The nullifier is fresh (no double-staking)

Design estimate: ~1.8 KB per kernel and ~2 ms verification per block. These figures require release-specific reproducible benchmarks.

NullStake V2 — Poseidon2 + BPAC

Proposed target: block 10,000,000 (IIP-0010). The design replaces the Sigma protocol with two cryptographic upgrades:

• Poseidon2 hash. An arithmetic-circuit-friendly hash function selected with an estimated ~3× constraint-count reduction versus the proposed SHA-256-based construction. That comparison is a design estimate, not a release benchmark; efficient FCMP++ composition is also an objective rather than a demonstrated result.
• Bulletproof Aggregate Commitment (BPAC). Extends Bulletproof range proofs to simultaneously prove stake eligibility, UTXO maturity, and lottery-win validity in a single compact proof.

Design estimate: ~720 bytes and ~55% of V1 verification time. These figures are not production benchmarks.

Summary table

Version	Activation block	Proof scheme	Proof size	Verification	Status
V1	9,500,000 target (IIP-0009)	Sigma protocol	~1.8 KB target	unverified estimate	proposed
V2	10,000,000 target (IIP-0010)	Poseidon2 + BPAC	~720-byte target	unverified estimate	proposed

No independent cryptographic audit is linked here. The published security review is useful implementation evidence but should not be represented as an external audit. Publish the reviewer, scope, commit hash, methodology, findings, and remediation status before making that claim.

Viewing-key observability (proposed)

NullStake separates three types of key material in its design:

• Spending key — full fund control
• Viewing key — read-only access to incoming shielded transactions (amounts and memos)
• Stealth scan key — detects which transactions are yours without granting spend authority

The proposal envisions a staker delegating read-only key material to a regulator, custodian, auditor, or tax adviser. The production key type, the stake events or balances it would expose, and whether it would reveal information beyond one operator are not established by a released NullStake interface. The current shielded-transaction viewing-key commands are evidence of wallet observability, not proof that private-staking observability is solved.

The intended compromise is private staking with operator-controlled observability, but its scope and privacy guarantees remain implementation and audit questions.

The following is conceptual syntax only, not a current documented RPC surface:

# After activation: stake from shielded balance (uses best available NullStake version)
innova-cli z_stake "z_your_address" 5000

# Explicit V1 or V2 selection
innova-cli z_stake "z_your_address" 5000 1
innova-cli z_stake "z_your_address" 5000 2

# Export viewing key for self-monitoring or auditor access
innova-cli z_exportviewingkey "z_your_address"

The current published RPC reference does not include z_stake or z_getstakingstatus. Current shielded-staking documentation uses Zarcanum. Do not copy these examples into production instructions until an implementing release documents them.

How NullStake composes with IDAG consensus

Innova's IDAG material is a research architecture: a proposed move to a block DAG with GHOSTDAG-style ordering, stake-weighted finality, epoch-anchored privacy, and a later DAGKNIGHT phase. NullStake is designed to fit into the proposed finality gadget's stake-weight inputs.

The designed interaction, once IDAG and NullStake are both active:

1. IDAG selects eligible stakers for each epoch (300 blocks post-DAG activation, ~5 minutes target).
2. Stakers submit CFinalityVote messages, stake-weighted by their committed amount.
3. NullStake provides stake weight as a ZK proof bound to a committed UTXO — never in plaintext.
4. Finality tiers accumulate as stake votes arrive: TENTATIVE (≥⅓), SOFT (≥½), HARD (≥⅔).
5. Binding finality requires the epoch itself and the two immediately-following epochs to all reach HARD tier — three consecutive HARD epochs total (900 blocks, ~15 min post-DAG).

A dedicated IDAG deep-dive is queued for this silo. Today's published materials do not establish an IDAG or NullStake mainnet activation. Any future coordination remains a proposal until release and chain evidence are published.

How NullStake interacts with FCMP++

The proposal selects Poseidon2 to pursue efficient composition with the arithmetic used by FCMP++ (Full-Chain Membership Proofs + Spend Authorization + Linkability). A future design could prove stake-output membership in an eligible-output tree, but that composition and its privacy properties remain unimplemented claims until code and review are published.

That future composition is why Innova's privacy and staking roadmaps are tracked together rather than independently.

Failure handling

A wallet may choose a different transaction type when private proof construction fails. That is different from consensus validation: a submitted proof that fails verification must be rejected according to the final rules, not silently reinterpreted as valid transparent stake.

No production consensus system can responsibly promise “no chain-split risk.” Cross-version test vectors, activation tests, independent review, and deployed-node observations are required to characterize that risk.

What the proposal aims to enable

If implemented and activated, the design would aim to provide stakers:

• Reduced public stake disclosure. Prove eligible committed stake without publishing the amount, subject to the final proof and metadata model.
• Defined withdrawal rules. Any lockup or unbonding behavior must be documented from the final consensus implementation.
• Proposed opt-in observability. Delegate read access under a release-defined viewing-key model, with disclosure boundaries verified from the implementation.

For the chain:

• Harder stake-based targeting. Hidden amounts could make direct stake-size enumeration more difficult, while network and operational metadata would remain relevant.
• Private consensus inputs. Stake weights could be verified from commitments rather than published directly, if the final design proves sound and deterministic.
• Release-defined capital rules. Lockup, withdrawal, and unbonding behavior must come from the implementing consensus release rather than the proposal alone.

Where this will sit in Innova's privacy architecture

Once activated, NullStake is Layer 5 of Innova's five-layer privacy stack, specifically addressing the staking boundary:

Layer	What it protects	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++ evolution)	Lelantus documented; verify the installed release; FCMP++ proposed
3	Receiver	Stealth addresses + Silent Shielding	Documented interfaces; verify the installed release
4	Network	Dandelion++ relay protocol	Configurable and documented as default-on; verify release and node configuration
5	Staking	NullStake V1/V2 ZK kernel proofs	Proposed

The layers separate concerns, but metadata and implementation failures can correlate across them; a weakness in one layer can reduce overall privacy. See the full privacy stack walkthrough →

Next up in the Innova silo

• FCMP++ Explained — proposed target block 7,320,000
• Five-Layer Privacy Stack
• IDAG consensus deep-dive — GHOSTDAG, DAGKNIGHT Phase 4 adaptive k, PoS finality gadget (upcoming)
• Dynamic Selective Privacy — the 8-mode per-transaction privacy selector (upcoming)

Or browse the Innova product page for testnet links and the broader architecture.

Continue reading

• FCMP++: design and implementation boundaries
• Current Innova project information