ArdorDocs - User contributions [en]

Exchange Integration Ignis

2021-08-27T09:16:22Z

Sergi: minor clarification

<languages />
<translate>
{{#seo:
|title=Exchange Integration 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, Exchange Integration Ignis
|description=The following page explains how to integrate Ignis or other child chain token into a currency exchange platform
}}
[[Category:Advanced_guides]]
__TOC__
==Introduction== 


The following page explains how to integrate the IGNIS token, the token of Ignis, the first child chain of the Ardor blockchain, into a crypto-currency exchange.


In this document we use IGNIS to refer to the token, Ignis to refer to the child chain and Ardor to refer to the platform in general.

==Prerequisites== 


Ardor node running 24/7 with fully synchronized blockchain.


It is also recommended to setup a testnet node for QA and testing purposes.


All examples in this document:


Use the 26876 testnet port. The mainnet port is 27876.


Use NXT Accounts, however, in ARDOR the NXT prefix is replaced with ARDOR prefix, everything else works the same way.


Ignis also supports numeric account ids from which the ARDOR account ids are derived. These numeric account ids has no error correction therefore we recommend that you'll never use it as any typo will lead to lost user funds.

==Accepting Deposits== 


Unlike Bitcoin's throw away addresses, Ardor addresses are somewhat expensive to maintain.


Each Ardor address and public key combination are maintained forever in the blockchain, however maintaining a completely empty account is less costly than maintaining an account with non-zero balance.


Due to this we do not recommend using a throw away Ardor address per deposit as creating these addresses require higher fees payment.


Instead, we recommend creating at most one deposit address per user or even direct all deposits to the same address and maintain user identity using a message attached to the deposit transaction.


Deposits can be accepted using one of the following approaches:


# '''Message Based Deposits''' - IGNIS deposits are sent to a single address, the user is identified by an attached message.


# '''Address per User''' - IGNIS is deposited to a new deposit address for each user.


Regardless of the method being used, always use a strong passphrase for the deposit account and protect the deposit account with a public key before accepting deposits.

===Message-Based Deposits=== 


Each payment transaction in Ignis can have an attached message, either in plain text or encrypted. This allows you to identify the user using a unique identifier such as customer number or order number specified in the message. Which identifier you will use in the message to connect the payment to a specific user account is up to you and won’t be discussed in this document.


To monitor your account for new incoming payments, the [[Accounts#Get_Blockchain_Transactions|GetBlockchainTransactions]] API call is used with the parameter executedOnly=true (the executedOnly parameter filters out phased transactions which did not execute).


The API call takes the following parameters:


* '''chain''' - child chain identifier use 2 for Ignis


* '''account''' - deposit account id

* '''timestamp''' - if specified, transactions should be newer than this block timestamp

* '''type''' - the type of transaction. For payments, this should be 0

* '''subtype''' - the transaction subtype. For payments, this should be 0 as well

* '''firstIndex''' - for pagination purposes

* '''lastIndex''' - for pagination purposes

* '''executedOnly''' - set to true to filter out phased transactions which did not execute

To monitor a specific account for payment transactions use the following URL:


<syntaxhighlight lang="bash">
http://localhost:26876/nxt?
requestType=getBlockchainTransactions&
chain=2&account=ARDOR-XK4R-7VJU-6EQG-7R335&
type=0&
subtype=0&
executedOnly=true&
includePhasingResult=true
</syntaxhighlight>


This is the JSON response:


<syntaxhighlight lang="json">
{
"transactions": [
{
"signature": "d29763e24e6a37d1ce3e20028626c72ff85c8c89003c19910a480467d321040f706e2b7bf4868958f104d38bc9899e6cbccfdffcb7b2e0a7214e31a134a7363e",
"transactionIndex": 1,
"type": 0,
"fxtTransaction": "14648538114781480244",
"phased": false,
"ecBlockId": "14641691034343322761",
"signatureHash": "c4ff8f67b36e51267421928009a7e7da97d481d0d39a79e157ee15c77e0dd710",
"attachment": {
"version.OrdinaryPayment": 0
},
"senderRS": "ABA-V4D7-D3XW-JX9Z-EAC8K",
"subtype": 0,
"amountNQT": "123000000",
"recipientRS": "ABA-XK4R-7VJU-6EQG-7R335",
"block": "6658279899956636731",
"blockTimestamp": 809066,
"deadline": 15,
"timestamp": 809009,
"height": 13648,
"senderPublicKey": "584486d2ba4dbd7eaeadd071f9f8c3593cee620e1e374033551147d68899b529",
"chain": 2,
"feeNQT": "1000000",
"confirmations": 1,
"fullHash": "8eed7b44f61235a7ec8a69b38dac5b7aaff71bb868187d56853512870f5af7d3",
"version": 1,
"sender": "14454664023893707109",
"recipient": "5873880488492319831",
"ecBlockHeight": 12926
}
... more transactions ...
]
}
</syntaxhighlight>


Loop over this array of transactions and process the transactions one by one. Note that this response includes both incoming and outgoing payment transactions. You should filter out your own (outgoing) payments by looking at the senderRS account address.

The important information of a transaction response is:


* '''senderRS''' - the sender’s account id


* '''confirmations''' - the number of confirmations

* '''amountNQT''' - the amount sent in [[API#Quantity_Units_amountNQT.2C_QNT_and_priceNQTPer.28Share.2C_Coin.2C_Unit.2C_etc..29|NQT form]]

* '''attachment.message''' - optional, an attached plain text message

* '''attachment.encryptedMessage''' - optional, an attached encrypted message

* '''timestamp''' - the time the transaction was made, in seconds since the genesis block

* '''blockTimestamp''' - the time of the block since the genesis block

* '''confirmations''' - number of confirmations received for the block in which the transaction is included


For most transactions, waiting for 10 confirmations should be enough. However, for transactions with large amount, special attention should be given to the transaction timestamp and deadline parameters, since blocks can become orphaned and transactions canceled as a result in case their deadline has passed.


When genesis time + timestamp + deadline * 60 is bigger than transaction.blockTime + 23 hours, a transaction can be accepted when the confirmations count reaches 10.


For phased transactions i.e. phased=true, verify that approved=true then check the block in which the transaction has executed not the block in which it was initially submitted using the executionHeight field. Another alternative is not to accept phased deposit transactions at all i.e. if phased=true do not credit the transaction, but then you'll have to deal with refunding this transaction manually and document that it is not allowed in the deposit dialog.


If genesis time + transaction.timestamp + transaction.deadline * 60 is smaller than transaction.blockTimestamp + 23 hours, you should wait until the transaction has 720 confirmations before crediting the user’s account. 720 blocks is the maximum depth a blockchain reorganization can go. By waiting that long, you ensure the transaction is always included. Transactions that only required 10 confirmations will be put back in the blockchain automatically due to their longer deadline time.


The default deadline in the client is 24 hours, which means that in 99% of the cases only 10 confirmations will be necessary before crediting the user’s account.


Genesis time for the Ardor blockchain is 1st of Jan, 2018 00:00:00 UTC.


To identify the user, you must look at the transaction attachment. If a plain text message is included, attachment.message is set and attachment.messageIsText is set to “true” (as string).


If an encrypted message was attached instead, attachment.encryptedMessage should exist instead. This is not just a string, but an object and contains two keys; data and nonce.


To decrypt the message use the [[Messages#Decrypt_From|decryptFrom]] API.


This API call takes the following parameters:


* '''account''' - account id that sent you the encrypted message

* '''data''' - the encrypted message data extracted from transaction.attachment.encryptedMessage.data

* '''nonce''' - the encrypted message nonce extracted from transaction.attachment.encryptedMessage.nonce

* '''decryptedMessageIsText''' - set to “true" if the message you’re trying to decrypt is text

* '''secretPhrase''' - passphrase of the account that received the encrypted message i.e. the deposit account

Example: to decrypt the message send the following request parameters:


<syntaxhighlight lang="bash">
http://localhost:26876/nxt?
requestType=decryptFrom&
secretPhrase=[passphrase from account ARDOR-EVHD-5FLM-3NMQ-G46NR]&
account=ARDOR-XK4R-7VJU-6EQG-7R335&
data=9fd7a70625996990a4cf83bf9b1568830f557136044fb3209dd7343eec2ed96ec312457c4840dabaa8cbd8c1e9b8554b&
nonce=650ef2a8641c19b9fd90a9ef22a2d50af90aa3b0de3d7a28b5ff2ad193369e7a&
decryptedMessageIsText=true
</syntaxhighlight>


The response is:
<syntaxhighlight lang="json">
{
"decryptedMessage": "test message",
"requestProcessingTime": 2
}
</syntaxhighlight>


After you have decrypted the message, you can now credit the customer account with the amount specified in transaction.amountNQT.


Note: If you wish you can show pending deposits to the user for the transaction which did not yet reach the required number of confirmations.


You could also check for new transactions since a specific block by specifying the last block’s timestamp+1 as the timestamp parameter:


<syntaxhighlight lang="bash">
http://localhost:26876/nxt?requestType=getBlockchainTransactions&...&timestamp=83099831
</syntaxhighlight>


To get the last block timestamp, you would look at the last processed transaction blockTimestamp, or use the getBlockchainStatus API described in the account-based deposits section.

====Preventing users from accidentally sending tokens without message. ''nrs_recipient_ui_options'' properties functionality====
Refer to guide [[Account Setup for Message-based Deposits]] to set up the property <code>nrs_recipient_ui_options</code> that prevents users to send funds without a message.

===Account-Based Deposits=== 


As discussed above, Ardor accounts are an expensive resource and should not be treated like disposable Bitcoin addresses.


For account-based deposits, you basically generate a new random passphrase for each user. The passphrase should be very strong and at least 35 characters long.


Once you have this passphrase, you can get the account id and public key via the [[Accounts#Get_Account_Id|getAccountId]] API call.


* '''secretPhrase''' - account passphrase


* '''publicKey''' - account public

Note that you only need to specify one of the above parameters, not both. So in our case, you just specify the secretPhrase parameter.


<syntaxhighlight lang="bash">
http://localhost:26876/nxt?
requestType=getAccountId&
secretPhrase=1234
</syntaxhighlight>


The response is:


<syntaxhighlight lang="json">
{"accountRS":"ARDOR-5WUN-YL5V-K29F-F43EJ","publicKey":"fddcda69eeca58e5d783ad1032d080d2758a4e427881b6a4a6fe43d9e7f4ac34", "account":"15577989544718496596"}
</syntaxhighlight>


On your site’s deposit page, you will need to show the account address extracted from the accountRS field i.e. '''ARDOR-5WUN-YL5V-K29F-F43EJ'''


If the account hasn’t yet had any incoming transactions, you will also need to display the publicKey to the user.


The public key doesn’t have to be displayed any more after it has had its first incoming transaction.


When a user sends funds to a new account, it needs to add the public key, so that an announcement of this key can be made. Once done, this is no longer needed.


Accounts without a public are only protected only by the 64-bit account address, not by the 256 public key.


Tracking New Account-Based Deposits


To track new deposits, it’s easiest to simply inspect all transactions in a block to see if any of them are to account addresses you generated. An alternative method would be to use the getBlockchainTransactions API detailed in message-based deposits.


(This is to be done in a loop)


Use the [[Server_info#Get_Blockchain_Status|getBlockchainStatus]] API to check if there is a new block. This API call has no parameters.


<syntaxhighlight lang="bash">
http://localhost:26876/nxt?requestType=getBlockchainStatus
</syntaxhighlight>

The response includes lastBlock (block id) and numberOfBlocks (the height).


If numberOfBlocks is different from the previous execution of this API request, one or more new blocks have been generated. The transactions from the block which now has 10 confirmations have to be fetched. You should save in your database the height of the last block you processed.


Use the new getExecutedTransactions API to load all transactions executed at a given height either directly for non-phased transactions or indirectly for phased transactions applied at this height.


<syntaxhighlight lang="bash">
http://localhost:26876/nxt?
requestType=getExecutedTransactions&
chain=2&
height=25117
</syntaxhighlight>

For each of the resulting transactions, see if the recipientRS field corresponds to one of the deposit accounts you generated for your users. If so, this is an incoming payment. Credit the user’s internal balance and send the money to your hot wallet.


Similarly to message-based deposits handling, special attention should be given to the transaction timestamp and deadline parameters


After all transactions of this block have been checked, see if you’ve processed the previous block before or not (previousBlock).


If not, traverse through the previous blocks chain until you reach the last processed block.

==Withdrawing / Sending Money== 


When a user wants to withdraw to a specific account, you ask him for the account id he wants to withdraw to. When you receive this account id, you must first check if that account has a public key attached to it or not (i.e. if it’s new or not).


To do this, you must use the [[Accounts#Get_Account_Public_Key|getAccountPublicKey]] API. It takes 1 parameter, account.


* '''account''' - account you want the public key of


<syntaxhighlight lang="bash">
http://localhost:26876/nxt?
requestType=getAccountPublicKey&
account=ARDOR-C6L6-UQ5W-RBJK-AWDSJ
</syntaxhighlight>

If the account does not have a public key, you will get this error:


<syntaxhighlight lang="json">
{ "errorCode": 5, "errorDescription": "Unknown account" }
</syntaxhighlight>

When you get this error, you should also ask the user for his public key or at least display a warning explaining the risk of using an account without a public key.


When you have both the account id and public key, you can verify that they are correct by comparing the given account id with the account id generated by the public key using the getAccountId API call.


* '''publicKey''' - account public key


We want to calculate only by publicKey so our request looks like this:


<syntaxhighlight lang="bash">
http://localhost:26876/nxt?
requestType=getAccountId&
publicKey=28f56a81e0f8555b07eacffd0e697b21cbbbdf3cf620db14522732b763564f13
</syntaxhighlight>


You’ll get back a response like this:


<syntaxhighlight lang="json">
{"accountRS":"ARDOR-C6L6-UQ5W-RBJK-AWDSJ","publicKey":"28f56a81e0f8555b07eacffd0e697b21cbbbdf3cf620db14522732b763564f13","requestProcessingTime":0,"account":"9827273118446850628"}
</syntaxhighlight>


Now compare the response accountRS to the account id the user provided. If they are equal, you can go ahead and perform the withdrawal.

Next, check if the account the user provided is configured for message-based deposits. See [[Account_Setup_for_Message-based_Deposits|Account Setup for Message-based Deposits]] page for more details.


Sending Ignis is done via the [[Accounts#Send_Money|sendMoney]] API call. The relevant parameters are:


* '''chain''' - the chain id, use 2 for Ignis


* '''recipient''' - recipient’s account address

* '''amountNQT''' - amount of Ignis (in NQT)

* '''feeRateNQTPerFXT''' - conversion rate between 1 child chain NQT to 1 whole Ardor FXT.


* '''feeNQT''' - transaction fee for the transaction in NQT. In most cases set to -1 to let the receiving node calculate the minimum fee

* '''secretPhrase''' - sender’s account passphrase

* '''deadline''' - deadline for the transaction in minutes. Should be set to the maximum value of 1440

* '''recipientPublicKey''' - recipient public key as provided by the user, only needed if the user account has no public key yet (on first transaction)

At the moment (Ardor v2.0.4e) the recipientPublicKey is optional, however not specifying it, puts the user's funds at risk. The recipientPublicKey is mandatory in case you like to attach an encrypted message to the withdrawal transaction of a new account.


This request has to be sent using '''HTTP POST'''.


The response should look like this if everything went OK:


<syntaxhighlight lang="json">
{ "fullHash": “10788f7ad3f145b5209da6145327d7fed869…”, ... a lot more information ... }
</syntaxhighlight>

If there’s an error, you may get a response such as this (other errors may apply):


<syntaxhighlight lang="json">
{ "errorCode": 5, "errorDescription": "Unknown account" }
</syntaxhighlight>


A correctly executed response should always contain the "transaction" field which represents the newly created transaction id.

====Adding a Message To a (Payment) Transaction==== 


You can add messages to any kind of transaction.


To do so, specify the below parameters in your request:


* '''message''' - plain text message.

* '''messageIsText''' - should be set to the string “true” if text.

* '''messageToEncrypt''' - plain text message that should be encrypted.

* '''messageToEncryptIsText''' - should be set to the string "true" if text.

In case you want to attach a plain text message, specify the message, and set messageIsText to “true”.

If the account to which funds are withdrawn is configured for message-based deposits, you should prevent the user from sending funds without a message, or with incorrectly formatted message. See the [[Account_Setup_for_Message-based_Deposits|Account Setup for Message-based Deposits]] guide.


If you want to attach an encrypted message that can only be read by the recipient, specify messageToEncrypt and set messgaeToEncryptIsText to “true”.


Note that these are not mutually exclusive, you can add both a plain text and encrypted message in the same transaction.


Allowing the user to add a message on your withdrawal page is recommended so that you can coordinate with other services that use a message-based deposit system.

===Hot and Cold Wallets=== 


You should not keep all of your user’s deposits in a single hot wallet. A hot wallet is a wallet for which the passphrase is stored somewhere on your server, so that you can send money from it.


Instead, you should have both a hot and cold wallet. The cold wallet should hold most of the coins and not be accessible from any of your servers. Ideally, you’d manually send from your cold wallet to your hot wallet when more coins are needed for day-to-day operations.


So the best thing to do is to have money sent to your cold wallet address, and then send out to your hot wallet manually when needed.

===Additional information=== 

====Account Format==== 


The account id is stored internally as a 64 bit signed long variable. When used in APIs it is usually returned as both unsigned number represented as string and using alphanumeric Reed-Solomon representation starting with "ARDOR-" prefix.


For example: ARDOR-ER8M-SYV3-R7EK-EUF3L


In API request parameters and response JSON, you will find both representations, the numeric representation is typically displayed as account, sender, recipient. The alphanumeric representation is typically displayed as accountRS, senderRS, recipientRS (simply always add “RS”).
RS stands for Reed-Solomon. This form of address improves reliability by introducing redundancy that can detect and correct errors when entering and using Nxt account ID’s.

====NQT Amounts==== 


Whole amounts should be converted to NQT format to be used in API calls.
NQT is the name given to 0.00000001 IGNIS (or 10^(-8) in mathematical shorthand). The NQT to Ignis ratio is equivalent to the Satoshi to Bitcoin ratio.
Simply put, 1 Ignis is 100000000 NQT, therefore to convert ignis to NQT, simply multiply by 100000000.

====Asset and currency QNT amounts==== 


Each NXT Asset and Currency (generally referred to as "Holding") has a specific number of decimal positions to which this holding is divisible.
API requests and responses always expect the holding quantity to be specified as a whole number without decimal positions. We refer to this value as QNT.
For example, when transferring 12.34 units of holding XYZ which has 4 decimal positions, specify the QNT value as 123400.

====Minimum Fee and bundling==== 


All outgoing transactions require a fee paid in the child chain token. 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 (as in NXT). 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 the parent chain token 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. Please note that this won't send the transaction. The API response will contain the full transaction JSON with the proper calculated fee. You can then replace the computed fee to actually send (broadcast) the transaction.

The default values for both `feeNQT` and `feeRateNQTPerFXT` are -1.


A transaction fee in ARDR varies depending on the status of the recipient account, sendMoney to a new account will charge a higher fee than sendMoney to an existing account so don't make any assumption about the ARDR fee the bundler will have to pay to bundle your transactions unless you check first if the recipient account is new.
One way to do this is to invoke the getAccount API on the recipient account and check for errorCode 5 in the response, then predict the fee according to the current minimum fee specifications.
A more robust approach is to submit the transaction when setting the broadcast parameter to false then read the minimumFeeFQT field from the response which indicates the minimum required fee in ARDR the bundler will pay for this transaction.


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 way the Ardor wallet works is that it first asks the user to calculate the fee then provides the best available fee from all bundlers as default fee which can be changed manually.


Alternatively, you can develop your own bundling filter which will only bundle your withdrawal transactions.
You will need to implement an interface with a single Java method or reuse the available PersonalBundler.java example.


<syntaxhighlight lang="java">
public interface Filter {
boolean ok(Bundler bundler, ChildTransaction childTransaction);
}
</syntaxhighlight>


You then register this bundling filter using the following property in your nxt.properties file:
# When running Bundlers, only bundle transactions that satisfy this filter.
# Filter class must implement the nxt.Bundler.Filter interface, see
# nxt.addons.PersonalBundler for an example.
# nxt.bundlingFilter=nxt.addons.PersonalBundler


Our recommendation is that if you know that all your withdrawal transactions will be issued from a single account, also perform the bundling using this account and use the provided PersonalBundler filter to bundle only your own withdrawal transactions and ignore other transactions. This will provide you full control over the bundling process for your Ignis withdrawals, you will pay the fee in ARDR and receive back the IGNIS you charge from your customers as transaction fees. You can regularly adjust the bundling rate based on the IGNIS per ARDR rate on your exchange.
Bundler is started or updated using the startBundler API. Also see [[Bundling]]

====Account Propertis Bundler==== 


A more flexible approach is to use the Account Property Bundler in order to designate several accounts whose transactions your bundler will bundle.


Add the property nxt.bundlingFilter=nxt.addons.AccountPropertyBundler to your nxt.properties file


Decide which account will perform the bundling (probably your Ardor deposit account which is guaranteed to contain Ardor to pay the fees), from this account submit a setAccountProperty transaction (better do it from the wallet under the dashboard --> Account Properties menu) set the recipient account to the account which will submit the child chain withdrawal transactions and the name of the property to "bundling", the value of the property is unimportant at the moment. Submit these transactions from the IGNIS chain, chain "2".


Wait for the set account properties transactions to confirm, then start a bundler from the property setter account (Ardor account) and set the bundling parameters as usual. In most cases, it makes sense to allow 0 fee transactions but it's not required.


As a result, only transactions submitted by accounts on which you set the "bundling" property will be bundled by your bundler.

====Dealing with Assets and Currencies==== 


In addition to sending the main transactional token Ignis between accounts, which is done using the sendMoney API (type:0, subType: 0) the Ardor blockchain supports two additional types of holding types: assets and currencies.


An asset typically represents a share in an entity.
Each asset is identified by the unique 64-bit transaction id of the asset issuance transaction, has a name, which is not necessarily unique, has a specific number of shares, which can be deleted and increased in the future. Asset quantities are divisible to between 0 to 8 decimal positions as specified by the asset issuance transaction. Use the getAsset API to retrieve the asset properties. Depositing and withdrawing assets is done using the transferAsset transaction, asset transfer transactions are identified by type=2 and subType=1.


A currency is a more general-purpose token, identified uniquely using a currency code, and also using the unique 64-bit transaction id of the asset issuance transaction.
Use the getCurrency API to retrieve the currency properties. Depositing and withdrawing currencies is done using the transferCurrency transaction, currency transfer transactions are identified by type=5 and subType=3.
When dealing with currencies, make sure the currency is issued, i.e. the blockchain passed the issuance height of the currency and that it is not deleted.
See more information in the monetary system documentation https://bitbucket.org/JeanLucPicard/nxt/issues/205/monetary-system-documentation


Other considerations regarding deposit and withdrawal of asset shares and currency units, for example, the treating of phased transactions and message attachments, should work the same way as Ignis deposits and withdrawals. Quantity and fee calculations for assets and currencies are explained above.

==Migration of tokens from NXT to Ardor== 


When Ardor is launched on mainnet it will be composed of two main tokens ARDR represents the parent chain token, IGNIS represents the first child chain token. There will be other child chain tokens that exchanges may want to support as well. For exchanges which already support NXT, support for the Ardor tokens can be easily implemented by porting the existing NXT integration using the [[Migrating_from_Nxt_to_Ardor|migration instructions]]

===Ardor Initial Distribution=== 


The initial balances of the ARDR token are based on the balances of the ARDR asset id 12422608354438203866 on the NXT blockchain. Each existing NXT account which holds the ARDR asset will receive the same amount of ARDR parent chain token using the same passphrase. During the snapshot period exchanges should freeze deposits and withdrawals of the ARDR token until migration from NXT asset-based trading to Ardor parent chain trading is complete.

===Ignis Initial Distribution=== 


The initial balances of the IGNIS token are based on the balances of the JLRDA currency id 823491988455668070 on the NXT blockchain. Each existing NXT account which holds the JLRDA currency will receive the same amount of IGNIS child chain token using the same passphrase. The JLRDA token is not tradable so there is no need to freeze trading.
In addition, each holder of the NXT token, will receive 0.5 IGNIS during the snapshot. Exchanges will receive these IGNIS automatically and need to make sure to credit these IGNIS tokens to their users according to their internal NXT balances at the time of the snapshot.

===Snapshot Process=== 


During the snapshot period, there is no need to freeze the trading of NXT itself. Deposits and withdrawals of the ARDR asset have to be freeze 12 hours before the snapshot and resumed only after the Ardor network is running stable in production. Internal trading of the ARDR token inside the exchange may resume.
</translate>

File:LoginSeedMasterPublicKey.png

2020-11-17T09:21:00Z

Sergi:

File:StandbyShufflerStartLegacyTab.png

2020-11-17T08:50:55Z

Sergi: Section of the start standby shuffler modal with the legacy accounts tab selected.

== Summary ==
Section of the start standby shuffler modal with the legacy accounts tab selected.

File:StandbyShuffling02.png

2020-11-17T08:46:49Z

Sergi: Sergi uploaded a new version of File:StandbyShuffling02.png

File:StandbyShuffling03.png

2020-11-17T08:41:22Z

Sergi: Sergi uploaded a new version of File:StandbyShuffling03.png

File:StandbyShuffling01.png

2020-11-17T07:57:37Z

Sergi: Sergi uploaded a new version of File:StandbyShuffling01.png

Create Transaction

2020-07-21T08:22:12Z

Sergi: fixed referencedTransaction API parameter

<languages />
<translate>

{{#seo:
|title=Create Transaction 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, Create Transaction
|description=Important description for the parameters for creating a transaction
}}
[[Category:API]]
__TOC__
The following API calls create Ardor transactions using HTTP POST requests. Follow the links for examples and HTTP POST request parameters specific to each call. Refer to the sections below for [[Create_Transaction#Create_Transaction_Request|HTTP POST request parameters]] and [[Create_Transaction#Create_Transaction_Response|JSON response fields]] common to all calls that create transactions. Calls in ''italics'' are phasing-safe (refer to [[Server_info#Get_Constants|Get Constants]] and [[Phasing#Create_Phasing_Poll|Create Phasing Poll]])


*''[[Account_Control#Set_Phasing_Only_Control|Set Phasing Only Control]]''
*''[[Account_Control#Lease_Balance|Lease Balance]]''
*''[[Accounts#Send_Money|Send Money]]''
*''[[Accounts#Set_Account_Information|Set Account Information]]''
*''[[Accounts#Set_Account_Property|Set Account Property]]''
*''[[Accounts#Delete_Account_Property|Delete Account Property]]''
*''[[Accounts#Delete_Contract_Reference|Delete Contract Reference]]''
*''[[Accounts#Set_Contract_Reference|Set Contract Reference]]''
*''[[Aliases#Buy_.2F_Sell_Alias|Buy / Sell Alias]]''
*[[Aliases#Delete_Alias|Delete Alias]]
*[[Aliases#Set_Alias|Set Alias]]
*''[[Asset_Exchange#Cancel_Order|Cancel Order]]''
*''[[Asset_Exchange#Dividend_Payment|Dividend Payment]]''
*''[[Asset_Exchange#Issue_Asset|Issue Asset]]''
*''[[Asset_Exchange#Place_Order|Place Order]]''
*''[[Asset_Exchange#Transfer_Asset|Transfer Asset]]''
*''[[Asset_Exchange#Delete_Asset_Shares|Delete Asset Shares]]''
*''[[Asset_Exchange#Increase_Asset_Shares|Increase Asset Shares]]''
*''[[Asset_Exchange#Set_Phasing_Asset_Control|Set Phasing Asset Control]]''
*''[[Child_Chain_Permissions#Add_Account_Permission|Add Account Permission]]''
*''[[Child_Chain_Permissions#Remove_Account_Permission|Remove Account Permission]]''
*''[[Coin_Exchange#Cancel_Coin_Exchange|Cancel Coin Exchange]]''
*''[[Coin_Exchange#Exchange_Coins|Exchange Coins]]''
*''[[Digital_Goods_Store#DGS_Delisting|DGS Delisting]]''
*[[Digital_Goods_Store#DGS_Delivery|DGS Delivery]]
*[[Digital_Goods_Store#DGS_Feedback|DGS Feedback]]
*''[[Digital_Goods_Store#DGS_Listing|DGS Listing]]''
*[[Digital_Goods_Store#DGS_PriceChange|DGS PriceChange]]
*[[Digital_Goods_Store#DGS_Purchase|DGS Purchase]]
*[[Digital_Goods_Store#DGS_Quantity_Change|DGS Quantity Change]]
*[[Digital_Goods_Store#DGS_Refund|DGS Refund]]
*''[[Forging#Lease_Balance|Lease Balance]]''
*''[[Forging#Bundle_Transactions|Bundle Transactions]]''
*[[Messages#Send_Message|Send Message]]
*[[Monetary_System#Currency_Buy_.2F_Sell|Currency Buy / Sell]]
*[[Monetary_System#Currency_Mint|Currency Mint]]
*[[Monetary_System#Currency_Reserve_Claim|Currency Reserve Claim]]
*[[Monetary_System#Currency_Reserve_Increase|Currency Reserve Increase]]
*[[Monetary_System#Delete_Currency|Delete Currency]]
*[[Monetary_System#Issue_Currency|Issue Currency]]
*[[Monetary_System#Publish_Exchange_Offer|Publish Exchange Offer]]
*[[Monetary_System#Transfer_Currency|Transfer Currency]]
*[[Monetary_System#Publish_Exchange_Offer|Publish Exchange Offer]]
*[[Shuffling#Shuffling_Cancel|Shuffling Cancel]]
*[[Shuffling#Shuffling_Create|Shuffling Create]]
*[[Shuffling#Shuffling_Process|Shuffling Process]]
*[[Shuffling#Shuffling_Verify|Shuffling Verify]]
*''[[Phasing#Approve_Transaction|Approve Transaction]]''
*[[Tagged_Data#Extend_Tagged_Data|Extend Tagged Data]]
*[[Tagged_Data#Upload_Tagged_Data|Upload Tagged Data]]
*[[Voting_System#Create_Poll|Create Poll]]
*[[Voting_System#Cast_Vote|Cast Vote]]

===Create Transaction Request=== 


The following HTTP POST parameters are common to all API calls that create transactions:
*''chain'' is the chain where the transaction will be generated (for instance: Ignis)
*''secretPhrase'' is the secret passphrase of the account (optional, but transaction neither signed nor broadcast if omitted)
*''privateKey'' is a hex string that represents the derived private key generated from the seed of the HD wallet
*''publicKey'' is the public key of the account (optional if ''secretPhrase'' provided)
*''feeNQT'' is the fee (in NQT) for the transaction. For child chain transactions, assuming no other fee restrictions, specify feeNQT=-1 to let the server calculate the minimum fee in ARDR and specify in the feeRateNQTPerFXT parameter the conversion rate between 1 child chain NQT to 1 whole Ardor unit.
<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 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>
*''feeRateNQTPerFXT'' is the conversion rate between 1 child chain NQT to 1 whole Ardor FXT.
*''minBundlerBalanceFXT'' is the limit on effective bundler account balance.
*''deadline'' is the deadline (in minutes) for the transaction to be confirmed, 32767 minutes maximum
*''referencedTransaction'' creates a chained transaction, meaning that the current transaction cannot be confirmed unless the referenced transaction is also confirmed (optional, format is chainId:fullHash)
*''broadcast'' is set to ''false'' to prevent broadcasting the transaction to the network (optional)
*''voucher'' see [[Transaction_Vouchers|Transaction vouchers]] (optional)
*''transactionPriority'' is either ''LOW'', ''NORMAL'' or ''HIGH'' depending on the bundler rates for automatically set the fee (optional)
'''Note:''' An optional arbitrary message can be appended to any transaction by adding message-related parameters as in [[Messages#Send_Message|Send Message]].


'''Note:''' Al transactions can use [[Secret_Sharing|Secret Sharing]] with the respective sharedPiece elements in the API transaction requests.


'''Note:''' Any phasing-safe transaction (refer to [[Create_Transaction#Create_Transaction|Create Transaction]]) can have its execution deferred either conditionally or unconditionally (refer to [[Voting_System#Phasing_operations|Create Phasing Poll]]).

===Create Transaction Response=== 


The following JSON response fields are common to all API calls that create transactions:
*''chain'' is the chain related with the transaction (for instance: Ignis)
*''signatureHash'' (S) is a SHA-256 hash of the transaction signature
*''unsignedTransactionBytes'' (S) are the unsigned transaction bytes
*''transactionJSON'' (O) is a transaction object (refer to [[Transactions#Get_Transaction|Get Transaction]] for details)
*''broadcasted'' (B) is ''true'' if the transaction was broadcast, ''false'' otherwise
*''requestProcessingTime'' (N) is the API request processing time (in millisec)
*''transactionBytes'' (S) are the signed transaction bytes
*''fullHash'' (S) is the full hash of the signed transaction
*''transaction'' (S) is the ID of the newly created transaction
</translate>

Transaction Vouchers

2020-07-16T10:19:32Z

Sergi: clarify that publicKey parameter is mandatory for vouchers

<languages />
<translate>

{{#seo:
|title=Transaction Vouchers
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, Transaction Vouchers
|description=Transaction Vouchers explained
}}
[[Category:Features]]
__TOC__
Transaction Vouchers is an Ardor feature that was introduced in the release [[Ardor_Software_Change_Log#ardor-client-2.1.0e|Ardor client 2.1.0e]]

== Introduction to Transaction Vouchers == 


See an article about [https://hackernoon.com/introduction-to-transaction-vouchers-8e7f42bbd0cb transaction vouchers] and their use cases.

== API support == 


To create a voucher set the "voucher" parameter to "true" when submitting any type of transaction. As a result the transaction won't get broadcast to the network, instead the response will include the special voucher format.
Convert this response to a file or QR code in order to generate a deliverable voucher.

Please note that the "publicKey" parameter is mandatory when "voucher" is "true", as the private key supplied is from the account signing the voucher.


<code>processVoucher</code> - the process voucher API is used to submit a transaction based on voucher file provided as parameter and the secret phrase of the account submitting the transaction.

== Usage Example == 


Vouchers are useful when Alice wants Bob to pay her in a secure tamper proof way.


Assume that Alice with account ARDOR-KX2S-UULA-7YZ7-F3R8L wants Bob whose account is ARDOR-V4D7-D3XW-JX9Z-EAC8K to pay her 100 IGNIS.
Alice logs into the wallet using Bob's address and using the normal send money dialog performs a payment from Bob to her account. But of course she cannot submit this payment since she doesn't have Bob's passphrase. Instead she enters her passphrase and checks the voucher checkbox.


[[File:Alice.asks.bob.to.pay.PNG]]


As a result the wallet generates a digitally signed voucher which she sends to Bob as a json file or QR code off blockchain. Nothing is submitted to the blockchain at this stage.
Note the download button above the voucher text.


[[File:Alice.voucher.PNG]]


Bob now uses the "Load Voucher" function from the wallet gear menu to load Alice's voucher. He double checks all the details then signs and submits voucher to the blockchain. The wallet helps Bob verify that the voucher was indeed signed by Alice, however Bob still needs to verify that the amount is correct in case of payment or in general that the transaction he is about submit is indeed acceptable according to his agreement with Alice.


[[File:Bob.submit.voucher.PNG]]


The result is that Alice received her payment while Bob now has the voucher file or QR code which represents an invoice for his financial records. Alice got her tokens and Bob is sure that he really paid Alice and that Alice indeed has a passphrase to her account.


This voucher is tamper proof, if Charlie attempts to change anything in the voucher file while in transit, the wallet will detect this change and alert Bob when he loads the voucher by reporting a "Cannot validate voucher content." message.
</translate>

File:Login Page - Master Public Key load.png

2020-06-05T07:28:18Z

Sergi:

File:Login Page - Master Public Key.png

2020-06-05T07:25:24Z

Sergi:

File:Login Page.png

2020-06-04T16:42:03Z

Sergi:

File:Login page - Hardware account list.png

2020-06-04T13:58:40Z

Sergi:

File:Login tutorial - Hardware wallet clean basic.png

2020-06-04T13:50:37Z

Sergi:

Tagged Data

2020-04-28T12:49:33Z

Sergi: full text search fields must be uppercase

<languages />
<translate>

{{#seo:
|title=Tagged Data or Data Cloud 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, Tagged Data
|description=Technical information of the Tagged Data API, also known as Data Cloud API
}}
[[Category:API]]
__TOC__
Tagged data are similar to [[API#Prunable_Data|prunable]] plain messages without a recipient, but with additional searchable metadata fields.

===Detect Mime Type === 
Gets the mime type of uploaded file or data.


'''Request:'''
*''requestType'' is ''detectMimeType''
*''data'' is the data (optional)
*''file'' is the pathname of a data file to upload (optional if ''data'' provided)
*''filename'' is a filename to associate with ''data'' (optional if ''file'' uploaded in which case the uploaded filename is always used)
*''isText'' is ''false'' if ''data'' is a hex string (optional)


'''Response'''
*''type'' (S) is the mime type
*''requestProcessingTime'' (N) is the API request processing time (in millisec)

====Detect Mime Type Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=detectMimeType&data=/9j/4AAQSkZJRgABAgAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRo...&isText=false| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=detectMimeType&
data=/9j/4AAQSkZJRgABAgAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRo...&
isText=false
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"requestProcessingTime": 348,
"type": "image/png"
}
</syntaxhighlight>
</accordion>

===Download Tagged Data=== 
Download tagged data as a file if it is still available.


'''Request:'''
*''requestType'' is ''downloadTaggedData''
*''chain'' the chain related to the operation
*''transactionFullHash'' is the transaction full hash of the tagged data
*''retrieve'' is ''true'' to retrieve pruned data from other nodes if not available (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:''' The downloaded data file named ''ardor'', unless there is an error in the request.

====Download Tagged Data Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=downloadTaggedData&chain=2&transactionFullHash=380760822f5cc9bc184b9c3136d42da0aa1d1e697798b3e296cf3c8039827df7 | Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=downloadTaggedData&
chain=2&
transactionFullHash=380760822f5cc9bc184b9c3136d42da0aa1d1e697798b3e296cf3c8039827df7
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="Response">
<syntaxhighlight lang="bash">
Downloaded file named ''Certificate.html'' with a html content
</syntaxhighlight>
</accordion>

===Get Account Tagged Data=== 
Get all available tagged data uploaded by a given account in reverse chronological order.


'''Request:'''
*''requestType'' is ''getAccountTaggedData''
*''chain'' the chain related to the operation
*''account'' is the account ID
*''firstIndex'' is a zero-based index to the first tagged data to retrieve (optional)
*''lastIndex'' is a zero-based index to the last tagged data to retrieve (optional)
*''includeData'' is ''true'' to include ''data'' (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:'''
*''data'' (A) is an array of tagged data objects (refer to [[Tagged_Data#Get_Tagged_Data|Get Tagged Data]] with ''hash'' omitted 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 Tagged Data Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAccountTaggedData&chain=2&account=ARDOR-4VDY-LNVT-LMAY-FMCKA&lastIndex=0| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAccountTaggedData&
chain=2&
account=ARDOR-4VDY-LNVT-LMAY-FMCKA&
lastIndex=0
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"data": [
{
"data": "d4f167249340d6d746f49441b8ccdb1bd3521feb",
"channel": "torrent",
"description": "Hash of the torrent.",
"type": "",
"parsedTags": [
"video",
"scifi",
"torrent"
],
"transactionTimestamp": 47843875,
"tags": "video, scifi, torrent",
"filename": "",
"accountRS": "ARDOR-4VDY-LNVT-LMAY-FMCKA",
"name": "Stargate SG1 full series",
"blockTimestamp": 47672045,
"transaction": "9086193976300572942",
"account": "15295723609781267838",
"isText": true
}
],
"requestProcessingTime": 2
}
</syntaxhighlight>
</accordion>

===Get All Tagged Data=== 
Get all available tagged data in reverse chronological order.


'''Request:'''
*''requestType'' is ''getAllTaggedData''
*''chain'' the chain related to the operation
*''includeData'' is ''true'' to include ''data'' (optional)
*''firstIndex'' is a zero-based index to the first tagged data to retrieve (optional)
*''lastIndex'' is a zero-based index to the last tagged data 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:'''
*''data'' (A) is an array of tagged data objects (refer to [[Tagged_Data#Get_Tagged_Data|Get Tagged Data]] with ''hash'' omitted 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 Tagged Data Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getAllTaggedData&chain=2&lastIndex=0| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getAllTaggedData&
chain=2&
lastIndex=0
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"data": [
{
"channel": "",
"description": "Titulo de Grado en Gestion",
"transactionFullHash": "380760822f5cc9bc184b9c3136d42da0aa1d1e697798b3e296cf3c8039827df7",
"type": "text/html",
"parsedTags": [
"universitas"
],
"transactionTimestamp": 42083391,
"tags": "Universitas",
"filename": "CertificadoFulanodeTal.html",
"accountRS": "ARDOR-46GW-VXST-EZH3-EPLD9",
"name": "Certifica Fulano de Tal",
"blockTimestamp": 42083406,
"account": "14100301901515002332",
"isText": true
}
],
"requestProcessingTime": 1
}
</syntaxhighlight>
</accordion>

===Get Channel Tagged Data=== 
Get available tagged data by channel, optionally filtered by account, in reverse chronological order.


'''Request:'''
*''requestType'' is ''getChannelTaggedData''
*''chain'' the chain related to the operation
*''channel'' is the channel string
*''account'' is an account ID (optional)
*''includeData'' is ''true'' to include ''data'' (optional)
*''firstIndex'' is a zero-based index to the first tagged data to retrieve (optional)
*''lastIndex'' is a zero-based index to the last tagged data 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:'''
*''data'' (A) is an array of tagged data objects (refer to [[Tagged_Data#Get_Tagged_Data|Get Tagged Data]] with ''hash'' omitted 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 Channel Tagged Data Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getChannelTaggedData&chain=2&channel=video&lastIndex=0| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getChannelTaggedData&
chain=2&
channel=video&
lastIndex=0
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"data": [
{
"data": "d4f167249340d6d746f49441b8ccdb1bd3521feb",
"channel": "video",
"description": "Hash of the video.",
"type": "",
"parsedTags": [
"video",
"scifi",
"torrent"
],
"transactionTimestamp": 47843875,
"tags": "video, scifi, torrent",
"filename": "",
"accountRS": "ARDOR-4VDY-LNVT-LMAY-FMCKA",
"name": "Stargate SG1 full series",
"blockTimestamp": 47672045,
"transactionFullHash": "380760822f5cc9bc184b9c3136d42da0aa1d1e697798b3e296cf3c8039827df7",
"account": "15295723609781267838",
"isText": true
}
],
"requestProcessingTime": 1
}
</syntaxhighlight>
</accordion>

===Get Data Tag Count=== 
Get the total number of distinct available data tags.


'''Request:'''
*''requestType'' is ''getDataTagCount''
*''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:'''
*''numberOfDataTags'' (N) is the total number of distinct data tags
*''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 Data Tag Count Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getDataTagCount&chain=2| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getDataTagCount&
chain=2
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"numberOfDataTags": 36,
"requestProcessingTime": 2
}
</syntaxhighlight>
</accordion>

===Get Data Tags=== 
Get the distinct tags of all available tagged data, with the number of uses of each tag, in order of number of uses, then alphabetical order.


'''Request:'''
*''requestType'' is ''getDataTags''
*''chain'' the chain related to the operation
*''firstIndex'' is a zero-based index to the first tag to retrieve (optional)
*''lastIndex'' is a zero-based index to the last tag 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:'''
*''tags'' (A) is an array of tag objects including the fields:
** ''tag'' (S) is a tag word
**''count'' (N) is the number of uses of ''tag'' among all tagged data
*''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 Data Tags Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getDataTags&chain=2| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getDataTags&
chain=2
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"requestProcessingTime": 5,
"tags": [
{
"count": 2,
"tag": "video"
},
{
"count": 1,
"tag": "scifi"
},
{
"count": 1,
"tag": "torrent"
}
]
}
</syntaxhighlight>
</accordion>

===Get Data Tags Like=== 
Prefix search of available data tags, return in alphabetical order.


'''Request:'''
*''requestType'' is ''getDataTagsLike''
*''chain'' the chain related to the operation
*''tagPrefix'' is the prefix to search for (2 character minimum) among all data tags
*''firstIndex'' is a zero-based index to the first tag to retrieve (optional)
*''lastIndex'' is a zero-based index to the last tag 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:'''
*''tags'' (A) is an array of tag objects including the fields:
** ''tag'' (S) is a tag word
**''count'' (N) is the number of uses of ''tag'' among all tagged data
*''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 Data Tags Like Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getDataTagsLike&chain=2&tagPrefix=con| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getDataTagsLike&
chain=2&
tagPrefix=con
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"requestProcessingTime": 2,
"tags": [
{
"count": 3,
"tag": "contract"
},
{
"count": 1,
"tag": "contracts"
}
]
}
</syntaxhighlight>
</accordion>

===Get Tagged Data=== 
Get available tagged data given a transaction full hash.


'''Request:'''
*''requestType'' is ''getTaggedData''
*''chain'' the chain related to the operation
*''transactionFullHash'' is the transaction Full Hash
*''includeData'' is ''true'' to include ''data'' (optional)
*''retrieve'' is ''true'' to retrieve pruned data from other nodes if not available (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:'''
*''data'' (S) is the tagged data
*''channel'' (S) is the metadata ''channel'' field
*''description'' (S) is the metadata ''description'' field
*''transactionFullHash'' (S) is the is the transaction Full Hash of the tagged data
*''type'' (S) is the metadata ''type'' field
*''parsedTags'' (A) is an array of tag words (S) parsed from ''tags''
*''filename'' (S) is the metadata ''filename'' field
*''transactionTimestamp'' (N) is the transaction timestamp (in seconds since the genesis block)
*''tags'' (S) is the metadata ''tags'' field
*''accountRS'' (S) is the Reed-Solomon address of the uploading account
*''name'' (S) is the metadata ''name'' field
*''isText'' (B) is the metadata ''isText'' field
*''account'' (S) is the number of the account that originally uploaded the tagged data
*''blockTimestamp'' (N) is the block timestamp (in seconds since the genesis 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)
'''Note:''' Refer to [[Tagged_Data#Upload_Tagged_Data|Upload Tagged Data]] for details about the ''data'' and metadata (''filename'', ''name'', ''description'', ''tags'', ''type'', ''channel'' and ''isText'') fields.

====Get Tagged Data Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=getTaggedData&chain=2&transactionFullHash=380760822f5cc9bc184b9c3136d42da0aa1d1e697798b3e296cf3c8039827df7| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=getTaggedData&
transactionFullHash=380760822f5cc9bc184b9c3136d42da0aa1d1e697798b3e296cf3c8039827df7
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"data": "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\">\n<html>\n<head>\n\t<meta http-equiv=\"content-type\" content=\"text/html; charset=utf-8\"/>\n\t<title></title>\n\t<meta name=\"generator\" content=\"LibreOffice 4.4.3.2 (MacOSX)\"/>\n\t<meta name=\"created\" content=\"2019-04-27T13:00:03.468019409\"/>\n\t<meta name=\"changed\" content=\"2019-04-27T16:50:06.047410833\"/>\n\t<style type=\"text/css\">\n\t\t@page { margin: 2cm }\n\t\tp { margin-bottom: 0.25cm; line-height: 120% }\n\t</style>\n</head>\n<body lang=\"es-ES\" dir=\"ltr\">\n \n\n\n<table width=\"807\" cellpadding=\"8\" cellspacing=\"0\">\n\t<col width=\"117\">\n\t<col width=\"657\">\n\t<tr valign=\"top\">\n\t\t<td rowspan=\"3\" width=\"117\" style=\"border: none; padding: 0cm\">\n\t\t\tUNIVERSITAS\n\t\t\tGRADUS\n\t\t\tMIRABILIS\n\t\t</td>\n\t\t<td width=\"657\" style=\"border: none; padding: 0cm\">\n\t\t\tUNIVERSIDAD DE\n\t\t\tTITULACIONES MARAVILLOSAS\n\t\t\t[Wonderful Degrees\n\t\t\tUniversity]\n\t\t</td>\n\t</tr>\n\t<tr valign=\"top\">\n\t\t<td width=\"657\" style=\"border: none; padding: 0cm\">\n\t\t\tFACULTAD DE ECONOMICAS\n\t\t\t[College\n\t\t\tof Economics]\n\t\t</td>\n\t</tr>\n\t<tr valign=\"top\">\n\t\t<td width=\"657\" style=\"border: none; padding: 0cm\">\n\t\t\t \n\n\t\t\t\n\t\t\t<table width=\"807\" cellpadding=\"8\" cellspacing=\"0\">\n\t\t\t\t<col width=\"791\">\n\t\t\t\t<tr>\n\t\t\t\t\t<td width=\"791\" valign=\"top\" style=\"border: none; padding: 0cm\">\n\t\t\t\t\t\tCERTIFICADO\n\t\t\t\t\t\tACADEMICO \n\t\t\t\t\t\t[Academic\n\t\t\t\t\t\tCertificate]\n\t\t\t\t\t</td>\n\t\t\t\t</tr>\n\t\t\t</table>\n\t\t\t \n\n\t\t\t\n\t\t</td>\n\t</tr>\n</table>\n \n\n\n \n\n\n<table width=\"856\" cellpadding=\"8\" cellspacing=\"0\">\n\t<col width=\"82\">\n\t<col width=\"5138\">\n\t<col width=\"71\">\n\t<col width=\"126\">\n\t<col width=\"47\">\n\t<col width=\"51\">\n\t<col width=\"92\">\n\t<col width=\"67\">\n\t<col width=\"41\">\n\t<col width=\"85\">\n\t<col width=\"23\">\n\t<tr valign=\"top\">\n\t\t<td colspan=\"3\" width=\"179\" style=\"border: none; padding: 0cm\">\n\t\t\tNOMBRE\n\t\t\tDEL ALUMNO\n\t\t\t[Student's\n\t\t\tName]\n\t\t</td>\n\t\t<td colspan=\"3\" width=\"256\" style=\"border: none; padding: 0cm\">\n\t\t\tFulano\n\t\t\tde Tal Martínez\n\t\t</td>\n\t\t<td colspan=\"5\" width=\"373\" style=\"border: none; padding: 0cm\">\n\t\t\tDOCUMENTO\n\t\t\tIDENTIFICATIVO:\n\t\t\t44555884V\n\t\t\t[ID]\n\t\t\t\n\t\t\t\n\t\t</td>\n\t</tr>\n\t<tr valign=\"top\">\n\t\t<td width=\"82\" style=\"border: none; padding: 0cm\">\n\t\t\tESTUDIOS [Studies]\n\t\t</td>\n\t\t<td colspan=\"10\" width=\"743\" style=\"border: none; padding: 0cm\">\n\t\t\tGRADO\n\t\t\tEN GESTIÓN DE\n\t\t\tGRANJAS \n\t\t\tPORCINAS[Bachelor’s\n\t\t\tDegree in Pork\n\t\t\tFarm\n\t\t\tManagement]\n\t\t</td>\n\t</tr>\n\t<tr valign=\"top\">\n\t\t<td colspan=\"2\" width=\"93\" style=\"border: none; padding: 0cm\">\n\t\t\tAREA ISCED\n\t\t\t[ISCED\n\t\t\tArea]\n\t\t</td>\n\t\t<td colspan=\"3\" width=\"276\" style=\"border: none; padding: 0cm\">\n\t\t\t0.4\n\t\t\t- 346\n\t\t</td>\n\t\t<td colspan=\"2\" width=\"160\" style=\"border: none; padding: 0cm\">\n\t\t\t \n\n\t\t\t\n\t\t</td>\n\t\t<td colspan=\"2\" width=\"124\" style=\"border: none; padding: 0cm\">\n\t\t\tBOE:\n\t\t\t11/04/2013\n\t\t\t[OSG]\n\t\t</td>\n\t\t<td colspan=\"2\" width=\"124\" style=\"border: none; padding: 0cm\">\n\t\t\tECTS:\n\t\t\t240.0\n\t\t</td>\n\t</tr>\n\t<tr valign=\"top\">\n\t\t<td colspan=\"3\" width=\"179\" style=\"border: none; padding: 0cm\">\n\t\t\tFECHA\n\t\t\tDE EMISIÓN (DD/MM/AAAA:\n\t\t\t [DATE\n\t\t\tof Issue DD/MM/YYYY]\n\t\t</td>\n\t\t<td width=\"126\" style=\"border: none; padding: 0cm\">\n\t\t\t02/07/2018\n\t\t</td>\n\t\t<td colspan=\"2\" width=\"114\" style=\"border: none; padding: 0cm\">\n\t\t\t \n\t\t\t\n\t\t</td>\n\t\t<td colspan=\"2\" width=\"175\" style=\"border: none; padding: 0cm\">\n\t\t\t \n\n\t\t\t\n\t\t</td>\n\t\t<td colspan=\"2\" width=\"143\" style=\"border: none; padding: 0cm\">\n\t\t\tNOTA\n\t\t\tMEDIA ( 1-10 )\n\t\t\t[Average\n\t\t\tGrade (1-10)]\n\t\t</td>\n\t\t<td width=\"23\" style=\"border: none; padding: 0cm\">\n\t\t\t9.40\n\t\t</td>\n\t</tr>\n</table>\n \n\n\n</body>\n</html>",
"channel": "",
"description": "Titulo de Grado en Gestion",
"transactionFullHash": "380760822f5cc9bc184b9c3136d42da0aa1d1e697798b3e296cf3c8039827df7",
"requestProcessingTime": 0,
"type": "text/html",
"parsedTags": [
"universitas"
],
"transactionTimestamp": 42083391,
"tags": "Universitas",
"filename": "CertificadoFulanodeTal.html",
"accountRS": "ARDOR-46GW-VXST-EZH3-EPLD9",
"name": "Certifica Fulano de Tal",
"blockTimestamp": 42083406,
"account": "14100301901515002332",
"isText": true
}
</syntaxhighlight>
</accordion>

===Search Tagged Data=== 
Full text search on available tagged data name, description and tags; optionally filtered by tag, channel or uploading account; return in reverse relevance order.


'''Request:'''
*''requestType'' is ''searchTaggedData''
*''chain'' the chain related to the operation
*''query'' is a full text query on the metadata fields (must be uppercase) ''NAME'' (S), ''DESCRIPTION'' (S) and ''TAGS'' (S) in the [http://lucene.apache.org/core/2_9_4/queryparsersyntax.html#Overview standard Lucene syntax]
*''tag'' is a word in the ''tags'' string (optional)
*''channel'' is a channel string (optional)
*''account'' is an account ID (optional)
*''includeData'' is ''true'' to include ''data'' (optional)
*''adminPassword'' [[API#Admin_Password|Admin password parameter (optional)]]
*''firstIndex'' is a zero-based index to the first tagged data to retrieve (optional)
*''lastIndex'' is a zero-based index to the last tagged data 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:'''
*''data'' (A) is an array of tagged data objects (refer to [[Tagged_Data#Get_Tagged_Data|Get Tagged Data]] with ''hash'' omitted 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)

====Search Tagged Data Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=searchTaggedData&chain=2&query=SG%3F&lastIndex=0| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=searchTaggedData&
chain=2&
query=contrac?&
lastIndex=0
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"data": [
{
"channel": "contracts",
"description": "{\"description\":\"This contract is an implementation of Jelurida's Identity Verification hackathon challenge (https:\\/\\/www.jelurida.com\\/ardor-hackathon-2018)\",\"version\":\"v0.9.0\"}",
"transactionFullHash": "8dde06360b7d4fe4523c2eecaa44a9f6b093e1fe917d2dbf00793751cef1298b",
"type": "application/java-archive",
"parsedTags": [],
"transactionTimestamp": 32791231,
"tags": "",
"filename": "contract.jar",
"accountRS": "ARDOR-5TT2-VS3T-EUTS-7WDBA",
"name": "some.one.contract.IdentityVerification",
"blockTimestamp": 32791240,
"account": "6063389766308718368",
"isText": false
}
],
"requestProcessingTime": 5
}
</syntaxhighlight>
</accordion>

===Upload Tagged Data=== 
Upload and broadcast new tagged data. POST only.


'''Request:''' Refer to [[Create_Transaction#Create_Transaction_Request|Create Transaction Request]] for common parameters.
*''requestType'' is ''uploadTaggedData''
*''chain'' the chain related to the operation
*''name'' is the name or title of ''data'' (optional if ''file'' uploaded in which case the uploaded filename is used, but ''name'' takes precedence if provided)
*''description'' is a description of ''data'' (optional)
*''tags'' is a list of up to 5 words from 3 to 20 characters long and separated by spaces and/or commas, describing the actual content of ''data''; for example: ''audio,mp3,classical'' (optional)
*''type'' is the mime type of ''data'' such as ''torrent'', ''pdf'', ''doc'', ''image'', etc. (optional)
*''channel'' is a data feed label such as ''contracts'', ''wikileaks'', etc. (optional)
*''isText'' is ''false'' if ''data'' is a hex string (optional)
*''filename'' is a filename to associate with ''data'' (optional if ''file'' uploaded in which case the uploaded filename is always used)
*''data'' is the data (optional)
*''file'' is the pathname of a data file to upload (optional if ''data'' provided)


'''Note:''' The maximum length of ''data'' plus all associated metadata is 42 kilobytes. The maximum length of ''description'' is 1000 bytes. The maximum length of the other metadata (''name'', ''tags'', ''type'', ''channel'' and ''filename'') is 100 bytes each.


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

====Upload Tagged Data Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=uploadTaggedData&chain=2&data=d4f167249340d6d746f49441b8ccdb1bd3521feb&name=Stargate%20SG1%20full%20series&description=Hash%20of%20the%20torrent.&tags=video%2C%20scifi%2C%20torrent&channel=torrent&secretPhrase=secretPhrase&feeNQT=100000000&deadline=60| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=uploadTaggedData&
chain=2&
data=d4f167249340d6d746f49441b8ccdb1bd3521feb&
name=Stargate SG1 full series&
description=Hash of the torrent.&
tags=video, scifi, torrent&
channel=torrent&
secretPhrase=secretPhrase&
feeNQT=100000000&
deadline=60
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"minimumFeeFQT": "34000000",
"signatureHash": "953a1023c84939a6e31da0db913ed2829b318d59663daddce63bdf2193af912e",
"transactionJSON": {
"senderPublicKey": "10f09c34f225d425306e5be55a4946908156072afbead4d574a512d7e086ef5c",
"chain": 2,
"signature": "17da947a7dc30a6d722a53f064d817c559f8f9c1387290048793d81b49dbf5082a0...",
"feeNQT": "100000000",
"type": 6,
"fullHash": "0e91b0dd47a5187e26ea5b54f1917e3b879ee3cf096eb597ce22c6833863cdb2",
"version": 1,
"fxtTransaction": "0",
"phased": false,
"ecBlockId": "7868019187120003959",
"signatureHash": "953a1023c84939a6e31da0db913ed2829b318d59663daddce63bdf2193af912e",
"attachment": {
"filename": "",
"data": "d4f167249340d6d746f49441b8ccdb1bd3521feb",
"name": "Stargate SG1 full series",
"channel": "torrent",
"description": "Hash of the torrent.",
"type": "",
"version.TaggedDataUpload": 1,
"isText": true,
"hash": "06fbac5b5358c00f5a2f19789b06220dca4e242a851b70072633a06ae8e6fb46",
"tags": "video, scifi, torrent"
},
"senderRS": "ARDOR-4VDY-LNVT-LMAY-FMCKA",
"subtype": 0,
"amountNQT": "0",
"sender": "15295723609781267838",
"ecBlockHeight": 304598,
"deadline": 60,
"transaction": "9086193976300572942",
"timestamp": 47671075,
"height": 2147483647
},
"unsignedTransactionBytes": "06102367d7023c0010f09c34f225d425306e5be55a494...",
"broadcasted": true,
"requestProcessingTime": 284,
"transactionBytes": "06102367d7023c0010f09c34f225d425306e5be55a49469081560...",
"fullHash": "0e91b0dd47a5187e26ea5b54f1917e3b879ee3cf096eb597ce22c6833863cdb2",
"bundlerRateNQTPerFXT": "10000000"
}
</syntaxhighlight>
</accordion>

===Verify Tagged Data=== 
Verify expired tagged data downloaded from another node, against the hash in the blockchain.


'''Request:'''
*''requestType'' is ''verifyTaggedData''
*''chain'' the chain related to the operation
*''transactionFullHash'' is the transaction Full Hash
*''data'' is the tagged data (optional)
*''file'' s the pathname of a data file to upload (optional if ''data'' provided)
*''filename'' (S) is the metadata ''filename'' field
*''name'' (S) is the metadata ''name'' field
*''description'' (S) is the metadata ''description'' field
*''tag'' is a word in the ''tags'' string (optional)
*''type'' is the mime type of ''data'' such as ''torrent'', ''pdf'', ''doc'', ''image'', etc. (optional)
*''channel'' is a channel string (optional)
*''isText'' (B) is the metadata ''isText'' field
*''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:''' The ''data'' and metadata (''filename'', ''name'', ''description'', ''tags'', ''type'', ''channel'' and ''isText'') must have exactly the same values as when the data was uploaded (refer to [[Tagged_Data#Upload_Tagged_Data|Upload Tagged Data]]).


'''Response:'''
*''verify'' (B) is ''true'' if the hash of the provided ''data'' and metadata matches the hash in the blockchain
*''hash'' (S) is the hash of the tagged data
*''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)
*''version.TaggedDataUpload'' (N) is ''1'', the version number
'''Note:''' This call returns an error if there is a hash mismatch.

====Verify Tagged Data Example==== 
<accordion parent="accordion" heading="Request"><btn size="sm">https://testardor.jelurida.com/test?requestType=verifyTaggedData&chain=2&transactionFullHash=95abb707e526cd14d01e5c41f62effa78a90a7b3887e1c5521309a7698ea4af7&data=d4f167249340d6d746f49441b8ccdb1bd3521feb&name=Stargate%20SG1%20full%20series&description=Hash%20of%20the%20torrent.&tags=video%2C%20scifi%2C%20torrent&channel=torrent| Test request|btn-primary</btn>
<syntaxhighlight lang="bash">
http://localhost:27876/nxt?
requestType=verifyTaggedData&
chain=2&
transactionFullHash=95abb707e526cd14d01e5c41f62effa78a90a7b3887e1c5521309a7698ea4af7&
data=d4f167249340d6d746f49441b8ccdb1bd3521feb&
name=Stargate SG1 full series&
description=Hash of the torrent.&
tags=video, scifi, torrent&
channel=torrent
</syntaxhighlight>
</accordion>
<accordion parent="accordion" heading="Response">
<syntaxhighlight lang="json">
{
"verify": true,
"requestProcessingTime": 7,
"version.TaggedDataUpload": 1,
"hash": "06fbac5b5358c00f5a2f19789b06220dca4e242a851b70072633a06ae8e6fb46"
}
</syntaxhighlight>
</accordion>
</translate>

File:NodeRewardProgram-initial message.png

2020-03-20T09:40:59Z

Sergi: Node Reward Program, initial message example

== Summary ==
Node Reward Program, initial message example

File:Add approval model.png

2019-10-11T09:00:23Z

Sergi: Sergi uploaded a new version of File:Add approval model.png

File:Reproduce Secret modal.png

2019-10-11T07:49:20Z

Sergi: The "Reproduce Secret" modal of a "Approved by Hash" phasing approval model.

== Summary ==
The "Reproduce Secret" modal of a "Approved by Hash" phasing approval model.

File:ApprovalModels-Hash.png

2019-10-11T07:48:28Z

Sergi: Shows a "approved by hash" approval model with the "Reproduce Secret" button.

== Summary ==
Shows a "approved by hash" approval model with the "Reproduce Secret" button.

File:Phasing by secret.png

2019-10-11T07:39:50Z

Sergi: Sergi uploaded a new version of File:Phasing by secret.png

File:Processes SaveContractRunner.png

2019-10-10T09:58:28Z

Sergi: Example screenshot of the Save modal for the Contract Runner processes UI.

== Summary ==
Example screenshot of the Save modal for the Contract Runner processes UI.

File:Processes start.png

2019-07-15T13:17:30Z

Sergi:

Process start modal.

File:Processes save encryption.png

2019-07-15T13:07:47Z

Sergi:

Process save modal with all secret phrases fullfilled and asking for the encryption passphrase.

File:Processes save secrets.png

2019-07-15T13:02:41Z

Sergi:

Processes save modal with pending passphrases.

File:Processes page.png

2019-07-15T12:56:43Z

Sergi:

Processes page showing the processes list with their corresponding action buttons.

File:Processes01.png

2019-07-15T12:39:26Z

Sergi: Processes page link under Settings.

== Summary ==
Processes page link under Settings.