The exe and dmg packages must have a digital signature by "Jelurida Swiss SA".

Change log:

This is a bug fix and usability enhancements release.

Users still using version 2.2.0e or earlier must upgrade immediately as they arealready 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 deleteand 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 returnmetadata 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 includedin a new block before exiting.

Contracts with an inner interface and an inner class implementing it are nowsupported.

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 apassphrase. Contract devs should encrypt the message first then submit theencrypted 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 anaccount 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 toprovide more screen real estate for the mobile app.

Increase and delete shares links are displayed in the "My Assets" page only whenthese 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 blockjson in a separate tab.

Coin exchange layout improvements.

Others:

Fixed an initialization issue that could cause some custom add-ons to deadlockon start.

The exe and dmg packages must have a digital signature by "Jelurida Swiss SA".

Change log:

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

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

Transactions with asset 6066975351926729052 (old CtC) will be disabled and openorders 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 theyare listed in the phasedTransaction parameter or not.

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

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

Lightweight Contracts:

Contract validations now use Java annotations. The following annotations areavailable:@ValidateContractRunnerIsRecipient - checks that the contract runner account is the recipient of the trigger transaction.@ValidateContractRunnerIsSender - checks that the contract runner account is thesender 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 rejectarray. 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 theexisting 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 canbe submitted with phasing by hashed secret. The contract runner will submit itsown 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 wizardwas 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 accountpassphrase used when generating it.

The parameter injection introduced in version 2.2.0e was replaced with a morerobust 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 followingstatement: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 willhave to be redeployed on testnet and contract runners using a previous versionwon'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" linkon the asset exchange page. Users can use it to set, update, and delete assetproperties.

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 thealias 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 firststart in order to fully apply the database changes.

The exe and dmg packages must have a digital signature by "Jelurida Swiss SA".

Change log:

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/valuepairs. The property name can be up to 32 characters, and property value up to160 characters in length. Anyone can set a property on an asset. Only the assetissuer, or the setter of the property, can delete a property. The setter of aproperty 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 arescheduled 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 assetproperty for assets, or account property for currencies.

After the freeze height, no further transactions with the frozen holding arepossible (with the exception of setting or deleting asset properties). Freezingis not reversible.

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

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

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

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

Lightweight Contracts:

The contract runner now executes contracts in their own sandbox which restrictsthe contract permissions based on a standard Java policy file named ardor.policyBy 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 APIsis 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 verificationof the contract unpacks the Jar and compares individual class files.

Parameter injection is now supported using the ContractInvocationParameter,ContractSetupParameter and ContractRunnerParameter annotations. This reducescontract 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 usingthe addon.contractRunner. prefix. The contracts.json configuration file is nowonly used when specifying secret contract runner parameters so can be ignoredin most configuration.

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

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

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

The exe and dmg packages must have a digital signature by "Jelurida Swiss SA".

Change log:

This is a critical bugfix release. IMMEDIATE update is mandatory for everyone.

Fixed validation of string fields length in transaction attachments.

Fixed locale issue affecting Turkish users.

Allow setting the Content-Type header of the API responses to application/jsoninstead of text/plain using the nxt.apiFixResponseContentType property. Defaultis still text/plain to preserve compatibility.

The exe and dmg packages must have a digital signature by "Jelurida Swiss SA".

Change log:

This is an experimental release. It is a mandatory upgrade only for testnetnodes, but can also be run on mainnet. On testnet, a hardfork to enable thelightweight 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 moreflexible bundling filters and fee calculations rules. Multiple bundling filterclasses 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 bundleraccount.

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

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 supportto run bundlers with more than one rule, by adding rules to an already startedbundler.

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

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

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

Account property with name "nrs_recipient_ui_options", set by the recipient onitself is now used to configure the modal when sending funds to that account.This can be used instead of the "#merchant:" account description and allowscontrol 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 accountdescription- - encrypt_message: default value for the encrypt message box- - encrypt_message_disabled: if true, the encrypt message box is disabled

The exe and dmg packages must have a digital signature by "Stichting NXT".

Change log:

Desktop wallet performance optimizations to reduce excessive load.

Do not allow login using passphrase to a non-existing account to prevent usersfrom losing their funds due to a typo. Use the "choose your own passphrase"link under "create new account" if you really need to login to a non-existingaccount using passphrase.

The exe and dmg packages must have a digital signature by "Stichting NXT".

Change log:

Bundlers page UI improvements and bugfixes.

Added AccountPropertyBundler add-on, which only bundles transactions sent byaccounts having the "bundling" property set on them by the bundler. To enable,set nxt.bundlingFilter=nxt.addons.AccountPropertyBundler. This will apply toall 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 feespecified by the sender.

To avoid third party websites linking to old releases and being out of date, we will maintain the following URL redirects from the Jelurida website to the latest version of each package. Those will be updated at each release to point to the most recent stable version.