Ardor Software Change Log

ardor-client-2.4.2

Bugfix release, all nodes are recommended to upgrade.

Increased base target threshold to 2000% when detecting forks for peer blockchain state. Added a property nxt.forkBaseTargetPercentage=2000 to allow configuring this threshold.

Broadcast transaction from the light client to many peers without validation only after successful validation by the main peer.

Added a checkpoint after the 2.4.1 hardfork. Do not connect to older version peers.

Fixed trading royalties info dialog, other minor issues.

Updated Jetty to version 9.4.46.

ardor-client-2.4.1

This is a mandatory upgrade for all Ardor mainnet nodes. A hardfork has been scheduled at block 2307000, expected on May 1st, 2022, in order to activate on mainnet the new features that were recently enabled on testnet: per-transaction-type asset control, asset trade royalties, deactivation of MPG child chain. There are no other notable changes since 2.4.0e

ardor-client-2.4.0e

This experimental release is a mandatory upgrade for the Ardor 2.0 testnet. It can also be used on mainnet. A testnet hardfork has been scheduled for block 9800000, expected on March 20, 2022.

The new features to be enabled at the hardfork on testnet are Per-Transaction Type Asset Control, and Asset Trade Royalties.

Per-transaction type asset control. When setting up asset control, it is now possible to specify different phasing requirements for different transaction types. The setPhasingAssetControl API now accepts a multivalue transactionType parameter specifying the types to which the asset control will be applied (or removed, if voting model is NONE). Possible values are: ASSET_TRANSFER, ASSET_DELETE, ASK_ORDER_PLACEMENT, BID_ORDER_PLACEMENT, ASK_ORDER_CANCELLATION, BID_ORDER_CANCELLATION, DIVIDEND_PAYMENT, ASSET_PROPERTY_SET, ASSET_PROPERTY_DELETE, SET_ASSET_CONTROL. If no types are specified, by default the asset control is applied to the following types: ASSET_TRANSFER, ASSET_DELETE, ASK_ORDER_PLACEMENT, BID_ORDER_PLACEMENT, DIVIDEND_PAYMENT, consistent with the original asset control implementation. Setting control for some transaction type removes any previous control for that specific transaction type. At any time, there is at most one control per transaction type, while the same control can apply to multiple transaction types.

The asset control can still be set only by the asset issuer, and the initial setting, when no transaction types have been set under control yet, still requires that the asset issuer holds all asset shares. Once asset control has been set for at least one transaction types, it is not required that the issuer holds all shares, but the SET_ASSET_CONTROL transaction type itself could be restricted by specifying asset control phasing requirements for it.

An API change was necessary, the getPhasingAssetControl API now returns an array of controls objects instead of a single controlParams.

Asset trade royalties. The asset issuer can now receive royalties, calculated as a fixed percentage from each trade of the asset, which is subtracted from the amount (in child chain coins) that the asset seller receives and gets added automatically to the asset issuer account.

Setting or changing the royalties percentage can be done only be the asset issuer and requires that he owns all shares of the asset. The asset issuer can also disable royalties by setting the percentage to 0, and disabling does not require ownership of all shares.

The new setAssetTradeRoyalties API is used to configure royalties, with the percentage specified in royaltiesPercentage parameter. The maximum allowed is 50%.

For open API public nodes, the default API result size limits and database query timeouts can now be bypassed for hosts as configured in the new nxt.unlimitedBotHosts property. The default is to ignore the limits for localhost, set to * to allow all hosts, but be aware of potential DoS issues.

The MPG child chain will be disabled on testnet at this hardfork, and on mainnet at the mainnet hardfork which is to be scheduled with the next release. MPG balances and transaction history will be preserved for now, but no more transactions of any type will be possible with MPG tokens.

A shell script contrib/ardor-ramdisk.sh has been added, for running Ardor with the database stored in memory on tmpfs, backed up and restored to/from persistent storage under contrib/ramdisk-backups. Run the script with no arguments for more help.

Bugfixes in Contract Manager, Transaction voucher processing, and others.

Added support for READ_ONLY mode of the ContractRunner.

Added support for Ledger Speculos emulator, use the nxt.ledger.speculosHostname and nxt.ledger.speculosPort parameters to configure.

Updated Jetty to version 9.4.45.

ardor-client-2.3.4

This stable release is an optional but recommended upgrade for all users. The Ledger Nano X and S hardware wallets are now identified correctly by both the desktop wallet and the browser wallet.

When a contract processTransaction invocation submits multiple transactions, and the contract runner account ARDR balance is lower than the balance needed to cover the referenced transaction deposit for all transactions, the contract runner will not submit any transaction in order to prevent partial expiry of transactions.

The default deadline for transactions submitted by the contract runner is now configurable using the defaultDeadline contract runner attribute.

Fixed running the contracts unit tests from an Ardor installation.

The IntelliJ ContractManagerPlugin has been updated and is now being built using gradle. See addons/plugins/ContractManagerPlugin/README for details.

The content of a loaded voucher is now properly escaped.

Verification of transaction bytes when locally signing transactions of type setAssetProperty and setAccountProperty now works properly.

The table paging widget has a new "Go To ..." numeric field to enable locating historical records without paging.

Fixed connectivity issues: don't blacklist peers on normal shutdown.

Added tool for creating Genesis JSONs from current blockchain balances. See nxt.tools.GenesisCreator for usage instructions.

Added tool to print shuffling recipients, run com.jelurida.ardor.client.api.ShufflingRecipients (edit serverUrl and adminPassword if necessary).

To prevent DoS or performance issues, database queries executed during API calls on open API nodes when adminPassword is not provided will timeout and fail with errorCode 25 if the query exceeds a preset number of seconds. This can be set with the new nxt property nxt.openApiQueryTimeout, default is 1 second, set to 0 to disable the timeout.

Allow filtering of logged stacktraces by exception class and message prefix, configurable using the nxt.disabledThrowableStackTraces property, see the nxt-default.properties file for the exact syntax.

Various UI fixes.

Updated Jetty to version 9.4.40.

ardor-client-3.0.0e

This is the first release of the Ardor pruning and snapshotting feature. It is experimental and for testnet use only. A new testnet has been created, starting from a snapshot of the current testnet as of Dec 8, 2020. Users having testnet balances as of the snapshot height, block 6248612, should have the same initial balances on this new testnet. The 3.0.0e release cannot be used with the current 2.3.3 mainnet or testnet however.

To enable pruning of child chain transactions, the nxt.pruneChildChains=true property must be set (default is false). If this is enabled, child chain transactions are not processed during blockchain download and are pruned from storage during normal operation. During download, only the parent Ardor chain is processed; when the download is finished, the blockchain state (consisting of child chain balances, asset holdings, aliases, etc - everything an account owns) is loaded from a state snapshot, downloaded from the network and confirmed by at least 720 blocks or as set in nxt.stateSnapshotConfirmations.

The peer networking port for the 3.0 testnet is 16874 and the API port is 16876 (SSL port 16877, if enabled). The different ports allow this version to be run in parallel with 2.3.3 mainnet or testnet instances.

Block times have been set to 30 s for this testnet.

Users familiar with running Ardor nodes are invited to join the 3.0 testnet by installing this release and report any issues in our support forum, https://talk.jelurida.com

Apart from the major new pruning and snapshotting feature, there should be no difference in functionality compared to 2.3.3.

The changes in Ardor version 3 to help developers that built on Ardor 2 migrate their applications to Ardor 3 are described in the following link Ardor 3.0 explained

ardor-client-2.3.3

This stable release is an optional but recommended upgrade for all users.

• Bundlers UI fixes and improvements.

• Support specifying the sha256 hash of the admin password in the nxt.properties as nxt.adminPasswordHash, instead of the actual admin password.

• Light client fixes and improvements.

• Allow specifying JVM options and PID file location using ARDOR_JVM_OPTS and ARDOR_PID_FILE environment variables.

• Contract runner fee calculation fixes.

• Added a checkpoint after the GPS hard fork, no longer accept connections from peers version older than 2.3.2.

• Node processes UI improvement - allow deleting the encrypted config file.

• Performance improvements based on load testing of asset and coin exchange transactions.

• Added run-taxreport.sh and run-taxreport.bat scripts to simplify running the tax reporting tool.

• Added filter selector to list all/my standby shufflers.

• Improved account ledger to distinguish fee from generated block, fee from next blocks and fee from shuffling penalty.

• Enhanced getUnconfirmedTransactions and getUnconfirmedTransactionIds APIs to also return the transactions in the waiting pool if the request parameter includeWaitingTransactions=true is specified.

• Fixed an UI bug in setting up account control with zero maximum fees which resulted in no fees limit being set at all. Users who have already tried setting zero max fees should check their account control settings and if necessary do it again`.

• Changelly and ChangeHero] Exchange UI improvements.

• Various other bugfixes and enhancements.

• Updated Jetty to version 9.4.35. Old libraries in lib folder must be deleted if installing manually.

ardor-client-2.3.2

This stable release is a mandatory update for mainnet. A hardfork to enable new functionality and activate the GPS child chain is scheduled for block 1453000 expected on Sep 22, 2020.

At the hardfork height, the GPS asset (assetID: 3123987739214429747) will be migrated to a child chain. Existing asset exchange orders for the GPS asset will be cancelled, further transactions with it will be disabled, and a snapshot of the asset balances as of that height will be used to automatically distribute the tokens of the newly enabled GPS child chain.

The following new features, already available on testnet, will be activated on mainnet after the hardfork:

• Allow sending zero fee child chain transactions even from accounts not yet registered on the blockchain.
• Allow setting up account control with zero max fees.
• The AEUR child chain will become permissioned, thus disabling further transactions with AEUR after the hardfork.

Locally generated SSL keystore

To simplify the setup of SSL certificates and a Java keystore required to enable https communication. The node auto-generates certificates and keystore in case none were provided. The auto-generated keystore can be used to setup Https communication quickly on a local node. When the nxt.apiSSL property is set to true and the keystore location is not specified or the nxt.keyStorePath property is pointing to a missing file, the node will automatically generate a key pair, a local root certificate and an SSL certificate signed by it, to form a valid certificate chain. The node will create a keystore containing these artifacts according to the format and password specified in nxt.keyStoreType and nxt.keyStorePassword correspondingly. The local root certificate is saved using the same path as the keystore file with a file suffix "-ca.crt". Import this certificate as a trusted CA into the browser keystore to make enable the browser to validate the auto-generated certificate chain.

When using light client or while downloading the blockchain, the local node forwards API calls to a random remote node and confirms each API response with up to three additional remote nodes. This functionality which was previously implemented by the wallet is now implemented by the node itself to make it faster and more reliable.

A new API - getAPIProxyReports - provides information about the light client remote API calls and their confirmations.

Improved retrieval of prunable transactions and bootstrapping of archival nodes.

Lightweight contracts framework improvements

Two new callbacks were added to the contract interface init and shutdown. init can be used by contract developers to perform static initialization tasks used during the lifetime of the contract, while shutdown can be used to reclaim resources used by the contract before shutting it down. When starting a node the init callback is invoked on all contracts loaded by the contract runner. Similarly, when shutting down the node the shutdown callback is invoked. When uploading a new version of an existing contract, when loading the new contract reference the contract runner will first shutdown the existing version of the contract then initialize the new version.

It now possible to submit transactions from processRequest callback. Transactions returned using context.createTransaction() are automatically broadcast to the node by the contract runner.

New sample contracts

Trading bot CoinExchangeTradingBot.java is a contract which performs market making on the coin exchange and asset exchange. Contract runners can define the holdings (coin or asset) on which to submit buy and sell orders and the percentage difference from a base exchange rate loaded from coinmarketcap, which serves as a sample data source. The bot can be configured to compete with other traders or issue orders according to the base exchange rate to provider liquidity.

The account balance notifier AccountBalanceNotifier.java monitors the account balances of configured holdings and raises an alert in case their holding balance drops below some minimum limit. The notifier can be used to monitor an account performing market making to alert the operator in case a holding balance is exhausted.

The chain monitor contract ChainMonitor.java monitors specific aspects of the blockchain operations. It submits an alert to one or more notification services in case a problem with the blockchain operation is detected.

Notification service contracts SlackNotifier.java, TelegramNotifier are utility contracts used for posting messages from other contracts to Slack and Telegram respectively.

Updated Jetty to version 9.4.31.

ardor-client-2.3.1e

This experimental release is a mandatory upgrade for all testnet nodes, and for all mainnet nodes already running 2.3.0e.

Fixed transaction validation and bundler rate propagation for not yet enabled child chains.

ardor-client-2.3.0e

This experimental release is a mandatory upgrade for all testnet nodes. It can also be used on mainnet.

On testnet, a hardfork is scheduled for block 4949000, expected on 18.06.2020.

Features that will be activated only on testnet at this hardfork are the new GPS child chain, and the child chain control for AEUR (see details below). All other new features do not require a consensus change and can therefore be used on both testnet and mainnet immediately, but should still be considered experimental.

HD Wallet Integration: This release introduces Hierarchical Deterministic (HD) wallets to Ardor, and enables the integration of hardware wallet devices such as Ledger.

Functionality to derive multiple public/private key pairs and account addresses based on the BIP32 specification is now integrated into the wallet.

This HD wallet functionality allows the creation of a practically unlimited number of accounts all from a single secret "seed". The user only needs to have this seed to be able to access and use all HD accounts derived from it. On the blockchain, HD accounts are indistinguishable from standalone accounts, and there is no way for a third party to determine which HD addresses are derived from the same seed, unless it has access to either the seed or the master public key.

Hardware based key derivation, transaction signing, encryption and token generation are now supported by the Ledger hardware wallet. For more information see: Connect Ledger Nano S or Nano X to your Ardor Wallet

Software based key derivation is compatible with the Ledger hardware wallet so that given the same seed, the same key pairs can be derived using hardware or using software.

The wallet defaults to the following standard BIP44 derivation paths:

• m/44'/16754'/0'/0' for mainnet
• m/44'/16754'/0'/1' for testnet

All keys generated by the wallet are direct child keys of these paths.

An account address derived from a seed with a specific path generates a pair of private/public keys from which the account address is derived. These HD accounts do not have an account secret phrase associated with them like existing standalone accounts. All API calls which accept the secretPhrase parameter now also accept the privateKey parameter, which allows a derived account to be used the same way as a standalone account simply by replacing the secretPhrase parameter with a privateKey parameter in all API calls. The GetAccountId API now includes the privateKey in the response, to be used to calculate privateKey from a secretPhrase.

New APIs were added to support the HD account functionality. GetLedgerMasterPublicKey connects directly to a Ledger device to load the public information of a BIP32 node given a BIP32 path parameter. Use this API to load a serialized master public key from the Ledger device to be used for offline child account derivation.

• DeriveAccountFromSeed uses software based seed derivation to derive the full information of a BIP32 node from the combination of a seed mnemonic, a seed passphrase and a BIP32 path. Use this API to load the information of a specific BIP32 node.
• DeriveAccountFromMasterPublicKey uses a serialized master public key obtained using any of the other APIs and a child index to derive the public key of a child BIP32 node. Use this API to derive the public key of a child account without exposing any private information.

For passphrase accounts, the private key is calculated using sha256 hash plus some bit manipulation (clamp), therefore every passphrase can be converted to a private key but a private key cannot be converted back to a passphrase. Whenever entering a passphrase in the wallet it is possible to enter the 64 characters private key hex string instead. To enter old 64 character passphrase composed of exactly 64 characters hex string, prefix it with the string "Passphrase:'" (without quotes).

When loading accounts from a hardware wallet or a software seed the wallet loads accounts sequentially starting from index 0 until finding an account without a registered public key or until loading 20 accounts. This behavior can be customized using the wallet login page. The APIs themselves does not restrict the range of child keys which can be used by applications.

The wallet login Page was redesigned, new tabs were added "Seed" for software based account derivation and "Hardware" for loading accounts from a hardware wallet. The passphrase and account login options are still available. QR code scanning tab was replaced with a widget available for specific fields.

When launching the wallet for the first time, a walkthrough tour is displayed to present the various login options. Each of the login options has its own specific tour activated using a '?' button on the top bar. Additional tour is displayed on the dashboard after login.

BIP39 compatible secret generator The old 12 words passphrase generator used for passphrase creation was replaced with a BIP39 compatible seed generator which can be used to generate seed or passphrase of 12 to 24 words with an internal checksum.

Public key creation for standby shuffler Standby shuffler can now use a master public key to derive a new public key for each shuffling it joins so that it can never run out of public keys. The Seed login option or a new "BIP32 Calculations" dialog can be used to generate a master public key for use by the standby shufflers.

GPS Child Chain A new GPS child chain will be added, migrating the existing GPS asset (asset id 3123987739214429747 on mainnet, 8016986501463341146 on testnet) to a child chain token. On testnet, the migration will happen at the testnet hardfork block. On mainnet, the migration will be scheduled for the next hardfork block. At the time of the migration, the GPS asset will be frozen, existing bid and ask orders cancelled, and further transactions with it will be disabled. The GPS token balances of the GPS child chain will be based on 1:1 snapshot of the GPS asset at that height.

Child Chain Control The child chain control functionality as described at Child Chain Control is now available on the Ardor blockchain, making it a unique hybrid public-permissioned platform. Child chains can now be made permissioned, allowing only authorised users to submit transactions on them, while still being a part of the public blockchain and relying on its consensus mechanism.

New APIs have been added to grant, revoke, or query account permissions on permissioned child chains: GetAccountPermissions, AddAccountPermission, RemoveAccountPermission, GetChainPermissions.

On testnet, the AEUR child chain will become permissioned at the testnet hardfork block, to be used for future testing of child chain control. On mainnet, it will become permissioned at the next mainnet hardfork block, thus disabling further transactions with AEUR.

Node Configuration Configuration of nxt.properties is now supported from inside the wallet using the new node configuration page. New GetConfiguration and SetConfiguration APIs have been added. Add-ons that make use of their custom properties in the nxt.properties file can define a getConfigProperties method returning the configuration metadata for such properties, to allow those to be displayed and edited from the node configuration page.

LedgerLogger add-on The new LedgerLogger add-on allows logging of Account Ledger records of selected accounts to a flat csv file, ledgerlog.csv, optionally decrypting message attachments if the private keys of these accounts have been provided. In addition to enabling the add-on by setting nxt.addOns=LedgerLogger, users should set nxt.ledgerTrimKeep=0 to enable logging of ledger entries even before the default trim height, set nxt.ledgerLogUnconfirmed=0 to only log confirmed balance changes, and set nxt.LedgerAccounts to a list containing the accounts to be included in the output. Optionally, the log can be limited using the nxt.LedgerLogger.from and nxt.LedgerLogger.to properties to define a date range in a 'yyyy-MM-dd HH:mm:ss Z' format. To decrypt message attachments, the secret phrase or the private key of each account can be provided respectively in the nxt.secretPhrase.<account> or nxt.privateKey.<account> property. A full rescan or re-download is needed to actually generate the ledgerlog.csv file after the add-on has been enabled and configured.

Improved Bundler fee rate calculator When submitting a child chain transaction without specifying a fee, users can now specify a transactionPriority parameter, displayed as a slider in the UI. Transaction with higher priority will use a fee higher than the best bundler rate, based on the higher rates announced by other bundlers, thus increasing the chances of the transaction to get bundled. The bundlers to be considered can still be filtered using the nxt.bestBundlerRateWhitelist property.

Other improvements

Light client networking Implemented bootstrap of API proxy - try to connect to known peers and if this fails, connect to trusted nodes to get latest open API peers. The purpose is to either have a node serving the proxy at start, or to know that the network is down, and also to fix the problems caused by old initial peers.

Default bootstrap node is defined in nxt.properties: nxt.proxyBootstrapNodes=ardor.jelurida.com;

The new BootstrapAPIProxy API can be used to refresh the latest open API peers from the bootstrap node.

Added a new property nxt.stopDownloadHeight to allow forcing the blockchain download to stop once a certain height is reached.

Added a new GetEpochTime API, to return the blockchain epoch time given a unix timestamp. Added unixtime to GetTime response.

The APIs returning expected transactions now return both bundled and non-bundled transactions.

The Node JS module provided with the installation no longer depends on the availability of the JQuery and JSDom modules thus making it easier to integrate with 3rd party libraries. The latest version is now published on https://www.npmjs.com/package/ardor.

Improved prunable data retrieval, genesis block loading, database shutdown. Improved keeping track of remaining bundler fees limit.

Optimize checkpoint calculation by using hash of checkpoint block bytes instead of hashing all intermediate transactions.

Performance optimizations in trimming of the derived tables to speed up blockchain download.

Trimming frequency can now be modified per table by setting a frequency modifier property nxt.trimFrequencyMultiplier, which contains a list of dash-separated pairs [schema.]table_name-frequency.

When attaching a message to a transaction, the boolean parameters messageIsText and messageToEncryptIsText, if supplied, are now used also when the message data is uploaded as a file, overriding the mime type auto detection.

Support multiple file parameters in the API requests that accept file uploads.

Usability of the wallet was enhanced for small screen form factor. Tables use horizontal scrollbar when necessary and some widgets change their look when the screen width is reduced.

Wallet static resources, Html and Javascript files, are now downloaded in parallel to significantly reduce the startup time.

Branded Account Prefix When specifying a recipient address users can use any alphabetic prefix they like before the first '-' symbol. The default prefix is determined by the account address used during login and the default for the login account can be defined in the device settings dialog. The default setting is "ARDOR". When using a branded account prefix the account addresses returned by API calls still use the "ARDOR" prefix regardless of the branded account value.

Updated Jetty to version 9.4.29 and Bouncy Castle to 1.65.

Backward Compatibility The SplitSecret API now accepts a "privateKey" parameter. The existing "secretPhrase" parameter was renamed to "secret" since it can represent seed words as well. Similarly the response of the CombineSecret API now returns the attribute "secret" instead of "secretPhrase".

Server APIs and client side code will no longer accept as parameter a hex string with an odd length.

ardor-client-2.2.6

This is a stable release, introducing multiple enhancements and bugfixes. It is a recommended upgrade for production use.

On testnet, upgrade before block 3250000 (expected Nov 7, 2019) is mandatory due to the activation of the following new features that require a hard fork:

Allow sending zero fee child chain transactions even from accounts not yet registered on the blockchain.

Allow setting up account control with zero max fees. This completely removes the risk that an attacker who obtains the passphrase of an account placed under account control may slowly waste its funds on fees, however the transactions fees for such an account will need to be sponsored, i.e. its transactions must be bundled by some bundler for free.

The above features will be available on testnet after block 3250000, and will also become enabled on mainnet at the next scheduled hard fork.

The node processes management add-ons:

• SaveForgingEncrypted
• StartForgingEncrypted
• SaveFundingMonitorsEncrypted
• StartFundingMonitorsEncrypted
• SaveBundlingEncrypted
• StartBundlingEncrypted,
• SaveStandbyShufflingEncrypted
• StartStandbyShufflingEncrypted,

have been replaced respectively with:

• ForgingEncryptedConfig
• FundingMonitorsEncryptedConfig
• BundlingEncryptedConfig
• StandbyShufflingEncryptedConfig

If you have enabled any of those in the nxt.properties file, the nxt.addOns property must be updated with the new add-on classname.

For add-ons in the nxt.addons package, such as the process management add-ons, specifying the full Java package name is now optional, i.e. if only the class name is specified in the nxt.addOns property, it is assumed to be in the nxt.addons package.

Each of the new add-ons exports two http APIs, to allow saving the encrypted configuration and starting the corresponding process.

The EncryptedConfig add-ons now by default use files under the conf/processes directory to save the encrypted processes configuration, overwriting existing files if needed. An alternative location can be specified using the nxt.addons.EncryptedConfig.path property. When using the API, the config file can also be saved under any other path, as long as it does not overwrite an existing file.

Client-side encryption is also supported by the SaveEncrypted add-on APIs. If the config data is already encrypted, the dataAlreadyEncrypted=true request parameter must be set, and there is no need to submit the encryptionPassword.

All of the above forging, bundling, funding monitors, and standby shuffling process management add-ons are now fully supported by the wallet UI. A "Processes" page has been added, accessible under the cogwheel menu, from which the configuration of currently running forgers, bundlers, funding monitors or standby shufflers can be saved to an encrypted configuration file, and restored again after a node restart by supplying the encryption password. The corresponding add-ons must first be enabled in the nxt.properties file in order for the option to save/start them to appear in the Processes page.

A tutorial and documentation is available at: Node Processes Configuration

The wallet UI now allows attaching an unencrypted message also to transactions that do not have a recipient.

Multiple UX improvements to reduce or automate the switching between chains that is sometimes needed when the user tries to access a feature or submit a transaction not supported on the current chain.

The Standby Shufflers UI has been improved to show the numbers of shuffling recipient accounts remaining and currently in use.

The Funding Monitors UI, available under the cogwheel menu / Monitors, now allows starting a funding monitor for assets or monetary system currencies, not only for child chain coins. Funding monitors for such holdings must be run on a chain that allows asset transfer or currency transfer transactions, i.e. not on the parent Ardor chain.

The startFundingMonitor and getFundingMonitor APIs now support an optional includeHoldingInfo parameter, to request the asset or currency info to be included in the response json.

Setting up https on a public node running Ardor has been made simple, without the need for a reverse proxy. The new pem.to.pkcs12.keystore.certbot.hook.sh script can be used to convert an SSL certificate issued by Let's Encrypt to a keystore file that the Ardor node can use. The run.sh script now supports authbind, if started with the --authbind modified, to allow the Ardor software to listen on port 443 without having to run it as root. A detailed tutorial putting everything together is available at: Configuring HTTPs on a standalone Ardor installation

A new managePeersNetworking API has been added, to allow disabling or enabling the node peer networking at runtime. It takes a single "operation" parameter, with possible values: "enable", "disable", and "query", and requires the adminPassword when run on a public node.

A new property has been added, nxt.deleteProcessedVotes=true, to optionally disable the deletion of votes records when trimming the votes table. Note that even if votes are not deleted, re-calculation of poll results may require data that are no longer available (such as account or asset balances at the time of poll finish), unless a blockchain rescan is done, this is why the default is still to delete old votes records.

The compact.sh script has been improved to better reduce the database size. A new property has been added, nxt.disableCompactOnShutdown=false to allow disabling database compact on shutdown, for faster restarts during development.

The export/import functionality for contacts and approval models, as used in the browser based wallet UI, is now available and compatible with the JavaFX based desktop wallet too.

The Contract Runner doesn't require anymore an initial configuration on nxt.properties or an external JSON file. Instead, it can be bootstrapped from the new Processes page or from an uploaded configuration file. The recommended configuration procedure is now the Processes page as it provides a persistent configuration using encryption instead of plain text files. It also helps with the initial configuration. When you open the Save modal window for Contract Runner under the Processes page you are presented with a basic minimum configuration like this:

{
  "accountRS": "ARDOR-XXXX-XXXX-XXXX-XXXXX",
  "autoFeeRate": true,
  "validator": false,
  "params": {}
}

The accountRS will match the currently logged in account, but you can change it. You only need to enter the passphrase for the account and then the encryption password. The UI will take care of adding the passphrase to the configuration file before encrypting it locally and sending to the node for persistent storage. In order to start the contract runner use the Start button under the Processes page. After restarting the node you only need to start it again.

The Contract Runner can now calculate the best fee when sending transactions instead of relying on a fixed fee ratio. There is a new 'autoFeeRate' boolean property to enable this new feature. If set to true (default: false), the contract runner will calculate the best fee available based on the current bundlers. This should be equivalent to the "Calculate Fee" button on the wallet. When autoFeeRate is set to false, or the best fee cannot be obtained, the contract runner will revert to using the usual "feeRateNQTPerFXT.<Chain Name>" properties.

Two new optional properties for the contract runner allow filtering out bundlers used to retrieve the best available fee when autoFeeRate is activated.

Bundlers with an effective balance below the property minBundlerBalanceFXT are not considered for the best fee calculation. The default for this property is to use the same value as the global property nxt.minBundlerBalanceFXT.

Also, bundlers with a fee limit currently below the property minBundlerFeeLimitFQT are also not considered for the best fee calculation. Again, the default for this property is to use the same value as the equivalent global property.

For more detailed information please check the updated documentation at: Lightweight contracts

Added ChangeHero as an integrated exchange in the wallet.

Node.js module fixes and improvements.

Various UI improvements and bugfixes. Updated the icons to Font Awesome Pro 5.11.2 (commercial version). Android related UI fixes.

Updated H2 to version 1.4.200. If using a custom nxt.dbParams or nxt.dbUrl properties, remove any MVCC settings from them, MVCC is now the default and not configurable.

Updated Jetty to version 9.4.22.

ardor-client-2.2.5

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.

ardor-client-2.2.4

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

• Permanently disallowed outgoing transactions from the new @ArdorBurnAccount, see announcement at https://www.jelurida.com/ardor-burn-account

• 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).

ardor-client-2.2.3

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.

Contracts

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 compact.sh or compact.bat script, which should take a few minutes, and will also improve the database performance.

ardor-client-2.2.2

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.

Contracts:

• 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.

Others:

• 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.

ardor-client-2.2.1

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

ardor-client-2.2.0e

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 nxt.properties 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: https://ardordocs.jelurida.com/Lightweight_Contracts 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.

ardor-client-2.1.2

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

ardor-client-2.1.0e

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.

ardor-client-2.0.14

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.

ardor-client-2.0.13

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.

ardor-client-2.0.12

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.

ardor-client-2.0.11

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.

ardor-client-2.0.10

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.

ardor-client-2.0.9

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.

ardor-client-2.0.8e

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.

ardor-client-2.0.7e

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.

ardor-client-2.0.6e

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.

ardor-client-2.0.5e

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 ardor.jelurida.com 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.

ardor-client-2.0.4e

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.

ardor-client-2.0.3e

Minor unconfirmed transaction processing improvements.

Coin Exchange UI improvements and bugfixes.

Updated jetty to version 9.3.17.

ardor-client-2.0.2e

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.

ardor-client-2.0.1e

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.

ardor-client-2.0.0e

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.

Bundling

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 nxt.properties, 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.

---