Ardor Software Change Log

From ArdorDocs
Jump to: navigation, search
Other languages:


This is a bugfix release, addressing an issue with the Standby Shuffler add-on. The recipient public keys were incorrectly generated with an \r character appended to the user-supplied secret phrases, resulting in actual recipient accounts different from what was displayed in the UI.

For users of the Standby Shuffler add-on who already had their shuffling recipient account affected by this issue, a simple RecoverFunds API has been added. Use that API with the secretPhrase of the intended shuffling recipient account to automatically transfer your shuffled coins to the correct recipient.

Fixed version update hash validation.


This release introduces the StandbyShuffler add-on, a new feature intended to simplify the use of our flagship privacy feature, fully decentralized and trustless Shuffling.

New feature: StandbyShuffler

A StandbyShuffler, as opposed to a regular Shuffler, does not start a new shuffling immediately, but runs in the background and waits for other users to start a shuffling which matches the StandbyShuffler parameters - holding (coin, asset or currency), minimum and maximum amounts, and number of participants. When such a shuffling is created, the StandbyShuffler joins it automatically. A StandbyShuffler is configured on start with a number of recipient public keys to use as recipients in each shuffling it joins, and shuts down once all have been used.

Running a StandbyShuffler requires a full node, not just a light client. To enable the StandbyShuffler add-on, add nxt.addons.StandbyShuffling to the list of enabled add-ons in the nxt.addOns property. This add-on registers three new APIs:

  • StartStandbyShuffler - start a StandbyShuffler. The secretPhrase of the shuffling account must be supplied. The holdingType and holding parameters define the coin, asset or currency for which to listen for shufflings being started. The optional minAmount, maxAmount and minParticipants parameters can be used to limit which shufflings to join. The recipientPublicKeys parameter holds one or more public keys, used one at a time as a recipient account public key each time a shuffling is joined. This can be specified either as a multi-value parameter, or a single text value holding multiple public keys separated by newlines. The feeRateNQTPerFXT parameter specifies what rate to use when calculating the child chain fees for each shuffling transaction submitted. Since the market rate can change between when the StandbyShuffler is started and an actual shuffling is joined, one should use a high enough rate to make sure shuffling transactions of the StandbyShuffler account are always bundled.
  • GetStandbyShufflers - returns a list of all StandbyShufflers running on the node, optionally filtered using holdingType, holding and account parameters. If not running locally, a secretPhrase or admin password are required.
  • StopStandbyShuffler - stops the StandbyShuffler for a specified account and holding or all StandbyShufflers running on the node if account is not specified. If not running locally, a secretPhrase or admin password are required.

An UI for starting, observing, or stopping StandbyShufflers has been added under Shuffling / My StandbyShufflers.

To automate starting the configured StandbyShufflers when the node is restarted, a set of StartStandbyShuffling, SaveStandbyShufflingEncrypted, and StartStandbyShufflingEncrypted add-ons has been provided.

StartStandbyShuffling automatically starts one or more StandbyShufflers as defined in a file set in the nxt.startStandbyShufflingFile property. The format of this JSON file is the same as the JSON output of GetStandbyShufflers, with secretPhrase field added for each StandbyShuffler, thus the simplest way to generate it is first to setup StandbyShufflers as required and then save and edit the GetStandbyShufflers response.

Alternatively, to avoid keeping the secretPhrase and recipient public keys in a plain text file, the SaveStandbyShufflingEncrypted add-on can be used to save the StandbyShufflers configuration JSON in an encrypted file, and the StartStandbyShufflingEncrypted add-on to start them by submitting the decryption password through the API.

Added ChangeNOW

Added ChangeNOW as an integrated exchange in the wallet, allowing exchange of Ignis and Ardor to any coin supported by ChangeNOW.

More features and improvements

  • Pause forging if there are not enough connected peers from which to download the blockchain, as defined in nxt.numberOfForkConfirmations or nxt.testnetNumberOfForkConfirmations, unless nxt.isOffline=true. This is to avoid building a fork if the node is temporarily disconnected. To disable this behavior, set nxt.pauseForgingOnNoConnection=false (default is true).
  • Do not allow accounts under account control to start a Funding Monitor.
  • The SaveBundlingEncrypted, SaveForgingEncrypted, SaveFundingMonitorEncrypted APIs now require admin password when running on a remote node.
  • Added a list of full transaction hashes with chain ids to the response of the getUnconfirmedTransactionIds API.
  • Added a new bundling filter, nxt.addons.TransactionTypeBundler, which bundles only transactions of the transaction types specified in the filter parameter. The parameter must be a comma separated list of <type>:<subtype> pairs with the "type" and "subtype" of the whitelisted transaction types.
  • Improved propagation of bundler rates between peers and calculation of best bundler rates. The CalculateFee, GetBundlerRates, and all CreateTransaction APIs now take both minBundlerBalanceFXT and minBundlerFeeLimitFQT parameters, with defaults based on the nxt.minBundlerBalanceFXT (default 1000 ARDR) and nxt.minBundlerFeeLimitFXT (default 10 ARDR) properties. Bundlers with effective balance lower than minBundlerBalanceFXT, or remaining fee limit or available ARDR balance lower than minBundlerFeeLimitFQT, are excluded from the best rates calculation.
  • Shamir secret sharing passphrases can now be used to sign transaction vouchers.
  • Updated Jetty to version 9.4.18. This release fixes a Jetty bug which causes a server hang after high load, therefore an update is highly recommended.
  • The Jelurida Public License has been updated to version 1.2, to clarify that Ardor code is not portable to Nxt clones unless the JPL requirements for Ardor are also satisfied (article 3.4.2 of the General Conditions), and to require that airdrops, including the fact that they are done in order to satisfy the JPL, are announced at least a month before the planned snapshot date (article 2.2 of the Special Conditions).


This release adds multiple usability enhancements, optimizations and bug fixes. For users of 2.2.1 or 2.2.2, upgrade is optional but highly recommended.

New feature: Shamir Secret Sharing

Shamir Secret Sharing support is now enabled for both client and server. It allows splitting a passphrase into N pieces out of which only K are required to restore the original secret. This technique is useful to protect the full passphrase from key loggers on the client workstation and from eavesdropping during transport to a remote node. Shamir Secret Sharing is also useful for the creation of fragmented backups, by storing each piece in a different physical place or with a different trusted party, with at least K of them required to recover the full passphrase.

Secret share splitting and combining is supported both on the server side using the node APIs, and client side in the wallet, so that secrets split on one side can be combined on the other.

Client side:

  • When printing a paper wallet, a new dialog enables setting the total number of secret pieces to generate from a passphrase, and the number of secrets required to re-combine a passphrase. These secrets are then printed into separate pages of the paper wallet.
  • For all dialogs which accept entry of a passphrase the user can now check the "Shared Secret" checkbox, then enter or scan the required number of secret pieces to combine the original passphrase in memory.

Server side:

Any API which accepts the "secretPhrase" parameter can now accept instead multiple "sharedPiece" parameters which the node will combine into the original passphrase in memory. A node can keep some of the secrets in its configuration file while accepting other secrets using API parameters. To configure this setup for account address X, split your passphrase into several pieces then list some of the pieces in a semicolon separated list as the value of the property nxt.secretPhrasePieces.X. When using the API, submit the parameter sharedPieceAccount=X where X is the account address, and also submit the remaining required pieces using multiple sharedPiece parameters. This configuration enables you to start forging, bundling, etc, on a remote node without ever transmitting the full account passphrase to it over the internet.

New APIs for Shamir Secret Sharing:

  • Use the splitSecret API to split a passphrase into pieces.
  • Use the combineSecret API to combine secret pieces to the original passphrase.


Due to enhancements to the underlying API caller infrastructure all lightweight contracts have to be recompiled and redeployed in order for a contract runner running this version to be able to execute them correctly.

Any other code using the API callers must also be recompiled.

UI improvements

  • When loading a transaction voucher it is now possible to attach an encrypted message to yourself, and to recalculate the transaction fee. It is now also possible to not immediately broadcast voucher transaction, for the purpose of offline signing.
  • The coin exchange displays the inverse rate in the "Buy" dialog, and as a tooltip when hovering with the mouse over any price field. Expected orders and order cancellations (unconfirmed or phased) are displayed in the order book with a special icon to their left. Left pane balances are updated with each new block.

The order of columns was changed so that the "Sum" column displays the coin to buy, clicking the "Sum" column updates the amount to buy accordingly. Red warning is displayed when typing an amount to buy which requires larger balance than the available balance. Total field is limited to 8 decimals.

  • The dashboard transaction view was improved to reduce appearances of duplicate transactions when the transaction moves from unconfirmed to confirmed status.
  • Support login by alias and recipient alias for any alias. If not an account alias, map the alias to the alias owner account. Since any alias owned by an account can now be used as an alias to the account, this release deprecates the so-called "account" aliases, and we will remove support for them in the next release.
  • Approximate leasing expiration date is displayed in the Account Leasing tab.
  • A new Account Properties tab has been added to the account info modal, displaying all properties set on the account.

Networking and performance improvements

As a result of our extensive load testing efforts, this release includes several network stability improvements and performance optimizations.

New add-ons to simplify automated and secure running of tasks on remote nodes:

  • A set of custom add-ons to automate forging, bundling, and funding monitors has been include in this release.
  • The StartForging add-on reads the passphrases stored in a plain text file, as defined in the property nxt.startForgingFile, one passphrase per line, and automatically starts forging with each of these accounts when the server is started. Since passphrases are stored unencrypted, this add-on should only be used on well secured servers, or with accounts of insignificant value, or in test environments.
  • For a secure way of starting forging with multiple accounts on a remote server, the SaveForgingEncrypted add-on can be used to store the passphrases of forging accounts in an encrypted file, and the StartForgingEncrypted add-on to start forging with them by only submitting to the server the password necessary to decrypt this file. Note that at runtime, the forging account passphrases will still be kept in server memory, but when using these add-ons will never need to be stored on disk, and will not need to be re-submitted to the server each time forging needs to be started. These add-ons are useful when forging on a fully trusted node, and having to restart forging remotely without a risk of exposing the passphrases in transit.
  • The StartBundling add-on reads a list of Bundlers stored in a JSON formatted file, as defined in the property nxt.startBundlingFile. The exact JSON can be initially generated by manually starting the bundlers configured as desired, including any custom bundling rules, and using the GetBundlers API to retrieve the list of bundlers in JSON format. The only manual modification required is to add a "secretPhrase" parameter to the JSON for each bundler, with the corresponding account secret phrase. On server start, the StartBundling add-on will automatically start all bundlers as configured.
  • Similarly to the above forging add-ons, the SaveBundlingEncrypted and StartBundlingEncrypted add-ons can be used to store the JSON configuration of bundlers in an encrypted instead of plain text file, and start the bundlers on submitting the decryption password to the server.
  • Finally, for automating funding monitors, the StartFundingMonitors add-on will automatically start all funding monitors configured in a JSON formatted file, as defined in the property nxt.startFundingMonitorsFile. The JSON can be generated by manually starting the funding monitors as desired, and using the GetFundingMonitor API to retrieve the list of monitors in JSON format. Again, the secretPhrase parameter needs to be manually added to the JSON for each funding monitor.
  • The SaveFundingMonitorsEncrypted and StartFundingMonitorsEncrypted add-ons allow storing the JSON configuration of funding monitors in an encrypted instead of plain text file, and starting the funding monitors by submitting only the decryption password to the server.

Other improvements

  • The CalculateFee API now also returns the required child chain fee based on the best bundling rate available, as feeNQT.
  • The JPLSnapshot add-on has been ported to Ardor. It can be used to generate a JPL-compliant snapshot of Ignis child chain balances.
  • Starting a funding monitor or shuffler with feeRateNQTPerFXT=0 is now allowed.

Library updates

  • Updated Jetty to version 9.4.17, Bouncy Castle to 1.61, and H2 database to 1.4.199. With the new H2 release, using MVStore mode is the default. However, conversion of existing databases to MVStore format is not automatic. To migrate to the new storage format, the easiest way is to use the or compact.bat script, which should take a few minutes, and will also improve the database performance.


This is a bug fix and usability enhancements release.

Users still using version 2.2.0e or earlier must upgrade immediately as they are already on a fork, and their nodes are blacklisted by this release.

Anyone who did not upgrade to 2.2.1 prior to block 543000 must manually delete and re-download the blockchain from scratch, after upgrading.

Users using version 2.2.1 are not required to upgrade.


  • Added an includeContract parameter to the getContractReferences API to return metadata about the actual contract being referenced.
  • The contract runner now removes the last block when started to make sure trigger transactions in the last block are processed in case processing stopped before processing the contracts for this block.
  • Contract unit tests now use simpler methods for verifying transactions submitted by a contract.
  • The contract manager now waits until the transactions it submitted are included in a new block before exiting.
  • Contracts with an inner interface and an inner class implementing it are now supported.
  • The contract processRequest callback now supports initializing a randomness source and accessing the last block.
  • Fail gracefully when a contract submits the messageToEncrypt parameter without a passphrase. Contract devs should encrypt the message first then submit the encrypted data.

UI Enhancements:

  • Contract selection widget and contract parameter specification template were added to dialogs which specify a recipient field. This enhancement simplifies the task of configuring a contract trigger transaction.
  • The Contracts page now provides simple runtime statistics about contract execution when clicking on any of the invocation types in the Invocation column.
  • Each chain now has a chain description displayed in the wallet and when switching between chains.
  • Login by account using an Ignis alias is now supported by deleting the ARDOR prefix then typing '@' in front of an existing alias name which is mapped to an account id.
  • "Fat Finger" warning for amount and fee is now defined and enforced per chain. Reasonable default values were defined. Use the account settings page to adjust these values for the current chain.
  • Dialogs now support more than one warning per form submit. For example in case both the amount and the fee are too high, both warnings are displayed one after the other.
  • The wallet no longer warns about assets and currencies with more than 6 decimals.
  • The Changelly menu items was moved from a top level menu to the settings menu to provide more screen real estate for the mobile app.
  • Increase and delete shares links are displayed in the "My Assets" page only when these actions are allowed.
  • Vouchers with unicode parenthesis are now parsed correctly.
  • The desktop wallet now displays a file chooser dialog before downloading a cloud data item or message attachment to the local workstation.
  • The transaction and block info dialogs now display the raw transaction and block json in a separate tab.
  • Coin exchange layout improvements.


  • Fixed an initialization issue that could cause some custom add-ons to deadlock on start.
  • Fixed false positive unsigned bytes verification error when cancelling ARDR buy order.
  • The getPeers and dumpPeers APIs now also allow filtering by version, optionally including newer versions.
  • Added a checkpoint at block 545555.
  • Updated Jetty to version 9.4.14.


This release adds support for the new Max Crowdfund (formerly Dominium) child chain, token name MPG, to be activated at block 543000 expected to be reached on January 10, 2019.

At the same block, the new Lightweight Contracts and Asset Properties features will also become enabled on mainnet.

Transactions with asset 6066975351926729052 (old CtC) will be disabled and open orders cancelled.

Revealing a secret using the ApproveTransaction API will now approve all phased by hash transactions which specified the hash of this secret regardless if they are listed in the phasedTransaction parameter or not.

A new GetHashedSecretPhasedTransactions API will return a list of phased by hash transactions with phasingHashedSecret and phasingHashedSecretAlgorithm as specified.

This is a stable release and a mandatory upgrade for all nodes, with block 543000 (Jan 10) as final deadline.

Lightweight Contracts:

Contract validations now use Java annotations. The following annotations are available:

  • @ValidateContractRunnerIsRecipient - checks that the contract runner account is the recipient of the trigger transaction.
  • @ValidateContractRunnerIsSender - checks that the contract runner account is the sender of the transaction.
  • @ValidateChain - checks that the chain of the trigger transaction is in the accept array and is not in the reject array.
  • @ValidateTransactionType - checks that the type of the trigger transaction is one of the types in the accept array and is not one of the types in the reject array. A new TransactionTypeEnum class lists all available transaction types and sub types.

See the HelloWorldForwarder sample contract for usage example of the validations

The contract runner getSupportedContracts API was enhanced to return more meta-data about the running contracts including the supported invocation types, contract invocation parameters, and contract validations. This information can be used by clients to provide better user experience by analyzing the contract capabilities and helping the user properly trigger the contract.

Contracts can override the built-in duplicate checks for transactions submitted by a contract by overriding the isDuplicate() method. Oracle contracts should implement this method to make sure they do not submit the same transaction more than once with different data. See for example the IgnisArdorRates contract.

Added uploadContractRunnerConfiguration API to let contract runner node admin upload the contract runner config after starting the node. This way contract runner nodes no longer need to store the contract runner account passphrase or other sensitive data on the node itself. Instead, they can upload it after starting the node from the contracts page in the wallet. The format of the uploaded configuration file is the same as the existing contracts.json format.

To prevent a contract runner from locking user funds permanently in the contract runner account in case the contract does not execute, contract transactions can be submitted with phasing by hashed secret. The contract runner will submit its own transactions using the same hashed secret and other phasing parameters. The trigger transaction, and transactions submitted by the contract in response, are either approved together or rejected together. If a transaction is not approved when reaching its finish height, its funds are released back to the sender.

To assist with generating secure secrets to hash, a new secret generator wizard was added to the wallet approval modals dialog. Generated secrets are not saved by the client. A secret can be reproduced by the client in case it was lost, using the account passphrase used when generating it.

The parameter injection introduced in version 2.2.0e was replaced with a more robust solution based on an interface. In the new design, invocation, setup and runner parameters are defined using an inner interface decorated with the @ContractParametersProvider annotation. For each contract parameter create a default method which defines its name, data type and default value, decorated with a contract parameter annotation:

  • @ContractInvocationParameter - specified by a trigger transaction or voucher.
  • @ContractSetupParameter - specified by the contract reference.
  • @ContractRunnerParameter - specified by the contract runner configuration.

To load the contract parameters from inside your contract code use the following statement:

  • Params params = context.getParams(Params.class);

Where Params is the inner interface decorated with @ContractParametersProvider annotation.

Due to interface changes introduced by this release, all existing contracts will have to be redeployed on testnet and contract runners using a previous version won't be able to run contracts deployed using the current version.

UI Enhancements:

A contracts page was added to the wallet to list the information provided by the getSupportedContracts API. This page is available only when the wallet is connected to a contract runner node.

Asset properties UI was implemented accessible from the "Asset Properties" link on the asset exchange page. Users can use it to set, update, and delete asset properties.

When entering recipient address in the client wallet use the @ prefix to point to an existing Ignis alias which stores the account id. In previous versions the alias was loaded from the current chain.

The contacts button to the right of the recipient field now lists all the remembered accounts in addition to the defined contacts.

Updating to this release from 2.2.0e may cause a one time shutdown on first start in order to fully apply the database changes


This is an experimental release, and a MANDATORY upgrade for all testnet nodes. It can also be used on mainnet.

Added Asset Properties feature, to be activated at block 455000 on testnet only.

Asset Properties allow attaching metadata to assets, in the form of name/value pairs. The property name can be up to 32 characters, and property value up to 160 characters in length. Anyone can set a property on an asset. Only the asset issuer, or the setter of the property, can delete a property. The setter of a property can edit it by setting a new property with the same name.

New APIs: SetAssetProperty, DeleteAssetProperty, GetAssetProperties.

Implemented freezing of assets and currencies, to be used for tokens that are scheduled to become child chains, or need to be deactivated for other reasons.

Freezing of arbitrary assets or currencies is not (and will not be) supported. The freezing of a particular holding must first be enabled in a new release, and is then triggered at a predefined height, optionally specified as asset property for assets, or account property for currencies.

After the freeze height, no further transactions with the frozen holding are possible (with the exception of setting or deleting asset properties). Freezing is not reversible.

Implemented migration of a frozen asset or currency to a new child chain. The migration of a particular holding must first be enabled in a new release, and is then triggered at a predefined height, optionally specified as asset property for assets, or account property for currencies.

Implemented loading of account balances for new child chains. The Dominium child chain will be launched on testnet at or after block 455000, with testnet balances allocated to developer accounts only.

Fixed loading transaction voucher which contains attached encrypted message.

Node log file name changed from nxt.log to ardor.{n}.log where {n} is the log file number. The current log file is always named ardor.0.log. Up to 10 log files are kept.

The windows startup script run.bat no longer relies on the windows registry when looking up the Java version.

Lightweight Contracts:

The contract runner now executes contracts in their own sandbox which restricts the contract permissions based on a standard Java policy file named ardor.policy By default contracts allowed to connect to any address, and read, write and delete files in the temp folder of the contract runner workstation. Direct access to the local workstation, or the local blockchain not through the APIs is blocked by default. The contract runner operator can grant additional permissions per contract or for all contracts submitted by a specific account. See examples in ardor.policy file.

Added support for deployment and verification of single source file contract which compiles into multiple class files. The contract classes are automatically packaged into a Jar file when deployed to the blockchain. Similarly verification of the contract unpacks the Jar and compares individual class files.

Parameter injection is now supported using the ContractInvocationParameter, ContractSetupParameter and ContractRunnerParameter annotations. This reduces contract boiler plate code for reading parameters.

Contract class selector was added to the contract manager plugin. Users upgrading from a previous release will need to redeploy the IntelliJ plugin after installing this version. The plugin version should be 2.2.0.

Contract runner parameters can be specified in the file using the addon.contractRunner. prefix. The contracts.json configuration file is now only used when specifying secret contract runner parameters so can be ignored in most configuration.

It is no longer required to define contracts which do not setup parameters in the contract.uploader.json file.

See: for more details and examples.

Due to interface changes introduced by this release, all existing contracts will have to be redeployed on testnet and contract runners using a previous version won't be able to run contracts deployed using the current version.

On testnet only, after block 455000 the average block time will be reduced to 10 seconds. This is to allow faster testing and development, and to test the feasibility of reducing block time should the need arise on mainnet.


This is a critical bugfix release. IMMEDIATE update is mandatory for everyone. Fixed validation of string fields length in transaction attachments.

This is a stable release and should be used for mainnet nodes too, however lightweight contracts are still available only on testnet.

Changelly exchange integration is now available in the Ardor wallet:

Changelly Integration

Javadoc is now available for sample contracts and API callers


This is an experimental release. It is a mandatory upgrade only for testnet nodes, but can also be run on mainnet. On testnet, a hardfork to enable the lightweight contracts feature has been scheduled at height 341500.

First release of lightweight contracts and transaction vouchers. Refer to the nxt wiki for official documentation.

The bundling of transactions has been significantly enhanced to support more flexible bundling filters and fee calculations rules. Multiple bundling filter classes can be defined in the nxt.availableBundlingFilters property.

The following predefined bundling filters are available by default:

nxt.addons.PersonalBundler - bundles only the transactions of the bundler account.

nxt.addons.AccountPropertyBundler - bundles only transactions sent by accounts which have the "bundling" property set on them by the bundler account.

nxt.addons.AssetBundler - bundles only transactions involving the specified asset.

nxt.addons.CurrencyBundler - bundles only transactions involving the specified MS currency.

nxt.addons.PurchaseBundler - bundles only purchases of digital goods sold by the specified account.

nxt.addons.QuotaBundler - bundles transactions until reaching a quota per sender and transaction type.

The startBundler API has been modified to accept an optional "bundlingRulesJSON" parameter, in which the list of bundling rules can be defined in JSON format. Alternatively, a single bundling rule can be defined using a "feeCalculatorName" and one or more "filter" parameters.

A new addBundlingRule API has been added to allow clients without JSON support to run bundlers with more than one rule, by adding rules to an already started bundler.

More than one filter is allowed per rule. The rule is executed only if all filters allow the transaction.

The lists of available bundling filters and fee calculators can be retrieved using the new getBundlingOptions API.

The Bundlers page has been enhanced to support the new bundling rules and filters features in the client UI.

Account property with name "nrs_recipient_ui_options", set by the recipient on itself is now used to configure the modal when sending funds to that account. This can be used instead of the "#merchant:" account description and allows control over the message encryption, such as disabling it for exchange accounts. The value of the nrs_recipient_ui_options property is a JSON object with fields: - - message_format: same as the format specifier in the #merchant account description - - encrypt_message: default value for the encrypt message box - - encrypt_message_disabled: if true, the encrypt message box is disabled

Don't show permanent message option on ARDR chain since permanent messages are disabled there. Fixed verification of prunable messages on ARDR.

IGNIS is now the default chain when loading the wallet for the first time.

Support compilation with Java 10 and language level 9.

Updated translation resources and removed old translations.

Added a checkpoint at height 221000.

Renamed the BITSWIFT child chain to BITS.

Updated Jetty to version 9.3.24 and Bouncy Castle to 1.60. Delete the old lib folder if installing on top.


Multiple client UI bugfixes and enhancements:

Correct coin order cancellation fee calculations when the exchange coin is ARDR and correct fee coin label in the buy and cancel modals.

Format amount and fee according to chain decimals in transactions tables.

Fixed server calculated exchange rate to display according to locale numeric formatting.

Added the buy orders side to the coin exchange, improved layout of the coin exchange page.

Fixed update of account balances per chain.

Fixed alias offer to any account. Fixed decryption of DGS goods.

Added Ardorgate EULA and privacy policy checkboxes and links.

Improved the "not enough funds" error message.

Fixed sending of transactions when running as light client.

Added UI for blacklisting bundlers.

Do not process or propagate bundler rates when running as light client.

Do not load genesis block json when running as light client, for faster initial startup.


Bundlers page UI improvements and bugfixes.

Added AccountPropertyBundler add-on, which only bundles transactions sent by accounts having the "bundling" property set on them by the bundler. To enable, set nxt.bundlingFilter=nxt.addons.AccountPropertyBundler. This will apply to all bundlers started on this node.

Added minimumFeeFQT field to the response for all Create Transaction APIs, indicating the minimum required fee in ARDR, regardless of the actual fee specified by the sender.

Desktop wallet performance optimizations to reduce excessive load.

Local signing and validation bugfixes, other minor code improvements.


Fixed setting the ecBlock parameter used when doing local signing for remote nodes, light clients, and mobile clients.

Coin exchange totals are now trimmed according to the chain decimals.


This release blacklists peers older than 2.0.10, and adds a checkpoint at height 6000.

Changed Open Coin Orders to My Coin Orders in the Coin Exchange, sort orders per chain then per rate descending, added pagination.

Always make prunable messages prunable regardless of their length, if the "message is never deleted" checkbox is not checked.

Added Mistertango withdrawal UI to the AEUR child chain, not yet functional.

Increased default number of fork confirmations to 5.

Other minor bugfixes and improvements.

This release will perform a database rescan.


This is a bugfix release, mandatory update for all nodes.

Fixed an issue with block pop-off handling, which can result in a node unable to continue downloading the blockchain after encountering an error condition.

Fixed processing of alias transfer transactions.

Fixed exchange price handling affecting some coin exchange trades.

Show correct total coin amounts for each chain.

Other minor bugfixes and improvements.

This release will perform a database rescan.


First production release of the Ardor Blockchain Platform.

The Ardor Genesis Snapshot has been taken at Nxt blockchain height of 1636363.

The Genesis timestamp is set to 00:00:00 UTC, Jan 1st 2018. Everyone with ARDR balance >= 1000 is invited to setup a node and start forging. Block generation will start automatically when the Genesis timestamp is reached. In the meantime, please check your balances and report any discrepancies from what you expected.

To simplify processing of phased transactions, the getExecutedTransactions API now returns the transactions ordered by the height at which they were executed, not at which they were included in the blockchain.


This release is a mandatory upgrade for all Ardor testnet nodes. It involves a reset of the existing testnet and starts from a new genesis block.

The new testnet genesis block is based on a snapshot of the Nxt blockchain at height 1631000. Forging on testnet is set to start at 14:00 UTC, Dec 26.

The number of decimals for the AEUR child chain has been changed to 4.

Login UI bugfixes and improvements. Increased initial heap size to 256M.

As this release requires a full reset of testnet, the nxt_test_db folder must be deleted before installation.


This release is a mandatory upgrade for all Ardor testnet nodes. It involves a reset of the existing testnet and starts from a new genesis block.

The new testnet genesis block is based on a snapshot of the Nxt blockchain at height 1624000. Forging on testnet is set to start at midnight UTC, Dec 22.

The BTC and USD testnet child chains have been removed, for consistency with the expected production child chains. The EUR child chain has been renamed to AEUR, with 2 decimals. Child chain ids for AEUR and Bitswift have changed to 3 and 4 respectively.

The child chain transaction types that affect only global platform entities and do not involve pricing or transfer of value are now allowed only on the IGNIS child chain. Such transactions currently are: asset issuance, setting account info, setting account properties, asset share increase, setting asset control, setting account control.

All fees have been reviewed and updated. Most fees have been decreased significantly, with the default Ardor chain fee set to 1 ARDR, and the default child chain fee to 0.01 ARDR.

Node JS module bugfixes.

Updated Lucene to version 7.1.0.

As this release requires a full reset of testnet, the nxt_test_db and the lib folders must be deleted before installation.


This is a feature-freeze release for the Ardor testnet. No more API changes or feature additions are planned before launch, only bug fixes.

The source code is now included in the package, for a public review, under a temporary evaluation license only.

Added getExecutedTransactions API. This new API accepts parameters: "chain", "height", "numberOfConfirmations", "type", "subtype", "sender", "recipient", "firstIndex", "lastIndex", and returns the transactions from the specified chain executed at this height, or executed with at least that many number of confirmations. Both non-phased and phased transactions are returned. For phased transactions, only those approved and executed at the specified height, or approved with at least that many confirmations of the final approval transaction, are returned. If height is specified, sender or recipient parameters are optional, otherwise at least one of them is required.

Fixed UI bugs - base target calculation, missing asset control setup, asset control local signing, calculation of deadline when doing manual transaction bundling.


This release is a mandatory update for all Ardor testnet nodes. It will perform a rescan on first start.

Client UI improvements for the new asset control, composite phasing, and asset increase features.

The default transaction deadline has been reduced to 15 min instead of 24 h.

Mobile app now connects to by default.

Use ARDOR as default account prefix. Using NXT or any other prefix continues to be supported for logging in.

Allow whitelisting of specific bundler accounts using the property nxt.bestBundlerRateWhitelist. If set, only bundler rates announced by the whitelisted accounts will be used.

Fixed bugs in peer networking, parsing genesis block json, by-property voting.


This Ardor platform release introduces several important new features. It is for testnet only, and involves a reset of the existing testnet and starting from a new Genesis block.

Major new features:

Asset Control

Similar to Account Control which once set requires all transactions of an account to be subject to approval (i.e. to use phasing), the new Asset Control feature allows imposing such restriction to all transactions involving a given asset - such as placing bid and ask orders, transfers, share deletions, and dividend payments that use the asset as a dividend. This feature enables for example a private company to issue its shares on the Ardor blockchain, yet to impose control over who can purchase or sell them, for example requiring asset transactions to be approved by its board of directors, or a shareholder voting. It also allows asset issuers to be KYC compliant, by only allowing verified accounts to transact with their assets.

Composite Phasing

The Composite Phasing ("Smart Phasing") is a very powerful new feature that allows approval models for conditional transactions to be defined in terms of a Boolean combination of other approval models, i.e. allows joining the current primitive approval models such as by whitelist, by asset balance, by hash, etc, using the AND, OR, and NOT operators. This allows the new Asset Control feature to be used in combination with the Account Control feature when required, the transaction execution being made conditional on satisfying both the Asset Control and Account Control settings. It also allows for example combining the existing by hash or by transaction approval models with by whitelist, by balance, etc, approvals, which enables doing atomic coupling of transactions (including cross-blockchain) even for multisignature accounts (i.e. subject to Account Control), or with assets subject to Asset Control. The NOT operator allows for dead-man-switch type conditions, where a transaction is executed only if some condition (e.g. revealing a secret) is not satisfied.

By-Property phasing

The new by-property approval model allows the transaction execution to be made conditional on the sender account or the recipient account having a specific account property set. If this property is set, the transaction will be executed immediately, else, a second check whether the property is set is performed at the finish height defined. This allows for example enforcing KYC by asset issuers, who can define in their Asset Control settings that only KYC-verified accounts, labelled with a predefined account property by a trusted authority (or the asset issuer itself), to perform transactions with their assets.

Asset share increase

A new transaction type has been added, allowing the asset issuer to increase the total number of asset shares in existence. The new shares are allocated to the asset issuer account, but can be then distributed to shareholders using a separate dividend payment transaction. This allows corporate actions such as capital increases or stock splits to be performed.

Imports from Nxt blockchain

To test the snapshot process planned for the production Ardor release, this testnet release is based on a Genesis block created from a snapshot of the production Nxt blockchain as of block height 1558030. The following records have been imported:

- Accounts public keys

- Account balances. ARDOR chain balances are based on ARDR asset balances, and IGNIS chain balances are based on NXT balances divided by 2, plus JLRDA asset balances. Each of those has been additionally divided by 2, in order to allocate 50% of the testnet coins to developer accounts for testing purposes. BITSWIFT chain balances are based on Bitswift asset balances, plus a 10% airdrop distributed proportionately to all IGNIS holders.

- Account info (name and description)

- Account properties

- Account control settings, but only for account control by whitelist with no minimum balance. Other types of account control will not be imported.

- Account aliases have been imported to the IGNIS child chain.

- Assets. Only the Janus, JanusXT, and ComJNSXT assets have been imported, with their asset ids preserved.

- Monetary system currencies have been imported to the IGNIS child chain, but only the currency code and name, in order to reserve those. It would be up to each currency issuer to re-issue the currency with the appropriate properties and re-distribute it to users.

Modified APIs:

GetAssetDeletes has been replaced with GetAssetHistory, with "deletesOnly", and "increasesOnly" optional parameters to retrieve only share delete or share increase history events.

ApproveTransaction now takes multivalued revealedSecret parameter, to allow revealing multiple secrets for transactions using composite phasing.

SetPhasingOnlyControl now optionally also accepts the account control phasing parameters in a JSON format, as a single "controlPhasing" parameter.

All CreateTransaction API now optionally also accept the transaction phasing parameters in a JSON format as "phasingParams" and "phasingSubPolls" parameters.

For by-property phasing, the following new parameters have been added: "phasingSenderPropertySetter", "phasingSenderPropertyName", "phasingSenderPropertyValue", "phasingRecipientPropertySetter", "phasingRecipientPropertyName", "phasingRecipientPropertyValue".

For composite phasing, the boolean expression can be supplied in Disjunctive Normal Form as "phasingExpression" parameter, with no parentheses, variables in format [a-zA-Z][a-zA-Z0-9]* and operators "&" (AND), "|" (OR), "!" (NOT).

For each variable appearing in the boolean expression, the phasing parameters of its sub-poll can be specified as separate parameter with prefix "phasing<variable name>", or as JSON in the "phasingSubPolls" parameter.

New APIs:

IncreaseAssetShares - create new asset shares. Only the asset issuer can submit a share increase transaction.

EvaluateExpression - evaluates a Boolean expression, for use in composite phasing.

ParsePhasingParams - converts phasing parameters, submitted as HTTP request parameters, to a JSON format.

GetPhasingAssetControl - returns the phasing control for a given asset, if set.

SetPhasingAssetControl - set or unset phasing control for an asset. Only the asset issuer can change asset control settings. If an asset is not under asset control, a new asset control can only be set if all shares are currently owned by the asset issuer.

Ported various bugfixes and improvements from Nxt up to version 1.11.9.

Updated jetty to version 9.3.22, bouncycastle to 1.58, and the izpack installer to version 5.1.2.

Since this release requires a full reset of testnet starting from a new Genesis block, if upgrading from 2.0.3e or earlier, in addition to the lib folder the nxt_test_db folder must also be deleted. The import of snapshot balances on first start may take a few minutes and should not be interrupted.

The testnet Genesis block timestamp has been set to 00:00 (midnight) UTC time on Monday, Nov 6th, in order to allow time for users to setup nodes check their balances, and start forging. Block generation will commence automatically once that time has been reached, and only then it will become possible to create and send new transactions.


Minor unconfirmed transaction processing improvements.

Coin Exchange UI improvements and bugfixes.

Updated jetty to version 9.3.17.


This release introduces an incompatible networking change in bundler rates propagation and is therefore a mandatory update for all Ardor testnet nodes.

Improvements in bundler rates handling and APIs:

The GetBundlerRates API now also returns the bundler account and the remaining fee limit for each bundler as currentFeeLimitFQT.

The new GetAllBundlerRates API returns all bundler rates known to the node, for all child chains, subject to optional minBundlerBalanceFXT limit on the bundler effective Ardor balance.

The new BlacklistBundler API allows manual blacklisting of bundler accounts. Rates advertised by such accounts will not be added to the local list of known rates each node maintains. Blacklisting of bundler accounts is also possible using the new nxt.blacklistedBundlerAccounts property.

Bundler rates are now broadcasted every 30 min instead of once an hour.

The new nxt.minBundlerFeeLimitFXT property allows skipping bundler rates that are announced by bundlers with lower remaining current fee limit, default 10 Ardor.

Added peer authentication and encryption framework for the peer networking, to be used for permissioned blockchains.

Added Bundle action for child chain transactions in the UI. Added visual representation of transaction bundling and confirmation status.

Client UI and peer networking bugfixes and improvements.

Updated H2 to version 1.4.194.


This is a bugfix release, for testnet only.

Added Node JS module, see html/www/js/README.

Multiple bugs fixed and improvements added in client UI, peer networking, blockchain download.

Removed obsolete news page, added About modal.

This release will force a rescan, deleting blocks after height 11619.


This is the first release of the Ardor software, for testnet only. It represents the first milestone in the building of the Ardor platform.

New Features

The main new user-visible feature is the existence of a single forging chain, using the ARDR token, and multiple child chains, each with its own token.

Forging Chain

The Ardor chain is used to establish the proof-of-stake consensus, using ARDR balances only. It supports only a few transaction types: ordinary payments, balance leasing, and coin exchange. Prunable plain or encrypted message attachments are also supported, but not permanent or standalone arbitrary message transactions.

Child Chains

The child chains support all transaction types as previously implemented on the Nxt platform, with the exception of balance leasing which is only available on the Ardor chain, and tagged data extend transaction which has been removed as unnecessary. A child chain can optionally be configured to disable certain transaction types, which has been done for testing purposes on the EUR child chain, disabling the Asset Exchange and Digital Marketplace.

Coin Exchange

To allow trading of child chain coins to each other, and also between child chains and the Ardor chain, a new Coin Exchange module has been implemented.

For trading between child chain coins, the coin exchange transactions are submitted on the child chain of the coin being sold. For trading between a child chain coin and Ardor, the transaction is submitted on the Ardor chain regardless of whether it is a buy or sell, and the fees for such transactions are higher.


The bundling process is used to group child chain transactions from a child chain into a transaction on the Ardor chain. Bundlers accept the fees from those child chain transactions, in the corresponding child chain coin, and pay fees in ARDR to the parent chain forgers. Bundlers can be started from the cogwheel/bundlers menu, defining the coin to ARDR exchange rate they accept, a limit on the total fees in ARDR a bundler will pay, and an optional overpay amount.

When a bundler is running, it checks the unconfirmed transactions pool every time a new transaction from the child chain being bundled arrives. If the transaction fee included by the transaction sender, in child chain coins, when converted to Ardor using the exchange rate accepted by the bundler is at least equal to the minimum Ardor fee required for this transaction, the bundler will generate a ChildBlock transaction, including in it this and all other currently unconfirmed child chain transactions satisfying this requirement. The Ardor fee the bundler will include for the ChildBlock transaction is equal to the sum of the minimum required Ardor fees for each, plus the calculated overpay amount, if any. Such overpay amount is optional, and may be used by bundlers willing to pay more in order to have their transactions included in block instead of those of competing bundlers. The new ChildBlock transaction will displace from the unconfirmed pool any ChildBlock transactions of the same child chain that include only a subset of the same child transactions. When propagating through the network, ChildBlock transactions will only be accepted by peers if they either include child transactions not already included in other ChildBlock transactions the peer already has in its pool, or offer to pay a higher fee for the same transactions. This ensures the network is not flooded with ChildBlock transactions even if every node is running a bundler, and allows bundlers to compete for propagating their transactions through the network by offering to pay higher fees.

It is now possible for child transactions to be submitted with zero fees, in child chain coins. If a bundler is willing to pay the Ardor fees for those, they will be included in the blockchain in the ChildBlock created by such bundler.

To prevent the unconfirmed pool from being overfilled with such zero-fees child chain transactions, once the maxUnconfirmedTransactions limit (configured in, default 2000) has been exceeded, child chain transactions will be dropped unless a bundler has already submitted a ChildBlock transaction which includes them.

Bundlers advertise their accepted bundling rates to other peers, signing such rates announcements with the private key of the bundler's account. To prevent fake rates announcements, they can be filtered based on this account effective balance (default set in nxt.minBundlerBalanceFXT is 1000 ARDR). The GetBundlerRates API can be used to retrieve known bundlers rates, again with optional filtering by minimum bundler effective balance.

Peer Networking

The peer networking has been fully re-written and optimized to use socket connections and binary messages instead of http and JSON.

Block and transaction propagation through the network has been optimized, by sharing with peers the inventory of transaction IDs in the unconfirmed pool or in recent blocks, and only propagating the missing ones, if any, when a new block is generated, or a child block is bundled.

The hallmark feature has been removed as it is not needed anymore, hallmarks are no longer supported.

New APIs

APIs of the new Coin Exchange feature: ExchangeCoins, CancelCoinExchange, GetCoinExchangeOrder, GetCoinExchangeOrders, GetCoinExchangeOrderIds, GetCoinExchangeTrade, GetCoinExchangeTrades, GetExpectedCoinExchangeOrderCancellations, GetExpectedCoinExchangeOrders, GetLastCoinExchangeTrade.

Bundling related APIs: BundleTransactions, GetBundlers, GetBundlerRates, StartBundler, StopBundler.

Other new APIs: GetBalances, GetEffectiveBalance, GetFxtTransaction.

API changes

All APIs that are now chain specific accept a new chain parameter. Either the chain name or the chain ID can be used.

Transaction IDs are no longer 64-bit longs but 256-bit hashes, necessitating changes in all APIs that accept transaction ID parameters or return such in the JSON fields. For transactions on the Ardor chain, 64-bit long IDs can still be used with the getFxtTransaction API, as those are enforced to be unique. For child chain transactions, the getTransaction API now requires a fullHash parameter, in addition to specifying the chain.

Prices and rates are now defined relative to a whole unit of the holding being bought or sold (asset, currency, coin), not to a QNT indivisible unit.

All priceNQT and rateNQT parameters and JSON fields have been renamed where appropriate to priceNQTPerCoin, priceNQTPerShare, rateNQTPerUnit, etc., to reflect their changed meaning of price per whole unit of each holding rather than per QNT.

All "units" parameters in the Monetary System APIs have been renamed to unitsQNT.

DividendPayment API accepts holding and holdingType parameters to allow paying dividends in another asset or MS currency. The amountNQTPerQNT parameter has been renamed to amountNQTPerShare and now refers to dividend amount in NQT per a whole share of the asset rather than per QNT.

The GetAccount API no longer returns balanceNQT and unconfirmedBalanceNQT, as balances are now chain specific. The GetBalance API should be used to get chain balances instead, or GetBalances for querying multiple chains.

APIs which accept holding and holdingType parameters now require holding to be set to the chain ID when holdingType=0 (coin).

Since 0 is now a valid fee value for child chains, all CreateTransaction APIs will accept it, instead of using it as a request for the server to calculate and use the minimum fee. To let the server calculate the child transaction fee, a value of feeNQT=-1 should be used, and a new feeRateNQTPerFXT parameter must be supplied, to indicate the exchange rate to use when calculating the fee (since minimum fees can only be calculated in ARDR). If feeRateNQTPerFXT is also set to -1, the server will query the currently known bundlers rates for this child chain, also subject to the minBundlerBalanceFXT limit on effective bundler account balance, and use the best one for the fee calculation. As bundlers rates cannot be trusted blindly, the transaction will not be broadcasted in this case, the returned transaction JSON including the fees calculated should be reviewed by the user. The bundler rate used will be returned in the bundlerRateNQTPerFXT JSON field, -1 if no bundlers are known for the chain.

The following APIs have been removed: ExtendTaggedData, GetPhasingPolls, GetTaggedDataExtendTransactions, GetInboundPeers, MarkHost, DecodeHallmark.

Transaction types and bytes format

The numbering of some transaction types has changed, due to the internal reorganizations of the TransactionType classes. Transaction types on the Ardor chain use negative numbers, e.g. -1 for ChildChainBlock, -2 for Ardor ordinary payment. Some transaction subtypes have been moved to a separate type, e.g. voting and phasing related transactions have been moved out of Messaging to a new Voting transaction type. The output of getConstants should be consulted for a full list of the current transaction types and subtypes.

The transaction bytes format has also changed, adding a chain ID, reorganizing the ordering of attachment and appendix bytes, and allowing prunable attachment parts to also optionally be represented in the bytes format, for the purpose of sending them more efficiently over the peer to peer network.

The JSON transaction representation is still supported, even though it is no longer used in the peer networking. Some attachment fields have been renamed for consistency with the API changes - units to unitsQNT, priceNQT to priceNQTPerShare, rateNQT to rateNQTPerUnit, amountNQT for dividend payments to amountNQTPerShare, etc.

Entity IDs

As part of designing child chain transactions to be prunable, it is no longer possible to enforce uniqueness of the 64-bit transaction IDs for child chains. This affects the IDs of derived entities such as Assets, MS Currencies, Polls, Digital Goods, Shufflings, etc.

For global derived entities such as Assets or Currencies, the 64-bit long IDs are still unique and used in the corresponding APIs. Note however that this uniqueness is now only within the same object type, i.e. it is not guaranteed that an Asset and a Currency will not happen to have the same 64-bit long ID.

For child chain local entities, such as Polls and Digital Goods, the 64-bit IDs are still unique, but within the same child chain only, and still used in their APIs. Again, there is no uniqueness guarantee across different entity types anymore.

For entities that are prunable, such as prunable messages, tagged data, and shufflings, the full 256-bit hash must be used as an ID now, and the appropriate APIs have been changed.

Phasing and Account control

Only child chain transactions can be phased. Therefore, when account control is set for an account, it can no longer submit Ardor chain transactions. Phasing parameters which refer to transaction IDs must now use transaction full hashes instead, prefixed with the chain ID separated with ':'. It is possible to refer to transactions on other chains when approving a phased transaction, or setting up a by-transaction phasing voting model. The controlMaxFees parameter when setting mandatory approval now accepts multiple values, each fee being prefixed with the child chain ID and ':', to indicate which child chain the limit applies to. If no max fee has been set for a child chain, there is no phasing transactions fees total limit on it for the controlled account.

Transaction selection, sorting, limits and fees

An Ardor chain block can contain up to 10 (ten) transactions, this including both native Ardor transactions and ChildBlock transactions. There is no total payload size limit.

A ChildBlock can contain up to 100 (one hundred) child transactions, subject to a total payload limit of 128 kbytes. Prunable child transaction parts are also counted towards the payload size limit.

There is a limit of one ChildBlock per Ardor block for each child chain.

As in Nxt, it is up to a block forger which transactions to include in a block and how to sort them. The default forger behaviour is to select transactions ordered by Ardor fee (not fee per byte as in Nxt, since there is no block payload limit), and then sort them based on arrival timestamp.

It is also up to the ChildBlock bundler which child transactions to include in a ChildBlock, and this selection can be customized by defining a custom filter in the nxt.bundlingFilter property. The default bundler behaviour is to select child transactions ordered by fee per byte, up to the count and payload limits of a child block, creating several child blocks if necessary. Within a child block, child transactions are sorted based on their full hash, but executed based on sorting them after adding the block hash to the child transaction hash, i.e. the execution order of child transactions within a block is deterministic but not predictable and not controllable by the bundler or by the forger. This is in order to prevent front-running of asset exchange and other trading orders.

Ardor fees from ChildBlock transactions paid to the block forger are shared with the previous three block forgers in 1:1:1:1 ratio. Other Ardor chain fees are fully kept by the block forger, and child block transaction fees (in child chain coins) are fully kept by the ChildBlock bundler.

The back fees sharing which was applied in Nxt for some other transactions types such as currency or asset issuance has been removed, however the limitations of one such transaction per block for scarce blockchain resources are preserved.

Default fee for Ardor chain transactions is 10 ARDR. Default fee for child chain transactions is 0.1 ARDR. A ChildBlock must contain at least one child chain transaction, but there is no minimum ChildBlock fee requirement, i.e. such a ChildBlock with a single transaction in it would require only 0.1 ARDR fee if this is the minimum fee for the child transaction it contains.

Fees for child chain transaction types have been scaled depending on their impact on the blockchain, e.g. asset issuance fees are still 1000 ARDR as assets are global and kept permanently. There is a 1 ARDR extra fee added to transactions that create a new account.

The above fees and limits are set for the current testnet only and are subject to change before the production mainnet release.

Testnet accounts

The testnet genesis block has been created based on account balances from the Nxt testnet, as of 2017/01/01 (block height 1061208). Users who had testnet accounts as of that height should find their ARDR and NXT testnet balances imported into this testnet, to ARDR and IGNIS tokens respectively, plus an approximately equivalent amount of BTC, USD, and EUR child chain coins for testing. To allow for developers testing and running forging and bundling nodes, account holdings have been reduced by 50% which have been allocated to developers accounts.

Upgrading from Nxt

The Ardor release is not an upgrade and does not in any way affect your existing Nxt account or client installation. Both Ardor and Nxt should be possible to run simultaneously on the same machine, as long as the hardware capacity allows it.

The included ArdorNxtComparison.pdf document summarizes the major differences between the Nxt and Ardor platforms, for those deciding which one is a better fit for their use case, or considering a migration from Nxt to Ardor. More documentation should be added as Ardor development and features mature and stabilize.