NullStake: Zero-Knowledge Private Staking Designed for Innova

Status note

NullStake is designed and specified but not yet active on mainnet. The spec is locked under IIP-0009 (V1) and IIP-0010 (V2). Activation is scheduled at specific block heights which have not yet been reached; once reached, a soft-fork activation brings the ZK kernel proofs online. Until then, Innova operates with transparent staking, and all descriptions of NullStake in this post refer to its designed behavior post-activation.

What is NullStake?

NullStake is Innova's zero-knowledge private staking protocol. Once activated, validators will stake shielded funds to participate in Proof-of-Stake consensus — but the individual stake amounts will never appear on-chain in plaintext. Consensus will still run correctly, weighted by stake, because the ZK kernel proofs demonstrate stake-weight correctness without exposing the weights themselves.

Two versions are specified:

• NullStake V1 — scheduled activation at block 9,500,000 (IIP-0009), Sigma protocol ZK proofs.
• NullStake V2 — scheduled activation at block 10,000,000 (IIP-0010), Poseidon2 + Bulletproof Aggregate Commitment (BPAC) proofs.

Both specifications have been through external cryptographic review. The activation gates ensure consensus compatibility: every full node upgrades before the block height, and the protocol enforces the upgrade through soft-fork semantics with deterministic fallback to transparent staking if any ZK proof fails validation.

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. Auditability. Collateral node operators (25,000 INN collateral threshold) need to verify their own stake is being counted — solved via viewing keys.
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

Scheduled activation at block 9,500,000 (IIP-0009). The staker will 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)

Proof size: ~1.8 KB per kernel. Verification adds ~2 ms per block.

NullStake V2 — Poseidon2 + BPAC

Scheduled activation at block 10,000,000 (IIP-0010). Replaces the Sigma protocol with two cryptographic upgrades:

• Poseidon2 hash. An arithmetic-circuit-friendly hash function that reduces constraint count in the ZK circuit by ~3× compared to SHA-256-based constructions. Also enables efficient composition with FCMP++ curve trees.
• Bulletproof Aggregate Commitment (BPAC). Extends Bulletproof range proofs to simultaneously prove stake eligibility, UTXO maturity, and lottery-win validity in a single compact proof.

Proof size: ~720 bytes (~60% reduction from V1). Verification time: ~55% of V1.

Summary table

Both circuits are undergoing external security audit prior to mainnet activation. Contact security@innova-foundation.com for the current audit state and methodology.

Viewing-key auditability (designed)

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

Post-activation, a staker will be able to export a viewing key and delegate it to a regulator, institutional custodian's compliance team, treasury auditor, or tax authority. The viewing-key holder will see that operator's stake activity in plaintext while learning nothing about any other operator's stake.

This is the compromise NullStake strikes: privacy by default, auditability as opt-in the staker controls.

The CLI surface is spec'd today:

# 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"

These commands exist in the current client but will reject shielded-stake submissions until the activation block is reached.

How NullStake composes with IDAG consensus

Innova's consensus migration plan is IDAG: a four-phase move to a block DAG with GHOSTDAG blue/red coloring, stake-weighted finality, epoch-anchored privacy, and DAGKNIGHT Phase 4 adaptive k. NullStake's staking proofs fit into the IDAG 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 Innova chain runs a pre-IDAG linear-chain design; IDAG and NullStake activate together via coordinated phased upgrades.

How NullStake interacts with FCMP++

NullStake V2's choice of Poseidon2 is not incidental. Poseidon2 was selected specifically because it composes efficiently with the curve tree arithmetic used by FCMP++ (Innova's Full-Chain Membership Proof construction, also pending activation). The design intent is that a future NullStake can cryptographically prove stake UTXO membership in the whole-pool FCMP++ tree — making stake provenance indistinguishable from the entire UTXO set, not just the shielded pool.

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

Deterministic fallback

A consensus-critical ZK system must not stall consensus if proof generation fails. NullStake's designed failure mode is explicit: if proof generation or verification fails, the node falls back to transparent staking automatically. Look for NullStake fallback entries in debug.log once activated.

This fallback behavior is part of the external audit scope — no chain-split risk.

What this will unlock

Post-activation, for stakers:

• No public balance exposure. Stake capital without advertising position to the world.
• No mandatory lockup. Innova's un-bonding period is calibrated for consensus safety, not for privacy preservation via time-based decay.
• Opt-in auditability. Share viewing keys with regulators, custodians, or auditors — without exposing other stakers.

For the chain:

• Attack-surface reduction. Adversaries cannot enumerate validators by stake and target the largest ones.
• Governance integrity. Voting weights are hidden from public view, reducing pre-vote manipulation.
• Capital flexibility. No aggressive lockup penalty — operators can run infrastructure without cash-flow strangulation.

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:

Each layer is independent. A weakness in one does not compromise the others. See the full privacy stack walkthrough →

Next up in the Innova silo

• FCMP++ Explained — also scheduled, activation 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.