Skip to main content

Nxt and Ardor Technical Feature Comparison





Single chain

One parent chain with multiple child chains

Transaction tokens

The same token (NXT) is used for establishing the consensus and providing the security of the blockchain, as well as for the basic unit of value in all transactions

Only the parent chain token (ARDR) is used in the proof-of-stake consensus, and thus provides security for all child chains. Child chain tokens are used as transactional units of value only.

Transaction fees

Transaction fees are paid in NXT only, requiring users to always have NXT in their accounts.

On each chain transaction fees are paid in the native token (coin) of that chain. End users do not need to own ARDR tokens. A business can sponsor the transaction fees for specific child chain or transaction type by running a custom bundler, in which case end users do need to pay fees at all.


Asset Exchange, Monetary System, Aliases, Messaging, Digital Goods Store, Voting System, Shuffling, Data Cloud, Phasing, Account Control, Account Properties

All these features are also present in Ardor, and are available on each child chain.

A child chain can optionally be restricted not to enable some features.

The parent chain supports a limited subset of features, as it is intended to be used for consensus establishing only and not for everyday transactions.


Each passphrase maps to a single account. Passphrases can't be changed, and there is no wallet file to store.

The same mapping of passphrases to account numbers is used as in Nxt. Accounts are global across all child chains, and an account can have balances in each of the existing child chain coins, as well as in Ardor.


There is a single coin (NXT), and unlimited user-issued Assets and Monetary System currencies.

Each chain has its own coin. Assets and MS currencies can be issued on any child chain, and are available for trading globally.

Assets or MS currencies can optionally be restricted* to some child chains only.


Assets and MS currencies can be traded for NXT only.

Assets and MS currencies can be traded on any child chain, with price denominated in the corresponding child chain coin.

Coin Exchange


A new feature, Coin Exchange, allows trading of child chain coins to each other, and also to the parent chain coin (ARDR).


Asset dividends can be paid in NXT, another Asset, or MS Currency.

Asset dividends can be paid in any of the child chain coins, by simply issuing the payment transaction on the corresponding chain. Paying dividends in another Asset or MS Currency is also possible.


Crowdfunding feature is available in the Monetary System, but the funds must be collected in NXT only.

Crowdfunding feature is available on all child chains, and on each child chain the funds are collected in the corresponding coin. Reserve and claim transactions must happen on the child chain the currency was issued on.


Shuffling of NXT, Assets, and MS currencies is available.

On each child chain, shuffling of the corresponding coin, or any Asset or MS Currency, is supported. Shuffling-as-a-Service is provided by an automated Standby Shuffling add-on.


Alias names are globally unique.

Alias names are unique within each child chain only.

MS Currencies

Currency codes and names are globally unique.

Currency codes and names are unique within a child chain only.


Pruning is available for plain and encrypted messages, and for tagged data (data cloud feature). Pruned data are retrieved automatically on demand from designated archival nodes.

Pruning and retrieving of all prunable data is available as in Nxt.

In addition, the child chain transactions themselves are designed to be prunable and will not need to be stored permanently or re-downloaded by every new node. The actual pruning of transactions will be implemented later.*

Transaction identifiers

Transaction IDs are 64-bit longs, and are globally unique.

The 64-bit transaction IDs are no longer guaranteed to be globally unique for child chains. 256-bit transaction hashes (sha256 digests) are used instead as transaction identifiers.

Block generation

A "forging" process is used to create new blocks, with the probability of block creation dependent on the account NXT balance (stake).

The same forging algorithm is used as in Nxt, dependent on ARDR account balances only.



A new process, "bundling", is used to group child chain transactions into a parent chain transaction ("child chain block"), which is then included in the parent chain.

Any account can play the role of a bundler. The bundling process also performs the exchange of fees paid by users in child chain tokens into ARDR fees accepted by the block forgers.


Transaction execution can be made conditional, subject to approval using various voting models.

Same voting models as in Nxt, but phasing is possible on child chains only. Approval transactions can be on a different child chain from the phased transaction, and the by-transaction voting model also supports linking to a transaction hash on a different child chain.

Composite Phasing

Not available, conditional transactions can use only one voting model at a time.

The new "Smart Phasing" feature allows the conditions for the execution of a phased transaction to be combined using AND, OR, and NOT Boolean operators, in a composite voting model. In this way declarative smart contracts can be built on top of the already available voting model primitives.

By-Property Voting Model


A new "by-property" voting model has been added, making the execution of a phased transaction conditional on its sender account having a specified property set. This can be combined with the new Asset Control feature, to allow only authorized or KYC-verified accounts to transact with some asset.

Account Control

Accounts can be restricted to use phasing only (mandatory approval).

Same as in Nxt, but accounts under phasing-only restriction cannot submit transactions on the parent chain, as those cannot be phased.

Asset Control


The asset issuer can impose a phasing-only restriction on all transactions affecting the asset. This allows enforcing shareholder agreements that require shareholder approval, or board of directors approval, on all transactions with company shares.

Child Chain Control


Child Chain Control can be used to make a child chain permissioned, with configurable user authorization levels, allowing the chain administrators to grant or revoke transaction privileges to the users of such permissioned child chain.

Shamir Secret Sharing


The Ardor platform support the use of Shamir Secret Sharing for splitting an account passphrase into several pieces, and reconstructing it from only a few of those pieces.

Lightweight Contracts


Lightweight Contracts represent a framework for developing a layer of automation on top of the existing Ardor APIs. Lightweight Contracts do not run on all nodes, only on those who elect to execute them. Being stateless, contracts do not store data on the blockchain and do not manipulate blockchain objects directly, but only submit standard blockchain transactions as a result of their execution.

Transaction Vouchers


Users can request a payment by preparing a digitally signed transaction template (voucher), and sending it to the payer off-blockchain. The payer then simply loads the template, verifies the amount and other details, signs and submits the transaction.

Peer Networking

HTTP based, also with WebSocket support, transmitting JSON formatted data between peers.

Completely re-written and optimized, using native Java sockets and binary messages between peers. Block and transaction propagation has been significantly improved, by exchanging and caching information about currently available blocks and transactions between peers and only propagating the missing data pieces.


HTTP query APIs, returning JSON formatted response.

Mostly unchanged, except:

1. A "chain" parameter has been added to each API that is child chain specific.

2. 64-bit long transaction IDs have been replaced with 256-bit hashes.

3. All prices and rates that were previously defined relative to the smallest indivisible holding amount ("QNT") are now defined relative to a unit of the holding (share).


Transactions are stored in the blockchain permanently, and need to be re-downloaded and re-processed by every new node, which after months and years of operation becomes a significant bottleneck.

All child chain transactions will be possible to prune completely, without affecting blockchain security, thus allowing the blockchain size to be kept much smaller. A new node joining the network only needs to download the parent chain transactions, followed by the latest snapshot of the current system state.*

*Functionality marked with asterisk is planned to be implemented in a future Ardor release. All other functionality is already available in production.