Staking

Navio's staking produces Proof-of-Private-Stake (PoPS) blocks on the current BLSCT chains: mainnet, testnet, and blsctregtest. Operators lock a portion of wallet funds as a Pedersen-committed stake; eligible hidden-amount commitments participate in the stake lottery and mint blocks when their ZK eligibility proof verifies.

Full protocol details (math, crypto proofs, verifier equations): BLSCT → Proof-of-Private-Stake.

How to stake

The only way to stake is via the standalone navio-staker binary. There is no in-daemon staking option — naviod itself does not produce blocks; it validates them. navio-staker connects to a running naviod over JSON-RPC, polls for eligible staked commitments, constructs the PoPS proof (set-membership + range proof), and submits candidate blocks.

Hardware requirements

BLSCT verification is heavier than transparent signatures: every block carries Bulletproofs++ range proofs and a BLS aggregate signature verify, and the staker additionally builds a set-membership proof + range proof against the current staked commitment set. RAM scales with the staked-set cap (N = 1024 commitments, padded to the next power of two) and with dbcache (default 2048 MiB).

Minimum (survives, but slow IBD and tight headroom)

Resource	Value
CPU	2 vCPU, x86-64 with AES-NI + AVX2, or ARMv8 with crypto
RAM	4 GB
Disk	40 GB SSD (NVMe strongly preferred), prune=4096
Network	50 Mbps symmetric, stable; monthly cap ≥ 100 GB
Clock	NTP-synced (chrony or equivalent); drift > 30 s risks stale PoPS templates

Recommended (mainnet, long-running operator)

Resource	Value
CPU	8 vCPU / 8 physical cores, modern x86-64 (AVX2) or ARMv8.2+ with crypto extensions. Navio parallelises heavily — Bulletproofs++ range-proof verification fans out one std::async task per proof, view-tag detection batches across threads, and the block check queue validates scripts in parallel. More cores ≈ faster IBD and lower per-block validation latency. Microbench on bench_navio: BLSCTRPVerify per-proof cost drops ~2.7× going from 1 → 8 parallel proofs.
RAM	8 GB (leaves headroom for dbcache=2048 + mempool + OS page cache)
Disk	200 GB NVMe SSD, unpruned; 4 KiB random-read IOPS ≥ 10k
Network	100 Mbps symmetric, low-jitter; monthly cap ≥ 1 TB
Clock	NTP, max ± 2 s skew from wall time

Notes

• Sustained load is low. After IBD, a synced node running navio-staker typically sits at < 10 % CPU between slots, spiking for a few hundred ms when validating a new block or assembling a candidate template. Provision for peak, not mean.
• Disk growth. Unpruned mainnet grows with chain size; prune=N caps block-file usage at roughly N MiB but chainstate still grows with UTXO count.
• More CPU cores help validation, not win rate. PoPS is stake-weighted: extra compute does not increase the probability of minting a block. But more cores do shorten IBD (parallel range-proof + view-tag batches), reduce per-block validation latency, and give you headroom when a busy block with many BLSCT outputs arrives. A fast-to-validate node also finishes its own candidate templates quicker, reducing the stale-template risk on busy networks. GPUs / ASICs do not apply — the parallel work is on general-purpose BLS12-381 pairings, not a hash function.
• Home connection is fine as long as uptime is solid. A VPS is mostly about availability, not throughput.
• Tighter testnet-only sizing and a step-by-step VPS bringup: Run a staking node on a VPS.

Requirements

• naviod fully synced to chain tip, with RPC enabled.
• A wallet holding ≥ 10,000 NAV locked as stake on mainnet / testnet (100 NAV on blsctregtest).
• Wallet unlocked for staking (walletpassphrase <pw> <timeout> true — third argument is staking-only unlock).

No stake-age minimum. Newly locked outputs become eligible as soon as they are confirmed and present in the staked commitment set.

Lock stake

navio-cli -testnet stakelock 10000

Creates a transaction locking 10,000 NAV into staking sub-addresses (account -2). The output is marked as a staked commitment rather than spendable for normal sends.

Run the staker

navio-staker -testnet -wallet=wallet

Keep it running. It will:

1. Call getblocktemplate to learn the current sampled staked_commitments ring, eta_fiat_shamir, eta_phi, prev_time, modifier, prev_chainwork, pops_hardened, pops_bind_phi, bits, curtime. The node computes the ring seed, eta_phi, and eta_fiat_shamir exactly as consensus will, so the staker uses them verbatim. pops_bind_phi tells the staker to build the V2 kernel (which binds the commitment image); it must match consensus or the produced block is rejected.
2. For each locked commitment held by this wallet, check membership in the returned set.
3. Construct a blsct::ProofOfStake with the hidden stake amount and blinding factor.
4. Self-verify, then submitblock.

Flags: navio-staker --help on the binary matching your release.

Unlock stake

navio-cli -testnet stakeunlock 5000

Releases 5,000 NAV from staking back to regular spendable UTXOs. Consensus enforces nPePoSMinStakeAmount on each locked output individually — you cannot partial-unlock below the minimum per commitment.

Rewards

Rewards flow to sub-addresses in the staking pool (account = -2).

• Mainnet: nBLSCTBlockReward = 8 NAV with nPosTargetSpacing = 120 s.
• Testnet / blsctregtest: nBLSCTBlockReward = 4 NAV with nPosTargetSpacing = 60 s.
• Height 1 on BLSCT chains: special initial supply mint via nBLSCTFirstBlockReward.

Inspect reward transactions with:

navio-cli -testnet listblscttransactions "*" 100 0 true

filter for category: "stake".

PoPS on BLSCT chains

On mainnet, testnet, and blsctregtest, the coinstake transaction does not reference a specific staked UTXO; block.posProof contains a set-membership proof + range proof that together show "one of these staked commitments is mine and my hidden stake satisfies the block's eligibility threshold" — without revealing which commitment or its amount. Plain signet and plain regtest do not use PoPS in the current chainparams. Protocol details: BLSCT → PoPS.

Cold staking

Since v0.1.7, Navio supports cold staking with no consensus changes: the staking (delegation) key stays hot on the block-producing machine while the spend key stays cold. Delegate to a staker you run yourself — the most secure way to run a validator — or to a third-party operator; either way the delegation is discovered and decrypted from an encrypted DATA-predicate payload on the staked output, and only the spend key can move the principal. Owner and operator workflows, trust model, fees and monitoring: Cold staking.

Troubleshooting

Symptom	Likely cause
Staker logs "no eligible commitments"	Wallet locked, stake not yet in staked_commitments set, or no staked outputs owned by this wallet
Wallet-unlock error on staker	Run walletpassphrase <pw> <large-timeout> true (true = staking-only)
Staker restarts immediately	Usually RPC auth misconfig — check staker log + rpcuser/rpcpassword
submitblock rejected	Verify naviod is at chain tip; stale templates produce PoPS proofs bound to the wrong parent
Blocks never mint	Check chain tip advancement (someone else is winning the lottery); your stake weight may be low relative to the set

Alternatives: dedicated staking pools

Third-party staking services may run validators on behalf of depositors. Prefer cold staking over custodial services: it delegates only block production — the operator can never spend or unstake the principal — while a custodian holds your funds outright.