How Tx Processing Works

Transactions

Calculating the balances of each Ardor account require a scan of the entire blockchain. While this might sound inefficient, with the current day network speeds and CPU speeds it is not that big of a computational task. This offloads the work required of the Ardor server and thus allows even low powered mobile devices to be a Ardor node.

The details of a Ardor transaction are as follows:

1. The sender specifies parameters for the transaction. Types of transactions vary (sending money, creating an alias, transmitting a message, issuing an asset or an order for an asset) but several parameters must be specified for any transaction:
   • the secret passphrase for the sending account
   • a specified fee of the transaction
   • a deadline for the transaction
   • an optional "referenced" transaction
2. All values for the transaction inputs are checked. For example, mandatory parameters must be specified; fees cannot be less than or equal to zero; a transaction deadline cannot be less than 1 minute into the future.
3. If no exceptions are thrown as a result of parameter checking:
   1. The public key for the generating account is computed using the supplied secret passphrase
   2. Account information generating account is retrieved, and transaction parameters are further validated:
      • The sending account's balance cannot be zero
      • The sending account's confirmed balance must not be lower than the transaction amount plus the transaction fee
   3. If the sending account has sufficient funds for the transaction:
      1. A new transaction is created, with a type and subtype value set to match the kind of transaction being made (sending money, creating an alias, sending a message, etc.). All specified parameters are included in the Transaction object. A unique transaction ID is generated with the creation of the object
      2. The transaction is signed using the sending account's private key
      3. The encrypted transaction data is placed within a message instructing network peers to process the transaction
      4. The transaction is broadcast to all peers on the network
4. The server responds with a result code: the transaction ID, if the transaction creation was successful; an error code and error message if any of the parameter checks failed.

Byte Order

The byte order of a send Ardor transaction. Verified: NRS v2.1.0e

Length (bits)	Name	Data Definition	Cumulative Total (bytes)
8	Type	Transaction type, eg. payment/assets/marketplace	1
4	TX Version	1 currently, added attachments and appendages	1.5
4	Subtype	Transaction subtype, eg. create bid order with asset type	2
32	Timestamp	Current Timestamp where the epoch is the Nxt genesis block	6
16	Deadline	Deadline in minutes for the transaction to be processed	8
256	Sender Public Key	The 256-bit public key of the person sending the tx	40
64	Recipent/Genesis	The recipent of the transaction, genesis for txs without recipient, eg. assets	48
64	Amount NQT	Amount to send to the recipient, 1 nxt = 100000000 NQT	56
64	Fee NQT	Fee amount, typical fee is 1 nxt/10000000 NQT	64
256	Referenced Transaction Full Hash	Full hash for transaction to reference, usually left blank	96
512	Signature	Signature of this transaction where this field is zero, signature must be generated by the private key of the earlier stated public key	160
32	Flags	Flags for position 1 for arbitrary message, position 2 for encrypted message, position 3 for public key announcement, position 4 for encrypted message to self	164
32	EC Block Height	Block height of referenced block for economic clustering	168
64	EC Block ID	ID of the block referenced above	176

Transaction Confirmations

All Ardor transactions are considered "unconfirmed" until they are included in a valid network block. Newly-created blocks are distributed to the network by the account that creates them, and a transaction that is included in a block is considered to be confirmed once. Since subsequent blocks are added to the existing chain of blocks, each additional block adds one more confirmation to the number of confirmations for a transaction.

Ardor transactions are deemed reliable after 10 confirmations. Up to 720 recent blocks can be "re-organized" by the network in case of problems, so a transaction is considered irreversible after 721 confirmations. Transactions that have been confirmed 1440 times are considered permanent.

Transactions Order within a Block

Each child chain block is limited to 100 transactions, each Ardor block can have up to 10 child chain blocks. Therefore when more than 1000 transactions are ready to be included, the block generator needs to select which transactions to include in the next block.

The selection criteria is as follows:

Phased transactions are processed first, ordered by height (when they were accepted in the blockchain) and then index (for phased transactions accepted at the same height). Only then the regular unconfirmed transactions are processed sorted by fee then by arrival timestamp.

The sort by fee, then arrival timestamp only determines which unconfirmed transactions make it into the block. Within the block, the unconfirmed transactions are sorted by arrival timestamp.