Documentation

What is Nival?

Nival is an independent coin forked from Zephyr, with its own NVL currency, genesis and RandomX Proof of Work consensus. Nodes verify blocks, signatures and the movement of funds. A standard transfer requires the sender's signature. A conditional payment lets both parties agree on the amount, recipient and refund height, then authorize settlement with two signatures.

Ordinary transfers use 16-member rings, stealth addresses and RingCT: a public address does not expose its balance, recipients or transferred amounts. Conditional payments disclose the locked amount, authorization keys and refund height. The protocol has no built-in arbitrator: the network checks transaction conditions, while the participants decide whether the work has been completed.

Network and emission

Mainnet has its own genesis and network identifier. Mainnet addresses begin with Niv. The genesis distributes no coins: premine is zero. Testnet and Stagenet have separate network identifiers and genesis blocks; their coins cannot be transferred to Mainnet.

The main reward decreases according to max((M − issued) >> 20, 450000000000) in atomic units. Tail emission continues after the main reward declines, so there is no hard supply cap. Fees go to the miner alongside the block reward and do not create new coins.

RandomX validates work using the block hashing blob and chain-derived seed. Difficulty follows the fork’s rolling block-time calculation. The chain with the greater verified cumulative work is selected. The 90-second interval is a target, not a guaranteed confirmation time.

Mainnet identifiers

Genesis

e690545005001376152c0efda349d09fdf7a56b69e007040936ce3e2580cccbd

Network ID

2cc64938-74ca-405b-a81e-a9d6d0c0f599

Conditional payment

1. Agreeing on terms

The sender creates a package containing the network, a unique identifier, title, amount, recipient, refund address, both parties' public keys and refund height E. The sender signs the entire package. The recipient reviews the terms and adds a signature. Changing any term requires a new agreement.

2. Funding

Once both signatures are present, the sender locks the amount in a conditional transaction output. Addresses and amount must match the signed package, and the funding block height must be below E. A package can be funded only once, including after it has been completed.

3. Settlement before the refund height

For settlement to be included at block height H < E, both parties must sign the same transaction body. The signatures on the original terms do not authorize settlement. The recipient receives the conditional output amount minus the settlement transaction fee.

4. Refund from height E

At block height H ≥ E the sender can sign a refund to the address specified in the terms. The recipient's signature is not required. The refund address receives the remaining conditional output amount after the transaction fee. When the chain tip is E − 1, a refund can already be submitted for inclusion in block E.

How this differs from a standard transfer

A standard transfer requires no action from the recipient and has no agreed refund height. A conditional payment requires agreement before funding and separate authorization for settlement. The network does not check documents, service quality or agreements outside the blockchain.

Getting started

1. Choose a package on the Downloads page. Linux AppImage and a complete Windows x64 ZIP are available.
2. Open Nival Wallet. Its Mainnet node starts automatically; wait for connection and synchronization.
3. Create a wallet, set a password and save the complete 25-word recovery phrase. Choose Restore if you already have a key.
4. To reveal your address for the first time, open Receive and select Show address. The core saves your approval, which remains in effect after closing the window or restarting the application.
5. To send funds, enter a Mainnet address and amount, review the fee and confirm with your password. You can look up the transaction hash in the explorer.

Wallet and recovery

Nival Wallet combines the Nival desktop interface with a native C++ wallet and node. Keys, transaction construction, RingCT proofs, signing and conditional payment authorization run in C++.

The wallet generates keys on your device and stores them in password-encrypted native wallet files. The seed controls the spend and view keys. The application locks after five minutes of inactivity. Sending funds and exporting the key require your password.

The backup is a 25-word CryptoNote recovery phrase, including its checksum word. Preserve every word in order. It restores the private keys and conditional authorization identity; it is not a BIP39 phrase.

Never share your recovery phrase. The pool, explorer and miner need only a public address. Wallet encryption protects the file at rest; it cannot protect an unlocked wallet on a compromised device.

Running a node

The wallet's built-in node uses the local RPC endpoint http://127.0.0.1:38181. This is an address on your own computer. Blocks are exchanged with other nodes through a separate port: 38180. You can select a compatible, separately running node in the wallet settings.

Example command for a compiled Linux node:

./nivald --non-interactive --data-dir ./mainnet-data --rpc-bind-ip 127.0.0.1 --rpc-bind-port 38181 --p2p-bind-port 38180 --prune-blockchain --max-concurrency 1

Mainnet seed nodes: 188.137.244.88:38180 and 188.137.243.192:38180. Their availability depends on connectivity; the website requests height and status from its connected node.

Build instructions and command-line options are available in the C++ component sources on GitLab ↗. Do not expose the administrative RPC endpoint to the internet. External connections use the peer port.

Mining, pool and explorer

XMRig connects through CryptoNote Stratum using algorithm rx/0; the native C++ RandomX miner uses the HTTPS work API of the PPLNS pool. Choose the thread count explicitly. It needs only your public Mainnet address, never your recovery phrase or private keys.

The PPLNS pool shares each block reward between participants according to accepted work in a window totaling twice the current network difficulty. A dedicated treasury receives block rewards. After 60 confirmations, balances of at least 0.1 NVL enter an automatic payout batch. The pool fee is 0%; the actual native transaction fee is divided between the recipients of each batch. An orphaned block provides no reward. Your account shows immature, available, reserved and paid amounts, with transaction links for completed payouts.

The pool setup guide generates commands for Windows and Linux, with miner downloads, one-thread defaults and memory options. For pool mining on Linux:

./nival-miner --pool https://nival.cc/api/pool --address YOUR_Niv_ADDRESS --threads 1

The explorer displays blocks, transactions and addresses using node data. It does not store a full blockchain copy. Pool statistics have a storage limit: rotation removes older records while new records continue to be written. Statistics contain no keys and hold no funds. Pool account data, worker addresses and payout amounts are public pool records; using a private blockchain does not hide data you disclose to the pool.

Testing and current limitations

Automated checks cover wallet creation and recovery, transfers, fees, conditional payments, refunds, node operation and crash recovery. Results and limitations are documented in the internal testing log ↗. Internal tests are not an independent security audit.

The daemon stores consensus state in LMDB and supports blockchain pruning. Pruning removes eligible proof data; indexes and current consensus state still grow. Pool statistics and logs rotate independently, while unpaid balances and signed payouts remain in reserved financial journals.

Release history and packages are available on GitLab Releases ↗. Report bugs through GitLab Issues ↗.