ArdorDocs - User contributions [en]

Getting started

2022-06-07T22:41:23Z

Almonte:

{{#seo:
|title=Getting started
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki
|description=Ardor documentation homepage - Getting started with the Ardor platform
}}
<languages />
<translate>


[https://www.jelurida.com/ardor Ardor] is a blockchain-as-a-service multi-chain platform that evolved from the time-tested and energy-efficient [https://www.jelurida.com/nxt Nxt blockchain]. The Ardor mainnet launched on 01 January 2018. Through this documentation, you will learn all about the extensive capabilities of the Ardor platform. Begin developing your knowledge by reading about each of Ardor’s distinctive [[Features]] or consider trying the technology yourself by following some [[Basic tutorials|Basic Tutorials]]. For developers, documentation is provided for each of Ardor’s more than 250 [[API|APIs]] that can be used to quickly and cost-effectively deploy dApps and smart contracts that integrate your business processes with the Ardor blockchain. Check this site regularly for new content and updates as additional features are released.

==Download Ardor== 


Before we begin, if you haven’t already done so, you may wish to check that you have the correct (usually most recent) version of [https://adoptopenjdk.net/ Java] installed on your computer. You can use any compatible Java available for your platform. The minimum required version is Java 8. The recommended version is Java 11. We usually test with OpenJDK 14.


To start with Ardor/[https://www.jelurida.com/ignis Ignis], you must first download the client, also known as a "wallet", on your machine. The client is distributed as a binary package for the following platforms:


[[File:200px-Windowslogo.jpg|100px|frameless|link=Getting_started#Windows]][[File:200px-AppleLogo.jpg|100px|frameless|link=Getting_started#MacOS]][[File:200px-Linuxlogo.jpg|130px|frameless|link=Getting_started#Linux]][[File:200px-RaspberryPi_Logo.png|100px|frameless|link=Getting_started#Raspberry_Pi]][[File:200px-Android.png|100px|frameless|link=Getting_started#Android]]

==Client Installation == 


<div class="accordion" id="accordion-win">
<accordion parent="accordion-win" heading="===Windows===">
#Download the Windows installer for the latest official Ardor Client {{NRSVersion}} from {{NRSWinInstaller}}. If you want to test the latest testnet-only version {{NRSVersionExperimental}} that includes the snapshotting and pruning functionality, refer to the Universal Zip Package.
#Ardor's Windows client comes as an .exe file. After downloading it, you can verify its integrity by performing an [[Faq#How_to_verify_authenticity_of_Ardor_installations|integrity check]]
#Run the installer and follow the instructions on the screen. Note that you can select either the testnet or mainnet during installation, if further details are needed please follow the [[How_to_download_the_ardor_client_wallet|step-by-step guide]]. Once installed icons will be created by default in your desktop and Start Menu.
#You can now run the Ardor software by clicking on the Ardor icon. After a few seconds, the Ardor wallet will open in its own window.
#If you already have created an Ardor account, click on 'Returning User' to introduce your passphrase. If you need to create your Ardor account, [[How_to_create_an_account_on_the_Ardor_Platform|click here for instructions to Create a New Ardor Account]].
</accordion>
</div>


<div class="accordion" id="accordion-mac">
<accordion parent="accordion-mac" heading="===MacOS===">


#Download the Mac installer for the latest official Ardor Client {{NRSVersion}} from {{NRSMacInstaller}}. After downloading, [[Faq#How_to_verify_authenticity_of_Ardor_installations|verify its signature]]. After downloading, check the SHA256 hash of the package for security. If you want to test the latest testnet-only version {{NRSVersionExperimental}} that includes the snapshotting and pruning functionality, refer to the Universal Zip Package.
#Open the MacOS terminal.
#Navigate to the Mac installer you just have downloaded.
#Execute the command <code>sudo xattr -c ardor-installer-{{NRSVersion}}.dmg</code>. Type your passphrase
#Run the installer package (Ardor's Mac installer comes packaged in .dmg format) and follow the instructions on screen
## Select the language [[File:MacInstaller_2.png|none|border|400px]]
## Click on 'Next' to begin with the installation [[File:MacInstaller_3.png|none|border|400px]]
## Accept the terms of the license agreement [[File:MacInstaller_4.png|none|border|400px]]
## Select the installation path [[File:MacInstaller_5.png|none|border|400px]]
## Select the packages you want to install [[File:MacInstaller_6.png|none|border|400px]]
## Check the options [[Tutorial_on_setting_up_the_ardor_testnet|See the tutorial for setting up the Ardor testnet]] [[File:MacInstaller_7.png|none|border|400px]]
## Once installed, click on finish [[File:MacInstaller_9.png|none|border|400px]]
#You can now run the Ardor software clicking on the "ardor.app" in Applications. If you already have created a Ardor account, click in 'Returning User' to introduce your passphrase. If you need to create your Ardor account, [[How_to_create_an_account_on_the_Ardor_Platform|click here for instructions to Create a New Ardor Account]].
</accordion>
</div>


<div class="accordion" id="accordion-linux">
<accordion parent="accordion-linux" heading="===Linux===">


Here is the guide to installing the Ardor Client on a Linux 64-bit platform. 32-bit installation instructions are very similar; you just might need to download the 32-bit version of Java instead of the 64-bit one.


You can use these instructions on your Linux VPS as well.

====Set up Java==== 
You can skip this step if you already have Java installed. Otherwise, you can install it via your distribution repository doing the following (for Ubuntu/Debian builds):


<pre>sudo apt update
sudo apt install openjdk-11-jre-headless</pre>


You can also use `openjdk-8-jre-headless` or any other Java 8+ compatible version.

====Install and run the Ardor Client==== 

=====Using the Unix installer===== 
You can execute the Unix installer executable compatible with most Linux distributions from [https://www.jelurida.com/ardor-client.sh ardor-client.sh] and follow the instructions.


<pre>wget https://www.jelurida.com/ardor-client.sh
sh ardor-client.sh
</pre>

=====Using the Universal Zip Package===== 
You can follow the more generic instructions as explained below:
#Change to your home folder and download the latest client (version {{NRSVersion}} or the experimental {{NRSVersionExperimental}}): <code>cd ~</code> <code>wget {{NRSDownload}}</code><code>wget https://www.jelurida.com/ardor-client.zip.asc</code> and verify that the signature is correct: <code>gpg --with-fingerprint ardor-client.zip.asc</code>
#Unzip it: <code>unzip ardor-client.zip</code> <code>cd ardor</code>

Using the experimental version is as follows:

 <code>cd ~</code> <code>wget {{NRSExperimentalDownload}}</code><code>wget https://www.jelurida.com/ardor-client-experimental.zip.asc</code> and verify that the signature is correct: <code>gpg --with-fingerprint ardor-client-experimental.zip.asc</code>

=====Run the Ardor client===== 


#Now it's time to start the software. You may start it by executing <code>./run.sh</code> or <code>./run.sh --daemon</code> for running the Ardor node in the background, which you will find in the ardor directory. The server will be active as soon as you see in the window a text similar to this: <code>Ardor server {{NRSVersion}} started successfully.</code> This shell window will be running the Ardor server and print all the Ardor log messages, so it needs to stay running! 
#Open http://localhost:27876/ from a web browser to access the Ardor Client. Please note that, if it's the first time you run Ardor in your machine, the Ardor blockchain will need to be downloaded until it is up to date. Depending on your network connection speed, this may take a few hours. The Ardor Client will show you a progress bar as the blockchain downloads. Now you can visit the [[How_to_create_an_account_on_the_Ardor_Platform|click here for instructions to Create a New Ardor Account]].
#*NOTE: If you've installed the client on a dedicated server or VPS, you should change "localhost" to your Server/VPS IP.
</accordion>
</div>


<div class="accordion" id="accordion-pi">
<accordion parent="accordion-pi" heading="===Raspberry Pi===">


For installing the Ardor client on a Raspberry pi, you can refer to the description of [https://medium.com/@mrv_89306/solar-powered-ardor-blockchain-node-aa680a976c50 an implementation with the Ardor client powered by solar panels]
</accordion>
</div>


<div class="accordion" id="accordion-android">
<accordion parent="accordion-android" heading="===Android===">
Click on the [[Android_Full_Node|Android Full Node installation guide]] and follow the instructions.
</accordion>
</div>

<div class="accordion" id="accordion-docker">
<accordion parent="accordion-docker" heading="===Docker Image===">
There is an Ardor Node Docker image available in the Docker Hub: [https://hub.docker.com/r/jeluridaswiss/ardor Ardor Docker Image]. Deploying this image requires knowledge about docker and management of containers. Please refer to the tutorial [[Deploying_the_Ardor_Node_Docker_Image|Deploying the Ardor Node Docker Image]]
</accordion>
</div>

==='''Need help?'''=== 
Need help during the download or development process? Contact us on the [https://talk.jelurida.com Ardor & Nxt Technical forum], and take a look at the [[Faq|FAQ]]. You can also reach us by opening a ticket in our [https://desk.zoho.eu/portal/jelurida/home helpdesk]

==Lightweight Contracts documentation== 
Lightweight Contracts represent a framework for developing a layer of automation on top of the existing Ardor APIs, refer to the official documentation to read more about this feature:


<div class="noprint" style="float:none; border:1px solid black;width:95%;background-color:#F6F0F0;padding:2px;">
{| cellspacing="0"
| style="padding-left:50px;"| '''[[Lightweight_Contracts|Lightweight Contracts documentation]]'''
|}</div>
<noinclude>

==Login to Ardor== 
There are different ways to log in to Ardor to create an account. It is explained in the [[Login_Page_Tutorial|Login Page Tutorial]]

==Getting your first ARDR== 


With the Ardor client installed, it is now time to start transacting. To do that, we need to get some tokens, be it ARDR, IGNIS, or any other child chain. The Ardor mainnet is live and actual tokens are in circulation across numerous major exchanges.


Note the tokens we will be using in the next examples are from testnet. These tokens are not traded in exchanges and have no monetary value -- they exist only as a convenience for developers and those willing to experiment with the features.


The process for receiving testnet tokens is simple. Ask for them in the [https://ardorforum.org Ardor Forum], contact us on the [https://ardornxt.slack.com slack] channel #helpdesk. There is an external [https://www.ardor.world/faucet_ardor/ faucet] as well.

=== Exchanges === 


* [https://www.jelurida.com/ardor/explorers Currently trading ARDR]

==Next steps== 


Learn how to use the Ardor platform by following the [[Basic_tutorials|basic tutorials]] or start reading about Ardor's extensive built-in [[Features]].

=== Staking === 


The process of staking in Ardor is called [[Forging_(f)|Forging]]. Once you have more than 1.000 ARDR you can start forging, thus earning the transaction fees when a block is generated by your node.


Furthermore, you can also opt-in the [[Node_Reward_Program|Node Reward Program]] by just setting up a node with both the API and peer ports open to the Internet and a public and static IP address.

==Feedback and errors== 


If an error in this documentation is found, we would love to be aware to correct it as soon as possible. Please write a question to [mailto:info@jelurida.com info@jelurida.com] and we will take care.


<accordion parent="accordion" heading="Latest documentation changes and updates">
{{Special:SimpleChanges/days=150,limit=100,bots,hideminor,namespace=0}}
</accordion>
</translate>

Ardor Software Change Log

2022-06-06T11:12:02Z

Almonte: Added 2.4.2 change log

<languages />
<translate>
{{#seo:
|title=Ardor Software Change Log
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, Ardor version, change log
|description=Full change log of the Ardor blockchain
}}

=== 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 [[Asset_Exchange#Set_Asset_Trade_Royalties|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 <code>addons/plugins/ContractManagerPlugin/README</code> for details.

The content of a loaded voucher is now properly escaped.

Verification of transaction bytes when locally signing transactions of type [[Asset_Exchange/en#Set_Asset_Property|setAssetProperty]] and [[Accounts#Set_Account_Property|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 <code>nxt.tools.GenesisCreator</code> for usage instructions.

Added tool to print shuffling recipients, run <code>com.jelurida.ardor.client.api.ShufflingRecipients</code> (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 <code>nxt.openApiQueryTimeout</code>, 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 <code>nxt.disabledThrowableStackTraces</code> property, see the <code>nxt-default.properties</code> 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 <code>nxt.pruneChildChains=true</code> 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 <code>nxt.stateSnapshotConfirmations</code>.

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 [https://www.jelurida.com/resources/ardor-3.0-introduction Ardor 3.0 explained]

=== ardor-client-2.3.3===

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

*[[Tutorial_on_custom_bundlers_for_child_chain_transactions|Bundlers UI]] fixes and improvements.

*Support specifying the <code>sha256</code> hash of the admin password in the <code>nxt.properties</code> as <code>nxt.adminPasswordHash</code>, instead of the actual [[API#Admin_Password|admin password]].

*[[General_notes#Roaming_and_Light_Client_Modes|Light client]] fixes and improvements.

*Allow specifying JVM options and PID file location using <code>ARDOR_JVM_OPTS</code> and <code>ARDOR_PID_FILE</code> environment variables.

*[[Lightweight_Contracts#Contract_Runner_fees_and_funds|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_Configuration|Node processes UI]] improvement - allow deleting the encrypted config file.

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

*Added <code>run-taxreport.sh</code> and <code>run-taxreport.bat</code> 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 [[Transactions#Get_Unconfirmed_Transactions|getUnconfirmedTransactions]] and [[Transactions#Get_Unconfirmed_Transaction_Ids|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_Integration|Changelly]] and [https://changehero.io 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 - [[Networking#Get_API_Proxy_Reports|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 <code>CoinExchangeTradingBot.java</code> 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 <code>AccountBalanceNotifier.java</code> 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 <code>ChainMonitor.java</code> 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 <code>SlackNotifier.java, TelegramNotifier</code> 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|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:
* <code>m/44'/16754'/0'/0'</code> for mainnet
* <code>m/44'/16754'/0'/1'</code> 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.

*[[Bip32#Derive_Account_From_Seed|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.
*[[Bip32#Derive_Account_From_Master_Public_Key|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 <code>nxt.properties</code> 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 <code>nxt.properties</code> 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|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|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:

<syntaxhighlight lang="json">
{
"accountRS": "ARDOR-XXXX-XXXX-XXXX-XXXXX",
"autoFeeRate": true,
"validator": false,
"params": {}
}
</syntaxhighlight>
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|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 <code>nxt.addons.StandbyShuffling</code> to the list of enabled add-ons in the <code>nxt.addOns</code> property. This add-on registers three [[Shuffling#Start_StandbyShuffler|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 <code>nxt.startStandbyShufflingFile</code> 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 <code>nxt.numberOfForkConfirmations</code> or <code>nxt.testnetNumberOfForkConfirmations</code>, unless <code>nxt.isOffline=true</code>. This is to avoid building a fork if the node is temporarily disconnected. To disable this behavior, set <code>nxt.pauseForgingOnNoConnection=false</code> (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, <code>nxt.addons.TransactionTypeBundler</code>, which bundles only transactions of the transaction types specified in the filter parameter. The parameter must be a comma separated list of <code><type>:<subtype></code> 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 [[Transactions#Calculate_Fee|CalculateFee]], [[Forging#Get_Bundler_Rates|GetBundlerRates]], and all [[Create_Transaction|CreateTransaction APIs]] now take both minBundlerBalanceFXT and minBundlerFeeLimitFQT parameters, with defaults based on the <code>nxt.minBundlerBalanceFXT</code> (default 1000 ARDR) and <code>nxt.minBundlerFeeLimitFXT</code> (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 [https://www.jelurida.com/sites/default/files/JPLv1.2-Ardor.pdf 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 [https://www.jelurida.com/sites/default/files/JPLv1.2-NRS.pdf 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|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.


--------------------------------------------------------------------------------
</translate>

Template:NRSVersion

2022-06-06T11:02:30Z

Almonte:

2.4.2

Lightweight Contracts

2022-04-21T21:06:09Z

Almonte:

<languages />
<translate>

{{#seo:
|title=Lightweight Contracts
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, Lightweight Contracts
|description=Lightweight Contracts represent a framework for developing a layer of automation on top of the existing Ardor APIs.
}}
[[Category:Features]]

== Introduction to Lightweight Contracts == 
Lightweight Contracts represent a framework for developing a layer of automation on top of the existing Ardor APIs.


Contracts are developed by implementing predefined interfaces. The contract code is deployed to the blockchain as a cloud data transaction, which stores the code itself, and a contract reference transaction which associates a specific account with an existing deployed contract and configures the contract setup parameters for this specific account.


Learn more about the concepts behind the lightweight contracts using these resources:


[https://medium.com/coinmonks/lightweight-contracts-b738b6e29377 introduction article]


[https://medium.com/@lyaffe/lightweight-contracts-faq-30273120da9a frequently asked questions]


[[Basic_tutorials#Tutorial_Seminar_on_Turing-complete_Lightweight_Contracts| video seminar]]

== Prerequisites == 
Contract developers are expected to master the Java programming language or any other language which uses the Java JVM as its runtime environment.


Some prior knowledge of blockchain in general, Ardor specifically. Familiarity with concepts like account, passphrase, transaction, and block are important but not mandatory as you can always review the sample contracts supplied with the product as reference implementation.

== Getting Started == 

=== Installation === 


As of Ardor 2.2.3 when installing Ardor using the Windows or Mac installer a fully functional JDK is installed into the jdk folder under the product installation. We recommend that you use this JDK version when setting up your IntelliJ project. For all other configurations install Java SE JDK 8 or higher manually.


Install the latest version of the IntelliJ IDE, the free community edition is supported. You can develop contracts using any other Java IDE but the project setup and all examples assume using the IntelliJ IDE.


Install the latest version of Ardor and make sure to leave the dev.tools option checked during installation.

=== Contract Runner === 


Unlike many other contract development frameworks, lightweight contracts are not executed by every node on the blockchain, instead node operators have to configure their node to run contracts by registering the contract runner addon. The contract runner monitors every new block for trigger transactions. When found it triggers the respective contract after loading it from the blockchain. The contract runner also supports contracts which execute on every block and provides APIs for triggering contracts directly or using a transaction voucher.

==== Contract Runner fees and funds ==== 


The contract runner account needs funds to pay the fees for any submitted transaction.
Please ensure that the account has enough balance on every chain where the contracts
will submit transactions. Alternatively, you can setup a bundler to sponsor the fees
and let the contract runner submit zero fee transactions.


The contract runner uses the reference transaction mechanism to link any submitted
transaction to the transaction that triggered the contract. This ensures that
the confirmation of the new transaction depends on the confirmation of the triggering
transaction. This requires a '''deposit of 10 ARDR''' for every submitted transaction
that is refunded when both transactions are confirmed or the submitted transaction
expires. So please '''make sure the contract runner account has enough ARDR balance to cover this deposit'''.

==== How to configure the Contract Runner ==== 


First and foremost, to activate the contract runner for your node add the property <pre>nxt.addOns=nxt.addons.ContractRunner</pre> to your node's [[Faq#Node_configuration_using_the_nxt.properties|nxt.properties]] file.


You have now several ways to configure the contract runner. '''You only need to use one of the options.'''


* The easiest and recommended way is to use the [[Node_Processes_Configuration|Node Processes UI]] to set up an encrypted configuration file stored on the node. You only need to save the file once and then just start the file using an encryption password on each node start. The ''Save'' modal popup even creates a basic working configuration for you that is fully functional so most of the times it is just a matter of entering the passphrase and an encryption password and you are good to go.


[[file:Processes_SaveContractRunner.png|class=img-responsive|center|Save Contract Runner modal]]


* Another option is to keep the configuration on your local computer and upload it as a json file using the provided button on the contract runner status page accessible via the ''Settings'' menu.


* You can also add the configuration parameters directly on the [[Faq#Node_configuration_using_the_nxt.properties|nxt.properties]] file so they will be used right away as the node starts. '''You need to prefix every parameter''' with <code>addon.contractRunner.</code> so they become like this: <code>addon.contractRunner.secretPhrase=IWontTellYou</code> Please be aware that there are several parameters that shall remain secret like the accounts’ secret phrases or some contract setup parameters. The <code>nxt.properties</code> file is stored in clear text.

==== Contract Runner General Configuration Settings ==== 


The following properties control the Contract Runner execution.


'''"privateKey"''' - specify the private key (for HD accounts) of the contract runner account i.e. the account from which the contract runner will submit transactions. It is never submitted to any remote node. Be careful if you decide to store this data in the ''nxt.properties'' file as it is stored in clear text.

'''"secretPhrase"''' - specify the secret phrase (for legacy accounts) of the contract runner account i.e. the account from which the contract runner will submit transactions. This passphrase is never submitted to any remote node. Be careful if you decide to store this data in the ''nxt.properties'' file as it is stored in clear text.


'''"accountRS"''' - alternatively if you only want your contract runner to verify transactions submitted by another contract runner, specify the account of the contract runner you would like to follow. This way your contract runner can repeat the contract calculations and verify transactions submitted by another contract but not submit its own transactions.


'''"autoFeeRate"''' – 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 UI.


'''"minBundlerBalanceFXT"''' – this optional parameter allows filtering out bundlers 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''.


'''"minBundlerFeeLimitFQT"''' - this optional parameter allows filtering out bundlers when ''autoFeeRate'' is activated. Bundlers with a fee limit currently below the property ''minBundlerFeeLimitFQT'' are not considered for the best fee calculation. Again, the default for this property is to use the same value as the equivalent global property.


'''"feeRateNQTPerFXT.<Chain Name>"''' - when ''autoFeeRate'' is set to false or the best fee cannot be obtained the contract runner will use this value specified in NQT to calculate the child chain fee to submit. For each chain your contract runner is expected to submit transactions, you can specify a different value. Example: to set the rate to 2.5 IGNIS per ARDR, set this property to 250000000. i.e. 2.5 IGNIS specified in NQT.


'''"validator"''' - if set to true (default: false), the contract runner will watch for transactions submitted by other contract runners and will try to verify that the other contract runner indeed runs the contract stored on the blockchain.


'''"validatorSecretPhrase"''' - when ''validator'' is set to true, and another contract runner is using an account under account control, specify here the secret phrase of the controlling account. Your contract runner will intercept the transactions submitted by the other contract runner, repeat the calculations, and if it receives the same result, will submit an approval transaction for the transaction submitted by the other contract runner.


'''"catchUpInterval"''' - a timeout value specified in seconds (default: 3600 i.e. one hour). During blockchain download, the contract runner will only submit transactions when downloading a block with a timestamp later than the current time minus the defined ''catchUpInterval''. The purpose of this setting is to prevent a contract runner from flooding the unconfirmed transaction pool with duplicate transactions during blockchain download.


'''"seed"''' - supply random seed to the contract runner formatted as hex string (default: the public key of the contract account which is useless from randomness perspective). Convert any random value to hex string using the hexConvert API and specify the resulting hex string value as a seed. A seed of less than 16 bytes can be easily brute-forced so make sure your seed is longer. Keep your seed secret, it can be used in the future to validate your contract execution.

==== Contract Runner Contract Specific Settings ==== 


Note that in most cases there is no need to specify these parameters. Always prefer using contract setup parameters that are stored on the blockchain itself except when a contract parameter has to remain secret (for example, a passphrase or some secret credentials to a 3rd party service) or the size of the parameters exceed the maximum for the contract reference transaction (160 bytes). [[#Contract_Parameters|More information about the different parameter types]].


In the cases when this configuration is needed it is recommended to use the [[Node_Processes_Configuration|Node Processes UI]].


Alternatively, specify the configuration file used by the contract runner to load contract specific setup parameters by adding the property ''addon.contractRunner.configFile'' to ''nxt.properties'', for example <code>addon.contractRunner.configFile=./conf/contracts.json</code>, the specified path is relative to the [[faq#User directories per product and platform|user directory]].


A sample contract configuration file is provided in the ./addons/resources/contracts.json file under the installation folder. Copy this file to the conf folder under your project's [[faq#User directories per product and platform|user directory]] and configure it as follows.


'''"params"''' - specify contract setup parameters per contract. Use this setting only for private setup parameters that you don't like to submit to the blockchain such as passwords, API keys, etc. Otherwise specify the setup parameters in the contract reference transaction as explained in the contract manager configuration. The contract parameters configured in the params object are accessed by the contract code using the context method <syntaxhighlight lang="java">context.getContractRunnerConfigParams(getClass().getSimpleName())</syntaxhighlight>


Alternatively, create an inner interface decorated with the <code>@ContractParametersProvider</code> annotation inside your contract and define a method with the annotation <code>@ContractRunnerParameter</code> using the same name as the corresponding parameter in the contract runner configuration file.
For example see the <code>secretPhrases()</code> method of the <code>LeaseRenewal</code> sample contract which returns the array of passphrases specified in contracts.json


<code>{ "params": { "LeaseRenewal": { "secretPhrases": [ ... ] }}}</code>

==== Monitoring the contract runner ==== 


To verify that the contract runner has started, look for the message "ContractRunner Started" in the [[Faq#Where_to_find_the_node_log_file.3F|node log file]].


To check the status of the contract runner and deployed contracts, invoke the getSupportedContracts API.


In response, you'll receive an array of contracts supported by the specific contract runner and their properties, and the contractAccount parameter which specifies the owner account of the contract runner, which is based on the passphrase or account id you specified in the contract runner configuration.


In case the contract runner has failed to start, the getSupportedContracts API will return a descriptive error message.


As of version 2.2.1 when your wallet is connected to a contract runner node, you can choose "Contracts" from the "Settings" menu to view information about the contract runner and the deployed contracts. Including information about invocation parameters for the contracts and validation used by the contract.


[[file:Contracts.page.PNG|class=img-responsive|Contracts Page]]

=== Contract Manager === 


The contract manager is a command-line utility that manages the contract lifecycle. Its primary usage is to deploy contracts to the blockchain, use it also to add or change a reference to an existing contract, to update contract setup parameters, to remove old contract references, and to verify that a specific contract was compiled from a specific Java source file.

==== Contract Manager Configuration ==== 


The settings which control the operation of the contract manager are defined in the nxt.properties file, their documentation is specified in the ./conf/nxt-default.properties file under the installation folder in the "#### CONTRACT MANAGER ####" section.


You should define the secret phrase for transactions submitted by the contract manager using the property <code>contract.manager.secretPhrase=[Secret Phrase]</code>


The contract manager connects to an Ardor node to use the Ardor APIs and submit transactions. By default, it connects to a node running on localhost. Use the <code>contract.manager.serverAddress=[Server Address]</code> property to connect the contract manager to a remote node. The contract manager will never submit its passphrase to a remote node.


Use the optional <code>contract.manager.uploadParamsFile=[Path to configuration file]</code> property, to configure the contract manager upload parameters configuration file.

==== Upload Parameters Configuration File ==== 


The upload parameters file contains a json array of contract definitions named "contracts".


Note: as of version 2.2, the contract upload configuration file is optional. Every setting in this file can be configured using a matching property in nxt.properties file.


For each contract specify the following parameters:


'''"className"''': the name of the class without package name, this name represents the class name loaded by the contract runner from the [[Data_Cloud|data cloud]] and the name of the contract reference. This is limited to 32 bytes.


'''"packageName"''': [optional, default to package specified as command line parameter] the Java package name of the contract class as specified in the package directive inside the source code.


'''"filePath"''': only in case the contract is deployed as a Jar file. Specify the path to the Jar file which will be deployed to the cloud data. If no filePath is specified the contract manager will attempt to load the class file specified by the className attribute from the classpath.


'''"params"''': a Json object representing the contract setup parameters. These parameters are accessed by the contract through its context object or using the <code>@ContractParametersProvider</code> interface methods decorated with <code>@ContractSetupParameter</code> annotation. Notice that there's a limit of 160 bytes for the content of this field in the contract reference transaction. The contract manager will trim all redundant white spaces. You can also reduce the size of the parameter names. If you still cannot manage to fit all parameters into 160 bytes you can move some of them to the contract manager.


The upload parameters for the sample contracts available out of the box are defined in the ./addons/resources/contract.uploader.json file under the installation folder. This file is automatically copied to the ./conf folder under the user directory in case it does not exist yet.


Alternatively, every setting in the contract uploader file can be defined in nxt.properties using the following format:


Contract Manager settings for a specific contract - contract.[contractName].[setting]


Contract setup parameters submitted to the blockchain - contract.[contractName].param.[setting]


For example, to define the "frequency" setup parameter of the "AllForOnePayment" contract use the following property:


<code>contract.AllForOnePayment.param.frequency=6</code>

== Setting Up the Development Environment == 


Assuming all dependencies were installed, we can now open the Ardor contracts project inside IntelliJ and start developing contracts.


The IntelliJ project structure is provided as part of the "Contract Development Tools" package you selected when installing Ardor so there is no need to create a new project.


If you installed Ardor into a read-only folder you will need to copy it to a folder for which you have write permissions.


Windows - copy <code>"c:\Program Files\Ardor"</code> to a writable location such as <code>c:\Users\<Your user>\Documents</code>


Mac - copy <code>/Applications/ardor.app</code> to <code>ardor.app</code> in your home folder (use cp -R from the terminal for recursive copy on Mac)


Linux - this should not be an issue as long as you installed Ardor into a folder you own.


Alternatively, if you decided to develop your project in the same location where you installed Ardor, a future upgrade may override some of the project files so make a backup of your project before upgrading.


Start IntelliJ, from the top menu choose "File->Open", in the resulting "Open file or project" dialog select the Ardor folder itself.


[[File:ope.project.PNG|class=img-responsive]]


Select the Ardor module from the left pane by clicking the "1:Project" label.


[[File:project1.PNG|class=img-responsive]]
[[File:project2.PNG|class=img-responsive]]


The Ardor module contains the sample contracts provided with installation.


Open the Ardor module settings by pressing F4 while the module itself is in focus or right click and choose "Open Module Settings".


Select the "Project" link from the left pane and set the "Project SDK" to the Java JDK you installed earlier and set the "Project Language Level" to 8 and click "Ok".


[[File:project5.png|class=img-responsive|border|Project structure]]


Build the Ardor module by selecting the "rebuild Module 'Ardor'" from the IntelliJ "Build" menu (Ctrl+Shift+F9)


Restart IntelliJ and reopen the project.


Under the Ardor module, there are two Java source roots, the first contains the sample contracts, the second contains the unit tests for the sample contracts.


For example, this is the HelloWorld sample contract.


[[File:project4.PNG|class=img-responsive|HelloWorld sample]]


Your IntelliJ contracts project contains the following launchers, visible in the selection box on the top right.


<code>Ardor Local</code> - runs the node using the existing node configuration


<code>ContractRunnerSuite</code> - invokes the automatic tests for all contracts


You are now ready to develop your first contract

== Contract Development == 


A contract is composed of one or more Java class files possibly packaged into a Jar and possibly relying on other Jar files.


The main contract class has to extend the nxt.addons.AbstractContract class and implement one or more of the provided callback methods which are invoked by the Contract Runner in response to specific events as shown as follows:


{{TransactionTriggers}}


A contract should implement one or more of these callback methods.

=== Context Objects === 


Each of the above callback methods, receive a context object, the context object provides various services to the contract and represents the interface between the contract and the blockchain.


Always prefer using the context object over calling directly to an internal blockchain method since every method provided by the context is guaranteed to maintain backward compatibility and not break your contract code when a new Ardor release is deployed. The services provided by the context object depend on the type of callback, these services are documented in the [https://testardor.jelurida.com/doc/ Javadoc] for the context class.

=== API callers === 


For each of the Ardor public APIs there is a specific Java caller class named the same as the API with a capital letter at the beginning and a "Call" prefix.


For example the call object for the getBlockchainStatus API is <code>GetBlockchainStatusCall</code>.


API invocation always follows the same pattern, create a caller instance, possibly set some API parameters, then invoke the call() method to receive a Json response as a JO object you can then work with.


For example: to invoke the getExecutedTransactions API from inside the contract:


<syntaxhighlight lang="java">
GetExecutedTransactionsCall request = GetExecutedTransactionsCall.create(2).height(height).type(0).subtype(0).recipient(context.getConfig().getAccount());


JO getExecutedTransactionsResponse = request.call();
</syntaxhighlight>


Always use the API callers to access information stored on the blockchain since these API callers represent the interface between your contract and the data stored on the blockchain. The API callers will remain compatible in future releases.

=== Submitting Transactions === 


In most cases, contracts should not save any internal state between contract invocations. To make changes to the blockchain state, contracts should submit transactions. To submit a transaction, invoke the API caller for the specific transaction type, then use the <code>context.createTransaction()</code> method to submit the transaction to the blockchain.
Internally the createTransaction method implements local signing, fee calculation, and other complex processing that you as contract developer don't have to deal with.


Example:


<syntaxhighlight lang="java">
SendMoneyCall sendMoneyCall = SendMoneyCall.create(context.getChainOfTransaction().getId()).recipient(recipient).amountNQT(returnAmount);


context.createTransaction(sendMoneyCall);
</syntaxhighlight>

=== What to return from the contract process methods ===

The process methods for a contract return a JO object. This object encapsulates the response from the contract invocation which can be nothing, some error or one or more transactions. As explained above those responses should be built from the provided Context. The same Context provides a <code>getResponse()</code> object that you can return.

In general you can finish your contract method like this:

<syntaxhighlight lang="java">
return context.getResponse();
</syntaxhighlight>

If you are only returning one transaction you can reuse the output of the <code>createTransaction()</code> method.

<syntaxhighlight lang="java">
return context.createTransaction(sendMoneyCall);
</syntaxhighlight>

=== Contract Parameters === 

There are three types of contract parameters:

* The invocation parameters, sometimes called runtime or transaction parameters, are the parameters sent with the transaction message triggering the contract. They can be private if sent on an encrypted message. The size is limited by the message size of the given transaction.

* The setup parameters are specified in the contract reference transaction, usually when uploading the contract. They are public and limited to 160 bytes.

* The contract runner parameters are specified when starting the contract runner. These are the only ones that are not on the blockchain, so they are private and have no size limits.

==== How to access the different parameters ====


For contracts triggered by a transaction use <syntaxhighlight lang="java">context.getRuntimeParams()</syntaxhighlight> to load the specific invocation parameters or preferably define the parameter as a method of an inner interface decorated with @ContractParametersProvider annotation. Name the method the same as the parameter name and decorate it with the @ContractInvocationParameter annotation.


To load the contract setup parameters specified in the contract reference transaction use <syntaxhighlight lang="java">context.getContractSetupParameters()</syntaxhighlight> or preferably define the parameter as a method of an inner interface decorated with @ContractParametersProvider annotation. Name the method the same as the parameter name and decorate it with the @ContractSetupParameter annotation.


To load the contract runner parameters specified in the contract runner configuration file for the specific contract use <syntaxhighlight lang="java">context.getContractRunnerConfigParams(getClass().getSimpleName())</syntaxhighlight> or preferably define the parameter as a method of an inner interface decorated with @ContractParametersProvider annotation. Name the method the same as the parameter name and decorate it with the @ContractRunnerParameter annotation.


All the parameters getter methods return a JO object.


For usage example of the <code>@ContractParametersProvider</code> decorated inner interface see the <code>HelloWorldForwarder</code> and <code>LeaseRenewal</code> sample contracts.

=== Working with Json === 


All API callers and configuration parameters return a JO object which represents a Json object.


Use the JO object to query the Json object. Specifically use the getArray() method to obtain a JA object representing a Json Array.


There are plenty of usage examples in the sample contracts.

=== Accessing External Resources === 


Unlike most smart contract frameworks, lightweight contracts support access to external resources. Your contract can communicate as client of any external service which provides a Java client API library, or Http, XML, Json, Soap, ldap, or a similar interface.


If necessary your contract can access code from 3rd party Jar files as long as these Jar files are included in the classpath of the contract runner node. You may add external Jar files to the classpath of the node by copying the files to the ./addons/lib folder under the installation folder.


Learn mode about [https://medium.com/@lyaffe/oracle-contracts-on-ardor-94480bc4890b Oracle Contracts]

=== Lightweight Contracts Design === 


To learn more about the internal design of the lightweight contracts framework see [https://medium.com/@lyaffe/lightweight-contracts-design-f37fa5211bae this article]

== Best Practices == 

=== Single Source File Multiple Classes === 


To simplify contract development always attempt to concentrate all your source code into a single source file which defines the contract class itself and possibly additional inner classes. When deploying the contract to the blockchain the contract manager loads the main contract class and checks if it has inner classes. If there are no inner classes, the contract class file is deployed to the blockchain, otherwise, the contract manager packs the contract and all its inner classes into a Jar file and deploys the Jar file to the blockchain.

=== Parameter Validation === 


Always start your contract code with input validity checks. For example, if your contract is triggered by a sendMoney transaction, make sure the payment recipient is the contract account and that the payment uses the expected chain, that the payment amount is correct, etc.


Validate that all invocation parameters represent the data type you expect and are within their valid boundaries.


For your convenience you can decorate the contract <code>processTransaction</code> and <code>processVoucher</code> methods with one of the following predefined annotations:


<code>@ValidateTransactionType</code> validates that the trigger transaction type is of one of the accepted types and is not of one of the rejected types.


<code>@ValidateContractRunnerIsRecipient</code> validates that the contract runner account is the recipient of the trigger transaction.


<code>@ValidateChain</code> validates that the chain of the trigger transaction is one of the accepted chains and is not one of the excluded chains.


See usage example in the <code>RandomPayment</code> contract.

=== Stateless Contracts === 


In most cases, contracts should only store state information in the blockchain itself or as setup parameters. If you are using member variables in the contract class itself you might be doing something wrong. Bare in mind that the contract runner may restart at any moment and that your contract callbacks may execute in parallel with other contracts. Learn more about [https://medium.com/coinmonks/stateful-vs-stateless-blockchain-contracts-bcd1b0c25ff stateless contracts]

=== Internal Blockchain Functionality === 


Do not invoke public methods of the blockchain directly. Always attempt to use the context object and the caller APIs.


If you are missing some essential function or service, let us know and we will add it in the next release.

=== Random Data === 


If your contract requires random data, make sure to define a secret random seed in the contract runner configuration. See the following article about our approach to [https://hackernoon.com/random-number-generator-in-contracts-44abfe48240d random number generation]

== Contract Deployment == 


As explained above, contract deployment is a two-step process, first the contract code is deployed using a cloud data transaction then a contract reference transaction is submitted to provide an entry point to the correct version of the contract. While this deployment process can be accomplished manually using the Ardor APIs, it is much simpler to perform the deployment using the contract manager utility.


First [[#Contract Manager|configure the contract manager]] then use either the contract manager IntelliJ plugin (recommended) or invoke the command line utility (ContractManager.bat or contractManager.sh) from the command line to view the available options.


In both configurations, the contract manager connects to an existing full node, preferably running on your local workstation. Make sure your node is properly configured and fully synchronized with the blockchain.


Remember that the contract manager deploys transactions to the blockchain. For the transactions to confirm you need to wait for the next block.

=== Contract Manager IntelliJ Plugin === 


The contract manager plugin provides a simple configuration dialog to invoke the contract manager utility from inside the IntelliJ IDE. You first need to install the contract manager plugin into your IDE, this process has to be repeated after every Ardor version upgrade.

==== Install the Plugin ==== 


From the "File" menu choose the "Settings" option.


From the resulting "Settings" dialog select the plugins page.


[[File:IntelliJ Plugin Installation1.jpg|class=img-responsive|Settings]]


Select the cogwheel menu on the right and click "Install plugin from disk" menu item. Using the resulting file dialog select the ContractManagerPlugin-2.3.0.zip file from the Ardor installation folder.


[[File:IntelliJ Plugin Installation2 2.jpg|class=img-responsive]]


You should now see an "Ardor Contract Manager" entry listed in the plugins list.


Restart IntelliJ to complete the installation.


The contract manager plugin is now installed.


Whenever there is a new version of the plugin, uninstall the old one and repeat the process above.

==== Use the Plugin ==== 


To use the contract manager plugin you must first start your Ardor node. One simple way to do so is to run the node using the "Ardor Local" launcher from inside the IntelliJ IDE. If your node is offline while running the contract manager, the contract manager will display the message "Cannot connect to http://<address>:<port>/nxt make sure the node is running" and terminate.


Edit the runtime configurations.


[[File:plugin4a.png|class=img-responsive]]


Add a new configuration of type "Ardor Contract Manager"


[[File:plugin5.png|class=img-responsive|Ardor Contract Manager]]


Name the configuration and define the contract manager options


[[File:plugin6.png|class=img-responsive|border|Contract Manager Options]]


Run the configuration as usual


[[File:plugin7.png|class=img-responsive]]


Review diagnostic messages logged to the IntelliJ console at the bottom of the screen.

=== Contract Manager Command Line Utility === 

==== Examples ==== 


Deploy a new version of the ForgingReward contract:


<syntaxhighlight lang="bash">contractManager.bat -u -n ForgingReward -p com.jelurida.ardor.contracts</syntaxhighlight>


Response:


<pre>
...


Contract class com.jelurida.ardor.contracts.ForgingReward uploaded 5f4afbead4f7f887082a36dd97df72f6ed7f980c1b3e99eccb7d67bb150c9748
...


Contract reference registered ForgingReward={"rewardArdor":"true","interval":5,"rewardNxt":"true","rewardChain":"IGNIS","rewardAmountNQT":150000000} for contract chain: IGNIS, full hash: 5f4afbead4f7f887082a36dd97df72f6ed7f980c1b3e99eccb7d67bb150c9748
</pre>


List deployed contracts for a specific account:


<syntaxhighlight lang="bash">contractManager.bat -l -a ARDOR-XK4R-7VJU-6EQG-7R335</syntaxhighlight>


Response:


<syntaxhighlight lang="json">
{"contract":{"chain":2,"transactionFullHash":"ff374385044519900147c145beeaa07520f0a9850b95d84b835c88ff1ce81015"},"name":"DistributedRandomNumberGenerator","id":"10806939862175194746","params":"{}"}


{"contract":{"chain":2,"transactionFullHash":"5f4afbead4f7f887082a36dd97df72f6ed7f980c1b3e99eccb7d67bb150c9748"},"name":"ForgingReward","id":"10360831005888949167","params":"{\"rewardArdor\":\"true\",\"interval\":5,\"rewardNxt\":\"true\",\"rewardChain\":\"IGNIS\",\"rewardAmountNQT\":150000000}"}


{"contract":{"chain":2,"transactionFullHash":"8292a5e3a9bd209a85b3a865be8175d1c762393dac33e84a3113e19a7efc0e39"},"name":"NewAccountFaucet","id":"4615352619232966745","params":"{\"thresholdAmountNQT\":72000000000,\"chain\":2,\"thresholdBlocks\":1440,\"faucetAmountNQT\":500000000}"}
</syntaxhighlight>


Delete contract reference for a specific account (the contract itself is not deleted)


<syntaxhighlight lang="bash">contractManager.bat -d -a ARDOR-XK4R-7VJU-6EQG-7R335 -n ForgingReward</syntaxhighlight>


Response:


<pre>
Contract reference 10360831005888949167 deleted for account ARDOR-XK4R-7VJU-6EQG-7R335 contract name ForgingReward
</pre>


Add or update contract reference


<syntaxhighlight lang="bash">contractManager.bat -r -h 5f4afbead4f7f887082a36dd97df72f6ed7f980c1b3e99eccb7d67bb150c9748 -n ForgingReward</syntaxhighlight>


(the hash parameter -h is the full hash of the cloud data transaction storing the contract version you would like to reference)


Response:


<pre>
Contract reference registered ForgingReward={"rewardArdor":"true","interval":5,"rewardNxt":"true","rewardChain":"IGNIS","rewardAmountNQT":150000000} for contract chain: IGNIS, full hash: 5f4afbead4f7f887082a36dd97df72f6ed7f980c1b3e99eccb7d67bb150c9748
</pre>


Verify that a contract class in the blockchain was compiled from a specific source file, note that this action has to run using a Java JDK and not using the Java JRE provided with some of the installations.


Invoke the command below from the Ardor installation directory. The verification action has to run using an Oracle Java JDK.


<pre>
"c:\Program Files\Java\jdk-10.0.2\bin\java.exe" -Djava.security.manager -Djava.security.policy=contractManager.policy -cp classes;lib\*;conf nxt.tools.ContractManager -v -h 4a8cd1c3fc86ad1cfbce4957142ff86c5d908af633bc6e38fddbf0be2418ff05 -s c:\Users\liory\ardor\addons\src\java\com\jelurida\ardor\contracts\HelloWorld.java
</pre>


Response:


<pre>
Verification succeeded - class files are identical
</pre>

== Contract Security == 


The contract runner relies on the Java JAAS framework to ensure that malicious contracts downloaded from the blockchain cannot attack the contract runner local workstation or the blockchain node operations. To achieve this, contracts are loaded using their own class loader and run in their own protection domain which forms a sandbox that limits the permissions assigned to contract code.


Most contracts should be able to run using default the permissions. However, if you need to make changes to security permissions, read on.


The main configuration files for controlling the contract security are ardor.policy and ardordesktop.policy, both files are standard [https://docs.oracle.com/javase/8/docs/technotes/guides/security/PolicyFiles.html Java policy files]. ardor.policy is the active policy file when running in command line mode and when running unit tests. ardordesktop.policy is a slightly more permissive policy file active when running the desktop wallet. In this document, we will always use ardor.policy, everything explained is also applicable to ardordesktop.policy.


By default, contracts are assigned the permissions defined in the virtual untrustedContractCode protection domain.


<syntaxhighlight lang="java">
grant codeBase "file://untrustedContractCode" {
permission java.io.FilePermission "${java.io.tmpdir}*", "read,write,delete";
permission java.util.PropertyPermission "java.io.tmpdir", "read";
};
</syntaxhighlight>


The defined permissions grant the contract code access to the temporary folder on the contract runner workstation. The contract can freely read, write, delete files in this folder.


In addition, contracts are always allowed to connect to any internet address.


See the <code>AllowedActions</code> contract for code samples permitted by the policy file and the <code>ForbiddenActions</code> for code samples not permitted by default. Neither of these samples cover the full list of permitted and non-permitted actions.

=== Granting Additional Contract Permissions === 


At the moment all sample contracts are designed to run using the default untrusted contract permissions, however, developing contracts with elevated permissions is supported. A contract runner node operator can grant additional permissions by adding these permissions to the untrustedContractCode protection domain of ardor.policy, but this is discouraged since it will grant these permissions to all the contracts run by this contract runner. Instead, we recommend elevating permissions per contract signer account or per specific contract.


To grant additional permissions for contracts signed by a specific account, define the public key of the account that submitted the contract to the blockchain, in a new protection domain entry using the "signedBy" token. The public key should be specified in hex string format.


For example the following ardor.policy section grants additional permissions for contracts submitted to the blockchain by the account whose public key is the following:<pre>112e0c5748b5ea610a44a09b1ad0d2bddc945a6ef5edc7551b80576249ba585b</pre>


<syntaxhighlight lang="java">
grant codeBase "file://untrustedContractCode" signedBy "112e0c5748b5ea610a44a09b1ad0d2bddc945a6ef5edc7551b80576249ba585b" {
permission nxt.util.security.BlockchainPermission "db";
permission nxt.util.security.BlockchainPermission "getBlockchain";
};
</syntaxhighlight>


Similarly to grant additional permissions to a specific contract use the "principal nxt.util.security.TransactionPrincipal" setting followed by the contract's transaction full hash or the hash of the whole tagged data as saved in the blockchain or the hash of the contract class/jar itself.


<syntaxhighlight lang="java">
grant codeBase "file://untrustedContractCode" principal nxt.util.security.TransactionPrincipal "df15278b53c5c24ccb179302834608b50b94c3e91c97ffa0510357e35fec919b" {
permission nxt.util.security.BlockchainPermission "db";
};
</syntaxhighlight>


To monitor the permissions assigned to your contract in runtime, use the following Java command line flag <code>-Djava.security.debug="access"</code>. Additional information about protection domains can be obtained using <code>-Djava.security.debug="access,domain"</code> but this creates very verbose output.
Look in the generated log for permissions which are marked as "denied" and use the diagnostic information to learn the reason for denial.


To configure the ardor.policy file you can use any text editor or IntelliJ IDE but be warned that the syntax of this file is very strict, therefore every small typo will render the file useless and remove all permissions to all code resulting in errors when starting the node.


Alternatively use the graphical [https://docs.oracle.com/javase/tutorial/security/tour1/wstep1.html policytool] provided with the Java JRE for making changes to the policy file without the risk of creating syntax errors.


To temporarily disable all permission checks add the following property to the nxt.properties file:
<code>nxt.disableSecurityPolicy=true</code>

=== Checking Contract Permissions === 


A contract that requires elevated permissions from the contract runner should start by checking that these permissions were granted, if not, it should fail gracefully. Use the <code>context.isPermissionGranted()</code> API to check if a specific permission is granted. See the DatabaseAccess sample contract for example how to check for permissions. If a required permission is not granted, log an error message and return.

== Sample Contracts == 


There are multiple sample contracts included with source code as part of the product installation. The sample contracts are documented using javadoc and internal comments. Always use the sample contracts as reference to understand correct coding techniques and best practices.


[https://testardor.jelurida.com/doc/com/jelurida/ardor/contracts/package-summary.html ''Javadoc documentation'']


In the next sub-sections it will be described several sample contracts. All the examples can be found in the [https://bitbucket.org/Jelurida/ardor/src/master/addons/test/java/com/jelurida/ardor/contracts/ contracts folder of the official repository].

=== Trading bot (CoinExchangeTradingBot.java) === 


Trading bot <code>CoinExchangeTradingBot.java</code> 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.

=== Account Balance Notifier (AccountBalanceNotifier.java) === 


The account balance notifier <code>AccountBalanceNotifier.java</code> 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.

=== Chain Monitor Contract (ChainMonitor.java) === 


The chain monitor contract <code>ChainMonitor.java</code> 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) === 


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

== Contract Trigger Transaction == 


To trigger the execution of a deployed contract, any account can submit a transaction with a special message attachment. The message should be prunable (leave "Message is Never Deleted" unchecked in the wallet) and should be formatted as Json, can be either encrypted or plain text, should identify the contract to execute and optionally provide contract specific invocation parameters.

=== Examples === 


Trigger the HelloWorld contract by sending a message transaction to the contract runner account with the text:


<code>{“contract”:”HelloWorld”}</code>


Trigger the SplitPayment contract and describe how to split the payment, by sending a payment transaction to the contract and add the following attached message:


<code>{"contract":"SplitPayment","params":{"ARDOR-SZKV-J8TH-GSM9-9LKV6":"0.2","ARDOR-9KZM-KNYY-QBXZ-5TD8V":"0.5","ARDOR-E93F-7E8Z-BHJ8-A65RG":"0.3"}}</code>


Note that the "params" token in the message is a Json object by itself, the data in the params object is contract specific. Consult the contract author as to which params need to be submitted and in which format.


When a trigger transaction is submitted, all active contract runners will process this transaction. Whether or not the contract will actually process the transaction depends on the contract itself.


For example, most contracts will only process payments submitted to their contract runner account and ignore payments made to other accounts but this depends on the contract logic. Contracts can choose to process certain transaction types, certain chains, and certain recipient accounts based on their own internal logic.

== Oracle Contracts - Interface with External Systems == 


One of the powerful features of Lightweight Contracts is their ability to interface with external systems to load data and register it on the blockchain and to save data to an external system based on blockchain data. Interfacing with external systems is a trade-off between decentralization and utility. There are cases where a specific contract runner can load data from an external system such as exchange rate or personal data that no other contract runner can validate. There is no choice for users but to trust the contract runner not to manipulate this data the same way users trust a centralized system. Still, once the data is registered on the blockchain, it is digitally signed and timestamped by the contract runner account and can no longer change. So as long as the contract runner is a trusted entity information provided by it can be used safely.


However, there are few steps contract developers need to take to increase the reliability of Oracle contracts, as a developer, you should consider that contracts should be designed to be idempotent (i.e. can run multiple times on the same data and produce the same result). For example, a contract can run once when a trigger transaction is received, then again if the node switches to a better fork and the trigger transaction is included in a different fork, and again in case the contract runner is re-downloading the blockchain. Ideally, in all these cases the contract should reproduce the exact same output transactions. The blockchain itself protects against including duplicate transactions in the blockchain.


However, when relying on external data there is no way to guarantee that transaction data won't change between invocations. Therefore developers of Oracle contracts should always look for duplicate transactions generated by the contract based on the same trigger transaction but with different data (if the data is the same, duplicate transactions will be discarded by the blockchain itself).


Contract developers need to override the following method:


<code>public <T extends TransactionResponse> boolean isDuplicate(T myTransaction, List<T> existingUnconfirmedTransactions) { ... }</code>


The method accepts the transaction currently submitted by the contract and a list of transactions already waiting to be included in the blockchain. The contract should implement contract specific policy to identify if the new transaction duplicates an existing transaction. If it does, the method should return true value to instruct the contract runner not to submit the new transaction to the blockchain.


Example for Oracle contracts


The <code>IgnisArdorRates</code> contract uses the Bittrex exchange APIs to calculate the market rate between Ardor and Ignis and compare it to the decentralized coin exchange market rate. For this contract duplicates are no a real risk, at worst, there will be slightly different exchange rates registered on the blockchain on the same block.


The <code>LiberlandCitizenRegistry</code> contract uses the Liberland APIs to load citizen data. There is a small risk that the citizen data will change between invocations of this contract so a duplicate check makes sense before submitting a transaction.

== Testing and Debugging your Contracts == 


Testing and debugging your contract is supported by the IntelliJ IDE using the standard tools used to test and debug any Java program.

=== Unit Tests === 


For each of the sample contracts provided with the product, there is also a matching unit test class with the same name followed by a "Test" postfix. For example contract <code>HelloWorld</code> has a unit test named <code>HelloWorldTest</code>.
Unit tests rely on the junit framework, each unit test starts from a clean blockchain copy, which only includes the Genesis block, it then deploys a contract, perform some actions on the contract and tests the output transactions.


All sample unit tests are grouped into the ContractRunnerSuite, the IntelliJ project provided by the installation includes a predefined launcher which runs this test suite. The first run will generate the unit tests blockchain database. Subsequent runs should work faster.


Our recommendation is that whenever you design a new contract you always design a matching unit test class to test it. Whenever you make changes to the contract make sure that all unit tests for the contract pass without errors. Unit tests also enable you to design your contract without deploying it to the blockchain where it is visible to others.

=== Debugging your Contracts === 


You can easily debug your contracts by placing a breakpoint inside the contract code. You can then run the unit test which test your contract in debug mode and debug the contract. Another option is to deploy your contract to the testnet then run your node using the "Ardor Local" launcher in debug mode. This will let you debug your contract exactly as it is executed in runtime. Since contracts are simply Java programs you can use any common debugging technique available by IntelliJ such as conditional breakpoints etc.

=== Obtaining more Diagnostic information === 


The contract runner and the contracts it runs, log information about their operation in the normal Ardor log.

=== Libraries and Scripts ===
The libraries and scripts for compiling, testing and deploying Ardor lightweight contracts can be found in [https://bitbucket.org/Jelurida/ardor-library/src/master/ the libraries official repository]
</translate>

Asset Exchange

2022-04-21T20:51:10Z

Almonte:

<languages />
<translate>
{{#seo:
|title=Asset Exchange API
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, API, API documentation, Application program interface, Asset Exchange
|description=Description and examples of the Asset Exchange operations
}}
[[Category:API]]
===Cancel Order=== 
Cancel an existing asset order. POST only.


'''Request:''' Refer to [[Create_Transaction#Create_Transaction_Request|Create Transaction Request]] for common parameters.
*''requestType'' is either ''cancelBidOrder'' or ''cancelAskOrder''
*''chain'' the chain that will be used for the operation
*''order'' is the order ID of the order being canceled


'''Response:''' Refer to [[Create_Transaction#Create_Transaction_Response|Create Transaction Response]].

====Cancel Order Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=cancelBidOrder&chain=2&secretPhrase=IWontTellYou&order=17185236428295897167&feeNQT=100000000&deadline=60| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=cancelBidOrder&
chain=2&
secretPhrase=IWontTellYou&
order=17185236428295897167&
feeNQT=100000000&
deadline=60
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"signatureHash": "20264f33a06331f6a8d7c4362d0525aee25e4ef991653f14bbfb1b2beebba433",
"unsignedTransactionBytes": "02153c6ed6013c0057fb6f3a958e320bb49c4e81b4c2cf28b9f25d086c143...",
"transactionJSON": {
"senderPublicKey": "57fb6f3a958e320bb49c4e81b4c2cf28b9f25d086c143b473beec228f79ff93c",
"signature": "30cf47942179f5969369699b548f5a3517ef7ff71b337db630ea5f8b6e740...",
"feeNQT": "100000000",
"type": 2,
"fullHash": "725f441d9f50a9b2e02d780098a827b1015ec902199becd493bfa73a4843ae89",
"version": 1,
"ecBlockId": "196207598250363138",
"signatureHash": "20264f33a06331f6a8d7c4362d0525aee25e4ef991653f14bbfb1b2beebba433",
"attachment": {
"version.BidOrderCancellation": 1,
"order": "17185236428295897167"
},
"senderRS": "ARDOR-L6FM-89WK-VK8P-FCRBB",
"subtype": 5,
"amountNQT": "0",
"sender": "15323192282528158131",
"ecBlockHeight": 285586,
"deadline": 60,
"transaction": "12873909654136315762",
"timestamp": 30830140,
"height": 2147483647
},
"broadcasted": true,
"requestProcessingTime": 7640,
"transactionBytes": "02153c6ed6013c0057fb6f3a958e320bb49c4e81b4c2cf28b9f25d086c143b...",
"fullHash": "725f441d9f50a9b2e02d780098a827b1015ec902199becd493bfa73a4843ae89",
"transaction": "12873909654136315762"
}
</syntaxhighlight>
</accordion>

====Cancel Ask Order==== 
Refer to [[Asset_Exchange#Cancel_Order|Cancel Order]].

====Cancel Bid Order==== 
Refer to [[Asset_Exchange#Cancel_Order|Cancel Order]].

===Delete Asset Property=== 
Permanently deletes a specified asset property.


'''Request:''' Refer to [[Create_Transaction#Create_Transaction_Request|Create Transaction Request]] for common parameters.
*''requestType'' is ''deleteAssetProperty''
*''chain'' is the chain of the operation. It is only available in the Ignis chain (2)
*''asset'' is the asset ID to delete the property
*''property'' is the property name to be deleted.
*''setter'' is the setter account of the property


'''Response:''' Refer to [[Create_Transaction#Create_Transaction_Response|Create Transaction Response]].

====Delete Asset Property Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=deleteAssetProperty&chain=2&asset=10982263251111884451&property=isIdentified&setter=ARDOR-X8ZN-WUJ2-SXY3-FBUYCsecretPhrase=IWontTellYou&| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=deleteAssetProperty&
chain=2&
asset=10982263251111884451&
property=isIdentified&
setter=ARDOR-X8ZN-WUJ2-SXY3-FBUYC
secretPhrase=IWontTellYou
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"minimumFeeFQT": "10000000",
"signatureHash": "c6039bd2a6d00b9f0960bf1fcd7e1e5f44cf121a7f3478a08f4ed848d01b6273",
"transactionJSON": {
"senderPublicKey": "df21142bd38c04bd5c5c342c6ca36802f9de89b75b2a0a8cbd32d29dca481e5c",
"chain": 2,
"signature": "b88c933d9fd1e325738ddf0769e2cda0deddaed8a1607f3b3597843504dd770c6dfa848a8060dc190237983365e31b3dfd247336172877f982c1ddd955dd16dd",
"feeNQT": "1000000",
"type": 2,
"fullHash": "02e3382805554d9caef831ebadd27acb8d689590ae813a5fab75e37004b29d7e",
"version": 1,
"fxtTransaction": "0",
"phased": false,
"ecBlockId": "12919444854690185600",
"signatureHash": "c6039bd2a6d00b9f0960bf1fcd7e1e5f44cf121a7f3478a08f4ed848d01b6273",
"attachment": {
"property": "isIdentified",
"asset": "-7464480822597667165",
"version.AssetPropertyDelete": 1,
"value": "true"
},
"senderRS": "ARDOR-X8ZN-WUJ2-SXY3-FBUYC",
"subtype": 10,
"amountNQT": "0",
"sender": "15382970207090678772",
"recipientRS": "ARDOR-X8ZN-WUJ2-SXY3-FBUYC",
"recipient": "15382970207090678772",
"ecBlockHeight": 449282,
"deadline": 15,
"timestamp": 26856670,
"height": 2147483647
},
"unsignedTransactionBytes": "02000000020a01decc99010f00df21142bd38c04bd5c5c342c6ca36802f9de89b75b2a0a8cbd32d29dca481e5cf49b0ea0e6497bd5000000000000000040420f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002db060080810e2ba5164bb30000000001a3b659883dd668980c69734964656e7469666965640474727565000000000000000000000000000000000000000000000000000000000000000000000000",
"broadcasted": false,
"requestProcessingTime": 5,
"transactionBytes": "02000000020a01decc99010f00df21142bd38c04bd5c5c342c6ca36802f9de89b75b2a0a8cbd32d29dca481e5cf49b0ea0e6497bd5000000000000000040420f0000000000b88c933d9fd1e325738ddf0769e2cda0deddaed8a1607f3b3597843504dd770c6dfa848a8060dc190237983365e31b3dfd247336172877f982c1ddd955dd16dd02db060080810e2ba5164bb30000000001a3b659883dd668980c69734964656e7469666965640474727565000000000000000000000000000000000000000000000000000000000000000000000000",
"fullHash": "02e3382805554d9caef831ebadd27acb8d689590ae813a5fab75e37004b29d7e",
"bundlerRateNQTPerFXT": "10000000"
}
</syntaxhighlight>
</accordion>

===Delete Asset Shares=== 
Permanently deletes a specified quantity of owned asset shares.


'''Request:''' Refer to [[Create_Transaction#Create_Transaction_Request|Create Transaction Request]] for common parameters.
*''requestType'' is ''deleteAssetShares''
*''chain'' is the chain of the operation (ie: Ignis)
*''asset'' is the asset ID
*''quantityQNT'' is the quantity (in QNT) of the asset to be deleted


'''Response:''' Refer to [[Create_Transaction#Create_Transaction_Response|Create Transaction Response]].

====Delete Asset Shares Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=deleteAssetShares&chain=2&asset=5920455660623529270&quantityQNT=100&secretPhrase=IWontTellYou&feeNQT=100000000&deadline=60&broadcast=false| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=deleteAssetShares&
chain=2&
asset=5920455660623529270&
quantityQNT=100&
secretPhrase=IWontTellYou&
feeNQT=100000000&
deadline=60&
broadcast=false
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"signatureHash": "883599a340375c387e7b27a4f2c37f4ee960760b31e4b1a9c604663c6b84c708",
"transactionJSON": {
"senderPublicKey": "373522bcd8904f4707472e590cbb67976d40e7af39650ea11cb2be5734cdf30c",
"signature": "b91a664d9ee99399ebba913fa56abea26fbf4b84fe10fa4f76a29a8eae16810e61...",
"feeNQT": "100000000",
"type": 2,
"fullHash": "8929fa9d30fd38c8811e079835b3959c1a3f8503df8999d5a858831ea6ba7741",
"version": 1,
"phased": false,
"ecBlockId": "9535861265974556985",
"signatureHash": "883599a340375c387e7b27a4f2c37f4ee960760b31e4b1a9c604663c6b84c708",
"attachment": {
"quantityQNT": "100",
"version.AssetDelete": 1,
"asset": "5920455660623529270"
},
"senderRS": "ARDOR-7A48-47JL-T7LD-D5FS3",
"subtype": 7,
"amountNQT": "0",
"sender": "12745647715474645062",
"ecBlockHeight": 757498,
"deadline": 60,
"transaction": "14427559791532059017",
"timestamp": 80204814,
"height": 2147483647
},
"unsignedTransactionBytes": "02170ed4c7043c00373522bcd8904f4707472e590cbb67976d40e7a...",
"broadcasted": false,
"requestProcessingTime": 2,
"transactionBytes": "02170ed4c7043c00373522bcd8904f4707472e590cbb67976d40e7af39650ea...",
"fullHash": "8929fa9d30fd38c8811e079835b3959c1a3f8503df8999d5a858831ea6ba7741",
"transaction": "14427559791532059017"
}
</syntaxhighlight>
</accordion>

===Dividend Payment=== 
Pay dividend to all shareholders of an asset. POST only.


'''Request:''' Refer to [[Create_Transaction#Create_Transaction_Request|Create Transaction Request]] for common parameters.
*''requestType'' is ''dividendPayment''
*''chain'' the chain related to the operation
*''asset'' is the asset ID
*''holdingType'' is a string representing the holding type (optional)
*''holding'' is the holding ID (optional)
*''height'' is the blockchain height at which asset holders shares will be counted (must be less than 1440 blocks in the past)
*''amountNQTPerShare'' is dividend amount (in NQT per share of the asset)


'''Response:''' Refer to [[Create_Transaction#Create_Transaction_Response|Create Transaction Response]].

====Dividend Payment Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=dividendPayment&chain=2&asset=3517042713515967694&height=161157&amountNQTPerShare=100000000| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=dividendPayment&
chain=2&
asset=3517042713515967694&
height=161157&
amountNQTPerShare=100000000
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"signatureHash": "5d92fee3570b7b058ace2387f5b4eef4377ea738e6a6c2aabc06bd9f6871e4b4",
"unsignedTransactionBytes": "02160feb0c023c0010f09c34f225d425306e5be55a49469081...",
"transactionJSON": {
"senderPublicKey": "10f09c34f225d425306e5be55a4946908156072afbead4d574a512d7e086ef5c",
"signature": "61e2398087b078bdba24021d909e937c2d5fe157a09fa3c82d910e7b5843e00cef2...",
"feeNQT": "100000000",
"type": 2,
"fullHash": "27b52e61813b73fdf9ff3b1bacf3b344d3ed60e8c94db2c9d0518c8483150770",
"version": 1,
"ecBlockId": "17871828515938613022",
"signatureHash": "5d92fee3570b7b058ace2387f5b4eef4377ea738e6a6c2aabc06bd9f6871e4b4",
"attachment": {
"version.DividendPayment": 1,
"amountNQTPerQNT": "100000000",
"asset": "3517042713515967694",
"height": 161157
},
"senderRS": "ARDOR-4VDY-LNVT-LMAY-FMCKA",
"subtype": 6,
"amountNQT": "0",
"sender": "15295723609781267838",
"ecBlockHeight": 161151,
"deadline": 60,
"transaction": "18263006340784764199",
"timestamp": 34401039,
"height": 2147483647
},
"broadcasted": true,
"requestProcessingTime": 111,
"transactionBytes": "02160feb0c023c0010f09c34f225d425306e5be55a49469081560...",
"fullHash": "27b52e61813b73fdf9ff3b1bacf3b344d3ed60e8c94db2c9d0518c8483150770",
"transaction": "18263006340784764199"
}
</syntaxhighlight>
</accordion>

===Get Account Asset Count=== 
Get the number of assets owned by an account given the account ID.


'''Request:'''
*''requestType'' is ''getAccountAssetCount''
*''account'' is the account ID
*''height'' is the height of the blockchain to determine the asset count (optional, default is last block)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)
'''Note:''' If table trimming is enabled (default), the height must be within 1440 blocks of the last block.


'''Response:'''
*''numberOfAssets'' (N) is the number of assets owned by the account
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Account Asset Count Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAccountAssetCount&account=ARDOR-8N9W-TN4F-YA2S-H5B7R| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAccountAssetCount&
account=ARDOR-8N9W-TN4F-YA2S-H5B7R
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"requestProcessingTime": 1,
"numberOfAssets": 3
}
</syntaxhighlight>
</accordion>

===Get Account Assets=== 
Get the assets owned by a given account in reverse quantity order.


'''Request:'''
*''requestType'' is ''getAccountAssets''
*''account'' is the account ID
*''asset'' is an asset ID filter (optional)
*''height'' is the blockchain height at which to retrieve balances (optional, default is the last block in the blockchain)
*''includeAssetInfo'' is ''true'' if asset information is to be included (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)
'''Note:''' If table trimming is enabled (default), the height must be within 1440 blocks of the last block.


'''Response:'''
*''accountAssets'' (A) is an array of asset objects (unless the ''asset'' parameter is specified) with the following fields for each asset:
**''quantityQNT'' (S) is the quantity (in QNT) of the asset
**''unconfirmedQuantityQNT'' (S) is the unconfirmed quantity (in QNT) of the asset
**''decimals'' (N) is the number of decimal places used by the asset (if ''includeAssetInfo'' is ''true'')
**''name'' (S) is the asset name (if ''includeAssetInfo'' is ''true'')
**''asset'' (S) is the asset ID
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Account Assets Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAccountAssets&account=ARDOR-4VNQ-RWZC-4WWQ-GVM8S| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAccountAssets&
account=ARDOR-4VNQ-RWZC-4WWQ-GVM8S
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"accountAssets": [
{
"quantityQNT": "68013764",
"unconfirmedQuantityQNT": "68013764",
"decimals": 0,
"name": "Test",
"asset": "17554243582654188572"
}
],
"requestProcessingTime": 1
}
</syntaxhighlight>
</accordion>

===Get Account Current Order Ids=== 
Get current asset order IDs given an account ID in reverse block height order.


'''Request:'''
*''requestType'' is either ''getAccountCurrentBidOrderIds'' or ''getAccountCurrentAskOrderIds''
*''chain'' the chain related to the operation
*''account'' is the account ID
*''asset'' is an asset ID filter (optional)
*''firstIndex'' is a zero-based index to the first order ID to retrieve (optional)
*''lastIndex'' is a zero-based index to the last order ID to retrieve (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''bidOrderIds'' or ''askOrderIds'' (A) is an array of order IDs
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Account Current Order Ids Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAccountCurrentBidOrderIds&chain=2&account=ARDOR-L6FM-89WK-VK8P-FCRBB&asset=17554243582654188572| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAccountCurrentBidOrderIds&
chain=2&
account=ARDOR-L6FM-89WK-VK8P-FCRBB&
asset=17554243582654188572
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"bidOrderIds": [
"17185236428295897167"
],
"requestProcessingTime": 4
}
</syntaxhighlight>
</accordion>

====Get Account Current Ask Order Ids==== 
Refer to [[Asset_Exchange#Get_Account_Current_Order_Ids|Get Account Current Order Ids]].

====Get Account Current Bid Order Ids==== 
Refer to [[Asset_Exchange#Get_Account_Current_Order_Ids|Get Account Current Order Ids]].

===Get Account Current Orders=== 
Get current asset orders given an account ID in reverse block height order.


'''Request:'''
*''requestType'' is either ''getAccountCurrentBidOrders'' or ''getAccountCurrentAskOrders''
*''chain'' the chain related to the operation
*''account'' is the account ID
*''asset'' is an asset ID filter (optional)
*''firstIndex'' is a zero-based index to the first order to retrieve (optional)
*''lastIndex'' is a zero-based index to the last order to retrieve (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''bidOrders'' or ''askOrders'' (A) is an array of order objects (refer to [[Asset_Exchange#Get_Order|Get Order]] for details)
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Account Current Orders Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAccountCurrentBidOrders&chain=2&account=ARDOR-L6FM-89WK-VK8P-FCRBB| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAccountCurrentBidOrders&
chain=2&
account=ARDOR-L6FM-89WK-VK8P-FCRBB
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"bidOrders": [
{
"quantityQNT": "1000000",
"priceNQTPerShare": "100",
"accountRS": "ARDOR-L6FM-89WK-VK8P-FCRBB",
"asset": "17554243582654188572",
"type": "bid",
"account": "15323192282528158131",
"order": "17185236428295897167",
"height": 285549
}
],
"requestProcessingTime": 1
}
</syntaxhighlight>
</accordion>

====Get Account Current Ask Orders==== 
Refer to [[Asset_Exchange#Get_Account_Current_Orders|Get Account Current Orders]].

====Get Account Current Bid Orders==== 
Refer to [[Asset_Exchange#Get_Account_Current_Orders|Get Account Current Orders]].

===Get All Assets=== 
Get all assets in the exchange in reverse block height of creation order.


'''Request:'''
*''requestType'' is ''getAllAssets''
*''firstIndex'' is a zero-based index to the first asset to retrieve (optional)
*''lastIndex'' is a zero-based index to the last asset to retrieve (optional)
*''includeCounts'' is ''true'' if the fields beginning with ''numberOf...'' are to be included (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''assets'' (A) is an array of asset objects (refer to [[Asset_Exchange#Get_Asset|Get Asset]])
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get All Assets Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAllAssets&firstIndex=1&lastIndex=5| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAllAssets&
firstIndex=1&
lastIndex=5
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"assets": [
{
"quantityQNT": "1",
"accountRS": "ARDOR-KZEK-7CVF-P88G-4DTRA",
"decimals": 0,
"name": "SNABCD",
"description": "Mobile Phone 2",
"hasPhasingAssetControl": false,
"asset": "9677555488988261487",
"account": "2620860970609212817"
},
{
"quantityQNT": "1000000",
"accountRS": "ARDOR-78Q5-GP4B-763B-7AGBG",
"decimals": 5,
"name": "Upps",
"description": "Unidades de participação",
"hasPhasingAssetControl": false,
"asset": "9896760296148674110",
"account": "6279645661425212099"
},
{
"quantityQNT": "10000",
"accountRS": "ARDOR-6645-FEKY-BC5T-EPW5D",
"decimals": 0,
"name": "AssetP2",
"description": "{\"name\":\"Lorem ipsum Paapp\",\"channel\":\"Not Panamerica\",\"fullhash\":\"b1147b93d37ada612de0934722d30d58d0b2efc6212196b4064e7dd07a54e712\"}",
"hasPhasingAssetControl": false,
"asset": "9908792094168526059",
"account": "14235761234537484355"
},
{
"quantityQNT": "1",
"accountRS": "ARDOR-WFWX-MMGU-AMTG-D5FTR",
"decimals": 0,
"name": "MstrTkn",
"description": "Master token",
"hasPhasingAssetControl": false,
"asset": "10164872532453123955",
"account": "13539407748888672157"
},
{
"quantityQNT": "50000000",
"accountRS": "ARDOR-APM5-TLV8-J3KY-6T3JG",
"decimals": 2,
"name": "PeterTest",
"description": "Peter Wallet Test",
"hasPhasingAssetControl": false,
"asset": "10260918643336798387",
"account": "5134167126598506083"
}
],
"requestProcessingTime": 0
}
</syntaxhighlight>
</accordion>

===Get All Open Orders=== 
Get all open bid/ask orders in reverse block height order.


'''Request:'''
*''requestType'' is either ''getAllOpenBidOrders'' or ''getAllOpenAskOrders''
*''chain'' the chain related to the operation
*''firstIndex'' is a zero-based index to the first order to retrieve (optional)
*''lastIndex'' is a zero-based index to the last order to retrieve (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''openOrders'' (A) is an array of order objects (refer to [[Asset_Exchange#Get_Order|Get Order]] for details)
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get All Open Orders Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAllOpenBidOrders&chain=2&firstIndex=123&lastIndex=123| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAllOpenBidOrders&
chain=2&
firstIndex=123&
lastIndex=123
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"requestProcessingTime": 5631,
"openOrders": [
{
"quantityQNT": "1000000",
"priceNQTPerShare": "101",
"accountRS": "ARDOR-L6FM-89WK-VK8P-FCRBB",
"asset": "17554243582654188572",
"type": "bid",
"account": "15323192282528158131",
"order": "12743274869785967304",
"height": 285577
}
]
}
</syntaxhighlight>
</accordion>

====Get All Open Ask Orders==== 
Refer to [[Asset_Exchange#Get_All_Open_Orders|Get All Open Orders]].

====Get All Open Bid Orders==== 
Refer to [[Asset_Exchange#Get_All_Open_Orders|Get All Open Orders]].

===Get All Trades=== 
Get all trades since a given timestamp in reverse block height order.


'''Request:'''
*''requestType'' is ''getAllTrades''
*''chain'' the chain related to the operation
*''timestamp'' is the timestamp (in seconds since the genesis block) to begin retrieving trades (optional, default 0)
*''firstIndex'' is a zero-based index to the first trade to retrieve (optional)
*''lastIndex'' is a zero-based index to the last trade to retrieve (optional)
*''includeAssetInfo'' is ''true'' if asset information is to be included in the result (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)
'''Note:''' If ''timestamp'' is omitted or zero, and no index is given, all trades in the entire blockchain will be retrieved, which may timeout or crash your system.


'''Response:'''
*''trades'' (A) is an array of trade objects (refer to [[Asset_Exchange#Get_Trades|Get Trades]])
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get All Trades Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAllTrades&chain=2&lastIndex=0| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAllTrades&
chain=2&
lastIndex=0
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"trades": [
{
"seller": "14968762166783718535",
"quantityQNT": "10000",
"bidOrder": "1166717226538227076",
"sellerRS": "ARDOR-8F69-W9Z9-8M6Y-ETXGZ",
"buyer": "202478233571806601",
"priceNQTPerShare": "19796",
"askOrder": "16222071953599729591",
"buyerRS": "ARDOR-RMEB-W7TE-28EM-2SUM7",
"decimals": 8,
"name": "mgwBTC",
"block": "8807797247643599359",
"asset": "4551058913252105307",
"askOrderHeight": 285768,
"bidOrderHeight": 286453,
"tradeType": "buy",
"timestamp": 30920039,
"height": 286453
}
],
"requestProcessingTime": 25840
}
</syntaxhighlight>
</accordion>

===Get Asset=== 
Get asset information given an asset ID.


'''Request:'''
*''requestType'' is ''getAsset''
*''asset'' is the asset ID
*''includeCounts'' is ''true'' if the fields beginning with ''numberOf...'' are to be included (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''account'' (S) is the number of the account that issued the asset
*''accountRS'' (S) is the Reed-Solomon address of the account that issued the asset
*''name'' (S) is the asset name
*''description'' (S) is the asset description
*''quantityQNT'' (S) is the total asset quantity (in QNT) in existence
*''asset'' (N) is the asset ID
*''decimals'' (N) is the number of decimal places used by the asset
*''numberOfAccounts'' (N) is the number of accounts that own the asset
*''numberOfTrades'' (N) is the number of trades of this asset
*''numberOfTransfers'' (N) is the number of transfers of this asset
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Asset Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAsset&asset=17554243582654188572| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAsset&
asset=17554243582654188572
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"quantityQNT": "2100000000000000",
"numberOfAccounts": 31,
"accountRS": "ARDOR-3TKA-UH62-478B-DQU6K",
"decimals": 8,
"numberOfTransfers": 63,
"name": "mgwBTC",
"description": "Production Multigateway BTC (mgwBTC) is backed 100% by...",
"numberOfTrades": 9,
"requestProcessingTime": 11,
"asset": "17554243582654188572",
"account": "13300069592148796968"
}
</syntaxhighlight>
</accordion>

===Get Asset Account Count=== 
Get the number of accounts that own an asset given the asset ID.


'''Request:'''
*''requestType'' is ''getAssetAccountCount''
*''asset'' is the asset ID
*''height'' is the height of the blockchain to determine the account count (optional, default is last block)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)
'''Note:''' If table trimming is enabled (default), the height must be within 1440 blocks of the last block.


'''Response:'''
*''numberOfAccounts'' (N) is the number of accounts that own the asset
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Asset Account Count Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAssetAccountCount&asset=17554243582654188572| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAssetAccountCount&
asset=17554243582654188572
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"numberOfAccounts": 38,
"requestProcessingTime": 14
}
</syntaxhighlight>
</accordion>

===Get Asset Accounts=== 
Get the accounts that own an asset given the asset ID in reverse quantity order.


'''Request:'''
*''requestType'' is ''getAssetAccounts''
*''asset'' is the asset ID
*''height'' is the height of the blockchain to determine the accounts (optional, default is last block)
*''firstIndex'' is a zero-based index to the first account to retrieve (optional)
*''lastIndex'' is a zero-based index to the last account to retrieve (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)
'''Note:''' If table trimming is enabled (default), the height must be within 1440 blocks of the last block.


'''Response:'''
*''accountAssets'' (A) is an array of asset objects with the following fields for each asset:
**''quantityQNT'' (S) is the quantity (in QNT) of the asset
**''accountRS'' (S) is the Reed-Solomon address of the account that owns the asset
**''unconfirmedQuantityQNT'' (S) is the unconfirmed quantity (in QNT) of the asset
**''asset'' (S) is the asset ID
**''account'' (S) is the number of the account that owns the asset
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Asset Accounts Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAssetAccounts&asset=5539238107226883203| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAssetAccounts&
asset=5539238107226883203
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"accountAssets": [
{
"quantityQNT": "100000000",
"accountRS": "ARDOR-JTE5-HB7Y-QPS5-B58MZ",
"unconfirmedQuantityQNT": "100000000",
"asset": "5539238107226883203",
"account": "11514793277306463619"
}
],
"requestProcessingTime": 19
}
</syntaxhighlight>
</accordion>

===Get Asset History=== 
Get asset deletions or increases for a specific asset or account.


'''Request:'''
*''requestType'' is ''getAssetHistory''
*''asset'' is the asset ID (optional if account is provided)
*''account'' is the account ID (optional if asset is provided)
*''firstIndex'' is a zero-based index to the first phased transaction to retrieve (optional)
*''lastIndex'' is a zero-based index to the last phased transaction to retrieve (optional)
*''timestamp'' is the earliest deletion (in seconds since the genesis block) to retrieve (optional)
*''deletesOnly'' is an optional parameter to retrieve only share delete history events
*''increasesOnly'' is an optional parameter to retrieve only share increase history events
*''includeAssetInfo'' is ''true'' if asset information is to be included (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''assetHistory'' (A) is an array of asset history objects with following properties:
**''quantityQNT'' (S) is the number of shares that were deleted or increased
**''chain'' is the chain related
**''assetHistoryFullHash'' (S) is the full hash of the increase or decrease transaction
**''account'' (S) is the account ID
**''accountRS'' (S) is the account Reed Solomon address
**''asset'' (S) is the asset ID
**''height'' (N) is the block height of the delete
**''timestamp'' (N) is the block timestamp of the delete
**''decimals'' (N) is the number of decimal places used by the asset (if ''includeAssetInfo'' is ''true'')
**''name'' (S) is the asset name (if ''includeAssetInfo'' is ''true'')

====Get Asset History Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=GetAssetHistory&includeAssetInfo=true&asset=17035400751454635539| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=GetAssetHistory&
includeAssetInfo=true&
asset=17035400751454635539
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"requestProcessingTime": 0,
"assetHistory": [
{
"quantityQNT": "1000",
"chain": 2,
"accountRS": "ARDOR-X8ZN-WUJ2-SXY3-FBUYC",
"decimals": 2,
"name": "domtest",
"assetHistoryFullHash": "05340a7863cd661aa64afb49de6584d565721396a5030ea2d685b07a4c67ed80",
"asset": "17035400751454635539",
"account": "15382970207090678772",
"height": 1168097,
"timestamp": 35150871
},
{
"quantityQNT": "-10000",
"chain": 2,
"accountRS": "ARDOR-X8ZN-WUJ2-SXY3-FBUYC",
"decimals": 2,
"name": "domtest",
"assetHistoryFullHash": "f15cfc6b2abfaf76370894689a833413c8cf6d340ec765a36d1a4f388a8864a7",
"asset": "17035400751454635539",
"account": "15382970207090678772",
"height": 1168088,
"timestamp": 35150766
},
{
"quantityQNT": "100000000",
"chain": 2,
"accountRS": "ARDOR-X8ZN-WUJ2-SXY3-FBUYC",
"decimals": 2,
"name": "domtest",
"assetHistoryFullHash": "1346e0dcb9e669ec0c55cc6b52721b4b3a55b0d4f60736155629ea2b1ed6aba8",
"asset": "17035400751454635539",
"account": "15382970207090678772",
"height": 577817,
"timestamp": 28421318
}
]
}
</syntaxhighlight>
</accordion>

===Get Asset Dividends=== 
Get the dividend payment history for a specific asset.


'''Request:'''
*''requestType'' is ''getAssetDividends''
*''chain'' the chain related to the operation
*''asset'' is the asset ID
*''firstIndex'' is a zero-based index to the first dividend payment to retrieve (optional)
*''lastIndex'' is a zero-based index to the last dividend payment to retrieve (optional)
*''timestamp'' is the earliest dividend payment (in seconds since the genesis block) to retrieve (optional)
*''includeHoldingInfo'' is ''true'' to include holding info (optional)
*''adminPassword'' is a string with the admin password (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''dividends'' (A) is an array of dividend transactions with the following properties:
**''assetDividendFullHash'' (S) is the dividend payment transaction full hash
**''numberOfAccounts'' (N) is the number of accounts that received a dividend
**''amountNQTPerShare'' (S) is the amount of the payment holding (in NQT) paid per quantity (in QNT) of the asset
**''totalDividend'' (S) is the total amount of the payment holding (in NQT) sent in the dividend payment
**''dividendHeight'' (N) is the block height of the dividend calculation
**''asset'' (S) is the asset ID
**''height'' (N) is the block height of the dividend payment
**''timestamp'' (N) is the block timestamp of the dividend payment
**''holding'' (S) is the asset or currency ID
**''holdingType'' (N) is the holding type (See [[Server_info#Get_Constants|Get Constants]] for type definitions)
**''holdingInfo'' (O) is an object containing the coin, asset or currency info (if includeHoldingInfo is true)

====Get Asset Dividends Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAssetDividends&chain=2&asset=6277929525780034120| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAssetDividends&
chain=2&
asset=6277929525780034120
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"dividends": [
{
"holding": "2270562915899608568",
"numberOfAccounts": 3,
"holdingType": 2,
"holdingInfo": {
"chain": 2,
"issuerAccountRS": "ARDOR-RKUL-XS5Y-NGQQ-FP6T5",
"code": "SBT",
"decimals": 0,
"name": "SBTether",
"issuanceHeight": 0,
"type": 33,
"issuerAccount": "15124378298184615762"
},
"amountNQTPerShare": "45",
"totalDividend": "290249910",
"dividendHeight": 121160,
"asset": "6277929525780034120",
"assetDividendFullHash": "a449536556c44251365ea4adec7aabfcc590a94697f9d497d9edeaac6c9475a5",
"height": 121162,
"timestamp": 7173990
},
{
"holding": "6277929525780034120",
"numberOfAccounts": 2,
"holdingType": 1,
"holdingInfo": {
"decimals": 0,
"name": "SBT"
},
"amountNQTPerShare": "1",
"totalDividend": "3099999",
"dividendHeight": 119456,
"asset": "6277929525780034120",
"assetDividendFullHash": "41101f9225abbe43436d62377d5b2c9c83ef746dea1fc86cb3801dfd6b6e73d1",
"height": 119459,
"timestamp": 7072622
},
{
"holding": "657",
"numberOfAccounts": 0,
"holdingType": 2,
"holdingInfo": {
"chain": 2,
"issuerAccountRS": "ARDOR-6Z5Q-HJ2L-E5M3-D94QR",
"code": "CHF",
"decimals": 0,
"name": "CHF",
"issuanceHeight": 0,
"type": 1,
"issuerAccount": "13535647277982579830"
},
"amountNQTPerShare": "1",
"totalDividend": "0",
"dividendHeight": 118673,
"asset": "6277929525780034120",
"assetDividendFullHash": "9839c9fb351ca26c8e5ba62c30cb71df5ba820e2adc34d20aea59de27b4c7fbc",
"height": 118676,
"timestamp": 7025926
}
],
"requestProcessingTime": 1
}
</syntaxhighlight>
</accordion>

===Get Asset Ids=== 
Get the IDs of all assets in the exchange in reverse block height of creation order.


'''Request:'''
*''requestType'' is ''getAssetIds''
*''firstIndex'' is a zero-based index to the first asset ID to retrieve (optional)
*''lastIndex'' is a zero-based index to the last asset ID to retrieve (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''assets'' (A) is an array of asset IDs
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Asset Ids Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAssetIds&firstIndex=15&lastIndex=15| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAssetIds&
firstIndex=15&
lastIndex=15
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"assetIds": [
"17554243582654188572"
],
"requestProcessingTime": 1
}
</syntaxhighlight>
</accordion>

===Get Asset Phased Transactions=== 
Get pending phased transactions based on an asset in reverse chronological creation order. These transactions can be considered transaction approval requests.


'''Request:'''
*''requestType'' is ''getAssetPhasedTransactions''
*''chain'' the chain related to the operation
*''asset'' is the asset ID
*''account'' is an account ID of the account that created the phased transactions (optional)
*''withoutWhitelist'' is ''true'' to omit phased transactions that include a whitelist (optional)
*''firstIndex'' is a zero-based index to the first phased transaction to retrieve (optional)
*''lastIndex'' is a zero-based index to the last phased transaction to retrieve (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:''' Refer to [[Transactions#Get_Transaction|Get Transaction]] for details.

====Get Asset Phased Transactions Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAssetPhasedTransactions&chain=2&asset=17091401215301664836| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAssetPhasedTransactions&
chain=2&
asset=17091401215301664836
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="Response">
<syntaxhighlight lang="bash">
{
"requestProcessingTime": 2,
"transactions": [
{
"signature": "803d3fad7076bfe3f48a8ced40bb7075539858bf2b9d23b7653671a7204e6108234d...",
"transactionIndex": 0,
"type": 0,
"phased": true,
"ecBlockId": "14167949999961480077",
"signatureHash": "693b18675d813dcc2de1a889fd919d0c4a0eaa679df0b0f8b0ec703bc2e278d4",
"attachment": {
"phasingFinishHeight": 262450,
"phasingHolding": "",
"phasingQuorum": "500",
"version.Phasing": 1,
"phasingMinBalance": "100",
"phasingMinBalanceModel": 2,
"version.OrdinaryPayment": 0,
"phasingVotingModel": 2
},
"senderRS": "ARDOR-4VDY-LNVT-LMAY-FMCKA",
"subtype": 0,
"amountNQT": "500000000",
"recipientRS": "ARDOR-BMUV-8QQR-47VK-CR7F3",
"block": "11015494088798322289",
"blockTimestamp": 43957876,
"deadline": 60,
"timestamp": 43957682,
"height": 262418,
"senderPublicKey": "10f09c34f225d425306e5be55a4946908156072afbead4d574a512d7e086ef5c",
"chain": 2,
"feeNQT": "2100000000",
"confirmations": 27,
"fullHash": "e57462c46447f8bd7a0bafd9ab65bde8743ca6c13213185271d7ea6c48118861",
"version": 1,
"sender": "15295723609781267838",
"recipient": "11580081983047651163",
"ecBlockHeight": 262409,
"transaction": "13688769565509711077"
}
]
}
</syntaxhighlight>
</accordion>

===Get Asset Properties=== 
Get asset properties given asset and a setter. When it is provided property it lists the value of the given property.


'''Request:'''
*''requestType'' is ''getAssetProperties''
*''asset'' is the asset id for its properties to be listed
*''setter'' is the property setter address
*''property'' when provided, it lists the value of the given property (optional)
*''firstIndex'' is a zero-based index to the first transfer to retrieve (optional, does not apply to expected transfers)
*''lastIndex'' is a zero-based index to the last transfer to retrieve (optional, does not apply to expected transfers)
*''includeAssetInfo'' is ''true'' if the ''decimals'' and ''name'' fields are to be included (optional, does not apply to expected transfers)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''setterRS'' is the setter address in reed salomon format
*''asset'' is the asset id
*''setter'' is setter numeric id
*''properties'' (A) is an array of the asset properties
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Asset Properties Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAssetProperties&asset=17554243582654188572&setter=ARDOR-X8ZN-WUJ2-SXY3-FBUYC&property=isIdentified| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAssetProperties&
asset=17554243582654188572&
setter=ARDOR-X8ZN-WUJ2-SXY3-FBUYC&
property=isIdentified
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"setterRS": "ARDOR-X8ZN-WUJ2-SXY3-FBUYC",
"requestProcessingTime": 1,
"asset": "3295228938014260892",
"setter": "15382970207090678772",
"properties": []
}
</syntaxhighlight>
</accordion>

===Get Asset Transfers=== 
Get transfers associated with a given asset and/or account in reverse block height order (or in the expected order of execution for expected transfers).


'''Request:'''
*''requestType'' is either ''getAssetTransfers'' or ''getExpectedAssetTransfers'', where expected transfers are from the unconfirmed transactions pool or are phased transactions scheduled to finish in the next block
*''asset'' is the asset ID (optional)
*''account'' is the account ID (optional if ''asset'' provided)
*''timestamp'' is the earliest transfer (in seconds since the genesis block) to retrieve (optional, does not apply to expected transfers)
*''firstIndex'' is a zero-based index to the first transfer to retrieve (optional, does not apply to expected transfers)
*''lastIndex'' is a zero-based index to the last transfer to retrieve (optional, does not apply to expected transfers)
*''includeAssetInfo'' is ''true'' if the ''decimals'' and ''name'' fields are to be included (optional, does not apply to expected transfers)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''transfers'' (A) is an array of transfer objects with the following fields for each transfer:
**''quantityQNT'' (S) is the quantity (in QNT) of the asset traded
**''senderRS'' (S) is the Reed-Solomon address of the sender
**''assetTransfer'' (S) is the transaction ID of the asset transfer
**''sender'' (S) is the account number of the sender
**''recipientRS'' (S) is the Reed-Solomon address of the recipient
**''decimals'' (N) is the number of decimal places used by the asset (if ''includeAssetInfo'' is ''true'')
**''recipient'' (S) is the account number of the recipient
**''name'' (S) is the name of the asset (if ''includeAssetInfo'' is ''true'')
**''asset'' (S) is the asset ID
**''height'' (N) is the height of the transfer block
**''timestamp'' (N) is the timestamp (in seconds since the genesis block) of the transfer block, does not apply to an expected transfer
**''phased'' (B) is ''true'' if the transaction is phased, ''false'' otherwise, applies only to an expected transfer
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Asset Transfers Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAssetTransfers&asset=17554243582654188572&lastIndex=0| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAssetTransfers&
asset=17554243582654188572&
lastIndex=0
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"transfers": [
{
"quantityQNT": "500000",
"senderRS": "ARDOR-9K6X-4ZQS-PCQN-465T4",
"assetTransfer": "15255934090738722602",
"sender": "2406158154854548637",
"recipientRS": "ARDOR-YMEM-ERX3-BFUZ-4MQ4P",
"decimals": 8,
"recipient": "3065494931320556947",
"name": "mgwBTC",
"asset": "17554243582654188572",
"height": 287648,
"timestamp": 31042663
}
],
"requestProcessingTime": 4
}
</syntaxhighlight>
</accordion>

====Get Expected Asset Transfers==== 
Refer to [[Asset_Exchange#Get_Asset_Transfers|Get Asset Transfers]]. Since version 2.3.0e it returns both bundled and non-bundled transactions.

===Get Assets=== 
Get asset information given multiple asset IDs.


'''Request:'''
*''requestType'' is ''getAssets''
*''assets'' is one of the multiple asset IDs
*''assets'' is one of the multiple asset IDs
⋮
*''includeCounts'' is ''true'' if the fields beginning with ''numberOf...'' are to be included (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''assets'' (A) is an array of asset objects (refer to [[Asset_Exchange#Get_Asset|Get Asset]])
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Assets Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAssets&assets=17554243582654188572| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAssets&
assets=17554243582654188572
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"assets": [
{
"quantityQNT": "2100000000000000",
"numberOfAccounts": 31,
"accountRS": "ARDOR-3TKA-UH62-478B-DQU6K",
"decimals": 8,
"numberOfTransfers": 63,
"name": "awsBTC",
"description": "Production aws BTC (awsBTC)",
"numberOfTrades": 9,
"asset": "17554243582654188572",
"account": "13300069592148796968"
}
],
"requestProcessingTime": 15
}
</syntaxhighlight>
</accordion>

===Get Assets By Issuer=== 
Get asset information given multiple creation account IDs in reverse block height of creation order.


'''Request:'''
*''requestType'' is ''getAssetsByIssuer''
*''account'' is one of the multiple account IDs
*''account'' is one of the multiple account IDs
⋮
*''firstIndex'' is a zero-based index to the first asset to retrieve (optional)
*''lastIndex'' is a zero-based index to the last asset to retrieve (optional)
*''includeCounts'' is ''true'' if the fields beginning with ''numberOf...'' are to be included (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''assets'' (A) is an array of asset objects (refer to [[Asset_Exchange#Get_Asset|Get Asset]])
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Assets By Issuer Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAssetsByIssuer&account=ARDOR-DE2F-W76R-GL25-HMFPR&lastIndex=0| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAssetsByIssuer&
account=ARDOR-DE2F-W76R-GL25-HMFPR&
lastIndex=0
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"assets": [
[
{
"quantityQNT": "10000000000",
"numberOfAccounts": 222,
"accountRS": "ARDOR-DE2F-W76R-GL25-HMFPR",
"decimals": 4,
"numberOfTransfers": 278,
"name": "NXTprivacy",
"description": "NXTprivacy will contain various privacy related projects...",
"numberOfTrades": 456,
"asset": "17911762572811467637",
"account": "18146608053740744717"
}
]
],
"requestProcessingTime": 9
}
</syntaxhighlight>
</accordion>

===Get Expected Asset Deletes=== 
Gets asset deletes which are expected to be executed in the next block. Since version 2.3.0e it returns both bundled and non-bundled transactions.


'''Request:'''
*''requestType'' is either ''getExpectedAssetDeletes''
*''chain'' the chain related to the operation
*''asset'' is the asset ID (optional)
*''account'' is the account ID (optional)
*''firstIndex'' is a zero-based index to the first phased transaction to retrieve (optional)
*''lastIndex'' is a zero-based index to the last phased transaction to retrieve (optional)
*''timestamp'' is the earliest deletion (in seconds since the genesis block) to retrieve (optional)
*''includeAssetInfo'' is ''true'' if asset information is to be included (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''deletes'' (A) is an array of expected asset delete objects with following properties:
**''assetDelete'' (S) is the transaction ID
**''asset'' (S) is the asset ID
**''account'' (S) is the account ID
**''accountRS'' (S) is the account Reed Solomon address
**''quantityQNT'' (S) is the number of shares that will be deleted
**''decimals'' (N) is the number of decimal places used by the asset (if ''includeAssetInfo'' is ''true'')
**''name'' (S) is the asset name (if ''includeAssetInfo'' is ''true'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Expected Asset Deletes Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getExpectedAssetDeletes&chain=2| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getExpectedAssetDeletes&
chain=2
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"deletes": [
{
"quantityQNT": "1000",
"assetDelete": "16186302132012496205",
"accountRS": "ARDOR-G885-AKDX-5G2B-BLUCG",
"asset": "5920455660623529270",
"account": "10892890577210644675"
}
],
"requestProcessingTime": 3
}
</syntaxhighlight>
</accordion>

===Get Order=== 
Get a bid/ask order given an order ID.


'''Request:'''
*''requestType'' is either ''getBidOrder'' or ''getAskOrder''
*''chain'' the chain related to the operation
*''order'' is the Order ID
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''account'' (S) is the account number associated with the order
*''accountRS'' (S) is the Reed-Solomon address of the account
*''asset'' (S) is the ID of the asset being ordered
*''quantityQNT'' (S) is the order quantity (in QNT)
*''priceNQTPerShare'' (S) is the order price (in NQT)
*''height'' (N) is the block height of the order transaction
*''transactionHeight'' (N) is the transaction height
*''transactionIndex'' (N) is a zero-based index giving the order of the transaction in its block
*''order'' (S) is the ID of the order
*''type'' (S) is the type of order (''bid'' or ''ask'')
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Order Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAskOrder&chain=2&order=6044046093672850641| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAskOrder&
chain=2&
order=6044046093672850641
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"askOrders": [
{
"quantityQNT": "100",
"orderFullHash": "e2c8201c2cf09ad7feb40e7275379f1686bcf1b9021de74f5df68e63153a7d22",
"transactionHeight": 315484,
"accountRS": "ARDOR-WP4X-2AMW-BXV4-3HDHU",
"priceNQTPerShare": "1000000",
"transactionIndex": 1,
"asset": "434314249088370370",
"type": "ask",
"account": "2106962255727711325",
"order": "6044046093672850641",
"height": 315485
}
],
"requestProcessingTime": 0
}
</syntaxhighlight>
</accordion>

====Get Ask Order==== 
Refer to [[Asset_Exchange#Get_Order|Get Order]].

====Get Bid Order==== 
Refer to [[Asset_Exchange#Get_Order|Get Order]].

===Get Order Ids=== 
Get bid/ask order IDs given an asset ID, in order of decreasing bid price or increasing ask price.


'''Request:'''
*''requestType'' is either ''getBidOrderIds'' or ''getAskOrderIds''
*''asset'' is the asset ID
*''chain'' the chain related to the operation
*''firstIndex'' is a zero-based index to the first order ID to retrieve (optional)
*''lastIndex'' is a zero-based index to the last order ID to retrieve (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''bidOrderIds'' or ''askOrderIds'' (A) is an array of order IDs
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Order Ids Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getBidOrderIds&chain=2&asset=17554243582654188572| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:7876/nxt?
requestType=getBidOrderIds&
chain=2&
asset=17554243582654188572
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"requestProcessingTime": 1,
"askOrderIds": [
"364789916640105484",
"14719767980908880113",
"15306957850759966204"
]
}
</syntaxhighlight>
</accordion>

====Get Ask Order Ids==== 
Refer to [[Asset_Exchange#Get_Order_Ids|Get Order Ids]].

====Get Bid Order Ids==== 
Refer to [[Asset_Exchange#Get_Order_Ids|Get Order Ids]].

===Get Orders=== 
Get bid/ask orders given an asset ID, in order of decreasing bid price or increasing ask price (if ''sortByPrice'' is ''true'' for expected orders, otherwise in the expected order of execution).


'''Request:'''
*''requestType'' is one of ''getBidOrders'', ''getAskOrders'', ''getExpectedBidOrders'' or ''getExpectedAskOrders'', where expected orders are from the unconfirmed transactions pool or are phased transactions scheduled to finish in the next block
*''chain'' the chain related to the operation
*''asset'' is the asset ID
*''sortByPrice'' is ''true'' to sort by price (optional, applies only to expected orders, which are returned in expected order of execution by default)
*''showExpectedCancellations'' is ''true'' to include orders that are expected to be cancelled in the next block, based on the content of the unconfirmed transactions pool and the phased transactions expected to finish in the next block (optional, does not apply to expected orders)
*''firstIndex'' is a zero-based index to the first order to retrieve (optional, does not apply to expected orders)
*''lastIndex'' is a zero-based index to the last order to retrieve (optional, does not apply to expected orders)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''bidOrders'' or ''askOrders'' (A) is an array of order objects (refer to [[Asset_Exchange#Get_Order|Get Order]] for details) with the following additional field only for an expected order:
**''phased'' (B) is ''true'' if the order is phased, ''false'' otherwise
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Orders Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getBidOrderIds&chain=2&asset=17554243582654188572| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getBidOrderIds&
chain=2&
asset=17554243582654188572
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"bidOrderIds": [
"17972270381487138621",
"8331653287549483600",
"16386956089071870421",
"12743274869785967304",
"3409888667133338290"
],
"requestProcessingTime": 1
}
</syntaxhighlight>
</accordion>

====Get Ask Orders==== 
Refer to [[Asset_Exchange#Get_Orders|Get Orders]].

====Get Bid Orders==== 
Refer to [[Asset_Exchange#Get_Orders|Get Orders]].

====Get Expected Ask Orders==== 
Refer to [[Asset_Exchange#Get_Orders|Get Orders]]. Since version 2.3.0e it returns both bundled and non-bundled transactions.

====Get Expected Bid Orders==== 
Refer to [[Asset_Exchange#Get_Orders|Get Orders]]. Since version 2.3.0e it returns both bundled and non-bundled transactions.

===Get Expected Order Cancellations=== 
Get all expected order cancellations in the order in which they are expected to be executed. Since version 2.3.0e it returns both bundled and non-bundled transactions.


'''Request:'''
*''requestType'' is ''getExpectedOrderCancellations'', where expected cancellations are from the unconfirmed transactions pool or are phased transactions scheduled to finish in the next block
*''chain'' the chain related to the operation
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''orderCancellations'' (A) is an array of order cancellation objects with the following fields for each transfer:
**''account'' (S) is the cancelling account number
**''accountRS'' (S) is the Reed-Solomon address of the account
**''order'' (S) is the ID of the order to be cancelled
**''height'' (N) is the block height of the order cancellation transaction
**''phased'' (B) is ''true'' if the order cancellation transaction is phased
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Expected Order Cancellations Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getExpectedOrderCancellations&chain=2| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getExpectedOrderCancellations&
chain=2
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"orderCancellations": [
{
"accountRS": "ARDOR-4VDY-LNVT-LMAY-FMCKA",
"account": "15295723609781267838",
"order": "8404616015717333294",
"height": 348793,
"phased": false
}
],
"requestProcessingTime": 1
}
</syntaxhighlight>
</accordion>

===Get Last Trades=== 
Get the last trade of each of multiple assets.


'''Request:'''
*''requestType'' is ''getLastTrades''
*''chain'' the chain related to the operation
*''assets'' is one of multiple asset IDs
*''assets'' is one of multiple asset IDs
⋮
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''trades'' (A) is an array of trade objects (refer to [[Asset_Exchange#Get_Trades|Get Trades]] without ''name'' and ''decimals'' for details)
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Last Trades Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getLastTrades&chain=2&assets=17091401215301664836| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getLastTrades&
chain=2&
assets=17091401215301664836
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"trades": [
{
"seller": "11580081983047651163",
"quantityQNT": "100",
"bidOrder": "12461616895431889058",
"sellerRS": "ARDOR-BMUV-8QQR-47VK-CR7F3",
"buyer": "15295723609781267838",
"priceNQTPerShare": "100000000",
"askOrder": "16690422801364092687",
"buyerRS": "ARDOR-4VDY-LNVT-LMAY-FMCKA",
"block": "9740784167963638799",
"asset": "17091401215301664836",
"askOrderHeight": 286247,
"bidOrderHeight": 286243,
"tradeType": "sell",
"timestamp": 46115694,
"height": 286247
}
],
"requestProcessingTime": 1
}
</syntaxhighlight>
</accordion>

===Get Order Trades=== 
Get all trades that were executed as a result of a given ''askOrder'' and/or ''bidOrder'' in reverse block height order.


'''Request:'''
*''requestType'' is ''getOrderTrades''
*''chain'' the chain related to the operation
*''askOrder'' is an ask order ID (optional)
*''bidOrder'' is a bid order ID (optional if ''askOrder'' provided)
*''firstIndex'' is a zero-based index to the first trade to retrieve (optional)
*''lastIndex'' is a zero-based index to the last trade to retrieve (optional)
*''includeAssetInfo'' is ''true'' if the ''decimals'' and ''name'' fields are to be included (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:''' Refer to [[Asset_Exchange#Get_Trades|Get Trades]].

====Get Order Trades Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getOrderTrades&askOrder=2769987326979385551&chain=2&includeAssetInfo=true| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getOrderTrades&
askOrder=2769987326979385551&
chain=2&
includeAssetInfo=true
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"trades": [
{
"seller": "8069635474378047786",
"quantityQNT": "200",
"bidOrder": "6083013926058683287",
"sellerRS": "ARDOR-5JBC-QQ8M-UAFJ-8UAZZ",
"buyer": "3617506283101058376",
"priceNQTPerShare": "5000000",
"askOrder": "2769987326979385551",
"buyerRS": "ARDOR-QXCA-TKAH-KK85-5QZE6",
"decimals": 0,
"name": "TWT",
"block": "17820716559461579006",
"asset": "7496917644161273018",
"askOrderHeight": 263896,
"bidOrderHeight": 265168,
"tradeType": "buy",
"timestamp": 44288754,
"height": 265168
}
],
"requestProcessingTime": 0
}
</syntaxhighlight>
</accordion>

===Get Trades=== 
Get trades associated with a given asset and/or account in reverse block height order.


'''Request:'''
*''requestType'' is ''getTrades''
*''chain'' the chain related to the operation
*''asset'' is the asset ID (optional)
*''account'' is the account ID (optional if ''asset'' provided)
*''firstIndex'' is a zero-based index to the first trade to retrieve (optional)
*''lastIndex'' is a zero-based index to the last trade to retrieve (optional)
*''timestamp'' is the earliest block (in seconds since the genesis block) to retrieve (optional)
*''includeAssetInfo'' is ''true'' if the ''decimals'' and ''name'' fields are to be included (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''trades'' (A) is an array of trade objects with the following fields for each trade:
**''seller'' (S) is the account number of the seller
**''quantityQNT'' (S) is the quantity (in QNT) of the asset traded
**''bidOrder'' (S) is the bid order ID
**''sellerRS'' (S) is the Reed-Solomon address of the seller
**''buyer'' (S) is the account number of the buyer
**''priceNQTPerShare'' (S) is the trade price per share (in NQT, the ask price for a buy or the bid price for a sell)
**''askOrder'' (S) is the ask order ID
**''buyerRS'' (S) is the Reed-Solomon address of the buyer
**''decimals'' (N) is the number of decimal places used by the asset
**''name'' (S) is the name of the asset (if ''includeAssetInfo'' is ''true'')
**''block'' (S) is the block ID of the trade (if ''includeAssetInfo'' is ''true'')
**''asset'' (S) is the asset ID
**''askOrderHeight'' (N) is the block height of the ask order
**''bidOrderHeight'' (N) is the block height of the bid order
**''tradeType'' (S) is the trade type (''sell'' or ''buy'', where ''buy'' implies that the bid occurred after the ask, or if in the same block, has a greater order ID)
**''timestamp'' (N) is the timestamp (in seconds since the genesis block) of the trade block
**''height'' (N) is the height of the trade block
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Get Order Trades Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getOrderTrades&chain=2&askOrder=2769987326979385551&includeAssetInfo=true| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getOrderTrades&
chain=2&
askOrder=2769987326979385551&
includeAssetInfo=true
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"trades": [
{
"seller": "11579697950237343285",
"quantityQNT": "400",
"sellerRS": "ARDOR-GHKP-XWB5-XMZB-CTUE3",
"buyer": "15382970207090678772",
"askOrderFullHash": "0c54fa167ffe0f050b0479ac6891ebfe4f7fa1475b6971f43c8a259fb8e2cc1a",
"buyerRS": "ARDOR-X8ZN-WUJ2-SXY3-FBUYC",
"priceNQTPerShare": "100000000",
"decimals": 2,
"bidOrderFullHash": "57bbdc200466e20b9429a9f28e8c22aa800e886338d30e48be4a4bc10b0dc4f7",
"name": "TESTAPPROV",
"block": "14437482425329065753",
"asset": "3295228938014260892",
"askOrderHeight": 177984,
"bidOrderHeight": 182007,
"tradeType": "buy",
"timestamp": 10788581,
"height": 182007
}
],
"requestProcessingTime": 0
}
</syntaxhighlight>
</accordion>

===Increase Asset Shares=== 
Increase asset shares of a specific asset. POST only.


'''Request:''' Refer to [[Create_Transaction#Create_Transaction_Request|Create Transaction Request]] for common parameters.
*''requestType'' is ''increaseAssetShares''
*''chain'' the chain related to the operation
*''asset'' the asset that shares will be increased
*''quantityQNT'' is the total amount (in QNT) of the asset to be increased


'''Response:''' Refer to [[Create_Transaction#Create_Transaction_Response|Create Transaction Response]]. The transaction ID is also the asset ID.

====Increase Asset Shares Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=increaseAssetShares&chain=2&asset=3295228938014260892&quantityQNT=1000000&secretPhrase=IWontTellYou| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=increaseAssetShares&
chain=2&
asset=3295228938014260892&
quantityQNT=1000000&
secretPhrase=IWontTellYou
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"minimumFeeFQT": "1000000000",
"signatureHash": "86cb335dfe08da715bd424cda7ac4348b04d372c55340a4aa7325de2f29ece8a",
"transactionJSON": {
"senderPublicKey": "df21142bd38c04bd5c5c342c6ca36802f9de89b75b2a0a8cbd32d29dca481e5c",
"chain": 2,
"signature": "0d0ae03e740c5461b189428adb1ba4566e4811d88eba4011afbdfc6635bcdf09252fb2838ddbefa91daf6fbfcd634d3d7ec65b65e10e0ad9b51c0e1b014c1014",
"feeNQT": "100000000",
"type": 2,
"fullHash": "02bfd8498c029aa5525cfe0c9350d47a623f50fbec8c5ecf05dbbf51fe10d6fc",
"version": 1,
"fxtTransaction": "0",
"phased": false,
"ecBlockId": "848399269223681227",
"signatureHash": "86cb335dfe08da715bd424cda7ac4348b04d372c55340a4aa7325de2f29ece8a",
"attachment": {
"quantityQNT": "10000",
"asset": "3295228938014260892",
"version.AssetIncrease": 1
},
"senderRS": "ARDOR-X8ZN-WUJ2-SXY3-FBUYC",
"subtype": 8,
"amountNQT": "0",
"sender": "15382970207090678772",
"ecBlockHeight": 378420,
"deadline": 15,
"timestamp": 22501256,
"height": 2147483647
},
"unsignedTransactionBytes": "02000000020801885757010f00df21142bd38c04bd5c5c342c6ca36802f9de89b75b2a0a8cbd32d29dca481e5c0000000000000000000000000000000000e1f505000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000034c60500cb4cc7eda31ec60b00000000019c7eed9f4201bb2d1027000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
"broadcasted": false,
"requestProcessingTime": 2,
"transactionBytes": "02000000020801885757010f00df21142bd38c04bd5c5c342c6ca36802f9de89b75b2a0a8cbd32d29dca481e5c0000000000000000000000000000000000e1f505000000000d0ae03e740c5461b189428adb1ba4566e4811d88eba4011afbdfc6635bcdf09252fb2838ddbefa91daf6fbfcd634d3d7ec65b65e10e0ad9b51c0e1b014c101434c60500cb4cc7eda31ec60b00000000019c7eed9f4201bb2d1027000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
"fullHash": "02bfd8498c029aa5525cfe0c9350d47a623f50fbec8c5ecf05dbbf51fe10d6fc",
"bundlerRateNQTPerFXT": "10000000"
}
</syntaxhighlight>
</accordion>

===Issue Asset=== 
Create an asset on the exchange. POST only.


'''Request:''' Refer to [[Create_Transaction#Create_Transaction_Request|Create Transaction Request]] for common parameters.
*''requestType'' is ''issueAsset''
*''chain'' the chain related to the operation
*''name'' is the name of the asset
*''description'' is a url-encoded description of the asset in UTF-8 with a maximum length of 1000 bytes (optional)
*''quantityQNT'' is the total amount (in QNT) of the asset in existence
*''decimals'' is the number of decimal places used by the asset (optional, zero default)


'''Response:''' Refer to [[Create_Transaction#Create_Transaction_Response|Create Transaction Response]]. The transaction ID is also the asset ID.

====Issue Asset Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=issueAsset&publicKey=57fb6f3a958e320bb49c4e81b4c2cf28b9f25d086c143b473beec228f79ff93c&chain=2&name=SecretCoin&description=This%20is%20SecretCoin&quantityQNT=100&deadline=60&feeNQT=100000000000&broad=false| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=issueAsset&
publicKey=57fb6f3a958e320bb49c4e81b4c2cf28b9f25d086c143b473beec228f79ff93c&
chain=2&
name=SecretCoin&
description=This is SecretCoin&
quantityQNT=100&
deadline=60&
feeNQT=100000000000&
broad=false
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"unsignedTransactionBytes": "021095e5da013c0073080c6a224062660184f10ebb7fb431d459364a12403...",
"transactionJSON": {
"senderPublicKey": "73080c6a224062660184f10ebb7fb431d459364a12403320c7f601f9d75cc547",
"feeNQT": "100000000000",
"type": 2,
"version": 1,
"ecBlockId": "1564408139943737911",
"attachment": {
"name": "SecretCoin",
"description": "This+is+SecretCoin",
"quantityQNT": "100",
"version.AssetIssuance": 1,
"decimals": 0
},
"senderRS": "ARDOR-4VNQ-RWZC-4WWQ-GVM8S",
"subtype": 0,
"amountNQT": "0",
"sender": "17013046603665206934",
"ecBlockHeight": 288402,
"deadline": 60,
"timestamp": 31122837,
"height": 2147483647
},
"broadcasted": false,
"requestProcessingTime": 2
}
</syntaxhighlight>
</accordion>

===Place Order=== 
Place an asset order. POST only.


'''Request:''' Refer to [[Create_Transaction#Create_Transaction_Request|Create Transaction Request]] for common parameters.
*''requestType'' is either ''placeBidOrder'' or ''placeAskOrder''
*''chain'' the chain related to the operation
*''asset'' is the asset ID of the asset being ordered
*''quantityQNT'' is the amount (in QNT) of the asset being ordered
*''priceNQTPerShare'' is the bid/ask price (in NQT)


'''Response:''' Refer to [[Create_Transaction#Create_Transaction_Response|Create Transaction Response]]. The transaction ID is also the order ID.

====Place Order Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=placeBidOrder&secretPhrase=IWontTellYou&chain=2&asset=17554243582654188572&quantityQNT=1000000&priceNQTPerShare=100&feeNQT=100000000&deadline=60| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=placeBidOrder&
secretPhrase=IWontTellYou&
chain=2&
asset=17554243582654188572&
quantityQNT=1000000&
priceNQTPerShare=100&
feeNQT=100000000&
deadline=60
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"signatureHash": "44028b4ddb46e7d4383331425b79019bb0f004f88ede12a5aa66f05c23a75f03",
"unsignedTransactionBytes": "02135a5ed6013c0057fb6f3a958e320bb49c4e81b4c2cf28b9f25d086c143...",
"transactionJSON": {
"senderPublicKey": "57fb6f3a958e320bb49c4e81b4c2cf28b9f25d086c143b473beec228f79ff93c",
"signature": "65713e80be99a927bfa7bb2e9a7b6fbd2f17c226fb956494c68a6d90a8127...",
"feeNQT": "100000000",
"type": 2,
"fullHash": "4f00aef17a397eee25027e834ca765660e4e3f3f1b162468bdac67b315aeb812",
"version": 1,
"ecBlockId": "14593256906948324209",
"signatureHash": "44028b4ddb46e7d4383331425b79019bb0f004f88ede12a5aa66f05c23a75f03",
"attachment": {
"quantityQNT": "1000000",
"priceNQT": "100",
"asset": "17554243582654188572",
"version.BidOrderPlacement": 1
},
"senderRS": "ARDOR-L6FM-89WK-VK8P-FCRBB",
"subtype": 3,
"amountNQT": "0",
"sender": "15323192282528158131",
"ecBlockHeight": 285545,
"deadline": 60,
"transaction": "17185236428295897167",
"timestamp": 30826074,
"height": 2147483647
},
"broadcasted": true,
"requestProcessingTime": 8729,
"transactionBytes": "02135a5ed6013c0057fb6f3a958e320bb49c4e81b4c2cf28b9f25d086c143...",
"fullHash": "4f00aef17a397eee25027e834ca765660e4e3f3f1b162468bdac67b315aeb812",
"transaction": "17185236428295897167"
}
</syntaxhighlight>
</accordion>

====Place Ask Order==== 
Refer to [[Asset_Exchange#Place_Order|Place Order]].

====Place Bid Order==== 
Refer to [[Asset_Exchange#Place_Order|Place Order]].

===Search Assets=== 
Get assets having a name or description that match a given query in reverse relevance order.


'''Request:'''
*''requestType'' is ''searchAssets''
*''query'' is a full text query on the asset fields ''name'' (S) and ''description'' (S) in the [http://lucene.apache.org/core/2_9_4/queryparsersyntax.html#Overview standard Lucene syntax]
*''firstIndex'' is a zero-based index to the first asset to retrieve (optional)
*''lastIndex'' is a zero-based index to the last asset to retrieve (optional)
*''includeCounts'' is ''true'' if the fields beginning with ''numberOf...'' are to be included (optional)
*''requireBlock'' is the block ID of a block that must be present in the blockchain during execution (optional)
*''requireLastBlock'' is the block ID of a block that must be last in the blockchain during execution (optional)


'''Response:'''
*''assets'' (A) is an array of asset objects (refer to [[Asset_Exchange#Get_Asset|Get Asset]])
*''lastBlock'' (S) is the last block ID on the blockchain (applies if ''requireBlock'' is provided but not ''requireLastBlock'')
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Search Assets Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=searchAssets&query=assets%20AND%20production| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=searchAssets&
query=assets AND production
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"assets": [
{
"quantityQNT": "2100000000000000",
"numberOfAccounts": 37,
"accountRS": "ARDOR-3TKA-UH62-478B-DQU6K",
"decimals": 8,
"numberOfTransfers": 84,
"name": "mgwBTC",
"description": "Production Multigateway BTC (mgwBTC) is backed 100% by...",
"numberOfTrades": 15,
"asset": "17554243582654188572",
"account": "13300069592148796968"
}
],
"requestProcessingTime": 96
}
</syntaxhighlight>
</accordion>

===Set Asset Property=== 
Set an asset property that allows 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.


'''Request:''' Refer to [[Create_Transaction#Create_Transaction_Request|Create Transaction Request]] for common parameters.
*''requestType'' is ''setAssetProperty''
*''chain'' the chain that will be used for the operation. It is only available in the Ignis chain (2)
*''asset'' is the asset id for setting a property
*''property'' is the property name. It can be up to 32 characters in length
*''value'' is the property value. It can be up to 160 characters in length


'''Response:''' Refer to [[Create_Transaction#Create_Transaction_Response|Create Transaction Response]].

====Set Asset Property Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=setAssetProperty&chain=2&asset=10982263251111884451&property=isIdentified&value=true&secretphrase=IwontTellYou| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=setAssetProperty&
chain=2&
asset=10982263251111884451&
property=isIdentified&
value=true&
secretphrase=IwontTellYou
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"minimumFeeFQT": "10000000",
"signatureHash": "24229be75fc4af5a3795ecc2a1c24d9bc8f9d44a72f05513b790c73be856cce5",
"transactionJSON": {
"senderPublicKey": "df21142bd38c04bd5c5c342c6ca36802f9de89b75b2a0a8cbd32d29dca481e5c",
"chain": 2,
"signature": "b3457fcb4b0d11dc5350c2ec55873c9ee8c0b4d8b4bc02008004257b83636b00f45e37bd6e668f33ea561ef5cdd081795300948dc7349a46ba8e8a1bd4f2dd4b",
"feeNQT": "1000000",
"type": 2,
"fullHash": "1cf769f04937350132e83fdc2598177841c4a37c93fbbb8e58e3f16776c29c50",
"version": 1,
"fxtTransaction": "0",
"phased": false,
"ecBlockId": "12919444854690185600",
"signatureHash": "24229be75fc4af5a3795ecc2a1c24d9bc8f9d44a72f05513b790c73be856cce5",
"attachment": {
"property": "isIdentified",
"asset": "-7464480822597667165",
"version.AssetProperty": 1,
"value": "true"
},
"senderRS": "ARDOR-X8ZN-WUJ2-SXY3-FBUYC",
"subtype": 10,
"amountNQT": "0",
"sender": "15382970207090678772",
"recipientRS": "ARDOR-X8ZN-WUJ2-SXY3-FBUYC",
"recipient": "15382970207090678772",
"ecBlockHeight": 449282,
"deadline": 15,
"timestamp": 26855134,
"height": 2147483647
},
"unsignedTransactionBytes": "02000000020a01dec699010f00df21142bd38c04bd5c5c342c6ca36802f9de89b75b2a0a8cbd32d29dca481e5cf49b0ea0e6497bd5000000000000000040420f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002db060080810e2ba5164bb30000000001a3b659883dd668980c69734964656e7469666965640474727565000000000000000000000000000000000000000000000000000000000000000000000000",
"broadcasted": false,
"requestProcessingTime": 10,
"transactionBytes": "02000000020a01dec699010f00df21142bd38c04bd5c5c342c6ca36802f9de89b75b2a0a8cbd32d29dca481e5cf49b0ea0e6497bd5000000000000000040420f0000000000b3457fcb4b0d11dc5350c2ec55873c9ee8c0b4d8b4bc02008004257b83636b00f45e37bd6e668f33ea561ef5cdd081795300948dc7349a46ba8e8a1bd4f2dd4b02db060080810e2ba5164bb30000000001a3b659883dd668980c69734964656e7469666965640474727565000000000000000000000000000000000000000000000000000000000000000000000000",
"fullHash": "1cf769f04937350132e83fdc2598177841c4a37c93fbbb8e58e3f16776c29c50",
"bundlerRateNQTPerFXT": "10000000"
}
</syntaxhighlight>
</accordion>

===Set Phasing Asset Control=== 
Set all transactions involving a given asset to be subject to approval (i.e. to use phasing).


'''Request:''' Refer to [[Create_Transaction#Create_Transaction_Request|Create Transaction Request]] for common parameters.
*''requestType'' is ''setPhasingAssetControl''
*''transactionType'' is a multivalue parameter that specifies the types to which the asset control will be applied
** The values are SET_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
*''asset'' the asset to set phasing asset control
*''chain'' the chain related to the operation
*''controlVotingModel'' is the voting model or -1 to remove phasing control
*''controlQuorum'' is the expected quorum (optional)
*''controlMinBalance'' is the expected minimum balance (optional)
*''controlMinBalanceModel'' is the expected minimum balance model (optional)
*''controlHolding'' is the holding ID (optional)
*''controlWhitelisted'' is the whitelisted accounts (optional, multiple values)
*''controlWhitelisted'' is the whitelisted accounts (optional, multiple values)
⋮
*''controlParams'' A JSON with all phasing parameters. Use the parsePhasingParams API to get this JSON. If provided, all control* parameters are ignored (optional)
<accordion parent="accordion" heading="JSON phasing parameters example">
<syntaxhighlight lang="json">
{
"phasingHolding": "0",
"phasingQuorum": "1",
"phasingWhitelist": [
"11334088826327847491"
],
"phasingMinBalance": "0",
"phasingMinBalanceModel": 0,
"phasingVotingModel": 0,
"description": "ARDOR-XNL5-RLNZ-ZKRT-AQQ2"
}
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="JSON composite phasing parameters example">
<syntaxhighlight lang="json">
{
"phasingHolding": "0",
"phasingQuorum": "1",
"phasingMinBalance": "0",
"phasingMinBalanceModel": 0,
"phasingExpression": "!fPaul & fAlex",
"phasingSubPolls": {
"fAlex": {
"phasingHolding": "0",
"phasingQuorum": "1",
"phasingWhitelist": [
"7089993074113883968"
],
"phasingMinBalance": "0",
"phasingMinBalanceModel": 0,
"phasingVotingModel": 0
},
"fPaul": {
"phasingHolding": "0",
"phasingQuorum": "1",
"phasingWhitelist": [
"9443818116697861381"
],
"phasingMinBalance": "0",
"phasingMinBalanceModel": 0,
"phasingVotingModel": 0
}
},
"phasingVotingModel": 6,
"description": ""
}
</syntaxhighlight>
</accordion>


'''Response:''' Refer to [[Create_Transaction#Create_Transaction_Response|Create Transaction Response]].

====Set Phasing Asset Control Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=setPhasingAssetControl&chain=2&asset=3295228938014260892&controlVotingModel=0&controlQuorum=1&controlWhitelisted=ARDOR-X8ZN-WUJ2-SXY3-FBUYC&secretPhrase=IWontTellYou&feeNQT=100000000&deadline=60| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=setPhasingAssetControl&
chain=2&
asset=3295228938014260892&
controlVotingModel=0&
controlQuorum=1&
controlWhitelisted=ARDOR-X8ZN-WUJ2-SXY3-FBUYC&
secretPhrase=IWontTellYou&
feeNQT=100000000&
deadline=60
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"minimumFeeFQT": "1000000000",
"signatureHash": "187fad368e3dca9b214a564966c942e889458b137d0527d9807388132fd2259b",
"errorDescription": "quorum <= 0",
"transactionJSON": {
"senderPublicKey": "df21142bd38c04bd5c5c342c6ca36802f9de89b75b2a0a8cbd32d29dca481e5c",
"chain": 2,
"signature": "0e7ff864ddae3b20095a4aea0084361d513a4a941478dde4eacc1a33872938037b0d91ef413b19fc109f5ae2efeac87828b3fce964da5fce59bf6fbd4ead790e",
"feeNQT": "100000000",
"type": 2,
"fullHash": "621627d8891386e8e2a00337d2decf24ebf40a4fdd005ba018750d7136c7f8fd",
"version": 1,
"fxtTransaction": "0",
"phased": false,
"ecBlockId": "14535864490653796608",
"signatureHash": "187fad368e3dca9b214a564966c942e889458b137d0527d9807388132fd2259b",
"attachment": {
"version.SetPhasingAssetControl": 1,
"asset": "3295228938014260892",
"phasingControlParams": {
"phasingHolding": "0",
"phasingQuorum": "0",
"phasingWhitelist": [
"15382970207090678772"
],
"phasingMinBalance": "0",
"phasingMinBalanceModel": 0,
"phasingVotingModel": 0
}
},
"senderRS": "ARDOR-X8ZN-WUJ2-SXY3-FBUYC",
"subtype": 9,
"amountNQT": "0",
"sender": "15382970207090678772",
"ecBlockHeight": 378416,
"deadline": 15,
"timestamp": 22501006,
"height": 2147483647
},
"unsignedTransactionBytes": "020000000209018e5657010f00df21142bd38c04bd5c5c342c6ca36802f9de89b75b2a0a8cbd32d29dca481e5c0000000000000000000000000000000000e1f505000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000030c605000049a26cbdc3b9c900000000019c7eed9f4201bb2d000000000000000000000000000000000001f49b0ea0e6497bd5000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
"errorCode": 4,
"broadcasted": false,
"requestProcessingTime": 2,
"transactionBytes": "020000000209018e5657010f00df21142bd38c04bd5c5c342c6ca36802f9de89b75b2a0a8cbd32d29dca481e5c0000000000000000000000000000000000e1f505000000000e7ff864ddae3b20095a4aea0084361d513a4a941478dde4eacc1a33872938037b0d91ef413b19fc109f5ae2efeac87828b3fce964da5fce59bf6fbd4ead790e30c605000049a26cbdc3b9c900000000019c7eed9f4201bb2d000000000000000000000000000000000001f49b0ea0e6497bd5000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
"error": "nxt.NxtException$NotValidException: quorum <= 0",
"fullHash": "621627d8891386e8e2a00337d2decf24ebf40a4fdd005ba018750d7136c7f8fd",
"bundlerRateNQTPerFXT": "10000000"
}
</syntaxhighlight>
</accordion>

===Set Asset Trade Royalties===
Set or change the royalties percentage. Asset issuer can 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.

'''Request:''' Refer to [[Create_Transaction#Create_Transaction_Request|Create Transaction Request]] for common parameters.
*''requestType'' is ''setAssetTradeRoyalties''
*''chain'' the chain that will be used for the operation. It is only available in the Ignis chain (2)
*''asset'' is the asset id for setting a property
*''royaltiesPercentage'' percentage of royalties

'''Response:''' Refer to [[Create_Transaction#Create_Transaction_Response|Create Transaction Response]].

====Set Asset Trade Royalties Example====
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=setAssetTradeRoyalties&chain=2&asset=10982263251111884451&royaltiesPercentage=10&secretphrase=IwontTellYou| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=setAssetTradeRoyalties&
chain=2&
asset=10982263251111884451&
royaltiesPercentage=10&
secretphrase=IwontTellYou
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"minimumFeeFQT": "1000000",
"signatureHash": "306825f705446f71a6bc51828b47e2c7edc3cc930d4bd57a10011b4543a7f608",
"errorDescription": "Setting royalties requires the asset issuer to own all asset units",
"transactionJSON": {
"senderPublicKey": "df21142bd38c04bd5c5c342c6ca36802f9de89b75b2a0a8cbd32d29dca481e5c",
"chain": 2,
"signature": "881ff2a1b0f73b629511ea14221a031ab4531ea4a1d717e48fa1551f6a05b00ed492a656eb252ca411467414b5abecebd2387f73cfbe3c8c1a4ec86dd86e33b1",
"feeNQT": "2000000",
"type": 2,
"fullHash": "cb4ba3270c409e53452128898852bb3433bfc8ebf91eac5bd91be49b002fbdc4",
"version": 1,
"fxtTransaction": "0",
"phased": false,
"ecBlockId": "15716861317765606984",
"signatureHash": "306825f705446f71a6bc51828b47e2c7edc3cc930d4bd57a10011b4543a7f608",
"attachment": {
"version.SetAssetTradeRoyalties": 1,
"asset": "10982263251111884451",
"percentage": "10"
},
"senderRS": "ARDOR-X8ZN-WUJ2-SXY3-FBUYC",
"subtype": 12,
"amountNQT": "0",
"sender": "15382970207090678772",
"ecBlockHeight": 10048378,
"deadline": 15,
"timestamp": 136264870,
"height": 2147483647
},
"unsignedTransactionBytes": "02000000020c01a63c1f080f00df21142bd38c04bd5c5c342c6ca36802f9de89b75b2a0a8cbd32d29dca481e5c0000000000000000000000000000000080841e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007a539900482e7fd518821dda0000000001a3b659883dd6689800e1f505000000000000000000000000000000000000000000000000000000000000000000000000",
"errorCode": 4,
"broadcasted": false,
"requestProcessingTime": 3,
"transactionBytes": "02000000020c01a63c1f080f00df21142bd38c04bd5c5c342c6ca36802f9de89b75b2a0a8cbd32d29dca481e5c0000000000000000000000000000000080841e0000000000881ff2a1b0f73b629511ea14221a031ab4531ea4a1d717e48fa1551f6a05b00ed492a656eb252ca411467414b5abecebd2387f73cfbe3c8c1a4ec86dd86e33b17a539900482e7fd518821dda0000000001a3b659883dd6689800e1f505000000000000000000000000000000000000000000000000000000000000000000000000",
"error": "nxt.NxtException$NotCurrentlyValidException: Setting royalties requires the asset issuer to own all asset units",
"fullHash": "cb4ba3270c409e53452128898852bb3433bfc8ebf91eac5bd91be49b002fbdc4",
"bundlerRateNQTPerFXT": "200000000"
}
</syntaxhighlight>
</accordion>

===Get Phasing Asset Control=== 
returns the phasing control for a given asset, if set.


'''Request:'''
*''requestType'' is ''getPhasingAssetControl''
*''asset'' the asset to get phasing asset control


'''Response:'''
*''controlParams'' (A) refer to [[Asset_Exchange#Set Phasing Asset Control|Setting Phasing Asset Control]]
*''assetName'' is the asset name
*''asset'' is the asset ID

====Get Phasing Asset Control Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getPhasingAssetControl&chain=2&asset=3295228938014260892&| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getPhasingAssetControl&
chain=2&
asset=3295228938014260892&
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"controls": [
{
"phasingHolding": "0",
"phasingQuorum": "1",
"transactionTypes": [
"ASSET_TRANSFER",
"ASK_ORDER_PLACEMENT",
"BID_ORDER_PLACEMENT",
"DIVIDEND_PAYMENT",
"ASSET_DELETE"
],
"phasingWhitelist": [
"15382970207090678772"
],
"id": "3783710658772967411",
"phasingMinBalance": "0",
"phasingMinBalanceModel": 0,
"phasingVotingModel": 0
}
],
"assetName": "TESTAPPROV",
"requestProcessingTime": 16,
"asset": "3295228938014260892"
}
</syntaxhighlight>
</accordion>

===Transfer Asset=== 
Transfer a quantity of an asset from one account to another. POST only.


'''Request:''' Refer to [[Create_Transaction#Create_Transaction_Request|Create Transaction Request]] for common parameters.
*''requestType'' is ''transferAsset''
*''chain'' the chain related to the operation
*''recipient'' is the recipient account ID
*''recipientPublicKey'' is the public key of the recipient account (optional, enhances security of a new account)
*''asset'' is the ID of the asset being transferred
*''quantityQNT'' is the amount (in QNT) of the asset being transferred


'''Response:''' Refer to [[Create_Transaction#Create_Transaction_Response|Create Transaction Response]]. The transaction ID is also the transfered asset ID.

====Transfer Asset Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=transferAsset&secretPhrase=IWontTellYou&chain=2&recipient=ARDOR-4VNQ-RWZC-4WWQ-GVM8S&asset=17554243582654188572&quantityQNT=1000&feeNQT=100000000&deadline=60| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=transferAsset&
secretPhrase=IWontTellYou&
chain=2&
recipient=ARDOR-4VNQ-RWZC-4WWQ-GVM8S&
asset=17554243582654188572&
quantityQNT=1000&
feeNQT=100000000&
deadline=60
</syntaxhighlight>
</accordion><accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"signatureHash": "f622557588bc82942984286e431c978e687783b32db6a68a1c554b2e11349751",
"unsignedTransactionBytes": "0211c9ebda013c0057fb6f3a958e320bb49c4e81b4c2cf28b9f25d086c143b...",
"transactionJSON": {
"senderPublicKey": "57fb6f3a958e320bb49c4e81b4c2cf28b9f25d086c143b473beec228f79ff93c",
"signature": "33d0fccf1f19d18b4ca97d2636cf62f7a801c07628d1bbb1d6084dc3ca658d...",
"feeNQT": "100000000",
"type": 2,
"fullHash": "c8f25b15b48fb5efd3341fb369627d00f8fefb59dc18016ba0c482b6de7cad59",
"version": 1,
"ecBlockId": "3925493493266246517",
"signatureHash": "f622557588bc82942984286e431c978e687783b32db6a68a1c554b2e11349751",
"attachment": {
"version.AssetTransfer": 1,
"quantityQNT": "1000",
"asset": "17554243582654188572"
},
"senderRS": "ARDOR-L6FM-89WK-VK8P-FCRBB",
"subtype": 1,
"amountNQT": "0",
"sender": "15323192282528158131",
"recipientRS": "ARDOR-4VNQ-RWZC-4WWQ-GVM8S",
"recipient": "17013046603665206934",
"ecBlockHeight": 288416,
"deadline": 60,
"transaction": "17272869949464638152",
"timestamp": 31124425,
"height": 2147483647
},
"broadcasted": true,
"requestProcessingTime": 4968,
"transactionBytes": "0211c9ebda013c0057fb6f3a958e320bb49c4e81b4c2cf28b9f25d086c143b473b...",
"fullHash": "c8f25b15b48fb5efd3341fb369627d00f8fefb59dc18016ba0c482b6de7cad59",
"transaction": "17272869949464638152"
"bundlerRateNQTPerFXT": "10000000"
}
</syntaxhighlight>
</accordion>
</translate>

Template:NRSVersionExperimental

2022-02-18T12:48:52Z

Almonte:

3.0.1e

Phasing Transactions

2021-05-18T15:50:56Z

Almonte:

<languages />
<translate>
{{#seo:
|title=Phasing
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, Phasing
|description=Ardor Phasing is a feature that allows certain phasing-safe transactions to be created with conditional deferred execution based on the result of a vote, on a list of linked transactions or on the revelation of a secret; or simply with unconditional deferred execution
}}
[[Category:Features]]
__TOC__
==Introduction== 
Ardor Phasing is a feature that allows certain phasing-safe transactions to be created with conditional deferred execution based on the result of a vote, on a list of linked transactions or on the revelation of a secret; or simply with unconditional deferred execution. Phasing-safe transactions are indicated with italics in the API [[Create_Transaction|Create Transaction]] list. See also the API for [[Phasing#Create_Phased_Transaction|creating a phase transaction]]
In this guide, all examples begin with phased ''Send IGNIS'' transactions created in the [[Ardor_client_interface|Ardor Client]]; the procedures are similar for other types of phasing-safe transactions supported by the Ardor Client.

==Create an Approval Model== 
Approval models are the conditions that can be linked to a phased transaction. In order to an approval to be created, click on Approval Models at the left of the Ardor client, under the Dashboard:
[[File:Approval_models.png|none|border|600px]]
*When clicking on add approval model, a pop-up entry form appears:
[[File:Add_approval_model.png|none|border|630px]]

===Voting Models=== 


The voting models are named according to the method of approval.


All voting models have a [[Phasing (f)#Finish_Height|Finish Height]] which determines when deferred execution will occur if approved, that is, if all requirements for execution will have been met in the block just prior to the finish height. The finish height is specified when [[Phasing (f)#Create_a_Phased_Transaction|creating the phasing transaction]], not when defining the approval model.


For the voting models (the ''Vote By ...'' models), the results of a vote determine whether execution will occur at the finish height. These models have in common: the [[Phasing (f)#Whitelist|Whitelist]] field for restricting voting to selected accounts and for generating [[Phasing (f)#Whitelisted_Approval_Requests|Whitelisted Approval Requests]], and the [[Phasing (f)#Minimum_Balance_Models|Min Balance Type]] control for restricting voting to accounts with a minimum balance of Ignis or other child chain tokens (eg: GPS, BITS), an asset or a currency.

====Deferred==== 
If the first graphic is clicked, the following appears:
[[File:Phasing_deferred.png|none|border|630px]]
*Transaction execution is deferred, however transaction does not need further approval to become valid at the [[Phasing (f)#Finish_Height|Finish Height]].
*The fee surcharge for the phasing appending is 0.01 ARDR.

====Vote By Account==== 
If the second graphic is clicked, the following appears:
[[File:Phasing_vote_by_account.png|none|border|630px]]
*Enter into the ''Number Accounts'' field the number of accounts that must vote for (approve) the transaction. Each account has one vote.
*The fee surcharge for phasing appendix is 0.01 ARDR when balance independent and 0.2 ARDR when balance dependent.
*A [[Phasing (f)#Whitelist|Whitelist]] can be used to restrict voting and to generate [[Phasing (f)#Whitelisted_Approval_Requests|Whitelisted Approval Requests]]. Otherwise, the only mechanism for voting is [[Phasing (f)#Manual_Approval|Manual Approval]].
*Voting can be restricted to accounts with a minimum balance of ARDR, an asset or a currency using the [[Phasing (f)#Minimum_Balance_Models|Min Balance Type]] drop-down control.

====Vote By Account Balance==== 
If the third graphic is clicked, the following appears:
[[File:Phasing_vote_by_account_balance.png|none|border|630px]]
*Enter into the ''Amount IGNIS'' field the minimum total amount of IGNIS needed to approve the transaction, with each voting account contributing to the total its IGNIS balance (including any outgoing pending phased transfers) just prior to the phasing poll's completion.
*The fee surcharge is +0.02 ARDR.
*A [[Phasing (f)#Whitelist|Whitelist]] can be used to restrict voting and to generate [[Phasing (f)#Whitelisted_Approval_Requests|Whitelisted Approval Requests]]. Otherwise, the only mechanism for voting is [[Phasing (f)#Manual_Approval|Manual Approval]].
*Voting can be restricted to accounts with a minimum balance of IGNIS using the [[Phasing (f)#Minimum_Balance_Models|Min Balance Type]] drop-down control.

====Vote By Asset Balance==== 
If the fourth graphic is clicked, the following appears:
[[File:Phasing_vote_by_asset_balance.png|none|border|630px]]
*Enter into the ''Asset Quantity'' field the minimum total quantity of the asset needed to approve the transaction, with each voting account contributing to the total its asset balance (including any outgoing pending phased transfers) just prior to the phasing poll's completion.
*Enter into the ''Asset'' field the asset ID. The name of the asset is instantly displayed in the shaded box to the right to confirm the ID.
*The fee surcharge is +0.2 ARDR.
*A [[Phasing (f)#Whitelist|Whitelist]] can be used to restrict voting and to generate [[Phasing (f)#Whitelisted_Approval_Requests|Whitelisted Approval Requests]]. Otherwise, an [[Phasing (f)#Asset_Approval_Requests|Asset Approval Request]] is automatically generated.
*Voting can be restricted to accounts with a minimum balance of the asset using the [[Phasing (f)#Minimum_Balance_Models|Min Balance Type]] drop-down control.

====Vote By Currency Balance==== 
If the fifth graphic is clicked, the following appears:
[[File:Phasing_vote_by_currency_balance.png|none|border|630px]]
*Enter into the ''Currency Units'' field the minimum total units of the currency needed to approve the transaction, with each voting account contributing to the total its currency balance (including any outgoing pending phased transfers) just prior to the phasing poll's completion.
*Enter into the ''Currency'' field the three- to five-letter currency code. The ID of the currency is instantly displayed in the shaded box to the right to confirm the code.
*The fee surcharge is +0.2 ARDR.
*A [[Phasing (f)#Whitelist|Whitelist]] can be used to restrict voting and to generate [[Phasing (f)#Whitelisted_Approval_Requests|Whitelisted Approval Requests]]. Otherwise, an [[Phasing (f)#Currency_Approval_Requests|Currency Approval Request]] is automatically generated.
*Voting can be restricted to accounts with a minimum balance of the currency using the [[Phasing (f)#Minimum_Balance_Models|Min Balance Type]] drop-down control.

====Vote By Property==== 
If the sixth graphic is clicked, the following appears:
[[File:Phasing_vote_by_property.png|none|border|630px]]
*Transaction is executed only if the sender or recipient have certain account properties. If both the sender and recipient properties are set then the transaction must match both. Please note that transactions that have no recipient (i.e. data cloud upload) are not checked for the recipient property.
*Enter into the ''Sender Property Setter'' the account id of the setter of the property that the sender needs for the transaction to be executed.
*Enter into the ''Recipient Property Setter'' the account id of the recipient of the property that the recipient needs for the transaction to be executed.
*Enter into the ''Sender Property Name'' and ''Sender Property Value'' the pair name and value.
*The fee surcharge is +0.01 ARDR.

====By Linked Transactions==== 
If the seventh graphic is clicked, the following appears:
[[File:Phasing_by_linked_transactions_2.png|none|border|630px]]
*Enter the full hash of a transaction that must be in the blockchain at the finish height for the phased transaction to be executed.
*A transaction already in the blockchain before the acceptance of the phased transaction can be linked, as long as it is not more than 60 days old, or itself a phased transaction. If the transaction is associated with your account, its full hash can be obtained by clicking on its timestamp in the [[Ardor_client_interface#My_Transactions|My Transactions]] screen to open the ''Transaction Info'' pop-up window, then clicking on the ''Transactions Detail'' tab. Otherwise, the full hash can be obtained using the [[Transactions#Get_Transaction|Ardor API]] if the transaction ID is known.
*A transaction not yet in the blockchain can be linked in advance if the transaction is created but not broadcast. The full hash is then available for linking to the phased transaction. The signed transaction bytes can be broadcast later (via the ''Transaction Operations'' item of the [[Ardor_client_interface#Settings_Menu|Settings Menu]]), before the finish height of the phased transaction, in order to approve it.
*It is possible to link up to ten transactions via the [[Phasing#Create_Phasing_Poll|Ardor API]], but currently only one can be linked via this entry form.
*The fee surcharge is +0.01 ARDR.

====By Secret==== 
If the eigth graphic is clicked, the following appears:
[[File:Phasing_by_secret.png|none|border]]
*Enter your secret phrase in order to generate a reproducible secret.
*Select a ''Hash Algorithm'' from the pull-down control.
*The ''Generated Secret'' field will show the secret that must be revealed by the finish height to approve execution of the phased transaction. The hash of the secret is shown in the ''Approved by Hashed Secret'' field.
*The fee surcharge is +0.01 ARDR.
*Update the [[Phasing (f)#Finish_Height|Finish Height]] field to change the default value.
*To approve the phased transaction once it is confirmed and before the finish height, use [[Phasing (f)#Manual_Approval|Manual Approval]].
*If you need to reproduce the secret again you can do so easily by selecting the ''Reproduce Secret'' button from the approval model you've created.
[[File:ApprovalModels-Hash.png|border]]
[[File:Reproduce Secret modal.png|border]]

====Composite Phasing==== 
If the ninth graphic is clicked, the following appears:
[[File:Phasing_composite.png|none|border|630px]]
*Write a boolean expression in ''Boolean Expression'' for conditional transactions to be defined in terms of a Boolean Expression of other approvals mode.
*See more information of [[Composite_phasing|composite phasing]]
*The fee is determined by phasing complexity based on 0.02 + 0.02 ARDR per 32b + per poll fees

===Whitelist=== 
Creation an approval model of one of the ''Vote By ...'' [[Phasing (f)#Voting_Models|voting models]] causes the ''Accounts (Whitelist)'' field and its associated controls to appear:
[[File:Phasing_whitelist.png|none|border|630px]]
*Enter into the ''Accounts (Whitelist)'' field the account ID of an account that is eligible to vote.
*Once the whitelist is created with the inclusion of a single account, only that account and up to nine other accounts optionally added to the whitelist are eligible to vote in the phasing poll.
*To add another account to the whitelist, click on the ''+ Add Account'' button and enter the account ID into the new field that appears.
*To remove an account from the whitelist, click on the ''- (minus)'' control on the right.
*Whitelisted accounts will receive a [[Phasing (f)#Whitelisted_Approval_Requests|Whitelisted Approval Request]], which is a mechanism for voting.

===Minimum Balance Models=== 
Creation an approval model of one of the ''Vote By ...'' [[Phasing (f)#Voting_Models|voting models]] causes the ''Min Balance Type'' drop-down control to appear:
[[File:Phasing_min_balance_box.png|none|border|630px]]
*The default selection is ''No min balance necessary'', meaning that possessing a minimum balance is not an eligibility requirement for voting. There is no additional fee surcharge.


Clicking on the drop-down control causes a list of one or more minimum balance models (types) to appear, depending on the voting model:
[[File:Phasing_min_balance.png|none|thumb|border|630px]]
*The list shown is for the [[Phasing (f)#Vote_By_Account|Vote By Account]] model and offers a choice of three minimum balance models: ''Min balance of ARDR required'', ''Min balance of asset quantity required'' and ''Min balance of currency units required''.
*If the voting model is [[Phasing (f)#Vote_By_Account_Balance|Vote By Account Balance]], [[Phasing (f)#Vote_By_Asset_Balance|Vote By Asset Balance]] or [[Phasing (f)#Vote_By_Currency_Balance|Vote By Currency Balance]], the minimum balance model must match the voting model and so only one choice is offered for each.
*Selecting one of the minimum balance models causes the fee surcharge to be +20 ARDR and one or more new fields to appear as described in the following subsections.

====Minimum Balance Of Ignis==== 
[[File:Phasing_min_balance_ardor.png|none|border|630px]]
*Enter into the ''Min Balance'' field the minimum balance of Ignis required for an account to be eligible to vote in the phasing poll for approval of the transaction.
*The account must possess this minimum balance (including any outgoing pending phased transfers) just prior to the phasing poll's completion.

====Minimum Balance Of Asset Quantity==== 
[[File:Phasing_min_balance_asset.png|none|border|630px]]
*Enter into the ''Min Balance'' field the minimum balance of asset quantity required for an account to be eligible to vote in the phasing poll for approval of the transaction.
*The account must possess this minimum balance (including any outgoing pending phased transfers) just prior to the phasing poll's completion.
*If the voting model is [[Phasing (f)#Vote_By_Account|Vote By Account]], enter into the ''Asset'' field the asset ID. The name of the asset is instantly displayed in the shaded box to the right to confirm the ID. This field is not displayed for the [[Phasing (f)#Vote_By_Asset_Balance|Vote By Asset Balance]] voting model, because the asset ID is already specified.

====Minimum Balance Of Currency Units==== 
[[File:Phasing_min_balance_currency.png|none|border|630px]]
*Enter into the ''Min Balance'' field the minimum balance of currency units required for an account to be eligible to vote in the phasing poll for approval of the transaction.
*The account must possess this minimum balance (including any outgoing pending phased transfers) just prior to the phasing poll's completion.
*If the voting model is [[Phasing (f)#Vote_By_Account|Vote By Account]], enter into the ''Currency'' field the three- to five-letter currency code. The ID of the currency is instantly displayed in the shaded box to the right to confirm the code. This field is not displayed for the [[Phasing (f)#Vote_By_Currency_Balance|Vote By Currency Balance]] voting model, because the currency code is already specified.

==Create a Phased Transaction== 
The wallet allows you to send any transaction as phased from the same pop-up form used to submit the transaction data.
[[File:Phasing_send_ardor_basic.png|none|border|630px]]
To create a phased transaction, click on the ''Advanced'' link in the lower left area of the form to display the phasing related fields:
[[File:Phasing_send_ardor_advanced.png|none|border|630px]]
*To return to the basic form, click on the ''Basic'' link in the lower left area of the form.
*The ''Referenced Transaction Hash'' field and the ''Do Not Broadcast'' and ''Note to Self?'' controls do not relate to Phasing.
*The Phasing Approval Model contains all the approvals models created to be used as phase transactions.

===Finish Height=== 
[[File:Phasing_finish_height.png|none|border|630px]]
*Next to the approval model selector is the entry field for ''Finish Height'' and is initialized to 7000 blocks (approximately a week) into the future. Enter the exact block height at which the phasing poll is to finish.
*As a convenience, an estimated finish date is displayed to the right of the ''Finish Height'' label. This date adjusts automatically whenever the ''Finish Height'' field changes.
*As a convenience, the second shaded box just to the right of the ''Finish Height'' field is a control which displays the current block height at the time the pop-up entry form was opened. Clicking on it causes the ''Finish Height'' field to change to this value.
*As a convenience, the third and fourth boxes contain controls labeled ''- (minus)'' and ''+ (plus)'' for decreasing or increasing, respectively, the ''Finish Height'' by 500 blocks (approximately half of a day).

==Approve A Phased Transaction== 
[[Phasing (f)#Approval_Requests|Approval Requests]] are the best mechanism for approval of phased transactions, but they only apply to the ''Vote By ...'' [[Phasing (f)#Voting_Models|voting models]], and in the cases of [[Phasing (f)#Vote_By_Account|Vote By Account]] and [[Phasing (f)#Vote_By_Account_Balance|Vote By Account Balance]], only when a [[Phasing (f)#Whitelist|Whitelist]] is used. Otherwise, and including the [[Phasing (f)#By_Secret|By Secret]] voting model, another mechanism must be used: [[Phasing (f)#Manual_Approval|Manual Approval]]. The [[Phasing (f)#By_Linked_Transactions|By Linked Transactions]] voting model does not require manual approval, only the presence of the specified linked transaction(s) in the blockchain.

===Approval Requests=== 
''Approval requests'' are invitations to vote in phasing polls, which apply to the ''Vote By ...'' [[Phasing (f)#Voting_Models|voting models]]. While voting is open (until the finish height of the phasing poll is reached), approval requests appear in all Ardor Clients logged into accounts that are invited to vote in the poll, either by inclusion on a whitelist or by virtue of owning an asset or currency, depending on the voting configuration.


If a whitelist is used, then approval requests appear only on the [[Phasing (f)#Whitelisted_Approval_Requests|Whitelisted Approval Requests]] screen, regardless of the voting model.


Absent a whitelist, [[Phasing (f)#Vote_By_Account|Vote By Account]] and [[Phasing (f)#Vote_By_Account_Balance|Vote By Account Balance]] voting model approval requests appear nowhere in the Ardor Client while [[Phasing (f)#Vote_By_Asset_Balance|Vote By Asset Balance]] and [[Phasing (f)#Vote_By_Currency_Balance|Vote By Currency Balance]] voting model approval requests appear on the [[Phasing (f)#Asset_Approval_Requests|Asset Approval Requests]] and [[Phasing (f)#Currency_Approval_Requests|Currency Approval Requests]] screens, respectively.

====Whitelisted Approval Requests==== 
This screen is accessed from the Ardor Client menu in the left pane by first clicking on ''Dashboard'' to expand the submenu, then clicking on the ''Approval Requests'' submenu item:
[[File:Phasing_account_approval.png|none|thumb|border|630px]]
*Note that the number of pending approval requests is displayed in a shaded circle to the right of the ''Approval Requests'' submenu item; this is an alert that approvals are requested.
*''(Account)'' in the screen title refers to the [[Phasing (f)#Vote_By_Account|Vote By Account]] and [[Phasing (f)#Vote_By_Account_Balance|Vote By Account Balance]] voting models for which whitelisting is required to generate approval requests, but this screen also includes the other two voting models when a whitelist is used and so would more accurately be represented as ''(Whitelisted)''.
*Details of phased transactions with open phasing polls are shown in each row of the list with an ''Approve'' button in the ''Actions'' column; the graphic in the gavel column indicates the [[Phasing (f)#View_Phasing_Poll_Status|phasing poll status]].
*The ''Approve'' button is highlighted and active if the logged-in account has not yet voted; after voting it becomes shaded and inactive.
*Clicking on the ''Approve'' button opens an ''Approve Transaction'' pop-up entry form; then clicking on ''Approve'' creates an approval transaction.

====Asset Approval Requests==== 
This screen is accessed from the Ardor Client menu in the left pane by first clicking on ''Asset Exchange'' to expand the submenu, then clicking on the ''Approval Requests'' submenu item; finally, select an asset from the drop-down list control under the screen title:
[[File:Phasing_asset_approval.png|none|thumb|border|630px]]
*Details of phased transactions with open phasing polls are shown in each row of the list with an ''Approve'' button in the ''Actions'' column; the graphic in the gavel column indicates the [[Phasing (f)#View_Phasing_Poll_Status|phasing poll status]].
*The ''Approve'' button is highlighted and active if the logged-in account has not yet voted; after voting it becomes shaded and inactive.
*Clicking on the ''Approve'' button opens an ''Approve Transaction'' pop-up entry form; then clicking on ''Approve'' creates an approval transaction.

====Currency Approval Requests==== 
This screen is accessed from the Ardor Client menu in the left pane by first clicking on ''Monetary System'' to expand the submenu, then clicking on the ''Approval Requests'' submenu item; finally, select a currency from the drop-down list control under the screen title:
[[File:Phasing_currency_approval.png|none|thumb|border|630px]]
*Details of phased transactions with open phasing polls are shown in each row of the list with an ''Approve'' button in the ''Actions'' column; the graphic in the gavel column indicates the [[Phasing (f)#View_Phasing_Poll_Status|phasing poll status]].
*The ''Approve'' button is highlighted and active if the logged-in account has not yet voted; after voting it becomes shaded and inactive.
*Clicking on the ''Approve'' button opens an ''Approve Transaction'' pop-up entry form; then clicking on ''Approve'' creates an approval transaction.

===Manual Approval=== 


For any phased transaction that appears on the [[Ardor_client_interface#My_Transactions|My Transactions]] screen but that uses neither the [[Phasing (f)#None|None]] nor the [[Phasing (f)#By_Linked_Transactions|By Linked Transactions]] voting model, approval can be accomplished by the following procedure:
#click on the timestamp of the transaction to open the ''Transaction Info'' pop-up window
#click on the ''Actions'' tab
#click on the ''Approve Transaction'' button to open the ''Approve Transaction'' pop-up window
#click on the ''Approve'' button to approve the transaction, after entering the secret phrase in the case of the ''By Secret'' voting model
Only (confirmed) transactions that are directly connected with the logged-in account appear on this screen, including transactions sent or received, and those with phased polls with an invitation to vote (approval request).


When there is no approval request and the phased transaction does not appear on the ''My Transactions'' screen, it can still be found if the block height of the block containing the transaction is known, via the [[Ardor_client_interface#Blocks|Blocks]] screen by clicking on the block height. Otherwise, the [[Phasing#Approve_Transaction|Approve Transaction]] API call can be used if the full hash of the phased transaction is known, and the full hash can be obtained using the [[Transactions#Get_Transaction|Get Transaction]] API call if the transaction ID is known.

==View Phasing Poll Status== 
The status of a phasing poll is indicated by a golden graphic which appears on an [[Phasing (f)#Approval_Requests|Approval Requests]] screen while the phasing poll is open and on the [[Ardor_client_interface#My_Transactions|My Transactions]] screen, where the graphic changes color to green (approved) or red (disapproved) upon phasing poll completion at the finish height. A tooltip appears when the cursor hovers over the graphic, displaying status details.


The status can change until the phasing poll's completion, when it freezes. At the finish height, the phased transaction is executed only if all requirements for approval are met in the block just prior to the finish block.

===Graphic Status Indicators=== 
{| class="wikitable"
|-
! Graphic
! Voting Model
! Status Indicator
|-
| [[File:Phasing_status_none.png|border]]
| [[Phasing (f)#Deferred|Deferred]]
| None
|-
| [[File:Phasing_status_account_number.png|border]]
| [[Phasing (f)#Vote_By_Account|Vote By Account]]
| Current / Required approvals (votes)
|-
| [[File:Phasing_status_account_balance.png|border]]
| [[Phasing (f)#Vote_By_Account_Balance|Vote By Account Balance]]
| Total IGNIS or child chain tokens balance progress scale, 0% to 100%
|-
| [[File:Phasing_status_asset.png|border]]
| [[Phasing (f)#Vote_By_Asset_Balance|Vote By Asset Balance]]
| Total asset balance progress scale, 0% to 100%
|-
| [[File:Phasing_status_currency.png|border]]
| [[Phasing (f)#Vote_By_Currency_Balance|Vote By Currency Balance]]
| Total currency balance progress scale, 0% to 100%
|-
| [[File:Phasing_status_property.png|border]]
| [[Phasing (f)#Vote_By_Property|Vote By Property]]
| Current vote by property progress scale, 0% to 100%
|-
| [[File:Phasing_status_transaction.png|border]]
| [[Phasing (f)#By_Linked_Transactions|By Linked Transactions]]
| Linked Transactions progress scale, 0% to 100%
|-
| [[File:Phasing_status_secret.png|border]]
| [[Phasing (f)#By_Secret|By Secret]]
| Secret revealed progress scale, binary: 0% or 100%
|-
| [[File:Phasing_status_composite.png|border]]
| [[Phasing (f)#Composite_Phasing|Composite Phasing]]
| Composite progress scale, binary: 0% or 100%
|}

===Graphic Status Indicator Color Codes=== 
{| class="wikitable"
|-
! Graphic
! Color
! Approval Status
|-
| [[File:Phasing_status_currency.png|border]]
| Gold
| Not yet approved; phasing poll still open
|-
| [[File:Phasing_status_currency_disapproved.png|border]]
| Red
| Disapproved; phasing poll finished, transaction ignored
|-
| [[File:Phasing_status_currency_approved.png|border]]
| Green
| Approved; phasing poll finished, transaction executed
|}

===Graphic Status Indicator Tooltips=== 
[[File:Phasing_status_tooltip.png|left|border]]


{|
|'''Accounts/Asset/Currency:''' The number of whitelisted accounts or the name of the asset or currency holding.
|-
|'''Votes:''' The number of accounts or the amount of ARDR, child chain tokens, asset QNT or currency Units in ''Current approvals / Required approvals'' format.
|-
|'''Percentage:''' ''Current approvals'' as a percentage of ''Required approvals''.
|-
|'''Finish Height:''' The block height at which the phasing poll finishes or finished.
|-
|'''Approved:''' ''Yes'' only if all requirements were met at phasing poll completion, ''No'' if not or if the phasing poll is still open.
|}
</translate>

Tutorial on basic bundlers for child chain transactions

2021-05-18T15:50:11Z

Almonte:

<languages />
<translate>

{{#seo:
|title=basic bundlers for child chain transactions
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, tutorials, basic tutorials, how to, bundlers, child chain transactions
|description=This guide provides details on how to set up basic transaction “bundlers” for child chain transactions
}}
[[Category:Basic_tutorials]]
__TOC__
This guide provides details on how to set up basic transaction “bundlers” for child chain transactions. “Bundlers” help to tackle two of the most critical issues facing blockchain platforms at the moment: customizing end user fees for dApps so that they can be as low as 0, and hedging to provide predictable day-to-day business transaction expenses on the blockchain. The information presented here represents a modified version of the information in the following [[Basic_tutorials#Demo_of_Custom_Bundlers.2C_0_Transaction_Fees_for_App_Users.2C_and_Hedging|Demo of Custom Bundlers, 0 Transaction Fees for App Users, and Hedging”]]


If you would like to set-up a bundler, you must hold a minimum of 1000 Ardor in your wallet and you must download the Full Ardor Client Wallet from the Jelurida website. The dowonload process is explained in the guide [[how_to_download_the_ardor_client_wallet|how to download the ardor client]].

==Background Context on Transaction Fees== 


For large scale adoption of blockchain technology to occur, users of blockchain based business services need to experience predictable fee structures. If you are playing a game or have a membership of some kind, you probably expect free transactions as part of the experience. Businesses set their fees based on regular reviews of cashflow projections, but the current market leaders like Ethereum do not offer any means of controlling end user fees and day-to-day business transaction expenses. The Ardor ecosystem has a process known as “Bundling” that solves these issues — allowing businesses to provide end users with customized fees as low as 0 while hedging their day-to-day business transaction expenses. By the end of this article, developers and businesses working at exchanges, investment platforms, retail stores or any other membership or subscription-based platform might start to have some exciting ideas on how to replicate their offerings on the blockchain. You can then proceed to learning about more advanced custom bundling options in the [[Bundling#Bundler_Setup|bundling features section]].

==Introduction to “Bundlers”== 


Let’s take a moment to understand the basics. Child chains do not have a means of verifying their own transactions because they have no way of performing their own consensus. These transactions must be packaged and sent to the Ardor parent chain for validation. This packaging process is called “bundling” and anyone can participate as long as you have 1000 Ardor and your node is online. “Bundlers” receive the transaction fees from child chain transactions in the native child chain token, while paying Ardor from their own account to send these transactions for validation on the Ardor chain. For example, if you bundle Ignis, you will be spending Ardor while receiving fees paid in Ignis.

==Hedging== 


Given the fact Bundlers are the ones paying to include transactions on the parent chain, this means the option exists for Bundlers to provide child chain or dApp users with customized, or even free transaction fees. The owner of the Bundler can then calculate expected monthly transaction volumes, and purchase batches of Ardor ahead of time to cover the costs of bundling those child chain transactions to the Ardor parent chain — it’s essentially hedging on the blockchain.

==Flexibility of the “Bundler” Functionality== 


The basic option for controlling end user fees is to set up a Bundler for all transactions occurring on a given child chain, like Ignis. However, if your business launches an asset on a child chain, you can create a custom Bundler that only packages transactions involving your asset so that you only spend Ardor to support relevant transactions. Perhaps you want to offer reduced or free transaction fees only for transactions involving your asset or monetary supply. You can do that too by learning to set up a [[Bundling#Bundling_rules|Custom Bundler]].

==How To Set Up A Basic Bundler== 


Let’s get started with a demonstration of how to set up a basic child chain bundler. Then, we can continue the journey with a demo of a [[Tutorial_on_custom_bundlers_for_child_chain_transactions|custom bundler]] option in a follow up guide. Note that you can only run one bundler per account (so if your account is bundling Ignis, it can’t simultaneously bundle GPS or BITS).


Open the Client Wallet and log in to your desired child chain. For this video, I will be going to the Ignis chain but the process is the same for each child chain.


[[File:1_jApFgbgnrOQQAD6qn3oD5g.png|center|border|640px]]


Once you are on the Ignis chain, click the gear symbol and select the “Bundler” option.


[[File:1_J5Wb5Vq_KsNpghgeTBlFOg.png|center|border|180px]]


We land on a page that shows all of the current bundlers and the rates they are charging. You will be competing against these bundlers.


[[File:1_STTHeVOU235h_S2zA_GxcA.png|center|border|640px]]


Click the “start” button in the upper right corner (red in the image above) and a pop up box will appear.


[[File:1_qL5ZBma6O0KoQEneUMQdHQ.png|center|border|640px]]


Here you must set the fees you will charge for bundling Ignis transactions. This is an important step — make sure to do your calculations properly. The first box, “Minimum Rate,” is the exchange rate. As of August 2nd, 2018 in the Ardor coin exchange, you could buy 2.41 Ignis for every 1 Ardor. This means you should set your “Minimum Rate” to approximately 2.41 Ignis. Please do your own research before you set this rate — cryptocurrency markets are volatile so you need to do your own research when you are making these decisions. The next box is the “Fee Limit” — this is the maximum amount of Ardor that you are willing to spend to bundle transactions at this minimum rate. Consider the formula below:


'''Ardor You Pay = Fee Limit + (Fee Limit * Overpay)'''


The total “Ardor You Pay” has no minimum, but the maximum is your Ardor balance. Again, the market is volatile, so it is a good idea to set small windows of “Fee Limits” bundling at specific rates so that you don’t get caught off-guard by unanticipated market changes. The next option, “Overpay amount” represents the extra Ardor you are willing to pay per child chain transaction to outcompete other bundlers. At the moment, this is unnecessary so just enter 0. But let’s take a moment to consider when this would make sense: bundlers receive the fees paid in native child chain tokens while spending Ardor — so if the value of a particular child chain token exceeds Ardor, it may become economically in the best interest of bundlers to “overpay” with Ardor in order to be the one that receives the fees paid out in that child chain token. This truly creates a competitive free market around the bundling process.


Anyways, we’re just about done here.


[[File:1__gqjMOxrF6Bl3auK3mqcJg.png|center|border|640px]]


Take a moment to double check your rates are all correct. Remember to check your math:


'''Ardor You Pay = Fee Limit + (Fee Limit * Overpay)'''


As an example, if I change the “Overpay” to 0.1 while maintaining a “Fee Limit” of 100, I will spend up to 110 Ardor. Once you are satisfied with the rates, enter your passphrase, and click “Start.”


[[File:1_YR_IxM3yy5sB1uLNDWcJ2w.png|center|border|640px]]

==Stopping or Updating a Bundler== 


That’s it. Keep your bundler online and you should be good to go. If you would like to stop your Bundler, you can do so by navigating to the Bundlers section, clicking on “My Bundlers,” and then clicking “Stop.”


[[File:1_1sqnMazthV6-vFAn6lgGGw.png|center|border|640px]]

==Business Implications of Bundlers== 


Consider the business implications of this process. Users of dApps and services literally never need to interact directly with the Ardor parent chain. They may not even realize they are dealing with the blockchain at all since fees can be eliminated and customized by the business running the dedicated Bundler. For businesses running a dedicated Bundler, you can track exchange rates and purchase large orders of Ardor when it is most favorable for your financial projections, effectively hedging against day to day market volatility while providing consistent customer experiences.


There are still some issues here though. What if your business launches an asset on Ignis and wants to provide reduced fees for transactions involving only your asset, but you don’t want to waste your Ardor bundling transactions that don’t involve your asset? Or, what if your business has tiered fee structures for different levels of membership? With this basic bundler, you are stuck bundling all transactions of a given child chain.


The Ardor ecosystem allows businesses to build their own custom bundlers to address each of these scenarios. To make the process more accessible to businesses, Jelurida released 5 custom bundler templates in August 2018 that can be interwoven to create complex customized fee structures [[Ardor_Software_Change_Log#ardor-client-2.1.0e|version 2.1.0e]]. For a demonstration of how powerful these custom bundlers can be, continue your learning with [[Tutorial_on_custom_bundlers_for_child_chain_transactions|custom bundlers]]. The Account Property Bundler allows you to create “whitelists” of accounts so that your bundler only packages transactions from those accounts.
</translate>

ERC20 to Ignis

2021-05-18T15:49:46Z

Almonte:

<languages />
<translate>
{{#seo:
|title=ERC20 to Ignis
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, tutorials, advanced tutorials, how to, ERC20 API, conversion
|description=How to implement the ERC20 APIs using the equivalent Ardor and Ignis APIs
}}
[[Category:Advanced_guides]]
__TOC__
==Introduction== 


ERC20 is a popular Ethereum standard for token management, explained here https://github.com/ethereum/EIPs/issues/20


The Ignis asset exchange on the Ardor platform already supports most of the ERC20 operations out of the box without the need to issue a smart contract.


This guide explains how to implement the ERC20 APIs using the equivalent Ardor and Ignis APIs.

==Why Use Ignis== 


Ignis is the first public, permissionless, and fully featured child chain of the scalable, multi-chain Ardor platform. Ardor provides comprehensive solutions to the blockchain industry’s scaling dilemmas with a unique parent-child chain architecture, where Ardor functions as the lean parent chain providing proof of stake consensus for the transactional child chains beneath it. The ecosystem has been live since 01 January 2018.


In just a few clicks, anyone can issue a unique singleton asset and/or larger supplies of assets on Ignis. Note this article demonstrates the Ignis equivalents of ERC20 tokens; however, it is simple to replicate ERC721 nonfungible tokens as well. That topic will be covered in a separate article. Core benefits of building on the Ignis child chain include:


• '''KYC/AML''' – This crucial process for verifying account owners and restricting the pool of individuals that can exchange specific assets is made simple with [https://ardordocs.jelurida.com/Features#Asset_control Asset] and [https://ardordocs.jelurida.com/Features Account controls].


• '''Flexible Token Supply''' – Assets only require you to set an initial supply, allowing a flexible token supply. Asset controls can limit these changes to the supply. Singleton assets can also be used where unique, individual tokens are needed.


• '''Dividend Payouts''' – Assets make it simple to pay out [https://ardordocs.jelurida.com/Asset_Exchange#Get_Asset_Dividends dividends] on your digital assets.


• '''Zero Fees''' - [https://ardordocs.jelurida.com/Tutorial_on_custom_bundlers_for_child_chain_transactions Custom bundlers] provide the ability for app and service owners to sponsor end-user fees associated with their specific users.


• '''DEX''' - A fully functional [https://ardordocs.jelurida.com/Features#Asset_exchange decentralized exchange] is built into the Ignis chain, as well as most other Ardor child chains. Since all child chains are compatible with one another, this means assets and monetary systems launched on different child chains have the potential to interact with one another.


Developers can make apps and services to the next level by leveraging secure, Turing-complete [https://ardordocs.jelurida.com/Lightweight_Contracts lightweight contracts] to automate more than [https://ardordocs.jelurida.com/API 250+ APIs] to create and manage digital assets, monetary systems, marketplaces, private messaging, voting systems, cloud storage systems, and more.

==Issuing Tokens== 


Each ERC20 token is represented as an IGNIS asset.
Issue the asset using the [[Asset_Exchange#Issue_Asset|issueAsset]] API.
Each asset is identified by a unique asset id set to the transaction id of the issueAsset transaction.

==Implementing the ERC20 APIs== 

===totalSupply=== 
To get the total token supply invoke the [[Asset_Exchange#Get_Asset|getAsset]] API and supply the asset id. The total supply is provided by the "initialQuantityQNT" attribute, the existing supply, after possible share deletes, is specified by the "quantityQNT" attribute. Quantity values are always provided as integer values, the number of decimal positions to apply to these quantities is specified by the "decimals" attribute.

===balanceOf=== 
To get the account balance of another account with a given address, invoke the [[Asset_Exchange#Get_Account_Assets|getAccountAssets]] API and provide the IGNIS address as the "account" parameter and the asset id as the "asset" parameter.
For example, http://localhost:27876/nxt?requestType=getAccountAssets&account=yourAccountId&asset=6789385243274909976 when using your own local node or https://testardor.jelurida.com/nxt?requestType=getAccountAssets&account=ARDOR-GHKP-XWB5-XMZB-CTUE3&asset=14378369355033436642 when using the Jelurida testnet public node.
The "unconfirmedQuantityQNT" attribute in the response represents the current account balance. The "quantityQNT" attribute represents the quantity available for use at the moment after taking into account balances locked by open asset orders.

===transfer=== 
To send tokens from your address to another address use the [[Asset_Exchange#accordion77|transferAsset]] API, specify the recipient address, the asset id, and the quantity to transfer as well as your account passphrase, the transaction fee and transaction deadline. Consider learning about [[Transaction_Vouchers|Transaction Vouchers]] to add an additional layer of security to your transactions on the Ardor platform.


The transferAsset transaction is recorded on the Ignis child chain, and validated by the Ardor parent chain. You can later track token transfers using the [[Asset_Exchange#Get_Asset_Transfers|getAssetTransfers]] API

===transferFrom=== 
This is specific to Ethereum. It deals with transferring tokens from a sender account to a recipient account in case the transaction issuer is not the sender and it is not directly supported by Ignis; however, in case you need to support it, you can implement the following procedure:
Submit a tranferAsset API but instead of specifying the sender secretPhrase specify the sender publicKey which you can obtain using the [[Accounts#Get_Account_Public_Key|getAccountPublicKey]] API by providing the sender address. As a result, you'll receive the unsigned transaction bytes in hex format. Send these bytes to the owner of the sender account - you can use a sendMessage transaction or send it off-blockchain. The sender account should then submit a [[Transactions#Broadcast_Transaction|broadcastTransaction]] API to sign the bytes with his passphrase and record the transaction on the blockchain.
The following procedure described above is suitable for [[Lightweight_Contracts|lightweight contracts automation]]

===approve=== 
Various approval methods can be implemented using the Ignis [[Phasing_(f)|phasing]] attachment, including the ability to approve a transaction only by an account holding a certain asset balance.

===allowance=== 
is not directly implemented by Ignis, by default the allowance is the available asset balance.

==Trigger the ERC20 events== 
Events such as '''transfer''' and '''approve''' can be triggered by using the [[Blocks#Get_Block|getBlock]] API, iterate over the transactions included in the block and look for asset transfer transactions for a given asset (transaction type 2 subType 1).
Care should be taken to notify only on phased transactions with the attribute "approved".

==Additional Options for Migrating from Ethereum to Ignis Using Monetary Systems== 
Ignis also supports a different type of token through the [[Monetary_system|Monetary System]], called "currency.” Monetary Supplies differ from Assets in that their names are unique and a maximum supply must be determined upfront. While this is a proof of stake environment, an option for creating “mintable” currencies exists, which mimics the supply increase you’d see with proof of work networks.


Among other features, a currency provides the ability to restrict token transfers so that they are allowed only between the issuer account and other accounts. This function prevents free trade of the token without the issuer permission, which is desirable in case of voting rights distribution and crowdfunding, for example. You can also launch currencies backed by reserves of the native child chain token. This means, for example, rewards points, loyalty points, and game tokens can be backed by any child chain by various companies – and each of these tokens have the potential to interact with one another.
</translate>

Voting system

2021-05-18T15:48:46Z

Almonte:

<languages />
<translate>
{{#seo:
|title=Voting system
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, Voting system
|description=The Ardor Voting System enables any account to create a poll with one question and up to 100 answers. Accounts are eligible to vote in the poll by themselves (Pollo by Vote by Account) based on a minimum required balance of child chain tokens (eg: Ignis, GPS, BITS), an asset or a currency
}}
[[Category:Features]]
__TOC__
==Introduction== 
The Ardor Voting System enables any account to create a poll with one question and up to 100 answers. Accounts are eligible to vote in the poll by themselves (Pollo by Vote by Account) based on a minimum required balance of child chain tokens (eg: Ignis), an asset or a currency. Voting consists of selecting an integer ''range'' value to associate with one or more answers as specified during poll creation.


An answer is given ''weight'' based on one of four voting models and then its ''weight'' is multiplied by the associated ''range'' value to compute a corresponding ''result''. The four voting models specify ''weight'' as: one per voting account, or equal to the balance per voting account of Ignis or other child chain tokens, an asset or a currency.


An aggregate ''weight'' for each answer is computed as the sum of all individual vote ''weights''; likewise an aggregate ''result'' is computed. Individual votes are saved until at least 1441 blocks after the poll completes, typically more than a day. After this time, votes are deleted and only aggregate ''weights'' and ''results'' remain available.


This guide describes the Monetary System active on the [[Testnet]] as of [[Ardor_Software_Change_Log|Ardor software release 2.0.14]]. Usage examples apply to the [[Ardor_client_interface|Ardor Client Interface]]. All the examples were done by using the Ignis chain.

==Voting System Menu== 
The Voting System is accessed by clicking on ''Voting'' in the left-pane menu area of the [[Ardor_client_interface|Ardor Client Interface]], causing a submenu to appear:


[[File:VS menu.png|left|border]]


{|
|'''Voting''': This item expands or contracts the submenu below and opens the [[Voting system#Active_Polls_Screen|Active Polls]] screen.
|-
|'''Active Polls''': This item displays a list of all active (unfinished) polls and their properties as shown in the [[Voting system#Active_Polls_Screen|Active Polls]] screen, where polls can be [[Voting system#Cast_A_Vote|voted in]] and [[Voting system#Followed_Polls_Screen|followed]].
|-
|'''Followed Polls''': This item displays a list of all polls followed (monitored) by the logged-in account as shown in the [[Voting system#Followed_Polls_Screen|Followed Polls]] screen, where where polls can be [[Voting system#Cast_A_Vote|voted in]] and ongoing aggregate results viewed.
|-
|'''My Votes''': This item displays a list of all polls already voted in by the logged-in account; from this screen polls can be [[Voting system#Followed_Polls_Screen|followed]] and the [[Voting system#View_Poll_Results|results viewed]] when finished.
|-
|'''My Polls''': This item displays a list of all polls created by the logged-in account; from this screen polls can be [[Voting system#Followed_Polls_Screen|followed]] and either [[Voting system#Cast_A_Vote|voted in]] while still active or the [[Voting system#View_Poll_Results|results viewed]] when finished.
|-
|'''Create Poll''': This item opens a pop-up entry form for [[Voting system#Create_A_Poll|creating a poll]].
|}


 
 
 

===Active Polls Screen=== 
[[File:VS_active_polls.png|none|thumb|border|640px]]


*The poll list is in order of most recently created polls.
*Clicking on the ''Title'' of a poll opens a detail pop-up window showing the values of all parameters specified during the creation of the poll.
*The ''Description'' column gives the purpose of the poll, often worded as a question.
*The ''Sender'' column gives the account ID of the poll creator. Clicking on the ID gives details about the account.
*The ''Start Date'' column gives the date/time when the poll opened for voting.
*The ''Blocks Left'' column gives the number of blocks remaining until completion of the poll. A block is added to the blockchain approximately every minute or two.
*Clicking on a highlighted ''Vote'' button in the ''Actions'' column opens a pop-up window to [[Voting system#Cast_A_Vote|cast a vote]] in the poll.
*Clicking on a highlighted ''Follow'' button in the ''Actions'' column adds the poll to the [[Voting system#Followed_Polls_Screen|Followed Polls]] screen, where the ongoing aggregate results can be viewed.
*If a poll has already been voted in or followed, the corresponding button fades and deactivates.
*Clicking on the ''Create Poll'' button in the upper right of the screen opens a pop-up window for [[Voting system#Create_A_Poll|creating a poll]].

===Followed Polls Screen=== 
[[File:VS_followed_polls.png|none|thumb|border|600px]]


*The left column is a list of followed (monitored) polls with their status in alphabetical order. Polls still active (incomplete) show the number of blocks left for voting. Clicking on one of the followed polls displays ongoing poll results in the pane to the right.
*On the left side of the pane, the ''Result'' and ''Weight'' are displayed for each poll ''Option'' (answer).
*The ''Weight'' associated with each option is the combined ''weight'' of all votes for that option, with the ''weight'' of each vote determined by the voting model selected during [[Voting system#Create_A_Poll|poll creation]]: ''One Vote Per Account'', ''Vote By Ignis Balance'', ''Vote By Asset'' and ''Vote By Currency''. In the example shown above, the voting model is ''One Vote Per Account'' and so the weight of each vote cast is ''1''.
*The ''Result'' associated with each option is the sum over all votes for that option of the ''weight'' of each vote multiplied by an integer ''range'' value selected when the [[Voting system#Cast_A_Vote|vote was cast]]. In the example shown above, the only ''range'' value allowed for a vote is ''1'' and so the ''Result'' and ''Weight'' columns match.
*On the right side of the pane, a pie chart of the results is displayed.
*On the bottom of the pane, the votes cast in the poll are displayed while they are still available. For each voting account the account ID is shown along with the integer ''range'' value associated with each option voted for.
*Clicking on the ''Add Poll'' button in the upper right of the screen opens a pop-up window for following a poll by specifying its poll ID.
*If the poll is still active (unfinished), a ''Vote in Poll'' button appears above the chart. Clicking on it opens a pop-up window for [[Voting system#Cast_A_Vote|casting a vote]]. If a vote has already been cast, the button is faded and deactivated.

==Create A Poll== 
A poll can be created by clicking on the [[Voting system#Voting_System_Menu|Create Poll]] menu item or on the ''Create Poll'' button on the [[Voting system#Active_Polls_Screen|Active Polls]] screen. A ''Create Poll'' pop-up window is opened as shown below.
[[File:VS_create_poll.png|none|border]]
*Enter a ''Name'' or title of the poll.
*Enter a ''Description'' for the poll; this is the purpose of the poll and is often worded as a question.
*Select a voting model for the poll from the ''Poll By'' drop-down list. Your choice affects some of the next fields/controls. For details on the four voting models and the affected controls, refer to the sections below: [[Voting system#Vote_By_Account|Vote By Account]], [[Voting system#Vote_By_Account_Balance|Vote By Account Balance]], [[Voting system#Vote_By_Asset_Balance|Vote By Asset Balance]] and [[Voting system#Vote_By_Currency_Balance|Vote By Currency Balance]].
*Enter a ''Finish Height'' in the box on the left, the height of the blockchain when the poll completes and voting ends. For convenience, an estimated date and time corresponding to the ''finish height'' is provided, and three buttons are provided to set the ''finish height'' to the current height, then adjust it in increments of 500.
*Enter ''Answers'' (options) in the fields provided, clicking on ''Add Answer'' or ''-'' (minus sign) as necessary to adjust the number of answers.
*Enter the minimum and maximum number of answers (options) that must and can be voted for in the ''Minimum Nr Of Choices'' and ''Maximum Nr of Choices'' fields.
*Enter the minimum and maximum integer ''range'' values to be assigned to answers when votes are cast in the ''Minimum Range Value'' and ''Maximum Range Value'' fields. Note that a ''range'' value of ''0'' is treated by the [[Ardor_client_interface|Ardor Client]] as a nonvote and so doesn't count toward the ''Nr of Choice'' fields.
*Note that if the minimum ''range'' value is greater than ''0'', a non-vote is interpreted as a minimum ''range'' value vote and so ''Maximum Nr of Choices'' must be equal to the number of answers (options).
*Click on the ''Create Poll'' button in the lower right of the window to create a transaction, the transaction ID of which becomes the poll ID if it is accepted into the blockchain. If there is an error in the poll specification, it will appear at the top of the window and the window will remain open.
===Vote By Account===
This voting model assigns a ''weight'' of ''1'' to each vote cast.
[[File:VS_vote_by_account.png|none|border]]
*Select ''Vote by Account'' from the ''Poll By'' drop-down list.
*Select the ''Min Balance Type''. The default selection ''None'' means that all accounts are eligible to vote. The other three choices prevent accounts from voting that do not meet the minimum IGNIS, asset or currency balance requirement.
*If ''Min Balance Type'' is set to ''Account Balance'', enter the minimum required account balance in the ''Min Voting Balance (IGNIS)'' field, in units of IGNIS.
*If ''Min Balance Type'' is set to ''Asset Balance'', an ''Asset'' field appears on the next line. Enter the asset ID in the left box; the right box will then display the name of the asset. Enter the minimum required asset balance in the ''Min Voting Balance (Asset)'' field on the next line, in standard asset units.
*If ''Min Balance Type'' is set to ''Currency Balance'', a ''Currency'' field appears on the next line. Enter the currency code in the left box; the right box will then display the ID of the currency. Enter the minimum required currency balance in the ''Min Voting Balance (Currency)'' field on the next line, in standard currency units.

===Vote By Account Balance=== 
This voting model assigns a ''weight'' equal to each voting account's balance of IGNIS (in NQT).
[[File:VS_vote_by_account_balance.png|none|border]]
*Enter the minimum required account balance in the ''Min Voting Balance (IGNIS)'' field, in units of IGNIS.

===Vote By Asset Balance=== 
This voting model assigns a weight equal to each voting account's balance of a specified asset (in QNT).
[[File:VS_vote_by_asset_balance.png|none|border]]
*Enter the asset ID in the ''Asset'' field (left box); the right box will then display the name of the asset.
*Enter the minimum required asset balance in the ''Min Voting Balance (Asset)'' field in standard asset units.

===Vote By Currency Balance=== 
This voting model assigns a weight equal to each voting account's balance of a specified currency (in QNT).
[[File:VS_vote_by_currency_balance.png|none|border]]
*Enter the currency code in the Currency field (left box); the right box will then display the ID of the currency.
*Enter the minimum required currency balance in the ''Min Voting Balance (Currency)'' field in standard currency units.

==Cast A Vote== 
A vote can be cast in an active (unfinished) poll in by clicking on the appropriate button or link on the [[Voting system#Active_Polls_Screen|Active Polls]] screen, the [[Voting system#Followed_Polls_Screen|Followed Polls]] screen, or the [[Voting system#Voting_System_Menu|My Polls]] screen. The button or link is only visible while the poll is still active. Vote buttons are only highlighted and active if a vote has not yet been cast. Clicking on the button or link opens a ''Cast Vote'' pop-up window as shown below.
[[File:VS_cast_vote.png|none|border]]


*The ''Description'' is the purpose of the poll, often worded as a question.
*The ''Range'' section begins with an instruction followed by the poll options (answers).
*The instruction specifies the number of answers that may be voted for, which can be as few as one and as many as all, as specified during [[Voting system#Create_A_Poll|poll creation]].
*Voting for an option (answer) consists of clicking on the checkbox to the left of the answer or dragging the slider below the answer to select an integer value, depending on the ''range'' specified during [[Voting system#Create_A_Poll|poll creation]].
*In the example above, the ''Minimum Range Value'' is ''0'' and the ''Maximum Range Value'' is ''1'', and so a checkbox is provided for voting and checking the checkbox is equivalent to choosing a ''range'' value of ''1''. Leaving a checkbox unchecked corresponds to a ''range'' value of ''0'', but the [[Ardor_client_interface|Ardor Client]] treats this case as a nonvote; it does not count it toward the ''Nr of Choices'' restrictions expressed as ''Select 1 option from below'' (''Minimum Nr of Choices'' and ''Maximum Nr of Choices'' are both ''1'').
*Click on the ''Cast Vote'' button in the lower right of the window to create a transaction. If there is an error, it will appear at the top of the window and the window will remain open.

==View Poll Results== 
Poll results can be viewed both while polls are still active and after their completion on the [[Voting system#Followed_Polls_Screen|Followed Polls]] screen. Only finished poll results can be viewed on the [[Voting system#Voting_System_Menu|My Votes]] screen or the [[Voting system#Voting_System_Menu|My Polls]] screen by clicking on a ''Results'' button or link, respectively. Clicking on ''Results'', once available, opens a ''Poll Results'' pop-up window with two tabs as shown below. The ''Poll Results'' tab displays the final aggregate results and the ''Votes Cast'' tab displays the individual votes that contributed to the results while the votes are still available in the database. Refer to the [[Voting system#Followed_Polls_Screen|Followed Polls Screen]] section for explanations of the information displayed.
[[File:VS_view_result.png|none|thumb|border|600px]]

==External Links== 
* [http://nxter.org/shareholders-meeting-via-blockchain/ Nxter Magazine: Shareholders Meeting Via Blockchain]
</translate>

Ignis child chains features

2021-05-18T15:48:16Z

Almonte:

<languages />
<translate>

{{#seo:
|title=Ignis child chains features
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, tutorials, basic tutorials, how to, Ignis features
|description=This guide provides an introductory tour of the live features available on the Ignis child chain as of August 2018
}}
[[Category:Basic_tutorials]]
__TOC__
This guide provides an introductory tour of the live features available on the Ignis child chain as of August 2018. The information presented here represents a modified version of the information in the 11-minute long video [[Basic_tutorials#Ardor_and_Ignis_features|Blockchain Ardor: Demo and Tour of Ardor and Ignis Features]]


The only prerequisite for joining this tour is that you must download the Ardor Client Wallet from the Jelurida website. An article explaining the download process is available [[How_to_download_the_ardor_client_wallet|here]].

==The Ignis Tour== 
Let’s begin the tour. Open your client wallet and log in to the Ignis chain.


'''Note''': Since version 2.3.0e the login page has been redesigned, please refer to the [[Login_Page_Tutorial|Login Page Tutorial]]. This guide provides instructions for creating and accessing Ardor accounts through the Ardor Client Wallet.


[[File:Login_tutorial_-_Passphrase.png|600px|center|New login page]]


The former login page was as follows:


[[File:1_gKieCXiDbwdhzThmKoPKfQ.png|center|border|640px]]

===Dashboard=== 


We arrive on the Ignis Dashboard, which looks similar to the Ardor Dashboard but with 8 blue boxes. The options in the top toolbar remain mostly the same as explained in the [[Introductory_tour_of_ardors_features#Ardor_Dashboard|Ardor guide]], but with the addition of the send message option and information on shuffled (private) transactions.


[[File:1_GsU6hS7QNaEBrUtiA4E-CQ.png|center|border|640px]]


In the center of the screen at the top row, the first blue box is our Ignis balance, the next is the quantity of assets owned on the Ignis chain, the 3rd box shows the quantity of any currencies owned, and the final box shows the number of items purchased through the marketplace. In the second line of boxes, we see the quantity of pending and completed sales through the marketplace. The second box shows how many messages you have. The third box shows the number of aliases you own. Aliases are like namespaces or domain names– they are shortened handles for referencing accounts. So, for example, you could purchase an alias so that clients, app users, or friends can send money to a name that is easier to remember than your current public address. The last box on this line shows the block information, just like the Ardor chain.

===Understanding Ignis Account Balances=== 


Click “More Info” on the Ignis Account balance.


[[File:1_sfUw0IAm-kMbxbOMRKj9xQ.png|center|border|640px]]


A pop up box appears>


[[File:1_3ByHuKLeXUxbdAxNkFkuxA.png|center|border|640px]]


You’ll notice the Balance and Available balance (orange) reflect your Ignis holdings, however, your Guaranteed Balance (blue) refers to your actual Ardor balance, while your Effective and Forged Balances refer to the forging power of your Ardor coins, as explained in the [[Forging_(f)#Target|forging features section]]. Note that there is an option for Account Leasing, but this does not work for Ignis. Forging power and the proof of stake consensus process are unique solely to the Ardor Parent Chain. The equivalent to forging for child chain transactions is a process called, “Bundling,” which you can refer to the [[Bundling#Description|bundling feature section]].


[[File:1_K3kTfgfzskhPlMaWBRhr_g.png|center|border|640px]]


Looking at the left side menu, we see our Dashboard with the same options as Ardor.

===Decentralized Coin Exchange=== 


[[File:1_Uss8st-UhsBzwH6CT6U9oA.png|center|border|640px]]


There is also the decentralized coin exchange where you can purchase Ardor, GPS, or BITS using Ignis. Remember one of the key benefits of the Ardor ecosystem is the fact that the parent chain and all child chains are interoperable, which means new assets and tokens across child chains can seamlessly interact with one another.


The next two functions are some of Ignis’s most powerful: the issuance and exchange of assets and new monetary supplies.

===Differences between Assets (green) and Monetary Supplies (blue)=== 


[[File:1_PowEehsdN9-adimDqu7gtA.png|center|border|640px]]

====Assets==== 


On the Ignis child chain, you can issue and exchange singleton assets (individual assets) or a large supply of assets representing anything from equities to ICO tokens to sports or entertainment event tickets to real estate properties — you can even use assets to issue dividends.


[[File:1_M9GCuERJ7c1Je5VSWUA_5A.png|center|thumb|border|Asset Menu]]


[[File:1_U947NbQ6DCOdEOSFd92P-Q.png|center|border|640px]]


The key here is that the name of an asset is not unique. The only way to identify a particular asset as legitimate is to verify its Asset ID, a series of randomly assigned numbers, against a list of Asset IDs known to be legitimate. You can use external tools such as https://ardor.tools and https://ardor.world as websites to research and identify assets before purchasing them in the wallet.

====Monetary Supplies==== 


Monetary supplies on the other hand, are like issuing your own cryptocurrency — the name is unique and the properties function a bit differently. Below, you see the list of existing monetary supplies.


[[File:1_Fo4q9J9zcTX8d6TprvE67g.png|center|border|640px]]


There are a variety of options for issuing monetary supplies.


[[File:1_DpaHFl-KQfNwGCLyi3xUTw.png|center|border|440px]]


For example, given that the option for setting reserves exists. To learn more about the types of monetary supplies, check out [[Monetary system|this]].

====Voting System==== 


The voting system is another element that can be useful in board rooms or municipal elections.


[[File:1_9Glsm8foHeaWjVCZoUPAOw.png|center|border|640px]]


Polls are public but you can limit the participant pool based on various criteria, such as minimum account balance, or by requiring that participants hold a particular Asset.


[[File:1_cCHbiAsx2iRd2ffBE7-EPA.png|center|border|440px]]


This means you could issue an asset only to your intended users, set up a poll that only allows people holding that asset to vote, and then continue on with the voting, effectively limiting the participant pool while maintaining a public record of the vote.

====Data Cloud==== 


The data cloud allows you to upload files to the blockchain and receive a hashed version of the file as a sort of “proof of existence.”


[[File:1_gKmc-0gdLGMSyUzFRA_8XA.png|center|border|640px]]


The documents themselves are “pruned” or removed from the blockchain, leaving just the hash. This minimizes the blockchain size while allowing you to reference the hash on your document, against the remaining hash on the blockchain to prove authenticity at a later date. This could have major applications for the copyright industry, insurance industries, and for cloud services.

====Marketplace==== 


The marketplace is like a craigslist environment where you can purchase and sell all types of goods.


[[File:1_gR4OieRVE5i5NRbrvmaJug.png|center|border|640px]]


It was originally meant for digital goods, like software registration codes, but has grown to include some physical items. Note, due to the nature of immutability on the blockchain, fraudulent and inappropriate listings cannot be prevented. There is also currently no way to reverse a transaction if a seller fails to send a product to the buyer. It’s a rich functionality — but be careful when dealing with this decentralized application.

====Shuffling==== 


Shuffling is synonymous with private transactions. It’s pretty straightforward, but could have big implications when it comes to combining this with other features, such as voting to protect identities.


[[File:1_lFeQcq8zZd4coVgaRuMMqg.png|center|border|640px]]

====Messaging==== 


Secure and arbitrary messaging are both pretty straightforward on the surface, but the potential goes beyond what we see here. There have been suggestions to use this feature to create decentralized applications, or a more complex distributed data storage system. You can get creative sending JSON files across the blockchain.


[[File:1_uHyWcsH4Qwqci97v4GGn-w.png|center|border|640px]]

====Aliases==== 


Aliases — this is where you can purchase your shortened account name to make it easier for app users or friends to send you or your business funds in Ignis ecosystem. You can also buy up aliases on a child chain that you think businesses might want in the future.


[[File:1_4M3fhPEglGOHLppEX-ENzg.png|center|border|640px]]

==Continue with bundlers and transaction vouchers== 


Learn how businesses and developers launching tokens on existing child chains, or businesses launching their own child chains, can provide free transactions and custom tiered fee structures to their end-users by learning about transaction [[Tutorial_on_custom_bundlers_for_child_chain_transactions|“Bundlers” tutorial]].


You also have the option of learning more about the revolutionary features of the Ardor ecosystem, such as Transaction Vouchers, which make it easy to send dual signature invoices and share distributions on the blockchain. They also make it possible to create counterfeit-proof “deposit” and “withdrawal” [[Tutorial on transaction vouchers|vouchers]].


Turing-complete lightweight contracts represent the next generation in smart contract technology and it’s a feature exclusive to the Ardor ecosystem. Written guidance on lightweight contracts [[Lightweight_Contracts|is available here]] and you can refer to several articles describing the functionality [https://medium.com/@lyaffe/lightweight-contracts-articles-49c3032a50da]
</translate>

Coin exchange

2021-05-18T15:44:50Z

Almonte:

<languages />
<translate>
{{#seo:
|title=Coin exchange
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, Coin exchange
|description=Coin exchange feature allows trading all chain tokens on the Ardor blockchain by using buy and sell orders and a built-in matching engine. For instance, the coin exchange allows trading ARDR for IGNIS and IGNIS for ARDR
}}
[[Category:Features]]
__TOC__
==Description== 


This page covers the decentralized coin exchange within the Ardor multichain platform. This feature allows trading all chain tokens on the Ardor blockchain by using buy and sell orders and a built-in matching engine. For instance, the coin exchange allows trading ARDR for IGNIS and IGNIS for ARDR.

==Accessing the Coin Exchange== 


To access the coin exchange, you need to install the Ardor client, check out the [[Getting_started|getting started]] page or the [[common problems and resolutions]] page in case you are having problems.

==The Interface== 


With the server running, access the Ardor interface of your client by visiting http://localhost:27876/ (or https://localhost:27876/ if you have enabled SSL). The 26876 port is for the Tesnet while 27876 is for mainnet. On the sidebar, select a chain (e.g.: Ignis), click the menu ''Coin Exchange'', this will give you access to the following options:


[[File:CoinExchange.png|left|border|300px]]
{|


|'''Coin Exchange''': This tab gives you access to the Coin Exchange itself. To select a coin to be traded of, click on the right one of the chains to be exchanged (e.g.: ARDR, BITS, GPS...). By selecting a coin, further information is provided such as a description, buy and sell orders, the quantity, and the trade history.
|-
|'''Coin Exchange History''': This page will list all the coins traded by your account: both those bought by you and those you sold from the exchange.
|-
|'''My Coin Orders''': Here is provided a list of all your orders, notably the coins you are either trying to sell or to buy. It also allows you to cancel them.
|} 

===Coin Exchange menu=== 


The coin exchange menu is as follows:


[[File:Coin_Exchange_Menu.png|thumb|none|border|630px|Coin Exchange available within the client.]]
{|
|This is the main menu for the Asset Exchange, it is fundamentally organized in two areas.
|-
|
:*a list with all the coins available.
:*an interface that allows interaction with these coins.
|-
|If you own tokens for a coin, it will appear the amount value on the side list.
|-
|By selecting a coin, the interface area will automatically display the corresponding information. This includes the amount of coins available ''("Total Available")'', how divisible is the coin ''("Coin Decimals")'' and the coin name ''("Coin Name")
|-
| To buy a coin, follow these simple steps:
|-
|
:1. select the coin from the list on the left.
:2. '''Amount''': define how many coin tokens you are interested in buying.
:3. '''Rate''': set how much you are willing to pay. It refers to the cost of a unit of tokens. So, by entering 10, you are willing to pay 10 of your currently selected chain tokens ''per'' coin token to buy.
:4. press buy, it will prompt a pop-up window (see figure below)
:5. '''fee''': define the fee, see fees in [[Create_Transaction#Create Transaction Request|Create Transaction Request]] or click on the "Calculate" button, which will automatically calculate the current network fee.
:6. it will ask you for your passphrase and finally press ''buy asset''.
|}
[[File:ConfirmOrderBuyCoinExchange.png|thumb|none|border|630px|Confirm Order Buy Coin Exchange.]]

===My Coin Orders menu=== 


Under this menu, you can see all your coin exchange orders that are currently open.


[[File:Open_orders_menu.png|none|border|thumb|630px]]


'''What to keep in mind:'''
* You can cancel any order you made. ''However''
** The process is not instantaneous. Your cancel order is broadcasted to the network, your order may get accepted before you can manage to cancel it.
** The process of canceling an order is a transaction, meaning it involves a fee of 0.01 Tokens, see: [[Create_Transaction#Create Transaction Request|fees]].
** An order in the process of being canceled will appear in red under your My Coin Orders menu.
* In this image, the sell order I am willing to sell Ignis to Buy ARDR at a rate of 1:1

==How to Calculate the Exchange Rate using the API== 


For example to calculate the chain 3 to IGNIS exchange rate


*To get the best asking price get the "askNQTPerCoin" attribute from the first result of [[Coin_Exchange#Get_Coin_Exchange_Orders|getCoinExchangeOrders]] with chain 2 and exchange 3 and convert it to 4 decimals


*To get the best bid price get the "bidNQTPerCoin" attribute from the first result of [[Coin_Exchange#Get_Coin_Exchange_Orders|getCoinExchangeOrders]] with chain 3 and exchange 2 and convert it to 4 decimals


*To get the last trade price get the "exchangeRate" rate attribute from the first result of [[Coin_Exchange#Get_Coin_Exchange_Trades|getCoinExchangeTrades]] with chain 3 and exchange 2

==FAQ== 
See more:
* [[Coin_Exchange|API Coin Exchange Operations]]</translate>

Node JS module

2021-05-18T12:13:49Z

Almonte: Removed the limitations as the packaged is already deployed to NPM

<languages />
<translate>
{{#seo:
|title=Node JS module Ardor
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, tutorials, advanced tutorials, how to, Node JS module
|description=Guide for the Node JS module which can be used for JavaScript application development using the Ardor platform APIs.
}}
[[Category:Advanced_guides]]
__TOC__
==Introduction== 


Existing client API library for Ardor suffer from the following limitations:


#The API library sends the passphrase directly to the remote node in order to sign transactions, this means that the remote node has to be trusted which limits the usability of the API library.
#Some client libraries does implement local transaction signing but still were unable to validate unsigned bytes data returned from a random remote node thus still making it somewhat insecure to submit transactions to a random remote node.
#Client API libraries are developed by 3rd party developers so sometimes lag behind recent changes.


To address these problems we introduced a simple Node JS module which can be used for JavaScript application development using the Ardor platform APIs.


This node JS module is now integral part of the core. It is wrapper of the existing Ardor Wallet JavaScript code configured as a node JS module.

The official Ardor NPM package link is the following https://www.npmjs.com/package/ardor

==Use Cases== 


#The Node JS module is able to work securely against any random Ardor node without trusting the node.
#When submitting a transaction, data submitted to a remote node is validated against the returned unsigned bytes.
#Transactions are signed locally so that the account passphrase is never submitted to a remote node.
#Message encrytption can be performed client side.
#API calls work at a higher level compared to the APIs provided by the existing test page, so that for example, complex numeric conversions and various formatting functions are already implemented by the API library.
#Updates to this API library will follow the standard Ardor release process and will be maintained by core developers.

==Getting Started== 


To quickly get started using the node JS module, see instructions for [[Node_JS_module#Setup using Ardor installation|Setup using Ardor installation]] or the setup using the official [https://www.npmjs.com/package/ardor NPM Ardor package]

=== Setup using NPM ===

*<code>npm i ardor</code>

*<code>echo n | copy /-y node_modules\ardor\sample\*.* *.*</code> - copy the Ardor samples without overwriting existing files

=== Setup using Ardor installation ===

* Install the Ardor software (no need to download the blockchain)
* Install Node JS and NPM from [https://nodejs.org nodejs.org]
*Open a command prompt
* Navigate to the Ardor installation folder
**<code>cd html/www/js</code> - make sure the folder has write permissions
**<code>npm install</code>
**<code>cd sample</code>

== Run Examples ==

* Configure the remote node, Ardor account and default chain by editing the <code>config.json</code> file
* Invoke any of the available samples using node, for example <code>node send.money.js</code>

== Packaging and Distribution ==

If installed from Ardor installation, the Ardor package no longer depends on a local Ardor node.
You can use the content of the <code>html/www/js</code> folder as a standalone module.

== Warning ==

Your passphrase or private key are submitted to a remote node only when invoking specific APIs which require them to operate like the startForging API.

We recommend that you avoid using these APIs in your scripts when connecting to an untrusted remote node.
</translate>

Advanced guides

2021-04-19T16:15:01Z

Almonte: Added IPFS guides

<languages />
{{#seo:
|title=Advanced guides
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, tutorials, advanced tutorials, how to, advanced guides
|description=Advanced tutorials of the Ardor platform
}}
<translate>


Welcome to the advanced guides. This is a series of guides that explain specific questions around the Ardor multi-chain ecosystem. If at any point something is unclear please contact us.

==Guides and tutorials== 

===[[Account Setup for Message-based Deposits]]===


Advanced guide that explains how to configure the account property nrs_recipient_ui_options that prevents users from accidentally sending funds without a message if it is required

===[[Configuring HTTPs on a standalone Ardor installation]]=== 


Advanced guide that explains how to configure HTTPs on a standalone Ardor installation running on a Linux or macOS system using letsencrypt certificates and the standard HTTPs port

===[[Deploying the Ardor Node Docker Image]]===
Advanced guide that explains how to deploy the Ardor Node Docker image. It allows us to deploy an Ardor node as a container and to bootstrap the initial blockchain automatically.

===[[Deploying the Microsoft Azure Ardor Node]]===
Advanced guide that explains how to deploy the Azure Ardor Node. It allows us to deploy an Ardor node as an Azure app and to bootstrap the initial blockchain automatically.

===[[Emulating Multi Signature Accounts on the Blockchain]]=== 


Advanced guide for emulating Multi-Signature accounts using the Ardor platform

===[[ERC20_to_Ignis|ERC20 to Ignis]]=== 


How to implement the ERC20 APIs using the equivalent Ardor and Ignis APIs.

===[[Exchange_Integration_Ardor|Exchange Integration for Ardor]]=== 


Explanation about how to integrate Ardor into a currency exchange platform

===[[Exchange_Integration_Ignis|Exchange Integration for Ignis]]=== 


Explanation about how to integrate the IGNIS token, the token of Ignis, the first child chain of the Ardor blockchain, into a crypto-currency exchange.

===[[Exchange_Integration_of_Assets|Exchange Integration of Assets]]=== 


Explanation about how to integrate assets of the Ardor platform into a crypto-currency exchange.

===[[How to connect Ardor node to IPFS node]]===

This guide will show you how to connect IPFS node to Ardor node. You will also learn how to Pin files to the IPFS node, connected to the Ardor node via another IPFS node.

===[[How to deploy IPFS node]]===

Advanced guide that explains how to deploy an IPFS node.

===[[How to setup the child chain permissions control]]=== 


Guide that explains the child chain control feature to control who can perform transactions on the child chain. Step-by-step guided tour showcasing the most common setup.

===[[How_to_tokenize_your_farm_using_Ignis|How to tokenize your farm using Ignis]]=== 


Use case of Ardor for tokenizing a farm with Ignis tokens

===[[How_Tx_Processing_Works|How Tx Processing works]]=== 


Detailed explanation about how the Tx processing works in the Ardor platform.

===[[Launch_Compliant_Security_Token_Offerings_(STO)_in_Three_Steps_using_Ignis|Launch Compliant Security Token Offerings (STO) in Three Steps using Ignis]]=== 


How to launch a fully compliant Security Token Offering (STO) with an on-Blockchain KYC-AML functionality using the Ignis chain

===[[Migrating_from_Nxt_to_Ardor|Migrating From Nxt to Ardor]]=== 


If you already have an Nxt application, this guide can help you migrate the application which relies on the Nxt APIs to Ardor.

===[[Node_JS_module|Node JS module]]=== 


Technical details of the Ardor Wallet JavaScript code configured as a node JS module

===[[Node_Processes_Configuration|Node processes configuration]]=== 


How to use the Processes feature to persist local configuration of bundlers, funding monitors, standby shufflers, forgers... between node restarts.

===[[Passphrase_Recovery|Passphrase recovery tool]]=== 


Tool included in the Ardor installation to attempt the recovery of your real account passphrase based on approximate passphrase you remember.

===[[Paging implementation of API response|Paging implementation of API response]]=== 


How to implement paging for API responses that cannot be fully loaded in one API call.

===[[Securing_IoT_devices_and_databases|Securing IoT devices and databases]]=== 


How to use build a hybrid solution for securing IoT data of a centralized database using the Ignis chain.

===[[Securing sensitive data with the blockchain|Securing sensitive data with the blockchain]]=== 


How to use build a hybrid solution for securing sensitive data of a centralized database using the Ignis chain.
</translate>

How to connect Ardor node to IPFS node

2021-04-19T16:09:58Z

Almonte:

<languages />
<translate>
{{#seo:
|title=How to connect Ardor node with an IPFS node
|titlemode=replace
|keywords=IPFS, IPFS node, IPFS documentation, Ardor, Ardor node, Ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, tutorials, advanced tutorials
|description=Detailed explanation step by step to connect IPFS to an Ardor node
}}
[[Category:Advanced_guides]]
__TOC__
== Introduction ==
This guide will show you how to connect '''IPFS node''' to '''Ardor node'''. You will also learn how to Pin files to the IPFS node, connected to the Ardor node via another IPFS node.

==== What is IPFS? ====
IPFS is a distributed system for storing and accessing files, websites, applications, and data. Refer to the IPFS [https://docs.ipfs.io official documentation] for more information.

== Installing and deploying IPFS node ==
Please refer to [https://wiki.jelurida.com/How_to_deploy_IPFS_node guide] for a detailed tutorial about how to install deploy IPFS node.

== Connecting the Ardor node to IPFS node ==
The connection between Ardor and IPFS nodes is possible via a Lightweight contract. If you are not familiar with Jelurida's Lightweight Contracts, please visit [https://wiki.jelurida.com/Lightweight_Contracts this documentation] for a detailed tutorial.

Assuming that you already have running Ardor node with enabled Contract Runner and two IPFS nodes connected to the IPFS network, the next step is to upload '''''PinToIpfs.java''''' and '''''PinFromMessage.java''''' contracts to the Ardor node. If you don't know how to deploy contracts, please visit [https://wiki.jelurida.com/Lightweight_Contracts#Contract_Deployment our tutorial] for Lightweight Contracts. After successfully uploading the contracts, you will observe the following in the Contracts menu:

[[File:Uploaded ipfs contract1.jpg|class=img-responsive|border|center]]

Your Ardor node is now connected to the IPFS node. If you are wondering which IPFS node is exactly connected, it's to the one with default IPFS settings, or you may call it the initial IPFS node (The default address of the IPFS API can be configured, please refer to the Configuring parameters section below).

Now let's see if the connection was indeed successful. Let's navigate to the Web UI of the second IPFS node,in our case that is <code>http://localhost:5002/ipfs</code> and make sure we have uploaded a file.

[[File:Ipfs uploaded file.jpg|class=img-responsive|border|center]]

The next step is to copy the CID of the uploaded file and open the Ardor app. As the name of the contract suggests, we have to issue a transaction with a message, it can be ''Send Money'', ''Send Message'', etc., as long as a message can be attached. We will simply send a message and paste the copied CID:

[[File:Send message CID.jpg|class=img-responsive|border|center]]

An important thing to remind here is that the message has to be '''''non-encrypted''''', otherwise the operation will not work.
* Wait for the transaction to be confirmed and published to the blockchain
* Open the Web UI of the initial node <code>localhost:5001/ipfs</code>
* Click on '''FILES''' on the left panel and as you already guessed, our file should be located in '''pins''' menu,
* You can open it. If you don't see the file, please refresh the page.

[[File:Ipfs pin.jpg|class=img-responsive|border|center]]

[[File:Ipfs pin1.jpg|class=img-responsive|border|center]]

== Configuring parameters ==

=== Max Pin Size ===
If you want to limit the size of the pinned files, you can do that by configuring the ''maxPinSize'' parameter.
It can be done by either adding '''''contract.PinToIpfs.param.maxPinSize=size_in_bytes''''' in ''nxt.properties'' file or editing the ''contract.uploader.json'' file and adding this code:

[[File:Max pin size.jpg|frame|none]]

As you can see, the max pin size is set to 1024 bytes.

=== IPFS API Address ===
The default IPFS API Address can be configured by changing the ''ipfsApiAddress'' parameter. It can be done by either adding <code>contract.PinToIpfs.param.ipfsApiAddress=http://127.0.0.1:5002/api/v0</code> in the <code>nxt.properties</code> file or editing the <code>contract.uploader.json</code> file and adding this code:

[[File:Api address.jpg|frame|none]]

In the example, only the ''Port'' is changed from 5001 to 5002.
</translate>

Graphical Installer

2021-04-15T17:24:53Z

Almonte:

<languages />
<translate>

{{#seo:
|title=Graphical Installer
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, Graphical Installer
|description=Explanation of the Ardor Graphical Installer
}}
[[Category:Features]]
__TOC__
Ardor's installer is provided in the following flavors:


* '''Java .jar''' file - smaller bundle, without JRE. Can be run on Windows, Linux, and Mac platforms.
* '''Windows''' executable - bundles a Java JRE and provides a familiar experience for Windows users.
* '''Mac OS/X''' disk image - includes a Java JRE and OS/X App which installs the Ardor client.


All versions of the installer are generated by a single build script and result in the same end product. The Windows executable and Mac disk image are larger since they include two copies of the Java JRE, one used to launch the server and another to invoke the installer itself.

== Installer benefits == 


* All installation scripts and metadata are part of the core Ardor code.
* Java-based, with support for Windows, Linux, and Mac.
* Installation is digitally signed.
* Based on two open-source tools [http://izpack.org IzPack] and [http://devwizard.free.fr/html/en/JavaExe.html JavaExe]
* Bundles a Java Server JRE for Windows.
* System tray integration for Windows, Mac, and Linux systems that support it, with the following functionality:
** Server status monitoring
** Log file viewing
** Server shutdown
** Starting up the wallet in a browser

== Installation steps == 
The installation process will guide you through the following steps:


# Language Selection
# Welcome page
# License agreement
# Change log
# Installation path selection
# Node Configuration
# Desktop shortcuts

=== Java .jar file installation === 
The Jar file installation is compatible with Windows, Linux and Mac. To invoke it, open a command prompt, make sure Java 8 JRE is in your path, then execute the following command:


<syntaxhighlight lang="bash">
java -jar <installer.name>.sh
</syntaxhighlight>


On Unix systems with no graphical environment, invoke the installer from the command line with the -console flag:


<syntaxhighlight lang="bash">
java -jar ardor-client-<version>.sh -console
</syntaxhighlight>

=== Windows installation === 
On Windows platforms the installer supports the following features:


* Wizard-based installation
* Start menu and desktop icons
* Automatic installation of Java JRE
* Creation of Ardor.exe Windows executable which launches the server
* System tray icons used for monitoring and management
* Ability to run the server as a Windows service (so that it continues to run when the user log off the workstation)
* Ability to run the server on Windows without administrator rights


On Windows, run the Ardor server from the desktop icon or by executing Ardor.exe installed in the installation root folder.
In response, an Ardor icon will show up in the system tray and the following folders will be created in the user profile folder, typically under <syntaxhighlight lang="bash" inline>c:\users\<UserName>\AppData\Roaming\Ardor</syntaxhighlight>:


* conf - contains the user configuration files nxt.properties and logging.properties
* logs - contains the server logs
* nxt_db - mainnet database
* nxt_test_db - testnet database

==== Windows Service ==== 
Running the node as a Windows service provides background operation of the node allowing the user to log off the workstation while the node is still running. It also allows the node to automatically start after a workstation restart.


To register the Ardor node as a windows service, open a command prompt with administrator privileges and invoke ardorservice.exe from the installation folder. Answer "Yes" to the confirmation prompt. The service is automatically registered and started.


Invoke ardorservice.exe again from a command prompt with administrator privileges to delete the service. Answer "Yes" to the confirmation prompt.


You can control the service operation and settings using the standard Windows Service dialog. Look for the "Ardor Server" service.


When running as a windows service on Windows 10 with open JDK 11 the blockchain database, log files, and configuration files are created in the C:\Windows\System32\config\systemprofile\AppData\Roaming\Ardor folder, and the system out and system err streams are redirected to folder C:\Windows\Temp. To view files in these folders you will need administrator privileges.


When running as a windows service, the system tray icon is not displayed.

==== Support for Windows 32 bit ==== 


The installer executable bundles a Java 64 bit JRE therefore it won't work on a 32 bit Windows workstation.


Similarly, ardor.exe and ardorservice.exe won't work on Windows 32 bit.


To run Ardor on a Windows 32 bit workstation, install Java 8 manually and then install Ardor from the .sh installer file or using the cross-platform zip file.


Use run.bat to start your node.

==== Additional Notes ==== 


Additional diagnostic information about the server, can be obtained from the files nxt.system.out.*.log and nxt.system.err.*.log in the Windows %TEMP% folder which captures the standard output and error streams. These files are especially useful to review environment information and diagnose startup problems.


In its default configuration, the server does not create or modify any files under the installation folder.

==== Limitations ==== 
# Uninstall from the Windows control panel does not clean all installed folders. You can manually remove the remaining files
# In some cases, desktop shortcut icons, require a refresh of the desktop before the Ardor icon becomes visible
</translate>

Forging Algorithm

2021-04-15T17:23:43Z

Almonte:

<languages />
<translate>
{{#seo:
|title=Forging
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, Forging
|description=Forging is the main process of the Ardor Proof of Stake algorithm
}}
[[Category:Features]]
__TOC__
===Features of the Algorithm=== 
There are two conditions that an account needs to satisfy before it can start forging:


* ''The account needs to have an ''effective balance'' of at least 1000 ARDR. That is, it needs to have had a balance of 1000 ARDR(or more) over the last 1440 blocks / 24 hours.''
: This is needed because the forging algorithm depends on the stake of the user.
* ''The account needs to have at least one outgoing transaction, also confirmed 1440 times.''
: The passphrase is the account's private key, a public key is obtained only after at least one outgoing transaction is executed and confirmed. This can be done in several ways, notably by sending 1 ARDR to your own account (or someone else's), by [[Arbitrary_messages#Sending_a_message|sending a message]] using the arbitrary message feature or by [[Alias_system#Alias_Transfer.2FSale|registering an alias]]


When these two conditions are met, a 1000 ARDR effective balance and public key published, the account is eligible to forge. Note that forging will stop if the effective balance drops below 1000 ARDR.

The forging algorithm employed by ARDR revolves around two variables: ''Hit'' and ''Target''.
====Hit==== 
Each forger generates one 'hit' value between 0 and 2^64 - 1 for each new block. While hit is deterministic, it's produced through hashing inputs, so it can be regarded as a uniform random variable.


From the code, hit is defined as:
<pre>
BigInteger hit = getHit(publicKey, lastBlock);
</pre>


Two arguments are given to the <code>getHit</code> function: the forger's public key and the previous block. The implementation of this function can be seen below.


<pre>
private static BigInteger getHit(byte[] publicKey, Block block){
[...]
MessageDigest digest = Crypto.sha256();
digest.update(block.getGenerationSignature());
byte[] generationSignatureHash = digest.digest(publicKey);
return new BigInteger(1, new byte[] {generationSignatureHash[7],
generationSignatureHash[6],
generationSignatureHash[5],
generationSignatureHash[4],
generationSignatureHash[3],
generationSignatureHash[2],
generationSignatureHash[1],
generationSignatureHash[0]});
}
</pre>
 Taken from ardor/ src / java / nxt / Generator.java 


Each block has a 64 bytes <code>generationSignature</code> parameter. A forger signs the previous block using its own public key. This same <code>generationSignature</code> is successively hashed using SHA256. The hit value is obtained by taking the first 8 bytes of the resulting hash.

====Target==== 
The target is an ever-increasing valor. This is its implementation


<pre>
BigInteger target = BigInteger.valueOf(lastBlock.getBaseTarget())
.multiply(BigInteger.valueOf(effectiveBalance))
.multiply(BigInteger.valueOf(elapsedTime));
</pre>
 Taken from nxt / src / java / nxt / Generator.java 


In other words, we have that


<pre>
Target = BaseTarget * EffectiveBalance * TimeSinceLastBlock
</pre>
Where:


* '''BaseTarget'''
: This parameter is the same for everybody. It gets adjusted from block to block to obtain, roughly, a generation time between blocks of 60s. If two successive blocks get generated too quickly, the new BaseTarget gets reduced. If instead, they take too long, the value gets increased. This adjustment is capped, it can go up at most twice as much (2 * currentBaseTarget) and down at most by half (0.5 * currentBaseTarget).
* '''EffectiveBalance'''
: This is your stake in ARDR. Only the amount of ARDR that has been confirmed at least 1440 times counts towards this balance. The reason the effective balance is used is to avoid shuffling attacks.
* '''TimeSinceLastBlock'''
: How long, in seconds, since the last block has been generated. This parameter is also the same for everybody.

====The block forger==== 
The way ''who'' gets to generate the next block is chosen, is done by using the condition:
<pre>
if (hits.get(accountId).compareTo(target) < 0){
BlockchainProcessorImpl.getInstance().generateBlock(secretPhrase);
}
</pre>
 Taken from ardor / src / java / nxt / Generator.java 


This says, essentially, that if the condition <code>Hit < Target</code> is satisfied, you get to generate the next block.


Now that we know the forging algorithm, there are some considerations we can make:
* All the parameters except the effective balance are the same for everybody.
* The hit parameter is static, what changes during the forging process is the target. Every forger has its own target (even though it depends on parameters equal for everybody) and it reflects the forger's stake. Every second that no block gets generated, the target increases until someone's hit, on the network, manages to be smaller than their own target. The consequence is clear: bigger is your stake, higher will be your target (and more rapidly it will grow) making it easier for you to satisfy the condition. In a practical sense, this entails you will get to generate a block more often.
* TimeSinceLastBlock is the parameter that gives target its increasing nature. The longer it takes to generate a block, the higher becomes the target.
* The situation where multiple forgers satisfy the forging condition at the same time is tangible, the network handles this situation accordingly.
</translate>

Data Cloud

2021-04-15T17:22:26Z

Almonte:

<languages />
<translate>
{{#seo:
|title=Data Cloud
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, Data Cloud
|description=Data Cloud feature is a decentralized data storage system. It is a feature that is reserved for the Ardor child chains
}}
[[Category:Features]]
__TOC__
== Introduction == 
The Ardor Data Cloud is a decentralized data storage system. It is a feature that is reserved for the Ardor child chains


In addition to keeping a record of Ardor transactions, the blockchain can also be used to store user-defined data. All forms of data can be uploaded to the Ardor blockchain, providing a secure (and, if desired, permanent) method of storing, retrieving, and publishing information. Ardor [[Arbitrary_messages|Messaging system]] makes use of this ability to embed data in the blockchain, and the Data Cloud can be seen as an extension of the Messaging system.


One of the most important features of data storage on the blockchain is that the Ardor blockchain is a permanent and immutable record that provides a tamper-proof time stamp. This allows for legal records (such as contracts) to be embedded in the blockchain, with absolute certainty about the time at which they were created.


A single data item is currently limited to 42K.


Only The sha256 hash of the data is stored on the blockchain as proof of existence. The data itself is pruned after several weeks and is only maintained by archival nodes.

==Data Cloud System Menu== 
The Data Cloud System is accessed in the child chains that have such feature (eg: Ignis) by clicking on ''Data Cloud'' in the left-pane menu area of the [[Ardor_client_interface|Ardor Client Interface]], causing a submenu to appear:


[[File:Ardor_DC_menu.png|300px|border|none]]


{|
|'''Search''': This item does not react. It solely refers to the two types of searches present on top of the Data Cloud main screen.
|-
|'''File Upload''': This item displays a modal popup dialog
|}

===Buttons upper right=== 
[[File:Ardor_DC_reset_upload.png|200px|border|none]]
{|
|'''Reset''': This button restores the Data Cloud main screen, discarding any paging done by the user by hand at the bottom of the screen. No data is involved or lost.
|-
|'''File Upload''': This item displays a modal popup dialog
|}

===Searches top=== 
[[File:Ardor_DC_freetextsearch.png|border|center]]

 
===Tag Cloud=== 
'''Tag: Java [2]'''
The number between brackets represents the number of Data Elements that have been tagged with that specific tag


[[File:Ardor_DC_Tagcloud.png|border|none|600px]]


These are all links, but when you click on them, they appear to be a tag cloud that only filters the 'hits' in the list below. The tags in the cloud are have been gathered through the historical use of the [[#Basic_file_upload | File Upload modal dialog]].

===File upload=== 
The toggle between ''basic'' and ''advanced'' upload is located at the bottom left end of the popup modal dialog called ''Upload Data''

====Basic file upload==== 
[[File:Ardor_DC_basic_FU.png|500px|border|none]]
{|
|'''Name''': This could be any given name. Does not need the correspond with the actually uploaded filename.
|-
|'''Description''': Possibility to provide some background; e.g. the reason to add this item to the Data Cloud, its status, and perceived value.
|-
|'''Tags''': Supply up to 5 comma-separated tags. Their purpose is to index the data cloud and make it efficiently searchable.
|-
|'''Channel''': Each tagged data can now also have a channel field. You can filter the search results by channel, which has been added to retrieve tagged data by channel, optionally filtered by account too.
|-
|'''File''': Upload button, no restriction of file type or extension. '''File upload is a mandatory field.'''
|-
|'''Fee''': Free input field in round numbers. Even a negative number can be submitted but will result in an error. The calculate button will calculate the minimum fee for you dependent on the file size you intend to upload.
|-
|'''Passphrase''': the passphrase matching the account
|}
</translate>

Coin Shuffling

2021-04-15T17:20:04Z

Almonte:

<languages />
<translate>
{{#seo:
|title=Coin Shuffling
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, Coin Shuffling
|description=is a privacy feature that enables users to mix token funds
}}
[[Category:Features]]
__TOC__
==Introduction== 
Coin Shuffling is a privacy feature that enables users to mix [[Asset exchange |assets]], [[Monetary system|currencies]] or child chain token funds (as long as the child chain has enabled such feature) quickly and efficiently with other users' funds by creating a random mapping between the existing user accounts and a new recipient accounts provided by the users.


This guide describes the Coin Shuffling feature, active for Ignis since the Ardor launch. Usage examples apply to the [[Ardor_client_interface|Ardor Client Interface]].

==Shuffling Menu== 
Coin Shuffling is accessed by clicking on ''Shuffling'' in the left-pane menu area of the [[Ardor_client_interface|Ardor Client Interface]], causing a submenu to appear:


[[File:Shuffle.menu.PNG|border|left]]


{|
|'''Shuffling''': This item expands or contracts the submenu below and opens the [[Coin_Shuffling#Active_Shufflings_Page|Active Shufflings]] page which lists the active shufflings related to the child chain tokens selected.
|-
|'''Active Shufflings''': This item displays a list of all [[Coin_Shuffling#Active_Shufflings_Page|Active Shufflings]].
|-
|'''My Shufflings''': This item displays all the shufflings in which the current account participates.
|-
|'''Create Shuffling''': This item opens a pop-up entry form for creating a new shuffling as described in [[Coin_Shuffling#Create_Shuffling_Modal|Create Shuffling]].
|}

===Active Shufflings Page=== 
[[File:active.shuffling.PNG|thumb|none|border|650px]]


*''Shuffling'' clicking on a shuffling link in the ''Shuffling'' column opens a detailed pop-up that displays details about the shuffling state and the list of senders and recipients in case the shuffling is complete.
*''Stage'' displays the current stage of the shuffling process.
*''Holding'' shows the type of holding used for shuffling asset, currency, or child chain tokens (eg: Ignis).
*''Amount'' is the common amount to shuffle specified in the holding unit.
*''Blocks Remaining'' is the number of blocks until shuffling is canceled unless the required information necessary for the shuffling to advance to the next stage is provided.
*''Participants'' shows the existing number of shuffling registrants and the number of required registrants for shuffling processing to begin.
*''Assignee'' represents the account that last updated the shuffling or the account which needs to specify the next piece of data.
*''Status'' displays 'join' in case the user is still not registered for the shuffling or the shuffler status in case the user has registered.

===My Shufflings Page=== 
[[File:my.shuffling.PNG|thumb|none|border|650px]]


*First columns are similar to the active shufflings page.
*The ''Shuffler'', ''Recipient'' and ''State'' columns represent the status of the Shuffler component which manages the shuffling process for the current account and shuffling.

===Create Shuffling Modal=== 
[[File:create.shuffling.PNG|border|none]]


*Create a new Shuffling.
*''Holding Type'' is the token used by the shuffling. child chain tokens (eg: Ignis), Asset id, or Currency name.
*''Amount'' the common amount used by all shuffling participants, specified in the holding token.
*''Register Until'' shuffling registration deadline. If the required number of participants do not register by this block height the shuffling is canceled and all funds are returned without a fine.
*''Fee ratio'' The fee ratio that the shuffler will use to send transactions on the account's behalf. The participants have full control over the fee ratio to prevent that the shuffler will not be able to submit shuffling transactions in case there are no bundlers available.
*''Participant Count'' number of registrants required to trigger the shuffling. Between 3 and 30.

===Start Shuffler Modal=== 
[[File:start.shuffler.PNG|border|none]]


*Start the shuffler process on the current node to coordinate the shuffling
*''Recipient Passphrase'' the passphrase of the recipient account for your shuffling participant. Do not lose this passphrase since it is the passphrase to your shuffled funds.
*''Recipient Account'' account id derived from the recipient passphrase (read-only field).

== Standby Shuffling == 


The Standby Shuffling add-on allows the creation of Standby Shufflers that monitors the blockchain for new shufflings. When a new shuffling meets given criteria the Standby Shuffler will start a shuffler on the node targeting an unused recipient account from a configured pool. See the [[Shuffling#Start_StandbyShuffler|API pages]] for more details.


A Standby Shuffler does not join active shufflings when started even if they meet the Standby Shuffler criteria. To join active shuffling use the "join" button from the ''Active Shufflings'' page.


In order to use this feature you need to configure the corresponding add-on:


<syntaxhighlight lang="bash">nxt.addOns=StandbyShuffling</syntaxhighlight>


The ''Standby Shufflers'' feature is enable within the Shuffling section in the [[Ardor_client_interface|Ardor Client Interface]]:


[[File:StandbyShuffling01.png|thumb|none|border|650px]]


The main ''Standby Shufflers'' page lists the running standby shufflers on the current node. You can list the ones running for the current account or all of them by using the ''All'' and ''My'' tab selectors on the top right.

[[File:StandbyShuffling03.png|thumb|none|border|650px]]

On this table, you will find the details of each shuffler as well as the pool of unused accounts status. The actual data will depend on the shuffler using the legacy list of public keys or the improved approach of deriving new accounts from an HD account.

The third button on the top right of the page opens the modal to start a new standby shuffler.

[[File:StandbyShuffling02.png|thumb|none|border|650px]]

The bottom of the modal window allows you to define how the standby shuffler will get unused accounts for each new shuffling. You have two options: an HD wallet or a list of secret phrases. The new and recommended way is to use an HD wallet so the shuffler could derive new public keys from a BIP 32 node. You could also use the legacy approach of entering a list of secret phrases for unused accounts.

[[File:StandbyShufflerStartLegacyTab.png|thumb|none|border|650px]]

=== Pool of unused accounts === 


Each shuffling requires an unused recipient account. That means we need to provide each Standby Shuffler with a mechanism to get unused accounts. Before HD wallets the only way was to pass a list of public keys to the Standby Shuffler which will be used one at a time for each matching shuffling (see ''recipientsPublicKey'' parameter). This required to generate secret phrases in advance and limited the size of the pool of unused recipient accounts for the Standby Shuffler. With the new HD wallets, the derivation of public keys from a master public key is very easy and provides a simple mechanism that doesn't require generating new secrets and can produce a practically unlimited number of new accounts. This mechanism is also compatible with hardware devices like the Ledger wallet.

==== Using Seed / Hardware ====

You need to pass your Master Public Key to the Standby Shuffler so it can derive new accounts. Keep in mind this is not the public key of any specific account on the HD wallet. You can find this Master Public Key on the login screen when using a seed, click on the ''Advanced'' button just below the seed input.

[[File:LoginSeedMasterPublicKey.png|thumb|none|border|650px]]

The ''Start From Child Index'' allows you to adjust the starting index the standby shuffler will use to look for unused accounts. It doesn't matter if that index or any of the next indices are used, the standby shuffler will keep looking from that index until it finds an unused account, derive its public key, and use that for joining a matching shuffling.

==== Using Legacy accounts====

You should generate the new accounts using the account wizard and write down the passphrases in secure storage. Then paste the passphrases, one per line, on the corresponding input of the Start Standby Shuffler window.

Keep in mind that the secret passphrases are never submitted to the remote node, only the derived public keys are.

When an unused account is needed the first one on the pool is reserved and assigned to the Shuffler that will monitor the shuffling. It's not discarded right away to reuse it in case we don't end up using it on the shuffling. The moment that the key is completely removed from the Standby Shuffler is when we enter the processing stage. From this point, a failed shuffling will reveal the link between our account and the new public key. These reserved keys are recovered when the Shuffler ends.

When both the unused and reserved pools become empty the Standby Shuffler is automatically removed from the node.

=== Configuration persistence === 
The Standby Shufflers, like other similar local node tools like bundlers or forgers, are not persisted across node reboots.


Check the [[Node_Processes_Configuration|Processes]] feature for an easy-to-use and secure tool to help you with recovering the configuration upon node restart.

=== Examples === 

Note: These examples were written for the legacy mechanism but are still valid. The only change when using the new HD wallets is that the Standby Shuffler will always have new accounts to use.

==== Example 1 ==== 
Suppose you have an account with 5000 IGNIS and you want to shuffle some of them. You are not in a hurry and don't care if you shuffle it in batches. So, you set up a Standby Shuffler with a minimum amount of 100 and a maximum amount of 1000. You generate three new accounts using the account wizard and write down the passphrases in secure storage. Let's call them NewAccount01, NewAccount02, and NewAccount03. You start the Standby Shuffler.


Current status:
* NewAccount01: unused
* NewAccount02: unused
* NewAccount03: unused


A new shuffling appears with an amount of 500 IGNIS. Your Standby Shuffler checks the shuffling: it meets the amount limits, you have enough balance and it has unused accounts. So, it joins the shuffling. Suppose that a few blocks later the shuffling completes successfully.


Current status:
* NewAccount01: 500 IGNIS
* NewAccount02: unused
* NewAccount03: unused


A new shuffling is created, 600 IGNIS. Again, it meets the criteria (100 <= 600 <= 1000) so it joins the shuffling for you. Let’s suppose it also completes successfully.


Current status:
* NewAccount01: 500 IGNIS
* NewAccount02: 600 IGNIS
* NewAccount03: unused


A new shuffling is created, 90 IGNIS. As the shuffling is outside the limits the Standby Shuffler ignores it.


One more shuffling of 200 IGNIS is detected. It meets the criteria. You have unused accounts so you join the shuffling.


Final status:
* NewAccount01: 500 IGNIS
* NewAccount02: 600 IGNIS
* NewAccount03: 200 IGNIS


The Standby Shuffler has no more unused accounts on the pool so it shuts down.

==== Example 2 ==== 
Suppose you have an account with 2000 IGNIS and you want to shuffle all of them. You set up a Standby Shuffler with a minimum amount of 500 and no maximum. You generate three new accounts using the account wizard and write down the passphrases in secure storage. Let's call them NewAccount01, NewAccount02, and NewAccount03. You start the Standby Shuffler.


Current status:
* NewAccount01: unused
* NewAccount02: unused
* NewAccount03: unused


A new shuffling appears with an amount of 500 IGNIS. Your Standby Shuffler checks the shuffling: it meets the amount limits, you have enough balance and it has unused accounts. So, it joins the shuffling. Suppose that a few blocks later the shuffling completes successfully.


Current status:
* NewAccount01: 500 IGNIS
* NewAccount02: unused
* NewAccount03: unused


A new shuffling appears with an amount of 1800 IGNIS. You had initially 2000 IGNIS and you've shuffled 500 IGNIS and paid some fees so you are probably a bit below 1500 IGNIS. You don't have enough funds to join the shuffling so the Standby Shuffler skips this shuffling.


A new shuffling is created, 90 IGNIS. As the shuffling is outside the limits the Standby Shuffler ignores it.


A new shuffling appears with an amount of 1400 IGNIS. Let's suppose you have enough funds at this moment. So, it joins the shuffling. Suppose that a few blocks later the shuffling completes successfully.


Current status:
* NewAccount01: 500 IGNIS
* NewAccount02: 1400 IGNIS
* NewAccount03: unused


You currently have, probably, some funds left but the Standby Shuffler has a minimum of 500 IGNIS so it won't join any other shuffling.

== Technical Background == 


Coin Shuffling is a privacy feature that enables users to mix their funds quickly and efficiently with other users' funds by creating a random mapping between the existing user accounts and new recipient accounts provided by the users.


This feature is based on the academic paper [http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf] which is also the source of the feature name.


Overview:


The implementation of the feature is based on the Ardor platform, this eliminates some of the manual steps and trust issues of existing 3rd party mixing solutions.
The client wallet provides a user interface for users to monitor and coordinate their actions during the shuffling process.


Shuffling can be performed using child chain tokens (eg: Ignis), assets, or currencies as specified by the creator of the shuffling.


Any account can create a new shuffling, specifying the holding to be shuffled, the shuffle amount, number of participants required, and registration deadline.


This is done using the shufflingCreate API. The subsequent shuffling steps can be performed manually, by using the shufflingRegister (for accounts other than the creator), shufflingProcess and shufflingVerify or shufflingCancel APIs.


However, due to the complexity of the process and the difficulty to predict the timing in which actions should be submitted, it is impractical to manage a shuffling manually.
Therefore shuffling is managed by an automated component called "Shuffler", using the startShuffler API.


Once started, the Shuffler monitors the blockchain state for transactions relevant to the specified shuffle, and automatically submits the required transactions on behalf of the user, performing shuffle processing, verification, or cancellation as needed.
To do this, the Shuffler is required to keep the users' secret phrase in memory, the same as when forging. And just like with forging, restart or a crash of the node requires restarting the shuffler manually.
The shuffler remains running for 720 blocks after a shuffling either completes successfully or is canceled to make sure it is still active in case of an (unlikely) blockchain reorder.


There is a single shuffler per node/shuffling/participant combination. A single node can run up to 100 shufflers concurrently for various shufflings and participants.


To participate in a shuffling, a deposit of 0.12 Ignis is needed (see [[Create_Transaction#Create Transaction Request|fees]]), in addition to the amount of currency or asset being shuffled or if shuffling, the amount of the shuffle must exceed this 0.12 Ignis minimum.

When a shuffling completes successfully, this amount is added to the recipient account balance, to allow it to send outgoing transactions (as it is required that only new, unused accounts are specified as recipients).
In case the shuffling fails due to a registered participant failing to participate as required, or intentionally submitting false data, the participant responsible for the shuffle cancellation is penalized by sending this security deposit to the forgers of the shuffle finish block and the previous three blocks.
If a shuffling is canceled because the required number of participants is not met, nobody is penalized and all deposits are refunded.
On testnet, the deposit and penalty are only 10 Ignis or 10 Bits.


After shuffling registration is complete, participants must submit processing data within a 100 blocks period each (10 blocks on testnet). For the verification and blame phase, the total allowance for all participants is 100 + numberOfParticipants blocks (again reduced to 10 + numberOfParticipants blocks on testnet).
Full blocks are not counted towards the limit. If at any stage the deadline is reached without some participant submitting the next required transaction, the shuffling is canceled and this participant loses its security deposit of 0.12 Ignis.
This process is managed by the shuffler. It is therefore critical that after registering for a shuffling, the shuffler started, is left running until the shuffling is successfully completed.
In case the node must be restarted, all previously running shufflers must be started manually.


Query APIs to retrieve currently running shufflers, shufflings, and shuffling participants are: getAllShufflings, getAccountShufflings, getAssignedShufflings, getHoldingShufflings, getShufflers, getShuffling, and getShufflingParticipants.


Finished shufflings can be automatically deleted from the database in case the nxt.deleteFinishedShufflings property is set to true (default is false).


The fee for creating a shuffling or registering in one is 0.12 Ignis, for the shuffling process or shuffling cancel transactions 10 Ignis, and for the verify transaction 0.1 Ignis.

=== Warnings === 
1. The recipient account of the shuffling participant must be newly created. Participants should take great care to create a strong passphrase for the recipient account and save this passphrase for later Failing to so will result in your funds being lost or stolen.


2. Once an account creates a shuffling or registers as a participant in one, **the node used by this account must remain online and the shuffler must remain active.**
The state of the shuffler can be monitored using the "My Shufflings" page. In case your node is restarted, make sure to start all shufflers related to the active shufflings in which your account participates.
</translate>

Child Chain Control

2021-04-15T17:14:52Z

Almonte:

<languages />
<translate>
{{#seo:
|title=Child chain control
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, permissioned blockchain, child chain control
|description=Description of the child chain control, permissioned layer of the Ardor blockchain
}}
__TOC__
[[Category:Features]]
==Description== 
Child Chain Control is a feature that introduces permissioning to the Ardor multichain platform. It manages the authorization levels of users on child chains. When operating on a chain that has permissioning policy enabled users can be restricted from performing chain transactions.

==Permission Types== 
To use child chain control features, you need to have the proper setup of the child chain. Namely, its ''permissionPolicy'' property should be set to ''CHILD_CHAIN'' only then you will be able to control permissioning. To check if it is enabled for a given chain open Account Details dialog. At the bottom of the dialog, you should see the value of the ''Account Permissions'' property for the current chain. If you don't see ''Account Permissions'' property it means you are operating on a chain that doesn't support permissioning, ask chain developers to enable it.
[[File:Account Details.png|thumb|border|none|Account Details modal on a chain that has permission policy. ]]


Without ''Chain User'' permission account will not be able to perform chain operations such as sending tokens and the user will be presented with a warning.
[[File:No chain user permission.png|thumb|border|none|Account without Chain User permission]]


Ardor child chains support the following permissions:
{| class="wikitable"
|-
! Permission Name !! Assigned by !! Features
|-
| Master Admin || developers|| Can only designate/block admins. Cannot perform operations on the chain.
|-
| Chain Admin|| Master Admin|| Can only designate/block users. Cannot perform operations on the chain.
|-
| Blocked Chain Admin|| Master Admin|| Chain admin rights blocked.
|-
| Chain User|| Chain Admin|| Can perform operations on the chain.
|-
| Blocked Chain User|| Chain Admin|| Cannot perform operations on the chain.
|}
A single account can have multiple permissions per chain:
[[File:Account Details with permissions.png|thumb|border|none|Account Details modal on the chain that has permission policy and has permissions specified]]

==How to assign account permissions== 
For Ardor accounts to be able to use child chains you need to explicitly grant them ''Chain User'' permission. But first, you need to designate a few accounts as admins by giving them ''Chain Admin'' permission. You need to have at least one ''Master Admin'' account (ask developers to configure one or a few accounts with ''Master Admin'' permission) for that. ''Master Admin'' and ''Chain Admin'' accounts will have an extra link in the sidebar leading to Permissions Control page:
[[File:Sidebar permissions control.png|thumb|none|Sidebar with Permissions Control link]]
Permissions Control page has two buttons on top that open a modal dialog through which you can grant or remove permissions for a specific account. It also lists all the recent permissioning operations on this chain.
[[File:Permissions Control page.png|thumb|none|Permissions Control page]]
To grant ''Chain Admin'' permission click on ''Grant Permission'' button and fill in fields in the modal dialog.
[[File:Grant permission modal.png|thumb|none|Granting permission to account]]
You can filter out operations performed by you using toggle control next to ''Granted by'' column title. The last column has action buttons that simplify granting or removing permissions by prepopulating account and permission fields in the modal dialog. Once the account gets ''Chain Admin'' permission it can start granting ''Chain User'' permission to other accounts. ''Chain User'' permission is essential as it gives account access to chain features.
[[File:Grant chain user permission modal.png|thumb|none]]

==How to see which permissions account has== 
Even if you don't have ''Chain Admin'' or ''Master Admin'' rights you can still see who granted you permissions from the ''Account Permissions'' tab in the ''User Info'' modal. It also shows who granted you permissions and when it happened.
[[File:User info account permissions.png|thumb|none|Granting permission to account]]

==How to remove previously granted permission== 
If permission was granted to a wrong account or an account no longer needs it you can remove permission (you must yourself have sufficient permissions to do that, check the table above). Click the ''Remove Permission'' button on the ''Permissions Control'' page and complete the modal dialog. Hint: you can find all the permissions granted by you by clicking the toggle button next to ''Granted by'' column title. If you click ''Remove Permission'' button from the table - it will prepopulate the modal dialog account and permission fields.
[[File:Remove permission modal.png|thumb|none|Removing permission]]

==How to block permissions== 
If you want to block users or admin simply grant them with ''Blocked Chain User'' or ''Blocked Chain Admin'' permissions. Blocked accounts will not be able to exercise their permissions until someone removes ''Blocked Chain User'' or ''Blocked Chain Admin'' permissions. Blocked accounts will see who blocked them.

</translate>

Changelly Integration

2021-04-15T17:11:38Z

Almonte:

<languages />
<translate>
{{#seo:
|title=Changelly Integration
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, Changelly Integration
|description=Changelly is a market-making service that utilizes crypto exchanges to provide a seamless exchange of crypto tokens without user registration. Since Ardor version 2.1.2 the Ardor wallet integrates its service
}}
[[Category:Features]]
__TOC__
== Introduction == 


[https://changelly.com/ Changelly] is a market-making service that utilizes crypto exchanges to provide a seamless exchange of crypto tokens without user registration.


Starting from Ardor version 2.1.2 the Ardor wallet integrates the changelly service to enable Ardor and Ignis to exchange with any other crypto directly from the wallet.

== Using the changelly API service == 


The service provides two main functions


1. Exchange to/from another crypto - this service is available from the exchanges page (See arrows icon at the top bar of the wallet).


2. Fund a new account by exchanging Bitcoin to either Ardor or Ignis. This function is accessible from the dashboard when creating a new account. At the moment, this exchange transaction will not announce the account public key to the network.


The user interface should be self-explanatory.

== Warnings, Notices and Limitations == 


Changelly is a 3rd party service provider which is not associated with Ardor in any way. We are not liable for any problem encountered with the service.


The Ardor wallet changelly page connects directly from the browser to the changelly APIs. Therefore any action you perform is visible to changelly and any information you receive is provided by changelly as is. Of course, your account passphrase is never submitted to changelly.


Always note the minimum deposit amount provided by changelly before performing an exchange. Sending a value lower than the minimum will likely result in lost funds.


While changelly does not provide a maximum deposit amount, exchanging a large amount through this service is likely to provide a less than optimal exchange rate. The changelly service relies on other crypto exchanges and if there is no liquidity on the exchanges, changelly may use a very unfavorable exchange rate. Therefore use your best judgment and consider not using this service to exchange large amounts.


Changelly transactions do not correspond 1:1 to Ardor transactions. Therefore when performing an exchange, you may see several changelly transactions listed in the "My Exchanges" table while only one of them shows the real exchange. This is normal. You may delete the extra transactions once the exchange is performed.


In case you need to approach the changelly customer support always specify the changelly transaction id which is listed in the id column of the "My Exchanges" table.


The changelly page, when displayed in the wallet, is refreshed every 60 seconds, some delays during refresh are normal, simply wait for the page to fully reload. Transaction timeouts may happen at any moment. When they do happen, simply start over the exchange operation or continue from where you left off.


When exchanging from Ardor/Ignis to another crypto, you have to specify a transaction fee denominated in Ardor/Ignis correspondingly. The wallet cannot calculate this fee automatically, therefore use your best judgment. In case this is your first exchange, changelly will provide a fresh deposit address, therefore your transaction will need to cover the 1 ARDR fee to create this new account, which means, your Ardor fee should be 1.01 ARDR and your Ignis fee should cover 1.01 ARDR based on the current bundling rate. Subsequent exchanges from the same wallet should use the same changelly deposit address so only needs to cover the 0.01 ARDR transaction fee.


Changelly charges a small exchange fee composed of several elements, you can view the complete details in the "View Changelly Transaction" dialog reachable by clicking the changelly transaction id in the "My Exchanges" table.
</translate>

Bundling

2021-04-15T17:09:56Z

Almonte:

<languages />
<translate>
{{#seo:
|title=Bundling
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, Bundling
|description=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
}}
[[Category:Features]]
__TOC__
==Description== 
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 representing an additional factor of the Ardor fee to pay in case of competing bundlers. This is a multiplier of what you will pay in terms of Ardor fee so if the fee is 100 ARDR and overpay is set to 0.1 you will pay 100 + 100 * 0.1 = 110 as bundling fee.


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, multiplied by the overpay amount, if any. Such overpay amount is optional and may be used by bundlers willing to pay more to have their transactions included in a 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.

==Bundler Setup== 
Bundling like Forging requires sending the passphrase to the remote node. Therefore only run a bundler on a node under your control. To view the running bundler on a node, the wallet has to include the remote node admin password in its account settings.


The bundlers, like other similar local node tools like standby shufflers or forgers, are not persisted across node reboots. Check the [[Node_Processes_Configuration|Processes]] feature for an easy-to-use and secure tool to help you with recovering the configuration upon node restart.

===Existing bundlers known to the remote node=== 


[[File:bundlers.list.png|border|none|thumb|630px|figure 1]]

===Start a new bundler=== 


[[File:start.bundler.png|||figure 2]]

==Bundling rules== 
Since [[Ardor_Software_Change_Log#ardor-client-2.1.0|Ardor 2.10e]] it is possible to enable bundling rules. 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. The bundler will operate on the currently selected child chain. One or more bundling rules must be added to each bundler, and also a limit specifying the total fees in ARDR, which the bundler will pay.


The bundling rule has following properties:

====Minimum Rate==== 
The coin to ARDR exchange rate of this rule. Transactions are accepted by this rule if the fee included by the transaction sender, in child chain coins, when converted to ARDR using this rate is at least equal to the [https://www.jelurida.com/sites/default/files/ArdorFees.pdf minimum Ardor fee required for this transaction].

====Fee Calculator==== 
Function used to determine the fee in ARDR, which the bundler will finally pay for each transaction, having the fee in child chain coins received from the transaction.
* MIN_FEE (default value, bundlers in Ardor v2.0 use this function): the Bundler will always pay the [https://www.jelurida.com/sites/default/files/ArdorFees.pdf minimum protocol fee], no matter how much child chain coins are received from the child transaction.
* PROPORTIONAL_FEE: the Bundler pays fee in ARDR proportionally to the received child chain coins, according to the Minimum Rate. This would give an advantage to the bundler versus bundlers using the MIN_FEE function in case the transaction creators start competing for block space by specifying higher fee in child chain coins.
* Custom calculators can be developed as add-ons by implementing the Bundler.FeeCalculator interface. Their classes must be listed in the nxt.customBundlingFeeCalculators configuration property.

====Overpay==== 
An additional factor of the Ardor fee to pay for each transaction. Used to give advantage to this bundler when competing with other bundlers. This is a multiplier of what you will pay in terms of the ARDR fee (the result of the Fee Calculator function). So if the fee is 100 ARDR and overpay is set to 0.1 you will pay 100 + 100 * 0.1 = 110 as bundling fee. Custom Fee Calculators may use this value for a different purpose, or disregard it.
====Filters====
Zero or more additional filters are applied to the bundled transactions. The transaction must satisfy the minimum fee rate and '''all''' filters to be processed. Filters can check various properties of the transaction like the sender, the recipient the transaction type, or even the presence of other transaction(s). A parameter can be specified for every added filter. The parameter is a filter-specific arbitrary string. Default filters provided "out-of-the-box":
{{BundlerFilters}}
Additional filters can be developed as add-ons by implementing the Bundler.Filter interface. Their classes must be added to the nxt.availableBundlingFilters property.


Bundlers with at least one non-filtered rule advertise to other peers the minimum rate among their non-filtered rules. This is the minimum rate at which the bundler will accept child transactions without checking any other property except the fee. The bundler signs 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). Bundlers that have at least one filter added to all of their rules are considered private and their rates are not announced.


When running a subsidizing bundler, it is more efficient to add a not-filtered rule with some acceptable rate at the last position in the list, so that the bundler bundles both zero-fee and regular (public) transactions. This will increase the total amount of ARDR in the ChildBlock transaction and will give it priority over ChildBlock transactions created by other bundlers. The transactions are prioritized first by the index of the rule accepting them, and then by the fee in child chain coins they pay. So a subsidizing bundler will include the subsidized transactions before the public transactions even if it receives 0 fee from them.


The GetBundlerRates API can be used to retrieve known bundlers rates, again with optional filtering by minimum bundler effective balance.

===Bundler Setup 2.1.0e=== 
Bundling like Forging requires sending the passphrase to the remote node. Therefore only run a bundler on a node under your control. To view the running bundler on a node, the wallet has to include the remote node admin password in its account settings.


Existing bundlers known to the remote node for the currently selected child chain (switch to ARDR chain to see the bundlers for all chains).


[[File:BundlersList_2.1.png|border|none|630px|figure 1]]


----


Start a new bundler


[[File:StartBundler_2.1.png|border|none|630px|figure 2]]


----


Initially the bundler is started with only one rule. More rules can be added with the Add Rule button:


[[File:MyBundler.png|none|border|750px|figure 3]]
</translate>

Asset Properties

2021-04-15T17:07:56Z

Almonte:

<languages />
<translate>
{{#seo:
|title=Asset Properties
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, account Properties, Asset Properties feature
|description=Asset Properties feature gives Ardor users the ability to permanently ‘tag’ any asset with a small amount of data.
}}
[[Category:Features]]
__TOC__
== Introduction == 


Asset properties give Ardor users the ability to permanently ‘tag’ any asset with a small amount of data. These properties tags can be used to provide meta-information about an asset, for example:
* A company can tag an asset to be identified as part of their ecosystem.
* A venture capital that manages different investments in form of assets, which can be tagged from a master account to set them as either ''approve'', ''approval process'' or ''rejected''
* For managing the lifecycle of a tokenized asset. For instance, a singleton asset that represents a renting vehicle can be tagged as ''on duty'' or ''in the workshop'' for calculating working hours

== How to set an asset property == 


{|
|-
|1. Visit http://localhost:27876/ (or https://localhost:27876/ if you enabled SSL) and log in.
|-
|2. Select the Ignis chain, click on ''Assets'' under "Dashboard" in the left sidebar and click on the "Asset Properties" link as shown in the following figure:


[[File:Asset properties_1.png|center|thumb|770px|Figure 1]]


|-
|3. A window showing the current asset properties for your account will appear. Click the 'Set'' tab in the top right:


[[File:Asset properties_2.png|center|thumb|770px|Figure 2]]


|-
|4. A form allowing you to set an asset property will appear. From here you can specify the asset id is selected allowing to set the property on, the name of the property, and the value for that property:


[[File:Asset properties_3.png|center|thumb|630px|Figure 3]]


|}
</translate>

Asset exchange

2021-04-15T17:07:38Z

Almonte:

<languages />
<translate>
{{#seo:
|title=Asset exchange
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, Asset exchange
|description=Asset exchange feature allows the following operation with assets: Issue, transfer, increase and delete shares, paying dividends, and exchange
}}
[[Category:Features]]
__TOC__
==Description== 
This page covers the decentralized Asset Exchange within the Ardor multichain platform. Before jumping into the details, we can start with an example that shows one of the possible uses of this feature.


In the words of ''BCNext (developer of the [https://nxtplatform.org Nxt blockchain]):''
{|border="0"
|<blockquote>''I want to run a business. I issue an asset (let's call it Krusty Krab tokens - KKT). I set the quantity of KKT to 1000. I announce that I sell KKT for 20 NXT each and pay 5 NXT monthly interest within the next 6 months. I create an ask order -- 1000 KKT for 20,000 NXT.''
''You create a transaction that sends me 500 NXT for 25 KKT. It's up to you what to do with your 25 KKT (you can place an ask order and sell them for 27 NXT) but each month I will check the blockchain to see who owns KKT. And I will send 5 NXT for each KKT to those who own them.''
</blockquote>
|}

==Accessing the Asset Exchange== 


Ardor has the decentralized asset exchange feature since its deployment in production (the 1st of January of 2018)
If you do not know how to install the Ardor client, check out the [[Getting_started|getting started]] page or the [[common problems and resolutions]] page in case you are having problems.

==The Interface== 
With the server running, access the Ardor interface of your client by visiting http://localhost:27876/ (or https://localhost:27876/ if you have enabled SSL). On the sidebar, select a child chain that has the asset exchange enabled (e.g.: Ignins), click the menu ''Asset Exchange'', this will give you access to the following options:


[[File:AE_menu.PNG|frame|left]]
{|
|'''Asset Exchange''': This tab gives you access to the Asset Exchange itself. To observe an asset click the "Add asset" button and enter either the Asset ID or ID of the issuing account. Assets of your interest will be listed on the left. By selecting an asset, further information is provided: a description, buy and sell orders, the quantity, etc.
|-
|'''Trade History''': This page will list all the assets traded by your account: both those bought by you and those you sold from the exchange.
|-
|'''Transfer History''': This page will list all the assets transferred and received by your account.
|-
|'''Quantity Change History''': This page will list the quantity change history of your assets.
|-
|'''My Assets''': This page will list all the assets in your possession: both those issued by you and those you bought from the exchange.
|-
|'''Open Orders''': Here is provided a list of all your orders, notably the assets you are either trying to sell or to buy. It also allows you to cancel them.
|-
|'''Approval Request''': Approval request for transactions related to your assets, see [[Asset_control|Asset control]]
|-
|'''Issue Asset''': A window will pop up allowing you to issue your own assets into the exchange.
|} 

===Asset Exchange menu=== 


By default, the Asset Exchange does not list any assets. You will have therefore to add the assets (using the ''Add Asset'' button) you are interested in, manually, yourself. For this purpose websites that rank the assets in meaningful ways (by volume, by the number of trades, etc) and that offer specific filters are starting to appear. In the future, you will be able to load asset lists in bulk instead of having to load them one by one. If you find yourself on the page of an asset, a ''Bookmark this Asset'' button will appear that will allow you to keep track of it.


Remind always to check that the asset id you are adding correspond with the legit asset:


* Asset names '''are not''' unique, asset ids '''are''' unique


'''Note:''' you can only add assets to the list if you are using the browser in normal mode. If you are in incognito (or equivalent) then any added list will disappear once you close the browser window. In the future, more portable systems will be implemented.


[[File:Asset_Exchange.PNG|thumb|none|border|630px|the Asset Exchange available within the client.]]
{|
|This is the main menu for the Asset Exchange, it is fundamentally organized in two areas.
|-
|
:*a list with all the assets you are tracking.
:*an interface that allows interaction with these assets.
|-
|If you own tokens for an asset, it will appear in yellow on the side list.
|-
|By selecting an asset, the interface area will automatically display the corresponding information. This includes the amount of tokens that have been created ''("quantity")'', how divisible is the token ''("asset decimals")'', a brief description of the asset, who created the asset ''("account")'' and the asset identifier ''("asset ID")''. These informations are crucial, in fact the asset names are '''''non-unique''''. What this means is that there can be multiple assets that have the same name.
|-
|The cost of issuing an asset will be charged in child-chain tokens corresponding value of 100 Ardor, see [[Create_Transaction#Create Transaction Request|Create Transaction Request]] should discourage people from spamming the exchange with assets whose only purpose is confusion and abuse. Without entering this worst-case scenario, it is reasonable to assume that perfectly legit users may create assets of the same name. Therefore a good degree of vigilance before buying is always beneficial.
|-
| To buy an asset, follow these simple steps:
|-
|
:1. select the asset from the list.
:2. '''quantity''': define how many tokens you are interested in buying.
:3. '''price''': set how much you are willing to pay.
::'''ATTENTION''': "price" refers to the cost of a unit of tokens. So, by entering 10, you are willing to pay 10 child chain tokens ''per'' asset token.
:4. '''fee''': define the fee, see fees in [[Create_Transaction#Create Transaction Request|Create Transaction Request]] or click on the "Calculate" button, which will automatically calculate the current network fee.
:5. press buy.
:6. it will ask you for your passphrase and finally press ''buy asset''.
|}

===My Assets menu=== 
[[File:My_assets.PNG|none|thumb|border|600px|Transfer Asset]]


In this menu all your confirmed assets will be displayed, this includes the assets you issued and those you obtained through trading.

====Transfer asset==== 
Assets are also transferable, the procedure is very simple:
#Under '''''My Assets''''', find the asset you wish to transfer.
#Click ''transfer''.
#Complete the fields as follows.


[[File:Transfer_asset.PNG|border|thumb|400px|left]]

{|
|-
|'''RECIPIENT''': the account you wish to transfer the assets to.
|-
|'''''Constraints''''':
|-
|
:''Mandatory'': this field is mandatory.
|-
|'''COMMENT''': you can attach a brief commentary to the transfer. when marking "Add a message"
|-
|'''''Constraints''''':
|-
|
:''Optional'': this field is optional.
|-
|
:''Characters allowed'': it can contain any Unicode characters but should be URL-encoded. Maximum length of 1000 characters.
|-
|'''QUANTITY''': specify the amount of assets you wish to transfer.
|-
|'''''Constraints''''':
|-
|
:''Mandatory'': this field is mandatory.
|-
|
:''Limits'': there is no upper limit, you can transfer all your assets. The minimum amount you can transfer depends on the nature of the asset. In particular, it depends on what has been defined as ''decimals''. For 0 decimals, the minimum would be 1 token. For 1 decimal, it would be 0.1 tokens and so on.
|-
|'''FEE''': set the fee you are willing to pay for the transaction.
|-
|'''''Constraints''''':
|-
|
:''Mandatory'': this field is mandatory.
|-
|
:''Limits'': there is no upper limit. However the minimum fee is 0.01 tokens, see [[Create_Transaction#Create Transaction Request|fees]].
|-
|'''SECRET PASSPHRASE''': enter '''''your''''' passphrase.
|-
|'''''Constraints''''':
|-
|
:''Mandatory'': this field is mandatory.
|
|-
|'''VOUCHER''': see [[Transaction_Vouchers#Usage_Example|Transaction Voucher]].
|-
|'''''Constraints''''':
|-
|
:''Optional'': this field is optional.
|-
|
|}
====Delete shares==== 
The asset issuer can delete assets shares, the procedure is very simple:
#Under '''''My Assets''''', find the asset you wish to delete shares.
#Click ''Delete Shares''.
#Complete the fields as follows.


[[File:DeleteShares.png|border|thumb|400px|left]]


{|
|-
|'''QUANTITY''': specify the amount of shares you wish to delete.
|-
|'''''Constraints''''':
|-
|
:''Mandatory'': this field is mandatory.
|-
|'''COMMENT''': you can attach a brief commentary to the transfer. when marking "Add a message"
|-
|'''''Constraints''''':
|-
|
:''Optional'': this field is optional.
|-
|
:''Characters allowed'': it can contain any Unicode characters but should be URL-encoded. Maximum length of 1000 characters.
|-
|'''FEE''': set the fee you are willing to pay for the transaction.
|-
|'''''Constraints''''':
|-
|
:''Mandatory'': this field is mandatory.
|-
|
:''Limits'': there is no upper limit. However the minimum fee is 0.01 tokens, see [[Create_Transaction#Create Transaction Request|fees]].
|-
|'''SECRET PASSPHRASE''': enter '''''your''''' passphrase.
|-
|'''''Constraints''''':
|-
|
:''Mandatory'': this field is mandatory.
|
|-
|'''VOUCHER''': see [[Transaction_Vouchers#Usage_Example|Transaction Voucher]].
|-
|'''''Constraints''''':
|-
|
:''Optional'': this field is optional.
|-
|
|}

====Increase shares==== 
The asset issuer can increase assets shares, the procedure is very simple:
#Under '''''My Assets''''', find the asset you wish to increase shares.
#Click ''Increase Shares''.
#Complete the fields as follows.


[[File:IncreaseShares.png|border|thumb|400px|left]]


{|
|-
|'''QUANTITY''': specify the amount of shares you wish to increase.
|-
|'''''Constraints''''':
|-
|
:''Mandatory'': this field is mandatory.
|-
|'''COMMENT''': you can attach a brief commentary to the transfer. when marking "Add a message"
|-
|'''''Constraints''''':
|-
|
:''Optional'': this field is optional.
|-
|
:''Characters allowed'': it can contain any Unicode characters but should be URL-encoded. Maximum length of 1000 characters.
|-
|'''FEE''': set the fee you are willing to pay for the transaction.
|-
|'''''Constraints''''':
|-
|
:''Mandatory'': this field is mandatory.
|-
|
:''Limits'': there is no upper limit. However the minimum fee is 0.01 tokens, see [[Create_Transaction#Create Transaction Request|fees]].
|-
|'''SECRET PASSPHRASE''': enter '''''your''''' passphrase.
|-
|'''''Constraints''''':
|-
|
:''Mandatory'': this field is mandatory.
|
|-
|'''VOUCHER''': see [[Transaction_Vouchers#Usage_Example|Transaction Voucher]].
|-
|'''''Constraints''''':
|-
|
:''Optional'': this field is optional.
|-
|
|}

===Open Orders menu=== 
Under this menu you can see all your orders that are currently open.


[[File:Open_orders_menu.PNG|none|border|thumb|630px]]


'''What to keep in mind:'''
* You can cancel any order you made. ''However''
** The process is not instantaneous. Your cancel order is broadcasted to the network, your order may get accepted before you can manage to cancel it.
** The process of canceling an order is a transaction, meaning it involves a fee of 0.01 Tokens, see: [[Create_Transaction#Create Transaction Request|fees]].
** An order in the process of being canceled will appear in red under your Open Orders menu.
* In this image, the sell order I am willing to sell the shares (5 IGnis).
** The TESTAPPROV asset refers to an asset named TESTAPPROV, whose ID is 14572747084550678873, and that has been created by me.

===Issue Asset menu=== 
Under this menu, you can issue assets yourself. These will be publicly available on the Asset Exchange where they can be traded for Ignis and vice-versa.


The following window will pop up:


'''NOTE: as the warning mentions, when you issue your asset you will not be able to modify any of the fields, ever. The reason why it is imperative to make sure all the information entered is correct.'''
[[File:Issue_asset.PNG|border|thumb|400px|left]]


{|
|-
|'''ASSET NAME''': the name of the asset you intend to issue. This is also the name announced to other traders, allowing them to find this asset.
|-
|'''''Constraints''''':
|-
|
:''Mandatory'': you cannot issue an unnamed asset.
|-
|
:''Names are non-unique'': multiple assets can be issued with the same name.
:'''Note''': for this reason, pay attention to what you are buying or selling!
|-
|
:''Length'': between 3 and 10 characters.
|-
|
:''Characters allowed'': uppercase letters, lowercase letters, and numbers.
|-
|'''DESCRIPTION''': in this field, you can briefly describe the asset being issued.
|-
|'''''Constraints''''':
|-
|
:''Mandatory'': this field is mandatory.
|-
|
:''Characters allowed'': it can contain any Unicode characters but should be URL-encoded. Maximum length of 1000 characters.
|-
|'''QUANTITY''': specify how many tokens you intend to create.
|-
|'''''Constraints''''':
|-
|
:''Mandatory'': this field is mandatory.
|-
|
:''Must be a whole number''
|-
|'''DECIMALS''': this field defines the divisibility of the token. As an example, by defining 2 decimals, the minimum amount of tokens you can sell or buy is 0.01.
|-
|'''''Constraints''''':
|-
|
:''Mandatory'': this field is mandatory.
|-
|
:''Limits'': you can set from 0 to, at most, 8 decimals. The latter corresponds to the minimum of 0.00000001 tokens.
|-
|'''FEE''': define the fee related to issuing the asset. To avoid spam on the Asset Exchange, the IGNIS equivalent of 100 ARDR are the minimum required to issue an asset.
|-
|'''''Constraints''''':
|-
|
:''Mandatory'': this field is mandatory.
|-
|'''DEADLINE''': how long you are willing to wait before the request gets automatically deleted.
|-
|'''''Constraints''''':
|-
|
:''Mandatory'': this field is mandatory.
|-
|
:''Expressed in hours''
|-
|'''PASSPHRASE''': the asset belongs to the person issuing it. Therefore it is required to enter your own passphrase. It will not be broadcasted.
|-
|
:'''Note''': assets belong to the person that creates them, but they can be bought, sold, and transferred.
|-
|'''''Constraints''''':
|-
|
:''Mandatory'': this field is mandatory.
|-
|-
|'''VOUCHER''': see [[Transaction_Vouchers#Usage_Example|Transaction Voucher]].
|-
|'''''Constraints''''':
|-
|
:''Optional'': this field is optional.
|-
|
|}

==FAQ== 
See more:
* [[Asset_Exchange#Asset_Exchange_Operations|API Asset Exchange Operations]]

==External Links== 
* [http://nxter.org/how-to-use-nxt-asset-exchange-tutorial/ Nxter Magazine: How to Use the Nxt Asset Exchange]
* [https://www.youtube.com/watch?v=0ZtFYEeHk8o Asset Exchange Introductory Video]
</translate>

Asset control

2021-04-15T17:04:38Z

Almonte:

<languages />
<translate>
{{#seo:
|title=Asset control
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, Asset control
|description=Asset control feature allows imposing phasing restrictions to all transactions involving a given asset
}}
__TOC__
[[Category:Features]]
==Description== 
Similar to [[Account control|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 a 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 when using the "By Property" voting model.

==Setting Asset Control== 
Only the asset issuer can set asset control. From the Asset Exchange page header locate the asset control ''Setup'' to load the asset control setup dialog.
Also, use this dialog to clear asset control.


[[File:asset.control.setup.png|||figure 1]]


Use the ''View'' button to view a JSON representation of the asset control data


[[File:asset.control.view.png|||figure 2]]

==Using Asset Control== 
For every transaction which involves the controlled asset, a new widget will show up on the create transaction dialog to allow the user to set the phasing height for the transaction.
The approval model set by the asset control has to be approved before this height for the transaction to execute.


[[File:asset.control.transaction.png|||figure 3]]
</translate>

Arbitrary messages

2021-04-15T17:04:03Z

Almonte:

<languages />
<translate>

{{#seo:
|title=Arbitrary messages
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, Arbitrary messages
|description=Messaging system of the Ardor blockchain. It allows the transmission of data messages up to 1000 bytes in length from any account to any other account.
}}
[[Category:Features]]
__TOC__

==Description== 
Transmission of data messages up to 1000 bytes in length from any account to any other account. In Ardor this feature is restricted for child chains such as Ignis. It is also possible to send messages encrypted, allowing a third party to decrypt the message using a unique shared key for each message.

==Details== 
Arbitrary messages are limited only by length. Any string can be transmitted, using any data structure or form of data encryption. Encoding, decoding, linked messages, data structures, and more can be implemented by any application that uses the system. For instance, it can be implemented groups ids, sequencing, message and correlation ids linked to the transaction, offsets, and so on to have a complete messaging system. Parsing of the messages is part of the end-party distributed applications.


Each arbitrary message has a shared key that allows a third party to decrypt the messages that were encrypted.


The base implementation allows for the transmission of simple, unencrypted text messages between accounts, but since the messages are truly "arbitrary" the range of possible applications is vast. Secure messaging, torrent applications, voting systems, data storage systems, and even simple distributed applications have been suggested.

==How To== 
* [[Messages#Arbitrary_Message_System_Operations|High-level API calls for implementing arbitrary messages]]

===Sending a message=== 
#When sending a message using your local node the Ardor software must be running, then browse to http://127.0.0.1:27876/ and log in to your account providing your passphrase. It is also possible to connect to the [[Testnet|testnet]] or to the [https://testardor.jelurida testnet node of Jelurida] to test this feature
#Select a chain that has the messages feature enable (ie: Ignis) [[File:Arbitrary_messages_cogwheel.png|200px|border|none]]
#*The "Messages" section and a "Send Message" button on top will appear. Click on the "Send Message" button and a modal will pop-up [[File:Arbitrary_messages_2.png|300px|border|none]]
#Complete the modal form shown below with the following entries: [[File:Arbitrary_messages_3.png|450px|border|none]]
#*''Recipient'': The account that will receive the message
#*''Message'': The message you would like to send (up to 1000 characters)
#*'''Note:''': This message is encrypted by default, which means the recipient must know how to decrypt the message once they receive it. To submit the message as plain text, you must manually select this option. The “messaging” feature is simple and open-ended on purpose to allow other developers to create more advanced tools and applications.
#*''Fee'': Expressed in child chain tokens such as Ignis. Enter the fee you are willing to pay for this transaction. The minimum fee in child chain tokens must be equal to 0.01 ARDR (see [https://www.jelurida.com/sites/default/files/ArdorFees.pdf Fee Structures]).
#*''Passphrase'': Your account passphrase.
#Click "Submit"
#*The server will respond with the box "Your message has been sent". [[File:Arbitrary_messages_4.png|450px|border|none]] Afterwards, the transaction will be shown in the [[Ardor_client_interface#My_Transactions|"My Transactions section of the user interface"]]
#*When the transaction is confirmed, it will appear in the "transactions" block in your client interface [[File:Arbitrary_messages_5.png|650px|border|none]]

===Sending an encrypted message=== 
#Follow the instructions 1 and 2 from the [[Arbitrary_messages#Sending_a_message|previous section]] above.
#Complete the modal form shown below with the following entries: [[File:Arbitrary_messages_6.png|450px|border|none]]
#*''Recipient'': The account that will receive the message
#*''Message'': The message you would like to send (up to 1000 characters)
#*'''Encrypt message:''': Check this box. The sender and recipient accounts must have published their [[Faq#What_is_my_public_key|public keys]] before this operation.
#*''Fee'': Expressed in child chain tokens such as Ignis. Enter the fee you are willing to pay for this transaction. The minimum fee in child chain tokens must be equal to 0.01 ARDR (see [https://www.jelurida.com/sites/default/files/ArdorFees.pdf Fee Structures]).
#*''Passphrase'': Your account passphrase.
#Click "Submit"
#*The UI will respond with the box "Your message has been sent". [[File:Arbitrary_messages_4.png|450px|border|none]] Afterwards, the transaction will be shown in the [[Ardor_client_interface#My_Transactions|"My Transactions section of the user interface"]]
#*When the transaction is confirmed, it will appear in the "transactions" block in your client interface. Clicking on it will open a new modal with the transaction's details [[File:Arbitrary_messages_7.png|650px|border|none]]

====Decrypting a message==== 
The message can be decrypted either using the sender or recipient's private key or the shared key provided with each arbitrary message transaction. For instance, using the user interface:


[[File:Arbitrary_messages_7.5.png|650px|border|none]]


When providing the private key of the sender and clicking on the "Decrypt" button, the encrypted message and the shared key is shown:


[[File:Arbitrary_messages_8.png|650px|border|none]]


The shared key is also a way to share the content of the message without revealing neither the sender nor the recipient's private keys. Hence, a third party can have access to the message. The message can be decrypted using this method using the UI or the API as the following picture shows:


[[File:Arbitrary_messages_9.png|650px|border|none]]

==External Links== 
* [http://nxter.org/nxt-core-arbitrary-messages/ Nxter Magazine: Nxt Arbitrary Messages]
[[Category:Features]]
</translate>

Alias system

2021-04-15T17:02:48Z

Almonte:

<languages />
<translate>
{{#seo:
|title=Alias system
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, Alias system, Alias system feature
|description=Alias system feature allows one piece of text to be substituted for another so that keywords or keyphrases can be used to represent other things.
}}
[[Category:Features]]
__TOC__
==Description== 
The Alias System feature of Ardor essentially allows one piece of text to be substituted for another so that keywords or keyphrases can be used to represent other things – names, telephone numbers, physical addresses, web sites, account numbers, email addresses, product SKU codes... almost anything you can think of. The types are URI, Account, or Other


For example, you could ask Ardor to associate "search" with "www.google.com". Once this is done, all you have to do to get to Google is type "uri:search" into an Ardor-capable browser, and it will translate your request into one for "www.google.com".


Immediate applications are simple: you can create an easy-to-remember alias for your Ardor account number, for example. But since the Alias System is open-ended, it can be used to implement a decentralized DNS system, shopping cart applications, and more.


Creating aliases is


# A user sends a transaction that states "ThisText = ThatText"
# If the alias is to be changed, just send another transaction with a new definition. Only the account that created an alias can change it.

==Details== 
The alias can be any string of latin-character numbers and letters. The address can be anything like:
*"173.194.112.174" (an IPv4 address)
*"2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d" (an IPv6 address)
*"mydomain.com/secretpage.php?parameter=value" (a URI)
*"johnsmith@matrix.com"
*"tel:+44-20-8123-4567"
*...or even "bitcoin:1BTCorgHwCg6u2YSAWKgS17qUad6kHmtQW".


There are 2 main ways to use Ardor aliases without having to rely on third-party plugins for your browser:


# '''Server-side. ''' A web server analyses the Ardor blockchain and replaces "ardor-links" with corresponding addresses before sending HTML documents to users.
# '''Client-side. ''' A web browser runs javascript code that connects to Ardor bootstrapping nodes and replaces "Ardor-links" with their addresses. This requires embedding a small script that is executed in an "onload" event. The script will do all the work via CORS, JSON, or other techniques.

==Alias Operations== 
Aliases can be transferred for a 0.1 Ardor fee.


An alias can be sold to either specific Ardor Accounts or the general public.
To sell an alias, you can set the price to sell for every alias.

===Create Alias=== 
Go to 'Aliases' in your client.
First click on 'Aliases' in the wallet, then click on 'Register Alias':


[[File:Aliases_001.png|none|border|600px|Figure 1]]


Here you can choose to use the alias for different purposes: By choosing 'Account', you can link to an Ardor account. If you choose 'URI' you can e.g. link any website with your alias. The third option 'Other' allows you to insert any text you like.


Please note, aliases are unique. There can never be two aliases with the same name. Aliases are not case sensitive.


Your new alias will now be listed on the 'Aliases' page.


You can either transfer your alias to any person or sell it to any person for a specific amount.

===Edit Alias=== 
You can at any time edit the content of the alias. Just click 'Edit' on the Alias tab. You will see this panel to input the specific information:


[[File:Aliases_002.png|none|border|600px|Figure 2]]

===Transfer Alias=== 
Click 'Transfer' in the Alias panel and input the Ardor Account where you want to transfer your alias:


[[File:Aliases_003.png|none|border|600px|Figure 3]]

===Sell Alias=== 
You can either sell the Alias to a specific Ardor Account or the public. Specific Ardor accounts will see an offer to buy the alias.

====Sell alias to any specific Ardor account==== 
Sell it by clicking on 'Sell'


[[File:Aliases_004.png|none|border|600px|Figure 4]]


After submitting the order, you should see:


[[File:Aliases_005.png|none|border|600px|Figure 5]]


You can cancel the sell offer anytime before the partner has accepted it. To change the amount of the sell order, you can create a new sell order.

====Sell alias to the public==== 
This way every user can see your offer and buy it for the price you entered.


[[File:Aliases_006.png|none|border|600px|Figure 6]]


Input the price. After submitting the order, you should see


[[File:Aliases_007.png|none|border|600px|Figure 7]]


Every user can now buy your alias. Both submitting a sell order and buying an alias incur a transaction fee.

===Buy public Alias=== 
There is no way to browse all aliases up for sale within the Ardor network. Just try to register the alias you want. If it has already been registered but is up for sale, you can see the offer if you search for it.


[[File:Aliases_008.png|none|border|600px|Figure 8]]

==External Links== 
* [http://nxter.org/nxt-core-alias-system/ Nxter Magazine: The Nxt Alias System]
</translate>

Account Properties

2021-04-15T17:00:33Z

Almonte:

<languages />
<translate>
{{#seo:
|title=Account Properties
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, account Properties, account Properties feature
|description=Account Properties feature gives Ardor users the ability to permanently ‘tag’ any Ardor account with a small amount of data.
}}
[[Category:Features]]
__TOC__
== Introduction == 


Account properties give Ardor users the ability to permanently ‘tag’ any Ardor account with a small amount of data. These properties tags can be used to provide meta-information about an account: for example
* A seller can tag buyer accounts that he has sold to in the past.
* An exchange can tag already identified user accounts for providing KYC and AML features


These properties are also used by the [[Account Monitor]] feature and for the [[Phasing (f)#Vote_By_Property|By-property phasing]]

== How to set an account property == 


{|
|-
|1. Visit http://localhost:27876/ (or https://localhost:27876/ if you enabled SSL) and log in.
|-
|2. Click on ''Account Properties'' under "Dashboard" in the left sidebar:


[[File:Account Properties1.png|none|border|Figure 1]]


|-
|3. A window showing the current Account Properties for your account will appear. Click the 'Set' tab in the top right:


[[File:Account Properties2.png|none|border||600px|Figure 2]]


|-
|4. A form allowing you to set an Account Property will appear. From here you can specify the account you want to set the property on, the name of the property, and the value for that property:


[[File:Account Properties3.png|none|border|Figure 3]]


|}
</translate>

Account Monitor

2021-04-15T16:59:52Z

Almonte:

<languages />
{{#seo:
|title= Account Monitor
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, account Monitor, account Monitor feature
|description=Account Monitor feature allows transferring IGNIS or other child chain tokens, ASSET, or CURRENCY from a funding account to recipient accounts when the amount held by the recipient account drops below a set threshold.
}}
[[Category:Features]]
<translate>
__TOC__
== Introduction == 
Server-side component which automatically will transfer IGNIS or other child chain tokens, ASSET or CURRENCY from a funding account to recipient accounts when the amount held by the recipient account drops below a set threshold. The transfer will not be done until the current block height is greater than equal to the block height of the last transfer plus the interval.


The funding account is identified by your secret phrase.


The recipient accounts are identified by specified [[Account Properties]]. Each account that has this property set by the funding account will be monitored for changes.


This feature is useful to make sure the account owners always poses enough tokens to transact.

Funding monitors, like other similar local node tools like standby shufflers or bundlers, are not persisted across node reboots. Check the [[Node_Processes_Configuration|Processes]] feature for an easy-to-use and secure tool to help you with recovering the configuration upon node restart.

== How to start an account monitor == 


1. Visit http://localhost:27876/ (or https://localhost:27876/ if you enabled SSL) and log in.


2. Click on the cogwheel in the top right and select "Monitors":


[[File:Account_Monitor.png|caption|none|border|Figure 1]]


3. A window showing the current Account Monitors for your account will appear. Click the "Start Monitor" button in the top right:


[[File:Account_Monitor2.png|none|border|600px|Figure 2]]


4. A form allowing you to set the specifications of the Account Monitor will appear. From here you can specify the account you want to set the property on, the name of the property, and the value for that property:


[[File:Account_Monitor3.png|none|border|600px|Figure 3]]


:'''''Fields to complete'''''


: '''CONTROL PROPERTY''': The account property set by the funding account to look for.
: '''AMOUNT''': Amount to transfer.
: '''THRESHOLD''': Minimal amount of chain tokens in account before transfer happens.
: '''INTERVAL''': The number of blocks between transfers.
: '''FEE RATIO''': The fee ratio for coin exchange conversions.
: '''PASSPHRASE''': The secret phrase of your account.
</translate>

Account Leasing

2021-04-15T16:58:41Z

Almonte:

<languages />
{{#seo:
|title= Account Leasing
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, account Leasing, account Leasing feature
|description=The Account Leasing feature allows a user to lease its forging power to another account for a fixed period of time
}}
[[Category: Features]]
<translate>
== What is Account Leasing == 
Account Leasing allows a user to lease its forging power to another account for a fixed period of time. This feature enables the creation of forging pools, where the forging power of multiple users is combined to increase the chance of generating a block. Account leasing is also relevant if a user wants to take part in the forging process without having to keep a node running 24/7.

== How to lease your balance == 


[[File:Balance1.png|thumb|right|figure 1]]
[[File:Account_leasing1.png|thumb|right|figure 2]]
[[File:Account_leasing_details1.png|thumb|right|figure 3]]


{|
|-
|1. Visit http://localhost:27876/ (or https://localhost:27876/ if you enabled SSL) and log in.
|-
|2. Click on ''more info'' under the tile showing your balance. (figure 1)
|-
|3. A window showing the details regarding your account will appear. Click the ''Account leasing'' tab. (figure 2)
|-
|4. Click ''lease your balance to another account''.
|-
|5. The form allowing you to lease your balance will appear. (figure 3)
|-
|
:'''''Fields to complete'''''
|-
|
: '''RECIPIENT''': address of the account you wish to lease your balance to.
: '''PERIOD''': for how long your balance will be leased. Expressed in blocks (1440 blocks is roughly 24h). Between 1440 and 65535. You cannot cancel a leasing once submitted.
: '''FEE''': the fee you wish to pay. The minimum is 1 ARDR.
: '''SECRET PHRASE''': the passphrase of your account.
|-
|6. Click ''Lease Balance''.
|}

== How does it work == 
When you lease your balance, you are essentially giving your forging power to another account. It is important to clarify certain points:


:''Your balance never leaves your account''
::* Your funds are still on your account after you lease them. They are still available for use: you can spend them, receive more, etc. The only thing given is your forging power, by consequence while your balance is leased, you will not be able to forge on your own.
::* If your funds vary, so will do your forging power. If you lease 1000 ARDR to a forging pool and the next day you spend half of them, you are now leasing only 500 ARDR.
::* This also means that the person you lease your balance to will not be able to do anything with your funds. They are still under your control.


:''You cannot cancel a lease''
::* This is important, so make sure you keep this in mind when you set the leasing period. When the leasing period expires, the forging power will return to you automatically. Not before.


:''You have control over your funds, not the rewards of block generation''
::* If you decide to lease your balance to a forging pool or a wealthy owner of NXT, there is no guarantee you will be paid accordingly when (if) a block is generated. So, make sure you lease your forging power to someone you trust will pay your share.

== Uses of account leasing == 
This feature introduces two main benefits.


Firstly, you no longer need to leave your node running 24/7 to take part in the forging process. You can lease your balance to someone that does.


'''''NOTE:''' it is still highly suggested to run as many nodes as possible. It strengthens the stability and the security of the network.''


Secondly, it allows the formation of ''forging pools'' where multiple users can combine their forging power to increase their chance of forging a block. Any ARDR forged is not automatically sent to your account, it's up to the pool owner what to do with it. For more details, visit [https://nxtwiki.org/wiki/Forging_Pool the page about forging pools from Nxt].
</translate>

Account control

2021-04-15T16:57:28Z

Almonte:

<languages />
<translate>
{{#seo:
|title=Account Control
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, account control, account control feature
|description=Explanation of the Account Control feature: Any account can be restricted to only be allowed to issue phased transactions subject to a specific voting model.
}}
[[Category:Features]]
__TOC__
==Description== 
Any account can be restricted to only be allowed to issue phased transactions subject to a specific voting model. This is achieved by the account submitting a setPhasingOnly transaction using
the setPhasingOnlyControl API. The getPhasingOnlyControl API can be used to retrieve the status of an account phasing control, and getAllPhasingOnlyControls to get all accounts subject to phasing control with their respective restrictions. The account control feature relies on the [[Phasing (f)|Phasing]] feature and is available in both Nxt and Ardor.


In Ardor, 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 that 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. Currently, the UI only supports setting max fee for the current chain.


These features present some interesting account usage scenarios:
* Multi-signature account <ref>For a detailed step-by-step guide, you can have a look at the advance guide [[Emulating_Multi_Signature_Accounts_on_the_Blockchain|How to use the phasing feature to emulate multisig accounts in the Ardor platform]]</ref>
* Tagging an account as a "savings" account, with no ability to send tokens
* Using a locked account as an "escrow" account
* limiting the ability to transfer assets, aliases, or other entities from an account

==Setting Account Control== 
To set account control on your account, click on the "Account Balance" tile.
[[File:Account.Control.Balance.png|figure 1|none|border|200px]]


Then select the "Account Control" tab then click on the "Setup Mandatory Approval" link.
[[File:Account.Control.Approval.Link.png|figure 2|none|border|400px]]


This will load the "Mandatory Approval" dialog.


In Ardor, select the "Control Approval Model" from the available approval models defined in the [[Composite_phasing#Setting_up_an_Approval_Model phasing|Approval Models]] page.


The rest of the parameters are explained using balloon text on the dialog. Use the same method to remove the account control from an account that is under account control, account control removal transaction is subject to the same account control restrictions.


[[File:account.control.png|figure 3|none|border|600px]]

==Using Account Control== 
When creating a transaction from an account that is under account control. The additional widget appears on the transaction dialog. It allows the user to select the specific phasing height and links to the account control information.


[[File:account.control.on.create.transaction.png|||figure 4|none|border|600px]]


''Note: Some exchanges do not accept phased transactions. In such cases, the approach would be to transfer first into a non-controlled account ("Hot Wallet"), and from there transfer to the exchange.''
</translate>

API

2021-04-15T16:56:27Z

Almonte:

<languages />
{{#seo:
|title=Ardordocs - Ardor API
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, API, API documentation, Application program interface
|description=Description and examples of the API of Ardor.
}}
__TOC__

<translate>
==Description== 
The Ardor API allows interaction with Ardor nodes using HTTP requests to port 27876. Most HTTP requests can use either the GET or POST methods, but some API calls accept only the POST method for security reasons. Responses are returned as JSON objects.


If you want to interact with an [[Testnet|Ardor testnet local node]], please be aware that the port for sending the HTTP requests is different, you should use 26876 instead of the mainnet one 27876.


Each API call is documented ([[All_Operations_index|see the full API list]]), with definitions given for HTTP request parameters and JSON response fields, followed by an example:
*The JSON response fields are each followed by one of ''S'' for string, ''A'' for array, ''O'' for object, ''N'' for number or ''B'' for boolean.
*In the examples, the Ardor node is represented as ''localhost'' and requests and responses are formatted for easy reading; line breaks and spaces are not actually used except in some parameter values. All requests are in URL format which implies the HTTP GET method. When GET is allowed, the URL can be entered into a browser URL field but proper URL encoding is usually required (e.g., spaces in a parameter value must be replaced by ''+'' or ''%20''). Otherwise, the URL should be used as a guide to preparing an HTTP POST request using cURL, for example.


All API calls can be viewed and tested at http://localhost:27876/test while the local server node is running. For specific API calls, use 'http://localhost:27876/test?requestType='''specificRequestType''''


There are some [[Sample_Java_Programs|Sample Java Programs]], which demonstrate how to perform operations such as calculating the best bundling fee for child chain transactions, the use of APIs locally without relying on a remote node among others.


This document corresponds to Ardor Software Version {{NRSVersion}}: [https://www.jelurida.com/sites/default/files/Ardor-Developers-Cheat-Sheet.pdf Download Ardor Developers Cheat Sheet]
<accordion parent="accordion" heading="Ardor developers cheat sheet">
'''Java Conversion Functions'''


{| class="wikitable"
|-
! '''From'''
! '''To'''
! '''Code'''
|-
| ''Secret Phrase''
| ''Public Key''
| <code>Crypto.getPublicKey(String s)</code>
|-
| ''Public Key''
| ''Numeric ID''
| <code>Account.getId(byte[] pk)</code>
|-
| ''Numeric ID''
| ''Public Key''
| <code>Account.getPublicKey(long id)</code>
|-
| ''Numeric ID''
| ''String ID''
| <code>Long.toUnsignedString(long id)</code>
|-
| ''String ID''
| ''Numeric ID''
| <code>Convert.parseUnsignedLong(String s)</code>
|-
| ''Numeric ID''
| ''RS Format''
| <code>Convert.rsAccount(id)</code>
|-
| ''RS Format or String ID''
| ''Numeric ID''
| <code>Convert.parseAccountId(String s)</code>
|-
| ''byte[]''
| ''Hex String''
| <code>Convert.toHexString(b)</code>
|-
| ''Hex String''
| ''byte[]''
| <code>Convert.parseHexString(hex)</code>
|-
| ''Full Hash''
| ''ID''
| <code>Convert.fullHashToId(byte[] b)</code>
|-
| ''Epoch Time''
| ''Time Millis''
| <code>Convert.fromEpochTime(int t)</code>
|-
| ''Time Millis''
| ''Epoch Time''
| <code>Convert.toEpochTime(long t)</code>
|-
| ''String''
| ''byte[]''
| <code>Convert.toString(byte[] b, Boolean isText)</code>
|-
| ''byte[]''
| ''String''
| <code>Convert.toBytes(String s, boolean isText)</code>
|}


'''Java Common Operations'''


{| class="wikitable"
|-
! '''Operation'''
! '''Code'''
! '''Return'''
|-
| ''Sign''
| <code>Crypto.sign(byte[] message, String secretPhrase)</code>
| <code>byte[]</code>
|-
| ''Verify''
| <code>Crypto.verify(byte[] signature, byte[] message, byte[] publicKey)</code>
| <code>Boolean</code>
|-
| ''Encrypt''
| <code>Account.encryptTo(byte[] publicKey, byte[] data, String senderSecretPhrase, boolean compress)</code>
| <code>EncryptedData</code>
|-
| ''Decrypt''
| <code>Account.decryptFrom(EncryptedData encryptedData, String recipientSecretPhrase, boolean uncompress)</code>
| <code>byte[]</code>
|-
| ''Sha256''
| <code>Crypto.sha256().digest(byte[] b)</code>
| <code>byte[]</code>
|-
| ''Compress''
| <code>Convert.compress(byte[] bytes)</code>
| <code>byte[]</code>
|-
| ''Uncompress''
| <code>Convert.uncompress(byte[] bytes)</code>
| <code>byte[]</code>
|}


'''Useful Constants''' see <code>nxt.Constants</code> class


'''Reading from properties file''' <code>Nxt.getBooleanProperty(), Nxt.getIntProperty(), Nxt.getStringProperty(), Nxt.getStringListProperty()</code>


'''Javascript Conversion Functions'''


{| class="wikitable"
|-
! '''From'''
! '''To'''
! '''Code'''
|-
| ''Secret Phrase''
| ''Public Key''
| <code>NRS.getPublicKey(converters.stringToHexString(secretPhrase))</code>
|-
| ''Public Key''
| ''String ID''
| <code>NRS.getAccountIdFromPublicKey(publicKeyHexString)</code>
|-
| ''String ID''
| ''Public Key''
| <code>NRS.getPublicKey(id, true)</code>
|-
| ''String ID''
| ''RS Format''
| <code>NRS.convertNumericToRSAccountFormat(id)</code>
|-
| ''byte[]''
| ''Hex String''
| <code>converters.byteArrayToHexString(bytes)</code>
|-
| ''Hex String''
| ''byte[]''
| <code>converters.hexStringToByteArray(hex)</code>
|-
| ''Full Hash''
| ''ID''
| <code>NRS.fullHashToId(fullHash)</code>
|-
| ''Epoch Time''
| ''Time Millis''
| <code>NRS.fromEpochTime(epochTime)</code>
|-
| ''Time Millis''
| ''Epoch Time''
| <code>NRS.toEpochTime(time)</code>
|-
| ''String''
| ''byte[]''
| <code>NRS.getUtf8Bytes(String), converters.stringToByteArray(String)</code>
|-
| ''byte[]''
| ''String''
| <code>converters.byteArrayToString(bytes)</code>
|-
| ''NQT''
| ''Chain tokens''
| <code>NRS.intToFloat(amountNQT, decimals)</code>
|-
| ''NQT''
| ''formatted''
| <code>NRS.formatQuantity(amountNQT, decimals) – many different variants</code>
|-
| ''Chain tokens''
| ''NQT''
| <code>NRS.floatToInt(amountNXT, decimals)</code>
|}


'''Javascript Common Operations'''


{| class="wikitable"
|-
! '''Operation'''
! '''Code'''
! '''Return'''
|-
| ''Sign''
| <code>NRS.signBytes(hexStringMessage, secretPhrase)</code>
| <code>Hex String</code>
|-
| ''Verify''
| <code>NRS.verifySignature(hexSignature, hexStringMessage, hexPublicKey, callback)</code>
| <code>boolean</code>
|-
| ''Encrypt''
| <code>NRS.encryptNote(), NRS.encryptData() – see test.nrs.encryption.js</code>
| <code>encrypted message, nonce</code>
|-
| ''Decrypt''
| <code>NRS.decryptNote(), NRS.decryptData() - see test.nrs.encryption.js</code>
| <code>Decrypted message, shared key</code>
|-
| ''Sha256''
| <code>CryptoJS.algo.SHA256.create(), update(), finalize()</code>
| <code>word array</code>
|-
| ''Compress''
| <code>pako.gzip(new Uint8Array(bytes))</code>
| <code>byte array</code>
|-
| ''Uncompress''
| <code>pako.inflate(new Uint8Array(bytes))</code>
| <code>byte array</code>
|}


'''Useful Constants''' see <code>nrs.constants.js</code> class


'''Reading account settings'''
<code>NRS.settings[<setting name>]</code> - account specific
<code>NRS.mobileSettings[<setting name>]</code> - device specific
</accordion>

==General Notes== 
===Flexible Account IDs===
All API requests that require an account ID accept either an account number or the corresponding [[RS_Address_Format|Reed-Solomon address]].

===Quantity Units amountNQT, QNT and priceNQTPer(Share, Coin, Unit, etc.)=== 
The Ardor system is defined relative to a whole unit of the holding being transactioned. The parent chain ARDOR has a currency ARDR used to quantify value of forging in the system. Like all currencies, ARDR circulates in the system, moving from one user to another by transfers. Also, a small fee is required for every transaction, including those in which no ARDR is transferred, such as simple messages when using a child chain. This fee goes to the owner of the node that forges (generates) the new block containing the transaction that is accepted onto the blockchain, and the bundlers get the child chain fees and pay the ARDR fees to the forgers.


One billion ARDR were distributed during the snapshot, and no new ARDR will ever be created. ARDR is divisible to eight decimal places. Yet internally, the currency is still stored in integer form in units of amountNQT, where 1 ARDR = 108 amountNQT. All parameters and fields in the API involving a quantity of a token are denominated in units of amountNQT, for example ''feeNQT''.


The Ardor system can be thought of as an asset owned by all who possess ARDR. In this sense, ARDR quantifies ownership of or stake in the system. Stakeholders are entitled to forge blocks and collect transaction fees in proportion to the amount of ARDR they possess.


Other assets can be created within ARDR using [[Asset_Exchange#Issue_Asset|Issue Asset]] within a child chain (eg Ignis). The issuer must specify the number of decimal places to use in quantifying the asset, and the amount of the asset to create in generic units of QNT or Quant. Quantities of assets are stored internally as integers in units of QNT, and assets are priced at priceNQTper(Share, Coin, Unit, etc.)


For example, an ABTC (it represents Bitcoin) asset is divisible to eight decimal places, like the original bitcoin (BTC). Therefore a QNT of ABTC is equivalent to a Satoshi (10-8 BTC). To place an order to sell 25,000,000 QNT of the ABTC asset at a price of 20,000 priceNQTperShare, use the API Call [[Asset_Exchange#Place_Order|Place Order]] with ''requestType''=''placeAskOrder'', ''quantityQNT''=25000000 and ''priceNQTPerShare''=20000 in the chain Ignis. If the entire quantity is sold on the Asset Exchange, the seller will receive 500,000,000,000 NQT (''quantityQNT'' * ''priceNQT'') from the buyer(s). This trade corresponds to selling 0.25 ABTC for 5,000 IGNIS, which is how the trade appears in the [[Ardor_client_interface|NRS client]]. In this case, the price of 20,000 in priceNQTperShare is also the price in Ignis per ABTC, since both ABTC and Ignis are divisible to eight decimal places.


Currencies in the Ardor [[Monetary_System#Monetary_System_Operations|Monetary System]] are a special kind of asset with properties and exchange methods suitable for currencies. Concerning quantities, exchange rates, and decimal places, the Monetary System API calls use amountNQT, QNT, and priceNQTPer(Share, Coin, Unit, etc.) in the same way as assets.

===Creating Unsigned Transactions=== 
All API requests that create a new transaction will accept either a ''secretPhrase'' or a ''publicKey'' parameter:
*If ''secretPhrase'' is supplied, a transaction is created, signed at the server, and broadcast by the server as usual.
*If only a ''publicKey'' parameter is supplied as a 64-digit (32-byte) hex string, the transaction will be prepared by the server and returned in the JSON response as ''transactionJSON'' without a signature. This JSON object along with ''secretPhrase'' can then be supplied to [[Transactions#Sign_Transaction|Sign Transaction]] as ''unsignedTransactionJSON'' and the resulting signed ''transactionJSON'' can then be supplied to [[Transactions#Broadcast_Transaction|Broadcast Transaction]]. This sequence allows for offline signing of transactions so that ''secretPhrase'' never needs to be exposed.
*''unsignedTransactionBytes'' may be used instead of unsigned ''transactionJSON'' when there is no encrypted message. Messages to be encrypted require the ''secretPhrase'' for encryption and so cannot be included in ''unsignedTransactionBytes''.

===Escrow Operations=== 
All API requests that create a new transaction will accept an optional ''referencedTransactionFullHash'' parameter which creates a chained transaction, meaning that the new transaction cannot be confirmed unless the referenced transaction is also confirmed. This feature allows a simple way of transaction escrow:
*Alice prepares and signs a transaction A, but doesn't broadcast it by setting the ''broadcast'' parameter to ''false''. She sends to Bob the ''unsignedTransactionBytes'', the ''fullHash'' of the transaction, and the ''signatureHash''. All of those are included in the JSON returned by the API request. (Warning: make sure not to send the signed ''transactionBytes'', or the ''signature'' itself, as then Bob can just broadcast transaction A himself).
*Bob prepares, signs, and broadcasts transaction B, setting the ''referencedTransactionFullHash'' parameter to the ''fullHash'' of A provided by Alice. He can verify that this hash indeed belongs to the transaction he expects from Alice, by using [[Transactions#Calculate_Full_Hash|Calculate Full Hash]], which takes ''unsignedTransactionBytes'' and ''signatureHash'' (both of which Alice has also sent to Bob). He can also use [[Transactions#Parse_Transaction|Parse Transaction]] to decode the unsigned bytes and inspect all transaction fields.
*Transaction B is accepted in the unconfirmed transaction pool, but as long as A is still missing, B will not be confirmed, i.e. will not be included in the blockchain. If A is never submitted, B will eventually expire -- so Bob should make sure to set a long enough deadline, such as the maximum of 32767 minutes.
*Once in the unconfirmed transactions pool, Bob has no way of recalling B back. So now Alice can safely submit her transaction A, by just broadcasting the ''signedTransactionBytes'' she got in the first step. Transaction A will get included in the blockchain first, and in the next block, Bob's transaction B will also be included.
Note that while the above scheme is good enough for a simple escrow, the blockchain does not enforce that if A is included, B will also be included. It may happen due to forks and blockchain reorganization, that B never gets a chance to be included and expires unconfirmed, while A remains in the blockchain. However, it is not practically possible for Bob to intentionally cause such chain of events and to prevent B from being confirmed.

===Prunable Data=== 


Prunable data can be removed from the blockchain without affecting the integrity of the blockchain. When a transaction containing prunable data is created, only the 32-byte sha256 hash of the prunable data is included in the ''transactionBytes'', not the prunable data itself. The non-prunable signed ''transactionBytes'' are used to verify the signature and to generate the transaction's ''fullHash'' and ID; when the prunable part of the transaction is removed at a later time, none of these operations are affected.


Prunable data has a predetermined minimum lifetime of two weeks (24 hours on the [[Testnet]]) from the timestamp of the transaction. Transactions and blocks received from peer nodes are not accepted if prunable data is missing before this time has elapsed. After this time has elapsed, prunable data is no longer included with transactions and blocks transmitted to peer nodes, and is no longer included in the transaction JSON returned by general-purpose API calls such as Get Transaction; the only way to retrieve it, if still available, is through special-purpose API calls such as Get Prunable Message.


Expired prunable data remains stored in the blockchain until removed at the same time derived tables are trimmed, which occurs automatically every 1000 blocks by default. Use [[Debug#Trim_Derived_Tables|Trim Derived Tables]] to remove expired prunable data immediately.


Prunable data can be preserved on a node beyond the predetermined minimum lifetime by setting the ''nxt.maxPrunableLifetime'' property to a larger value than two weeks or to ''-1'' to preserve it indefinitely. To force the node to include such preserved prunable data when transactions and blocks are transmitted to peer nodes, set the ''nxt.includeExpiredPrunables'' property to ''true'', thus making it an archival node.


Currently, there are two varieties of prunable data in the Nxt system: prunable [[Messages#Arbitrary_Message_System_Operations|Arbitrary Messages]] and [[Tagged_Data#Tagged_Data_Operations|Tagged Data]]. Both varieties have a maximum prunable data length of 42 kilobytes.

===Properties Files=== 
The behavior of some API calls is affected by property settings loaded from files in the ''ardor/conf'' directory during Ardor server initialization. This directory contains the ''nxt-default.properties'' and ''logging-default.properties'' files, both of which contain default property settings along with documentation. A few of the property settings can be obtained while the server is running through the [[Server_info#Get_Blockchain_Status|Get Blockchain Status]] and [[Server_info#Get_State|Get State]] calls.


It is recommended not to modify default properties files because they can be overwritten during software updates. Instead, properties in the default files can be overridden by including them in optional ''nxt.properties'' and ''logging.properties'' files in the same directory. For example, a ''nxt.properties'' file can be created with the contents:


nxt.isTestnet=true


This causes the Ardor server to connect to the [[Testnet]] instead of the Mainnet.

===Admin Password=== 
The admin password protects the node from malicious external access. It is not related to your passphrase or seed, your account id nor your public key.
Some API functions take an adminPassword parameter, which must match the nxt.adminPassword property unless the nxt.disableAdminPassword property is set to true or the API server only listens on the localhost interface (when the nxt.apiServerHost property is set to 127.0.0.1).

====How to setup the Admin Password====
The setup is done in the node <code>nxt.properties</code> [[Faq#Node_configuration_using_the_nxt.properties|configuration file]]:
# Password that should be provided when executing protected (administrative) API requests.
# Please choose a decent password here. Preferably, use a password generator.
# Password protection is disabled and password is not needed when the API server only listens on the localhost interface, i.e. when <code>nxt.apiServerHost=127.0.0.1</code>
# Add the <code>nxt.adminPassword=<type here the password></code> entry
# Restart the node

The same value specified in nxt.adminPassword should be passed when calling any API which accepts adminPassword as parameter. When loading the wallet from a remote node enter this value in the account settings page "Administrator Password" field.

==== Operations that require Admin Password ==== 
The admin password is required for the following operations (partial list)
# For any query API such as getBlockchainTransactions to return more than 100 records
# Get and stop APIs for forging, bundling, funding monitor, and shuffler
# Access to the /dbshell page to execute SQL queries
# Various administrative APIs: All [[Debug#Debug_Operations|Debug Operations]] require adminPassword since they require some kind of privilege. On some functions, adminPassword is used to override the maximum allowed value for the lastIndex parameter, which is set to 100 by default by the nxt.maxAPIRecords property. Giving you the option to retrieve more than objects per request.

==== Admin Password API responses ====
API response errors and their meaning, as follows:
* "Administrator's password is not configured. Please set nxt.adminPassword" - you need to configure the admin password on the remote node.
* "adminPassword not specified" - password is configured on the remote node but is not specified by the API call
* "Incorrect adminPassword (the specified password does not match nxt.adminPassword)" - the password specified did not match the remote node password
* "Too many incorrect admin password attempts from ..." - you specified too many incorrect password attempts

===Roaming and Light Client Modes=== 
The remote node to use when in roaming and light client modes is selected randomly, but can be changed manually in the UI, or using the new [[Networking#Set_API_Proxy_Peer|set API Proxy Peer]] API, or forced to a specific peer using the ''nxt.forceAPIProxyServerURL'' property.


Remote nodes can be blacklisted from the UI, or using the [[Networking#Blacklist_API_Proxy_Peer|Blacklist API Proxy Peer]] API. This blacklisting is independent of peer blacklisting. The API proxy blacklisting period can be set using the ''nxt.apiProxyBlacklistingPeriod'' property (default 1800000 milliseconds).


API requests that require sending the secret phrase, shared key, or admin password to the server, for features like forging, shuffling, or running a funding monitor, are disabled when in roaming or light client mode.
</translate>

Features

2021-04-15T16:54:02Z

Almonte:

<languages />
{{#seo:
|title=Ardor features
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, features
|description=Functionality of the Ardor platform
}}
__TOC__
<translate>


Current features of Ardor, as of version {{NRSVersion}}, include:

==Account control== 
With Account control, any account can be restricted to only issuing [[#Phasing|phased transactions]] subject to a specific voting model. This enables interesting use cases like:
* [https://nxtwiki.org/wiki/Account_Control_NXT Multi-signature], so that more than one key is required to authorize a transaction.
* Tagging, so that an account tagged as e.g. "savings" cannot, for example, send tokens.
* Escrow, so that a locked account cannot transfer assets, aliases, etc. except when some specific circumstances are met.


[[Account control| Learn more about Account control]].

== Account leasing== 
Account leasing allows users to [[Account_Leasing|lease]] their forging power to another account for a fixed period of time. This enables the creation of ''forging pools'', where the forging power of multiple users is combined to increase the chance of generating a block.


Account leasing is also relevant if a user wants to take part in the forging process without having to keep a node running 24/7.


[[Account Leasing| Learn more about Account leasing]].

== Account monitor == 
An Account monitor is a component that automatically transfers [[Bundling#Description|child chain]] tokens (eg: IGNIS), ASSET, or CURRENCY from a funding account to recipient accounts when the amount held by the recipient accounts drops below a set threshold.


[[Account Monitor| Learn more about the Account monitor]].

== Account properties == 
Account properties enable Ardor users to permanently ''tag'' an Ardor account with a small amount of data. These properties can then be used to provide meta-information about an account and can be linked to [[phasing]] by property conditions.


[[Account Properties| Learn more about Account properties]].

== Alias system == 
Ardor implements an alias system that translates alphanumeric text into almost anything: Ardor account addresses, email addresses, URLs, phone numbers, SKU codes, and more. The [[Alias system]] not only gives Ardor the ability to function as a Decentralized DNS system but also adds additional possibilities for mapping short names to other entities.


[[Alias system| Learn more about the Alias system]].

== Arbitrary messages == 
Arbitrary messages allow Ardor users to send small amounts of data through the decentralized network. This data can be optionally encrypted. The term "message" is loose: this feature can be used to send simple text messages, but can also be used to send up to 1000 bytes of any data. As a result, it can be used to build file-sharing services, decentralized applications, and higher-level Ardor services.


[[Arbitrary messages| Learn more about Arbitrary messages]].

== Asset control == 
The Asset Control feature allows restricting all transactions involving a given asset - such as placing a bid and ask orders, transfers, share deletions and dividend payments that use the asset as a dividend to be subject to approval


[[Asset_control| Learn more about Asset control]].

== Asset exchange == 
Ardor's Asset exchange provides a decentralized, peer-to-peer exchange system based on the "[https://bitcoil.co.il/BitcoinX.pdf|colored coins]" concept that eliminates trust points and their associated fees.


Up until now, if you wanted to trade cryptocurrencies and other digital assets, you had to sign up for an account on a centralized platform such as Cryptsy/BTC-E/Bter/etc, transfer your assets to them, and pay them the transaction fees. This brings in a large concern: a centralized exchange could just bail with everyone's deposits.


The same technology used to trade Ardor for other child chain tokens can allow you to trade any token within the Ardor multichain platform for almost any commodity.


[[Asset exchange| Learn more about the Asset exchange]].

== Asset Properties == 
Asset properties allow attaching metadata to assets, in the form of name/value pairs. 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.


[[Asset Properties| Learn more about Asset properties]].

== Bundling == 
[[Bundling]] is the process of grouping transactions from a child chain into a transaction on the Ardor chain. Bundlers accept fees from those child chain transactions in the corresponding child chain coin and pay fees in ARDR to the parent chain forgers.


[[Bundling| Learn more about Bundling]].

== Changelly integration == 
Changelly is a market-making service that utilizes crypto exchanges to provide a seamless exchange of crypto tokens without user registration.
Starting from Ardor version 2.1.2 the Ardor wallet integrates the changelly service to enable Ardor and Ignis to exchange with any other crypto directly from the wallet.


[[Changelly Integration| Learn more about Changelly integration]].

== Child Chain Control == 
The [[Child Chain Control]] is a feature that introduces permissioning to the Ardor multichain platform. It manages authorization levels of users on child chains. When operating on a chain that has permissioning policy enabled users can be restricted from performing chain transactions.


[[Child Chain Control| Learn more about the Child Chain Control]].

== Coin exchange == 
The [[Coin exchange]] is an Ardor feature that allows users to trade child chain tokens on the blockchain using [[Coin exchange#Coin_Exchange_menu|buy and sell orders]] and a built-in matching engine.


[[Coin exchange| Learn more about the Coin exchange]].

== Coin shuffling == 
Coin shuffling is a privacy feature that enables users to mix their funds with that of others.
The process is quick and efficient and works by creating a random mapping between the existing user accounts and different, new recipient accounts also provided by the users.


[[Coin Shuffling| Learn more about Coin shuffling]].

== Composite phasing == 
Composite phasing (or "''Smart Phasing''") is a powerful new feature that allows joining the current primitive approval models (such as [[Phasing (f)#Whitelisted_Approval_Requests|by whitelist]], [[Phasing (f)#Vote_By_Asset_Balance|by asset balance]], [[Phasing (f)#By_Secret|by secret]], etc) using the AND, OR, and NOT operators.


As simple as it sounds, defining new approval models in terms of boolean expressions provides an incredible amount of flexibility to our transaction workflow.


[[Composite phasing| Learn more about Composite phasing]].

== Data cloud == 
The Ardor Data Cloud is a decentralized data storage system. It is a feature that is reserved for the Ardor child chains


In addition to keeping a record of Ardor transactions, the blockchain can also be used to store user-defined data. All forms of data can be uploaded to the Ardor blockchain, providing a secure (and, if desired, permanent) method of storing, retrieving and publishing information


[[Data_Cloud| Learn more about Data cloud]].

== Forging == 
In Ardor the process of block generation is called forging. Every Ardor node is involved in this providing the associated wallet has at least 1.000 ARDR and stays open no less than 24 hours (1440 blocks)


[[Forging_(f)| Learn more about Forging]]

== Graphical installer == 
The graphical installer provides a simple and user-friendly setup of the Ardor client software for the [[Getting_started#Client_Installation|supported operating systems]].


[[Graphical Installer| Learn more about the Graphical installer]].

== Lightweight contracts == 
Lightweight contracts is a powerful new framework to develop a layer of automation on top of the existing Ardor APIs.


Contracts are developed by implementing pre-defined interfaces. The contract code is deployed to the blockchain as a cloud data transaction that stores the code itself and a contract reference transaction which provides the trigger to activate the contract and provides the setup parameters.


[[Lightweight Contracts| Learn more about Lightweight contracts]].

== Marketplace == 
The Marketplace feature provides a protocol for building decentralized, peer-to-peer stores for any kind of digital goods.


[[Marketplace| Learn more about the Marketplace]].

== Monetary system == 
The monetary system enables any user to issue customizable currencies secured by the Ardor network.


[[Monetary system| Learn more about Ardor's Monetary system]].

== Phasing == 
Phasing allows transactions with deferred execution, with or without conditions, which form the basis of many use cases.


[[Phasing (f) | Learn more about Phasing]].

== Plugins == 
The plugin framework allows third-party software developers to add new functionality and embed it directly into the [[Ardor_client_interface|Ardor client interface]].


[[Plugins | Learn more about Plugins]].

== Transaction Vouchers == 
Transaction Vouchers are a feature that simplifies and reduces the possible errors when two addresses make a transaction with each other on the blockchain.


[[Transaction Vouchers| Learn more about Transaction Vouchers]]

== Voting System == 
The secure, encrypted, consensus-based nature of the Ardor network allows the implementation of a voting system that guarantees anonymity and security, without relying on a central authority to tally the votes.


[[Voting system | Learn more about the Voting System]].

== Secret Sharing == 
Protect your account passphrase by splitting it into multiple shares that only some of them are required to reconstruct the passphrase.


[[Secret_Sharing| Learn more about secret sharing]].
</translate>

Introductory tour of ardors features

2021-04-15T16:50:18Z

Almonte:

<languages />
<translate>

{{#seo:
|title=Introductory tour of ardors features
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, tutorials, basic tutorials, how to, ardors features, introduction
|description=This guide provides an introductory tour of the live features available on the Ardor “parent chain” mainnet as of August 2018
}}
[[Category:Basic_tutorials]]
__TOC__
This guide provides an introductory tour of the live features available on the Ardor “parent chain” mainnet as of August 2018. The information presented here represents a modified version of the information in the 11-minute long video [[Basic_tutorials#Ardor_and_Ignis_features|Blockchain Ardor: Demo and Tour of Ardor and Ignis Features]]


If you would like to participate in this guide in real-time, you will need to download the Ardor Client from the Jelurida website. An article explaining the download process is available [[How_to_download_the_ardor_client_wallet|here]].

==Ardor Feature Tour== 
Open your Ardor desktop client and log in to the Ardor chain.

===Verify Your Public Address — First Time Users=== 


If this is your first time accessing your Ardor account through the client wallet, you will likely see 8 blue boxes on the Dashboard and a message across the top to validate a public key (pictured below).


[[File:1_dwRseq0sAaTxYCJrd6B2ow.png|center|border|640px]]


Normally, you should only see 2 blue boxes on the Ardor dashboard — but you must complete the validation of the public key first. You should click the orange button in the message bar, enter your secret passphrase, and then copy the newly displayed public key. Once you are ready to make your first transfer of funds to your Ardor wallet, you must include the public key in that first transaction. This will literally change the interface you see in the client.

===Ardor Dashboard=== 


Now that your account is verified, there are 2 blue boxes on the Ardor Dashboard — your account balance and the most recent block information. Your recent transactions on the Ardor chain are listed below.


[[File:1_zHXKUKk1ea0hriY-rsVoPw.png|center|border|640px]]


Looking at the very top of the screen, you see the button to Send ARDR (indicated in red below) — this is how you would begin a new transaction.


[[File:1_jutT4wUm42n749EO3u8HMg.png|center|border|640px]]


The circular symbol (indicated in orange above) is a shortcut to your Unconfirmed Transactions. Notifications are represented by numbers displayed in the blue and gray circles (indicated in yellow above). The symbol of a person is a contact book, the gears are a shortcut to your settings, the question mark takes you to guidance documentation, the tree chart takes you to the web wallet, and the power button logs you out.

===Navigating Between Child Chains=== 


The current account’s public address is located in the upper left corner (red). Beneath that, you see the current Ardor balance (orange), and the blockchain we are currently on (yellow).


[[File:1_DqCWNyaSi_DxLYfZqkRLBA.png|center|border|640px]]


Remember, child chains are their own blockchains, they are simply secured by Ardor. So, if you want to use the functions of a child chain or see balances on a child chain, you must navigate to the specific chain.


[[File:1_dpY_Hf80qvtOGcxXvy7Vqw.png|center|border]]


For example, we see in the photo below that Ignis has far more functions built-in, and there are multiple balances on the Dashboard.


[[File:1_jgJ9SN3JpFfAHhW_1ZC4Cw.png|center|border|640px]]


If you are interested in learning about issuing assets, new monetary supplies, marketplaces, messaging, cloud storage, and other functionalities — you should check out the article on the features of Ignis, available [[Ignis_child_chains_features|here]].

===Search Box=== 


Let’s navigate back to the Ardor chain.


[[File:1_qBP_eZ9MTMqNj7es3yoV6A.png|center|border]]


The next box allows you to search for specific accounts, transactions, or assets on the blockchain.


[[File:1_j0CuRsa2vNtAc6rdK7EYcQ.png|center|border]]

===Understanding Your Two Ardor Balances=== 


Let’s focus on the main dashboard for another minute. Click on the “more info” button under Account Balance and let’s discuss some key terms.


[[File:1_TaB1-hCcHITGv8O9izGfiQ.png|center|border|640px]]


Your Ardor coins have two “values.” There is the actual coin itself, and the power of the coin to secure the network through Forging.


[[File:1_S_0AtCURDS1y4VXDEp-4KA.png|center|border|440px]]

====Actual Value (green in the image above)==== 


That first value of the coin, the coin itself, is represented by the first 3 balances: Balance, Available Balance, Guaranteed Balance. The only difference between these 3 is the Guaranteed Balance updates every 1440 blocks or approximately every 24 hours.

====Forging Power (blue in the image above)==== 


Now, the second value of your Ardor coins, the securing power of the coins, is represented by Effective Balance and Forged Balance. Both require 1440 blocks to update.


The important thing to understand is that the actual value of your coins (Available Balance) represents your current spending power at a given moment. Your Effective Balance can be 0 for a variety of reasons, such as leasing your balance to a forging pool, but you always retain your spending power based on Available Balance. If you are interested in learning how to begin forging or leasing your balance, refer to [[Forging_and_leasing|Begin forging and leasing]]

===Decentralized Coin Exchange=== 


[[File:1_sgdCuILIE3rRq5f0DADOXg.png|center|border|640px]]


Here, you can begin trading between Ardor and its [https://www.jelurida.com/ardor/child-chains child chains].


An important note about Ardor is the fact that all of its child chains are interoperable — meaning, you can trade directly from one to the other without needing to convert to Ardor or any other intermediary token.


Another point here — when you are on the Ardor chain and you enter the coin exchange, you can buy Ignis using Ardor. But, if you want to do the reverse transaction and you want to buy Ardor using Ignis, then you must initiate that trade from the Ignis Child Chain’s coin exchange.


Moving on, you can review your open orders and exchange history in the left side menu.

==Continuing with learning the basic features on Ignis== 


During this guide, we have only just begun to scrape the surface of what Ardor can do. For those of you looking to keep it simple, [[Ignis_child_chains_features|continue learning about the basic features available on Ardor’s first child chain, Ignis]].


You also have the option of learning more about the revolutionary features of Ardor, such as Transaction Vouchers, which make it easy to send dual signature invoices and share distributions on the blockchain. They also make it possible to create counterfeit-proof “deposit” and “withdrawal” vouchers, [[Tutorial on transaction vouchers|Learn more]]


Turing-complete lightweight contracts represent the next generation in smart contract technology and it’s a feature exclusive to the Ardor ecosystem. Written guidance on lightweight contracts [[Lightweight_Contracts|is available here]] and you can refer to several articles describing the functionality [https://medium.com/@lyaffe/lightweight-contracts-articles-49c3032a50da]
</translate>

File:More nodes5.jpg

2021-04-14T09:32:22Z

Almonte:

File:Initialize repository 5.jpg

2021-04-13T16:47:45Z

Almonte:

File:Initialize repository 10.jpg

2021-04-13T16:39:40Z

Almonte:

File:Initialize repository 9.jpg

2021-04-13T16:39:32Z

Almonte:

File:Initialize repository 8.jpg

2021-04-13T16:39:15Z

Almonte:

File:Initialize repository 7.jpg

2021-04-13T16:39:09Z

Almonte:

File:Initialize repository 6.jpg

2021-04-13T16:39:00Z

Almonte:

File:Initialize repository 4.jpg

2021-04-13T16:38:46Z

Almonte:

File:Initialize repository 3.jpg

2021-04-13T16:38:37Z

Almonte:

File:Initialize repository 2.jpg

2021-04-13T16:38:27Z

Almonte:

File:Initialize repository 1.jpg

2021-04-13T16:38:17Z

Almonte:

Faq

2021-03-31T12:41:00Z

Almonte:

<languages />
<translate>

{{#seo:
|title=Ardor Frequently Asked Questions
|titlemode=replace
|keywords=What is Ardor, What is Jelurida, Where do I get started, What is my public key, How to announce my public key, Install Ardor on Windows 7 32 bit, Where to find the node log file, Exchange IGNIS to ARDR, transaction returns "not enough funds", Ardor block rewards, What is the testnet, How to verify authenticity of Ardor installations, Dealing with Passphrase Problems, User directories per product and platform, What is my Ardor account address?, It is impossible to reset your passphrase, Changelly issues, Why do I sometimes see 0 balance (Light Client mode), Exchange deposit problems, Exchange Withdrawal Problems, What is Forging?, Cannot submit transactions while using light client in Ardor, How to download a copy of the blockchain, Ardor Scaling Parameters and Constants, What wallet/client should I use?, How to check your IGNIS balance, Is there a mobile wallet?, How do I get ARDOR/IGNIS?, Node configuration using the nxt.properties,What is the admin password?, What is the roadmap of Ardor?, Where can I find more detailed information about Ardor and its features?, Where do I find news about Ardor?, Where do I find information about the API?, What features does Ardor have, How many nodes are up for Ardor?, Where is the source code?, Does Ardor have a testnet?, How do I access my Ardor account on the Ardor client/wallet?, Why am I getting a Java error when I try to start the software?, Why cannot I open the client in a web browser?, Why doesn't my blockchain finish loading?, Does Jelurida still maintain Nxt?, How can I buy IGNIS?
|description=Answers to the most frequent questions with regards with Ardor, Nxt and Ignis
}}
[[Category:Basic_tutorials]]
__TOC__

=== What is Ardor? === 
Ardor is an evolution of the Nxt software that addresses issues of blockchain bloat, scalability, and versatility. Its turn-key functionality allows new blockchain applications to be built and launched without the need for extensive custom code or architecture.

=== What is Jelurida? === 
Jelurida BV is the name of the company that owns the Nxt and Ardor blockchain platforms. It was created in 2016 and provides blockchain-as-a-service solutions to other companies and organizations.

=== Where do I get started? === 
Please, see [[Getting started]] on this wiki.

=== What is my public key === 
Our public key is not your passphrase
Your public key is not your account
In most cases, you don't need to worry about your public key at all.


However, for a new account which never made any outgoing transactions, you can find the public key when you login using your passphrase (not using your account id)
It will be displayed on the dashboard as a 64 characters long stream of hexadecimal characters:


[[File:faq.public.key.png|none|border|820px]]

=== How to announce my public key === 
When sending ARDR, child chain tokens such as IGNIS or any other token to a new account using the new account's address the resulting account is protected only by 64 bit account id, which is somewhat not as secured as the 256 public key which provides ultimate protection.


The risk is that someone can brute force a passphrase that maps into the same account id so that both accounts are indistinguishable so that the attacker can spend the funds in this address.


More specifically, the reason why this one-time extra step is necessary is because the 8-byte account ID is much shorter than the 32-byte public key it is derived from. There are many secret passphrase/public key pairs that reduce to the same account ID (2^192 keys). But once a particular public key is associated with an account ID by storing it in the blockchain, no other secret passphrase that generates a different public key can access that account.


To protect against this a simple step has to be taken to record the account public key in the blockchain. Recording the public key in the blockchain protects against the attack described above. The options to announce a public key is as follows:

==== Option 1: Submit an outgoing transaction from the new account ==== 
Any type of outgoing transaction will do since the user is signing this transaction with his passphrase and by doing so records the public key in the blockchain. This transaction can for example be sending ARDR, IGNIS, sending a message, creating an alias, and so on.


Note: your account must contain enough tokens (either ARDR or child chain tokens such as IGNIS) to pay the transaction fee, so you have to fund it with some tokens first.

==== Option 2: Another account can announce the public key of the new account to the blockchain ==== 
Any type of transaction in which the recipient is the new account will do. The sender needs to specify the new account public key as the "recipientPublicKey" parameter for the transaction API or using the wallet "Recipient Public Key" field. Most exchanges which support ARDR or Ardor child chain tokens, already supports this public key announcement function. This procedure is also suitable for companies that want to announce the public keys of their user accounts, hence the blockchain integration in the current business processes is smoother and seamless.


[[File:faq.public.key.announcement.png|none|border|620px]]


To find your account public key, simply login to your account using your passphrase (not using your Ardor address). If the account is not registered on the blockchain yet, the public key will be displayed on the dashboard.


For registered accounts, you can find the public key by clicking on the "Account Balance" tile from the dashboard

=== Install Ardor on Windows 7 32 bit === 
Install Oracle Java 8 32 bit
From the command line, in folder "c:\program files\ardor" or the previously folder selected during the installation run the following command:
<pre>java -cp classes;lib\*;conf;addons\classes;addons\lib\* -Dnxt.runtime.mode=desktop nxt.Nxt</pre>
For instance:
<pre>"C:\Program Files (x86)\Java\jre1.8.0_172\bin\java.exe" -cp classes;lib\*;conf;addons\classes;addons\lib\* -Dnxt.runtime.mode=desktop nxt.Nxt</pre>

=== Where to find the node log file? === 
ardor.log is our main diagnostic resource for diagnosing node related problems such as startup issues, blockchain download and contract execution.


To locate this file, first find your [[faq#User directories per product and platform|Ardor user directory]]. The log files are located in the logs subdirectory where you will find the ardor.log file. There are multiple revisions of this file named ardor.0.log, ..., ardor.9.log.


In most cases, ardor.0.log represents the existing node log file.

=== Exchange IGNIS to ARDR transaction returns "not enough funds" === 
Coin exchange transactions from any child chain to the Ardor parent chain are recorded on the parent chain since it affect the ARDR balances and therefore pay fee in ARDR.
Therefore exchanging IGNIS to ARDR using the coin exchange is impossible unless you already have ARDR to pay for the transaction fee.


As a temporary solution to enable users to exchange child chain coins to Ardor even if they do not already own ARDR, Jelurida has deployed the ChildToParentExchange lightweight contract at the account ARDOR-FGET-YXM3-USHQ-2SPC9 (alias: @IgnisToArdor).

The steps to trigger the contract are as follows:

'''1:''' Launch the [[Ardor_client_interface|Ardor User Interface]], select the IGNIS chain and click on the button 'Send IGNIS'

'''2:''' The sent IGNIS amount must be high enough to pay the 1 ARDR transaction fee required by the ARDR funding transaction to be submitted by the contract according to the calculated IGNIS/ARDR exchange rate, i.e. if the rate is 2:1 send more than 2 IGNIS, the contract will automatically send back ARDR based on the market rate. Enter as a recipient the values ARDOR-FGET-YXM3-USHQ-2SPC9 or the alias @IgnisToArdor:

[[file:IgnisToArdor_contract_1b.png|class=img-responsive|border|center|420px|@IgnisToArdor]]

'''3:''' The Contract Reference selector box is now populated, select the contract 'ChildToParentExchange' as shown in the image above. Click on the 'Add a message' box, add either to encrypt the message or not, calculate the fee and send the transaction.

[[file:IgnisToArdor_contract_1c.png|class=img-responsive|border|center|420px|@IgnisToArdor]]

'''4:''' Once the transaction is confirmed, switch to the parent chain Ardor:

[[file:IgnisToArdor_contract_3.png|class=img-responsive|center|border|300px|Switching to Ardor]]

'''5:''' In the Section 'Recent Transactions' it will be shown the transaction from the @IgnisToArdor account to your account:

[[file:IgnisToArdor_contract_4.png|class=img-responsive|center|750px|@IgnisToArdor Transaction back]]

=== Ardor block rewards === 
When forging a block in Ardor all transaction fees from the included transactions are rewarded to the forger account except block rewards from transactions of type Child Chain Block which are split between forgers of the last 4 blocks 25% each.


The reason it's implemented this way is to prevent forgers with a large stake from predicting their forging time and forge their own transactions and thus pay the transaction fees to themselves

=== Ardor Fee Structures === 
A small fee is required for every transaction, including those in which no ARDR is transferred, such as simple messages when using a child chain. The Ardor fee structures are as follows:


[https://www.jelurida.com/sites/default/files/ArdorFees.pdf Download Ardor Fee Structures]
<accordion parent="accordion" heading="Ardor Fee Structures">
{| class="wikitable"
|-
! Transaction
! Fee (ARDR)
! Reasons
|-
| Default Ardor fee
| 1
| permanent transaction
|-
| Default Child Chain fee
| 0.01
| prunable transaction
|-
| New account fee
| 1
| creates permanent global entity
|-
| Balance leasing
| 0.1
| Ardor chain only, not frequently used
|-
| Ardor Coin Exchange
| 0.5
| permanent transaction
|-
| Asset issuance
| 100
| create permanent global entity, Ignis chain only, not frequently used, need to reduce scam assets
|-
| Singleton asset issuance
| 1 + 1 per 32b
| Ignis chain only, more frequently used, but still creates global permanent entity
|-
| Asset increase
| 10
| Ignis chain only, rarely used
|-
| Dividend payment
| 0.1
| needs processing, not frequently used
|-
| Set asset control
| 10
| Ignis chain only, not frequently used, asset issuers only
|-
| Set account control
| 1
| Ignis chain only, not frequently used
|-
| Cloud data upload
| 0.1 + 0.01 per 1kb
| prunable, but takes space
|-
| Poll creation
| 1 + 0.1 per option > 20 + 0.2 per 32b > 288b
| not frequently used, need to keep until the poll is over, takes space
|-
| Phasing approval
| 0.01 per approved tx
| needs processing
|-
| Account info
| 1 + 1 per 32b
| permanent, Ignis only, rarely used
|-
| Set account property
| 0.1 + 0.1 per 32b
| permanent, Ignis only, not frequently used
|-
| Alias assignment
| 1 + 1 per 32b
| creates permanent unique entity, not frequently used
|-
| Shuffling (total)
| 0.12
| takes space, but prunable, not frequently used
|-
| Shuffling penalty
| 10 IGNIS, 10 Bitswift
| must be affordable, but not negligible
|-
| Currency issuance
| 4 / 100 / 2500
| creates permanent unique entity, not frequently used
|-
| Marketplace listing
| 0.2 + 0.2 per 32b
| takes space, need to keep until delisting, not frequently used
|-
| Marketplace delivery
| 0.1 + 0.2 per 32b
| takes space, need to keep
|-
| Permanent message
| 0.1 + 0.1 per 32b
| permanent
|-
| Prunable message
| 0.01 per 1k
| prunable
|-
| Phasing appendix
| 0.01 balance independent, 0.2 balance dependent + 0.01 per 32b size
| depends on size and complexity, needs processing
|-
| Composite phasing appendix
| 0.02 + 0.02 per 32b + per poll fees
| determined by phasing complexity
|-
| Referenced Tx deposit
| 10
| refundable
|}
</accordion>

=== What is the testnet === 
When we develop our blockchain products Nxt and Ardor we need to perform testing.
For this purpose, we keep another blockchain instance we call Testnet which is similar in functionality to the actual production blockchain also known as Mainnet but uses a worthless token.


When you connect to the testnet you see a Red message saying "You are connected to the TestNet!"
This means that any information you see in the wallet is just test data and does not represent any official amount.
Use this blockchain only for testing.


To turn on testnet add the following property to your nxt.properties file nxt.isTestnet=true and restart your node.
To connect to mainnet remove this property or set it to false.

=== How to verify authenticity of Ardor installations === 
Windows exe:
Right-click, Properties, Digital Signatures Tab, Name of Signer should be "Jelurida Swiss SA"


Mac DMG file:
1. Open the DMG file to create the Ardor Installer application
2. From the command like issue the following command:
<pre>codesign --verify -v /Applications/ardor-installer.app</pre>
The output should be:
valid on disk
For more a verbose output use:
<pre>codesign -dv --verbose=4 /Applications/ardor-installer.app</pre>
Linux .sh and .zip files
<pre>sha256sum <file name></pre>
The result should match the sha256 hash published on https://ardorforum.org/ by account Jelurida


Android mobile app:
'''Note:''' You may need to install ''gpg'' from [http://gnupg.org/ GNUPG.org].
# Point your web browser at https://www.jelurida.com/ardor/downloads
# In this web, you will see the latest Android software in file, along with a corresponding .ASC file. The ZIP file contains the Nxt software, and the ASC file contains the GPG signature.
# Download both the clint ZIP file and its corresponding ASC file, and place them into the same directory on your system
# Execute the following command <code>gpg --verify SIGFILE.asc</code> ...where <code>SIGFILE</code> is the name of the ASC file
Execute the following command <code>gpg --verify SIGFILE.asc</code> ...where <code>SIGFILE</code> is the name of the ASC file published on https://www.jelurida.com/ardor-android.apk.asc

=== Dealing with Passphrase Problems === 
Due to the decentralized design of the blockchain, the user is the only one who received the secret passphrase during the creation of a new Ardor account with the default Ardor client. There is no way for anyone to restore or reset the passphrase, not even for the developers. So if the passphrase is lost, it is impossible to make transactions from the account.


Every combination of characters opens a different Ardor account. So if you mistakenly add an extra space at the end of your passphrase, or make a small typo, you will open a different Ardor account.


The default Ardor passphrase consists of 12 random English words out of a 1600+ words dictionary. This is impossible to crack by brute-forcing. Only if you think you made a small typo, or if you forgot for example 1 of the 12 words, it might be possible to find the correct passphrase by brute-forcing it. Some community members made tools for this, for example, https://ardor.tools/typo/typo.html (which needs the public key), and Ardor itself provides a basic password recovery tool [[Passphrase_Recovery]]. You can also ask for help in ardorforum.org or the Ardor Slack chat.


If your passphrase and the account that has your ARDR don't match, you are either using the wrong password, or you sent your ARDR to the wrong account by mistake, thinking it was your account.


For example:
You create the account, and passphrase A is shown on screen. You enter it in the client the first time, but you, unfortunately, make a small typo, so you end up in account B. Every combination of chars opens a new (empty) account.
You think passphrase A matches account B, so you send your tokens to account B.
Now when you enter your passphrase for A without the typo, it doesn't work for account B. When you login with passphrase A, you end up in the real account A, which has 0 ARDR in it.
You could try to find out what password B (with the typo) is, that gets you to account B with the ARDR in it, but you'll have to be lucky to find the typo.


The best way to prevent this is to always REALLY make sure you REALLY control your account that has the passphrase. Just send 1 small outgoing transaction from the account before you even put large amounts of funds in it. By the way, the client DOES strongly recommends you to do an outgoing transaction in order to publish your public key to the blockchain for new accounts.

=== User directories per product and platform === 
Default user directory:
Ardor on Windows: C:\Users\<username>\AppData\Roaming\ardor


Ardor on MAC: ~/.ardor


Linux: Ardor folder where the installation package was unzipped


If you are not sure, look for the 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. These files exist under the user's logs directory.

=== What is my Ardor account address? === 
Your Ardor account address is the string displayed in the upper left corner of the wallet with the format ARDOR-XXXX-XXXX-XXXX-XXXXX
Is something else my address? No this is your address, don't use anything else as your address.
Your passphrase is not your address, never reveal it to anyone, don't even post it in a support ticket unless the account is empty.
Your public key composed of 64 hexadecimal characters, it is not your address. Only provide it when someone is asking you specifically to provide your public key.
In addition, remote nodes may use administrator password, this is not your account address, not your public key, and not your passphrase, and of course you should not reveal it to anyone.

=== It is impossible to reset your passphrase === 
Blockchain is designed to be completely decentralized, therefore it is technically impossible to reset your passphrase or retrieve it.
The user is the only one who has the passphrase. There is no central authority which controls your funds, like in the traditional banking system.
Not even the developers can reset your passphrase.


The only way to submit transactions from an account on the blockchain is to use the original passphrase (from which the cryptographic private/public key pair is derived).

=== Changelly issues === 
The Ardor wallet includes pages that integrate with Changelly.
In addition, when funding your account for the first time the wallet will use the Shapeshift widget to exchange tokens.


However, the wallet uses the exchange APIs while the actual exchange is performed using Shapeshift or Changelly, therefore if something went wrong, please open a support ticket for the relevant exchange and provide all the relevant information. From our experience they resolve tickets relatively quickly and efficiently and in most cases will simply refund your deposit to a refund address you'll provide.


Typical reasons for problems include:
1. Waiting too much time between getting the deposit address and making the deposit. This process has to complete within 5-10 minutes or else the exchange will cancel the offer and your deposit will never be exchanged.
2. Sending a deposit amount which is smaller than the minimum

=== Why do I sometimes see 0 balance (Light Client mode) === 
After starting the Ardor client for the first time, the client needs to download a copy of the blockchain. This download process can take a while. During this time the client relies on random remote nodes for its operation.
Some of these nodes are not up to date and include the old state of the blockchain.
Therefore recent transactions are not reflected causing your balance to show 0.


There is nothing to worry about.


How to fix the problem? Any of the methods below will do
1. Restart your node to allow it pick another remote node
2. Download local copy of the Blockchain
3. Check your balance on a block explorer

=== Exchange deposit problems === 
If you sent your ARDR or IGNIS to an exchange and it did not arrive you should check with the exchange what happened.
Some exchanges manage all their tokens in a single account and identify user deposits based on message text they provide and should be attached as a message to the deposit transaction.


There are several ways to get your funds locked because of this:
1. Failing to send this requested message when submitting the transaction from the wallet, will surely get your funds locked and requires contacting the exchange customer support and you should expect a long delay until getting a refund.
2. Sending an encrypted message when the exchange asks for plain text one or vice versa is another popular way to lock your funds. If the exchange does not specify otherwise we recommend that you send the message as plain text.
3. Sending ARDR/IGNIS, from one exchange to the other will get your funds locked since there will be no message attachment.


Another common deposit issue is with sending a very small amount, which is not economical for the exchange to deal with.
It's not simple to tell what is this minimum amount and it changes between exchanges.


Sorry, but there is nothing we can do to help with these issues since these are restrictions related to the inner working of exchanges

=== Exchange Withdrawal Problems === 
When withdrawing your funds from an exchange always make sure to provide your [[faq#What is my Ardor account address?|account address]] and make sure you have a [[faq#passphrase to this account|passphrase]]. Providing an incorrect account address or an account address to which you don't have the passphrase is a sure way to lock your funds forever.
Writing the amount in the account address field or any other irrelevant info is another popular way to lock your funds forever, since some exchanges do not validate the account address before withdrawal.
If the exchange also asks for a public key, login using your passphrase, and retrieve the 64 character long account public key.

=== What is Forging? === 
Forging is the process of generating new Nxt and Ardor blocks.
A block is a container of 0 or more transactions, blocks are generated every 1 minute on average.
The forger of the next block receives the transaction fees for this block.


Q: Who can forge new blocks?
A: Any account with a balance of more than 1000 ARDR vested over 1440 blocks (approx. 24 hours).


Q: Why is my wallet showing "Not Forging" indicator?
A: Because you are not forging, either because your balance is insufficient or because you did not start forging since your last node restart.


Q: Should I use an account with a lot of ARDR for forging?
A: No, you should lease your balance to another account and forge with the other account see [[Account_Leasing|Account leasing]].

=== Cannot submit transactions while using light client in Ardor === 
This is a known problem we are looking to fix in one of the next releases.
The transaction appears to be submitted but is not being broadcast to the network. No funds are lost or affected.


This problem affects two configurations:
1. Light client which does not download the blockchain
2. Roaming client which works as light client during blockchain download


Workaround:
Switch to full client


Option 1: Reinstall Ardor without checking the light client option during installation
Option 2: Add the following line to conf/nxt.properties under [[faq#User directories per product and platform|User directories per product and platform]] nxt.isLightClient=false


In both cases, you'll need to restart your node and wait for the blockchain to finish downloading.

=== How to download a copy of the blockchain === 
By default, when installing the Ardor software as a 'full client' the local wallet automatically finds other remote peers and starts the blockchain download. This process is very secure, since your node re-validates all the transactions during the download.


However, on slow hardware or limited internet connection, this process can be very time consuming and could take several hours (Ardor). If you are in a hurry, and trust Jelurida to provide a good copy of the blockchain, you can go to the Jelurida homepage www.jelurida.com and download a copy of the blockchain database.


There are several options:
[https://www.jelurida.com/Ardor-nxt_db.zip Ardor production] - is the Ardor mainnet blockchain
[https://www.jelurida.com/Ardor-nxt_test_db.zip Ardor testnet] - is the Ardor testnet database used for development and testing (doesn't contain real transactions)


On Windows (when using Ardor mainnet) the blockchain will be downloaded to your "C:\Users\USERNAME\AppData\Roaming\ardor\nxt_db" folder. Make sure that you can see hidden folders. You can find your AppData folder very quickly by entering "%appdata%" in the address bar of the file explorer.
Shutdown your Ardor client (using the Ardor icon in your Windows system tray), and place the nxt_db folder into your "C:\Users\USERNAME\AppData\Roaming\ardor" folder.
Start the Ardor client again and the download should be up-to-date quickly.


On macOS (when using Ardor mainnet) your default user directory is ~/.ardor for Ardor

=== Ardor Scaling Parameters and Constants === 
As of version 2.0.12
Parent block time: 1 minute on average
Parent transactions per block: 10
ChildChainBlock transaction per chain per block: 1
Child chain transactions per ChildChainBlock transaction on the parent chain: 100
ChildChainBlock transaction pay load size: 128K
Epoch beginning mainnet: 2018-01-01 00:00:00 UTC
Epoch beginning testnet: 2017-12-26 14:00:00 UTC


For other constants and limits, [https://bitbucket.org/Jelurida/ardor/src/8269057d7889276dbe8b04fe8cd1c6e5310e6f08/src/java/nxt/Constants.java see]

=== What wallet/client should I use? === 
We recommend using the [[Getting_started#Download_Ardor|Ardor client]].

=== How to check your IGNIS balance === 
To check your IGNIS balance:
1. Install Ardor from jelurida.com (See Ardor Downloads).
2. Run Ardor and wait for the blockchain to download.
3. Login using your Ardor account.
4. Switch to the IGNIS chain to check your IGNIS balance.


[[File:faq.switch.chain.png|none|border]]

=== Is there a mobile wallet? === 
There is one for Android, refer to [[Android Full Node]]


There is also an [https://play.google.com/store/apps/details?id=mrv.ardor.lite Ardor] Lite version in the Google play. Click on install with your Android device and follow the instructions.

=== How do I get ARDOR/IGNIS? === 
Here are places where you can get ARDR and/or IGNIS with EUR, USDT, BTC, and other currencies.


* [https://www.jelurida.com/ardor/explorers Ardor exchanges]
* [https://www.jelurida.com/ignis/explorers Ignis exchanges]

=== Node configuration using the nxt.properties === 
The configuration of your Ardor node is configured using properties set in the nxt.properties file.


The nxt.properties file is a text file which can be created using any text editor (notepad on Windows and vi on Linux and Mac will do)
Create or update the nxt.properties file in the conf directory under the [[Faq#User_directories_per_product_and_platform|user directory]]


Every change to properties will only take effect after you restart your node.


You can use the nxt-default.properties file from the conf directory of the Ardor or Nxt installation as a reference to see the existing properties and their documentation.


Never modify the nxt-default.properties file since your modifications will be overwritten by an upgrade to a new version.


Another configuration file you should never modify is nxt-installer.properties. This file stores the configuration selected during the installation.


Any setting set in nxt.properties will override settings in nxt-default.properties and nxt-installer.properties


For advanced users:


The location from which the property files are loaded can be customized using a Java command-line argument named according to the property file name.
For example:


<code>java ... -Dnxt.properties=./conf/examples/testnet.properties ...</code>


Will tell the Ardor node to load the nxt.properties file from the ./conf/examples/testnet.properties folder.


==== How to open the API access of your node from remote client ====
Add the following lines to nxt.properties:


<pre>nxt.apiServerHost=0.0.0.0


nxt.allowedBotHosts=*</pre>
and restart the node for the properties to take effect.

=== What is the admin password?=== 
The admin password is not your passphrase, not your account id, and your public key, it is something else, read on.
When connecting to a remote node using the API there are certain operations that are restricted by default unless the adminPassword parameter contains a value matching the remote node admin password is specified in the API call.


You setup the admin password in the remote node in the nxt.properties file:
# Password that should be provided when executing protected (administrative) API requests.
# Please choose a decent password here. Preferably, use a password generator.
# Password protection is disabled and password is not needed when the API server only listens on the localhost interface, i.e. when nxt.apiServerHost=127.0.0.1.
nxt.adminPassword=


The same value specified in nxt.adminPassword should be passed when calling any API which accepts adminPassword as parameter.
When loading the wallet from a remote node enter this value in the account settings page "Administrator Password" field.


The admin password is required for the following operations (partial list)
1. For any query API such as getBlockchainTransactions to return more than 100 records
2. get and stop APIs for forging, bundling, funding monitor and shuffler
3. Access to the /dbshell page in order to execute SQL queries
4. Various administrative APIs


API response errors and their meaning:
"Administrator's password is not configured. Please set nxt.adminPassword" - you need to configure the admin password on the remote node.
"adminPassword not specified" - password is configured on the remote node but is not specified by the API call
"Incorrect adminPassword (the specified password does not match nxt.adminPassword)" - the password specified did not match the remote node password
"Too many incorrect admin password attempts from ..." - you specified too many incorrect password attempts

=== What is the roadmap of Ardor? === 
Jelurida maintains a public [https://www.jelurida.com/ardor-roadmap Ardor roadmap] and have a good track record sticking to it.

=== Where can I find more detailed information about Ardor and its features? === 
You can read all the material in the [[Features]] and Tutorials section. By then you should have a pretty good foundation to dab into the [[API]].

=== Where do I find news about Ardor? === 
* [https://talk.jelurida.com Ardor Technical forum]
* [https://nxtplatform.org/slack/ slack]
* [https://ardorforum.org/ Ardor historical forum]
* [https://twitter.com/Jelurida Twitter Jelurida]
* [https://www.nxter.org/ Nxter newsletter]

=== Where do I find information about the API? === 
Please see the [[API]] section on this site.

=== What features does Ardor have? === 
Ardor functionality is restricted to maintain the PoS algorithm.
Ignis has numerous core-level features such as the ability to issue assets, a decentralized asset exchange, decentralized voting, coin shuffling (for anonymity), alias system, decentralized marketplace, multisig capabilities, and a monetary system for currencies. For more information, you can read the [[Features]] section of this site.

=== How many nodes are up for Ardor? === 
PeerExplorer is a great tool to see live information about nodes.

=== Where is the source code? === 
You can find the source code in Jelurida's Bitbucket.

=== Does Ardor have a testnet? === 
Yes, you can [https://testardor.jelurida.com access Ardor's testnet here].

=== How do I access my Ardor account on the Ardor client/wallet? === 
Download the client and introduce your passphrase

=== Why am I getting a Java error when I try to start the software? === 
Ardor relies on Java 8. Make sure you download and install the latest version installed from Oracle! You can check to see which version of Java is running on your computer by running the following command in a terminal window:


java -version

=== Why cannot I open the client in a web browser? === 
First of all, you need to make sure that the Ardor server window has finished loading, as indicated by a message like this:


Ardor Server vx.xx.xx started successfully.
To access your client interface, you can then use either of these addresses:


http://localhost:27876/
http://127.0.0.1:27876/

=== Why doesn't my blockchain finish loading? === 
Patience is usually the best fix; your client will eventually catch up with the network. Some delay may occur especially when you have updated to a new software version that performs a database upgrade. If you are in a hurry you can download a recent copy of the blockchain from the Jelurida web site.

=== Why do my blockchain files keep getting corrupted? === 
The blockchain database may get corrupted as a result of the Ardor software being forcefully terminated in a way that doesn't allow the server to close the database properly. You should be able to see "Database shutdown completed" in the log before shutdown as a sign that data files have been properly closed. To prevent data corruption when closing Ardor:


In Windows, use Ctrl-C to shut down the process in the terminal window
In UNIX, use kill -15 #ID PROCESS do not use kill -9 #ID PROCESS.

=== I keep accessing a different account number than the one I created. What's going on? === 
Since different account numbers are accessed using different passphrases, getting a different account number than the one you expected means you used a different passphrase than the one originally used to generate your account number. Make sure you are introducing your original passphrase correctly. This means double-checking for typing mistakes, and ensuring no extra spaces are accidentally pasted (or omitted!) in the beginning or the end of your passphrase as you paste it to unlock your account.

=== Does Jelurida still maintain Nxt? === 
Yes, Jelurida will continue to support and develop both Ardor and Nxt. A portion of the funds from the Ignis token sale was reserved towards Nxt development as explained in the Whitepaper.

=== How can I buy IGNIS? === 
You can buy IGNIS using the Ardor [[Coin exchange| coin exchange feature]] or [https://www.jelurida.com/ignis/explorers with centralized exchanges]

</translate>

Account Setup for Message-based Deposits

2021-01-12T09:40:10Z

Almonte:

<languages />
<translate>
{{#seo:
|title=Account Setup for Message-based Deposits
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, tutorials, advanced tutorials, how-to, message-based deposits, prevent users to send tokens without a message
|description=This guide explains how to prevent users from accidentally sending tokens without message setting up the property nrs_recipient_ui_options. It is covered with a step-by-step guide for both configuring the receiving account and to send tokens to the account.
}}
[[Category:Advanced_guides]]

==Introduction==

This guide explains how to configure the account property <code>nrs_recipient_ui_options</code>. It prevents users from accidentally sending tokens without a message to the account that has the property set up.

Decentralized applications that require a message to process the funds received, or any other use case that accepts message-based deposits should enable this functionality to prevent errors.

The guide explains the configuration of the account that will require the message-based deposit as well as the end-user steps to send funds.

=='''nrs_recipient_ui_options''' property configuration==

The [[Account_Properties|account property]] with name <code>nrs_recipient_ui_options</code>, set by the recipient on itself is used to configure the modal in the [[Introductory_tour_of_ardors_features|Ardor UI]] when sending funds to that account. It also allows control over the message encryption, such as disabling it. The value of the <code>nrs_recipient_ui_options</code> property is a JSON object containing the following fields:

* '''message_format''': [https://en.wikipedia.org/wiki/Regular_expression Regular expression] of the message format which is required when depositing to this address. For instance:
** The expression <code>[0-9]+</code> will only allow a numeric message.
*** For instance: <code>291</code>
** If the message should be of a particular length use the expression as follows: <code>[a-zA-Z0-9]{4,8}</code>.
*** This format will only allow alphanumeric messages with length 4 to 8 characters.
** Note that the regular expression is case sensitive.
* '''encrypt_message''': default value for the encrypt message box. Must be boolean, not string - <code>true</code> is valid value, <code>"true"</code> is not.
* '''encrypt_message_disabled''': if <code>true</code>, the encrypt message box is disabled. Set this to <code>true</code> if you can accept either only encrypted or only unencrypted messages. Must be boolean, not string. If <code>true</code>, the '''encrypt_message''' field must also be set to <code>true</code> or <code>false</code>. Or else the configuration is invalid.

Example of the <code>nrs_recipient_ui_options</code> property:

<syntaxhighlight lang="json">
{"message_format":"[a-zA-Z0-9]{4,8}","encrypt_message":true,"encrypt_message_disabled":true}
</syntaxhighlight>

==Checking the '''nrs_recipient_ui_options''' property==
Applications that implement withdrawal of funds to user's account (like exchanges) should respect the '''nrs_recipient_ui_options''' property similarly to the Ardor UI - in order to protect the user from withdrawing funds to account owned by some other service which requires a message.

To get the property, use the [[Accounts#Get_Account_Properties|Get Account Properties]] API with parameters
* '''setter''': the account to which the user wants to withdraw funds
* '''recipient''': again the account to which the user wants to withdraw funds. This parameter should be equal to the '''setter''' parameter because the '''nrs_recipient_ui_options''' property must be set by the account on itself.
* '''property''': the string "nrs_recipient_ui_options"

Example:

<btn size="sm">https://testardor.jelurida.com/test?requestType=getAccountProperties&property=nrs_recipient_ui_options&setter=ARDOR-S9Q3-GPL9-XLPB-EDW66&recipient=ARDOR-S9Q3-GPL9-XLPB-EDW66| Test Get Account Properties|btn-primary</btn>

<syntaxhighlight lang="bash">
http://localhost:26876/nxt?
requestType=getAccountProperties&property=nrs_recipient_ui_options&
setter=ARDOR-S9Q3-GPL9-XLPB-EDW66&recipient=ARDOR-S9Q3-GPL9-XLPB-EDW66
</syntaxhighlight>

If the account ARDOR-S9Q3-GPL9-XLPB-EDW66 is properly configured for message-based deposits, the result will be something like
<syntaxhighlight lang="json">
{
"setterRS": "ARDOR-S9Q3-GPL9-XLPB-EDW66",
"recipientRS": "ARDOR-S9Q3-GPL9-XLPB-EDW66",
"recipient": "13984674604228812481",
"requestProcessingTime": 0,
"setter": "13984674604228812481",
"properties": [
{
"property": "nrs_recipient_ui_options",
"value": "{\"message_format\":\"[0-9]+\",\"encrypt_message\":true,\"encrypt_message_disabled\":true}"
}
]
}
</syntaxhighlight>

If it is a regular account, not configured for message-based deposits, the '''properties''' array will be empty.

The '''properties''' array cannot contain more than 1 element for this request. If not empty, get the only element and then get the '''value''' field. It should be a string. Parse it as JSON object. If the parsing failed, consider this a regular account. If the parsing succeeded:

* Get the '''message_format''' field of the parsed object:
** If not present, consider this a regular account.
** If '''message_format''' is present in the object, check if the message which the user entered is matched by this regular expression. If your UI doesn't allow the user to enter message, block the withdrawal and show an explanatory error message to the user.

* Get the '''encrypt_message_disabled''' field. If <code>true</code>, this means that the destination account can accept either only encrypted or only unencrypted messaged. In this case check the '''encrypt_message''' field:
** If <code>true</code>, the account accepts only encrypted messages
** If <code>false</code>, the account accepts only unencrypted messages
** Anything else: the account is not properly configured - consider that it is a regular account

==Step-by-step configuration of the receiving account==

It will be used the Ardor account <code>ARDOR-GHKP-XWB5-XMZB-CTUE3</code> for this example. First [[Login_Page_Tutorial|login into the Ardor wallet]] with the account that will receive the funds.

Then click on 'Account Properties':

[[File:Account setup for Message-based deposits - 1.jpg|class=img-responsive|border|Account properties]]

Click on 'Set' as shows the following image:

[[File:Account setup for Message-based deposits - 2.jpg|class=img-responsive|border|Set property]]

Set the values of the account property:
* Recipient account (it must be the same account, in this case, <code>ARDOR-GHKP-XWB5-XMZB-CTUE3</code>
* Property: <code>nrs_recipient_ui_options</code>
* Value: The JSON message. In this case the values of the fields are
** '''message_format''': [a-zA-Z0-9]{4,8}
** '''encrypt_message''': true
** '''encrypt_message_disabled''': false

[[File:Account_setup_for_Message-based_deposits_-_3.jpg|class=img-responsive|border|Set property values]]

Once the transaction is bundled, the account property will appear in the "Incoming" properties. It can be updated or deleted if needed.

The receiving account is now already configured. When sending funds it will check the correctness of the message format and will automatically enable the message encryption. Refer to the next section to see how to send funds to the receiving account.

==Sending funds to the receiving account==

It will be used the Ardor account <code>ARDOR-X8ZN-WUJ2-SXY3-FBUYC</code> to send funds to the previously created receiving account of the section above. First [[Login_Page_Tutorial|login into the Ardor wallet]] with the account that will send the funds.

It is possible to send any token, in this guide we will send IGNIS tokens to the <code>ARDOR-GHKP-XWB5-XMZB-CTUE3</code> already configured.

Click on the "Send IGNIS" button:

[[File:Account setup for Message-based deposits - 4.jpg|class=img-responsive|border|Send IGNIS]]

Fill the recipient account (for this case: <code>ARDOR-GHKP-XWB5-XMZB-CTUE3</code>), the amount, and the message.

===Error when sending funds due to bad-formatted message===

When the message does not fit the regular expression set up in the recipient account, it will disable the "Submit" button and will be prompted a message as follows:

[[File:Account setup for Message-based deposits - 5.jpg|class=img-responsive|border|Preventing users to send funds with a wrong message]]

===Sending funds with well-formatted message===

When the message is well-formatted it will allow sending funds to the recipient account as the following image shows:

[[File:Account setup for Message-based deposits - 6.jpg|class=img-responsive|border|Sending funds with a well-formatted message]]

</translate>

File:Account setup for Message-based deposits - 6.jpg

2021-01-11T17:08:10Z

Almonte:

File:Account setup for Message-based deposits - 5.jpg

2021-01-11T17:08:02Z

Almonte:

File:Account setup for Message-based deposits - 4.jpg

2021-01-11T17:07:53Z

Almonte: