Show Posts - Jelurida singapore
Please login or register.

Login with username, password and session length
Advanced search  


Latest Ardor Client: Ardor 2.2.6

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Jelurida

Pages: [1] 2
Ardor Software Releases / Ardor v2.2.6
« on: November 05, 2019, 06:31:50 pm »
Hash: SHA512

Release 2.2.6

sha256 checksums:



The exe package must have a digital signature by "Jelurida Swiss SA".

Change log:

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:


If you have enabled any of those in the 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 file in
order for the option to save/start them to appear in the Processes page.

A tutorial and documentation is available at:

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
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 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:

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 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 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:

  "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>"

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:

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.



Official Nxt Releases / NRS v1.12.0e
« on: August 29, 2019, 03:40:36 pm »
Hash: SHA512

Release 1.12.0e

sha256 checksums:



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

Change log:

This is an experimental release, enabling several new features on testnet
only at block height 2500000. All testnet nodes must upgrade to this release
before this block (expected Sept 1, 2019). This release can also be used on
mainnet but upgrade is optional.

New features:

Added Asset Dividends payment by asset or currency. This allows paying asset
dividends not only in NXT, but also in any asset or monetary system currency.

Added Asset Properties feature, to allow setting arbitrary name/value metadata
on assets. Any user can set a property on any asset, only the asset issuer or
the user who sets the property can delete it.

Added Asset Increase transaction, allowing asset issuers to increase the total
number of asset shares available.

The Asset Delete History has been renamed to Quantity Change History and now
shows both asset deletion and new shares issuance transactions.
The getAssetDeletes API has been deprecated and a new getAssetHistory API can
be used to retrieve asset deletions, increases, or both.

Asset Dividends by Holding, Asset Properties and Asset Increase are currently
testnet-only features and will be enabled on mainnet at the next planned
hardfork block, exact height to be announced later.

New APIs related to the above features:

getAssetHistory, increaseAssetShares, getAssetProperties, setAssetProperty,

Process management add-ons, APIs and UI:

When enabling add-ons using the nxt.addOns property, if a package name is not
specified, the nxt.addons package is assumed, therefore it is no longer needed
to specify the full package name for the default add-ons included in the

Added StartForging and ForgingEncryptedConfig add-ons to facilitate management
of forging processes.

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 ForgingEncryptedConfig add-on can be used to store the passphrases of
forging accounts in an encrypted file. This add-on exports two APIs:
saveForgingEncrypted and startForgingEncrypted, used respectively to save the
list of forging passphrases in an encrypted file, and 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.

Added StartFundingMonitors and FundingMonitorsEncryptedConfig add-ons to
facilitate management of funding monitor processes.

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. The secretPhrase parameter needs
to be manually added to the JSON for each funding monitor.

The FundingMonitorsEncryptedConfig 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.
It exports two APIs for this purpose, saveFundingMonitorsEncrypted and

The SaveEncrypted APIs require the admin passphrase when used on a remote node.
To prevent overwriting arbitrary files, they will only overwrite an existing
file located in the conf/processes directory and with a default for the add-on
filename; otherwise the file must not already exist.

An UI for the above ForgingEncryptedConfig and FundingMonitorsEncryptedConfig
add-ons has been added, accessible under the cogwheel/processes menu.

Accounts under account control are no longer allowed to start FundingMonitors.

Java programming API:

As an alternative to programming against the http API, the same API calls are
now accessible from java programs using the so called APICallers. Those are
available in the nxt.http.callers package, and code samples for how to use them
are provided under src/java/com/jelurida/ardor/client/api, demonstrating tasks
such as local signing, message encryption and decryption, waiting for a new
block, etc. When integrating the Nxt functionality in your java programs,
using APICallers is the recommended approach instead of accessing core Nxt
classes directly.

Light client networking improvements:

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;

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

Performance and stability improvements and bugfixes.

Windows and Mac installations now use by default an embedded Open JDK 12

The H2 database now uses the newer MV_STORE format by default. Conversion to
this format however takes effect only when running on an existing
database, or re-downloading the blockchain from scratch.

Updated Jetty to version 9.3.27, H2 to 1.4.199.



Ardor Software Releases / Ardor v2.2.5
« on: June 16, 2019, 09:23:20 am »
Hash: SHA512

Release 2.2.5

sha256 checksums:



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

Change log:

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 Software Releases / Ardor v2.2.4
« on: June 13, 2019, 11:19:10 am »
Hash: SHA512

Release 2.2.4

sha256 checksums:



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

Change log:

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.

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

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 as an integrated exchange in the wallet, allowing exchange of
Ignis and Ardor to any coin supported by ChangeNOW.

Permanently disallowed outgoing transactions from the new @ArdorBurnAccount,
see announcement at

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

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 Software Releases / Ardor v2.2.3
« on: April 23, 2019, 12:36:33 pm »
Hash: SHA512

Release 2.2.3

sha256 checksums:



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

Change log:

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 to start forging, bundling, etc, on a remote node without
ever transmitting the full account passphrase to it over the internet.

New APIs for Shamir Secret Sharing:

Use the splitSecret API to split a passphrase into pieces.

Use the combineSecret API to combine secret pieces to the original passphrase.


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

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


The Windows and Mac installers now bundle a copy of OpenJDK 11 and Java FX sdk.
OpenJDK is installed into the jdk folder.
Java FX is installed into the javafx-sdk folder.
The jre folder which included the Java distribution in previous releases is no
longer created by the installation.
Users who created customized scripts relying on the jre folder should adjust
their scripts to the new structure.
For the linux installation package, the code is compiled with OpenJDK 8, and
can still be run under either Java 8, or Java 11 or 12. For Windows and Mac,
the installation package is compiled using Java 11.

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 hoovering 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 networking stability improvements and performance optimizations.

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

A set of custom add-ons to automate forging, bundling, and funding monitors
has been include in this release.

The StartForging add-on reads the passphrases stored in a plain text file, as
defined in the property nxt.startForgingFile, one passphrase per line, and
automatically starts forging with each of these accounts when the server is
started. Since passphrases are stored unencrypted, this add-on should only
be used on well secured servers, or with accounts of insignificant value, or
in test environments.

For a secure way of starting forging with multiple accounts on a remote server,
the SaveForgingEncrypted add-on can be used to store the passphrases of forging
accounts in an encrypted file, and the StartForgingEncrypted add-on to start
forging with them by only submitting to the server the password necessary to
decrypt this file. Note that at runtime, the forging account passphrases will
still be kept in server memory, but when using these add-ons will never need to
be stored on disk, and will not need to be re-submitted to the server each time
forging needs to be started. These add-ons are useful when forging on a fully
trusted node, and having to restart forging remotely without a risk of exposing
the passphrases in transit.

The StartBundling add-on reads a list of Bundlers stored in a JSON formatted
file, as defined in the property nxt.startBundlingFile. The exact JSON can be
initially generated by manually starting the bundlers configured as desired,
including any custom bundling rules, and using the GetBundlers API to retrieve
the list of bundlers in JSON format. The only manual modification required is
to add a "secretPhrase" parameter to the JSON for each bundler, with the
corresponding account secret phrase. On server start, the StartBundling add-on
will automatically start all bundlers as configured.

Similarly to the above forging add-ons, the SaveBundlingEncrypted and
StartBundlingEncrypted add-ons can be used to store the JSON configuration of
bundlers in an encrypted instead of plain text file, and start the bundlers
on submitting the decryption password to the server.

Finally, for automating funding monitors, the StartFundingMonitors add-on will
automatically start all funding monitors configured in a JSON formatted file,
as defined in the property nxt.startFundingMonitorsFile. The JSON can be
generated by manually starting the funding monitors as desired, and using the
GetFundingMonitor API to retrieve the list of monitors in JSON format. Again,
the secretPhrase parameter needs to be manually added to the JSON for each
funding monitor.

The SaveFundingMonitorsEncrypted and StartFundingMonitorsEncrypted add-ons
allow storing the JSON configuration of funding monitors in an encrypted
instead of plain text file, and starting the funding monitors by submitting
only the decryption password to the server.

Other improvements:

The CalculateFee API now also returns the required child chain fee based on
the best bundling rate available, as feeNQT.

The JPLSnapshot add-on has been ported to Ardor. It can be used to generate
a JPL-compliant snapshot of Ignis child chain balances.

Starting a funding monitor or shuffler with feeRateNQTPerFXT=0 is now allowed.

Library updates:

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



Ardor Software Releases / Ardor v2.2.2
« on: January 15, 2019, 01:36:39 pm »
Hash: SHA512

Release 2.2.2

sha256 checksums:



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 are
already on a fork, and their nodes are blacklisted by this release.

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

Users using version 2.2.1 are not required to upgrade.


Added an includeContract parameter to the getContractReferences API to return
metadata about the actual contract being referenced.

The contract runner now removes the last block when started to make sure
trigger transactions in the last block are processed in case processing stopped
before processing the contracts for this block.

Contract unit tests now use simpler methods for verifying transactions submitted
by a contract.

The contract manager now waits until the transactions it submitted are included
in a new block before exiting.

Contracts with an inner interface and an inner class implementing it are now

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

The Changelly menu items was moved from a top level menu to the settings menu to
provide more screen real estate for the mobile app.

Increase and delete shares links are displayed in the "My Assets" page only when
these actions are allowed.

Vouchers with unicode parenthesis are now parsed correctly.

The desktop wallet now displays a file chooser dialog before downloading a cloud
data item or message attachment to the local workstation.

The transaction and block info dialogs now display the raw transaction and block
json in a separate tab.

Coin exchange layout improvements.


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

Fixed false positive unsigned bytes verification error when cancelling
ARDR buy order.

The getPeers and dumpPeers APIs now also allow filtering by version, optionally
including newer versions.

Added a checkpoint at block 545555.

Updated Jetty to version 9.4.14.



Ardor Software Releases / Ardor v2.2.1
« on: December 13, 2018, 03:44:44 pm »
Hash: SHA512

Release 2.2.1

sha256 checksums:



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

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
@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

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
Params params = context.getParams(Params.class);
Where Params is the inner interface decorated with @ContractParametersProvider

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

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 Software Releases / Ardor v2.2.0e
« on: November 02, 2018, 10:19:42 am »
Hash: SHA512

Release 2.2.0e

sha256 checksums:



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/value
pairs. The property name can be up to 32 characters, and property value up to
160 characters in length. Anyone can set a property on an asset. Only the asset
issuer, or the setter of the property, can delete a property. The setter of a
property can edit it by setting a new property with the same name.

New APIs: SetAssetProperty, DeleteAssetProperty, GetAssetProperties.

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

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

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

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

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

Fixed loading transaction voucher which contains attached encrypted message.

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

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

Lightweight Contracts:

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

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

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

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

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

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

See: for more details and

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 General Discussion / Ardor Online Hackathon 2018
« on: October 22, 2018, 08:12:25 am »
Jelurida announces the Ardor Online Hackathon - a Lightweight Contracts Coding Competition:

Ardor General Discussion / Ardor Learning Hub
« on: October 22, 2018, 08:10:26 am »
The new Ardor documentation site we have been working on, the Ardor Learning Hub:, is now ready!!!

Ardor Software Releases / Ardor v2.1.2
« on: October 07, 2018, 12:34:00 pm »
Hash: SHA512

Release 2.1.2

sha256 checksums:



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.

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:

Javadoc is now available for sample contracts and API callers



Official Nxt Releases / NRS v1.11.15
« on: October 07, 2018, 10:44:15 am »
Hash: SHA512

Release 1.11.15

sha256 checksums:



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/json
instead of text/plain using the nxt.apiFixResponseContentType property. Default
is still text/plain to preserve compatibility.

Updated libraries to Jetty 9.3.24, Bouncy Castle 1.60, IzPack installer 5.1.3.



Ardor Software Releases / Ardor v2.1.1e
« on: September 29, 2018, 08:49:34 am »
Hash: SHA512

Release 2.1.1e

sha256 checksums:



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 testnet
nodes, but can also be run on mainnet.

Contract Manager IntelliJ Plugin is now available to enable contract
deployment and management from inside the IntelliJ Java Development IDE.

The Contract Manager utility now supports contract verification which, given
a hash of existing contract deployed as cloud data and a Java source file,
compiles the source file and verifies that the resulting class file is
identical to the contract class file.

API callers are objects which enable simple integration of Java programs with
the Ardor APIs. Multiple code samples are provided under
./addons/src/java/com/jelurida/ardor/client/api to demonstrate tasks such as
local signing, fee calculation, message encryption and decryption, and waiting
for a new block.

Transaction voucher loading is now supported when logging in using remembered

Fixed coin exchange between parent and child chain.

Fixed decimal calculations for MS currency reserve and claim dialogs.



Ardor Software Releases / Ardor v2.1.0e
« on: August 17, 2018, 08:31:44 am »
Hash: SHA512

Release 2.1.0e

sha256 checksums:



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

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

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

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



Official Nxt Releases / NRS v1.11.14
« on: June 05, 2018, 11:03:17 am »
Hash: SHA512

Release 1.11.14

sha256 checksums:



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

Change log:

Updated the translation resource files.

Updated default peers, added checkpoint at height 1865000.



Ardor Software Releases / Ardor v2.0.14
« on: February 14, 2018, 10:38:58 am »
Hash: SHA512

Release 2.0.14

sha256 checksums:



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

Change log:

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

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



Official Nxt Releases / NRS v1.11.13
« on: February 12, 2018, 07:14:04 pm »
Hash: SHA512

Release 1.11.13

sha256 checksums:



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 users
from 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-existing
account using passphrase.

Client UI enhancements and bugfixes.



Ardor Software Releases / Ardor v2.0.13
« on: January 23, 2018, 09:43:22 am »
Hash: SHA512

Release 2.0.13

sha256 checksums:



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



Pages: [1] 2