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 an Ardor node.

The details of an 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.3.2

Length (bits)	Name	Data Definition
32	Chain	Chain id, eg. Ignis, Ardor...
8	Type	Transaction type, eg. payment/assets/marketplace
8	Subtype	Transaction subtype, eg. create bid order with asset type
8	TX Version
32	Timestamp	Current Timestamp where the epoch is the Nxt genesis block
16	Deadline	Deadline in blocks time (1 minute in mainnet, and 10 seconds in testnet) for the transaction to be processed
256	Sender Public Key	The 256-bit public key of the person sending the tx
64	Recipent/Genesis	The recipient of the transaction, genesis for transactions without recipient, eg. assets
64	Amount NQT	Amount to send to the recipient, 1 nxt = 100000000 NQT
64	Fee NQT	Fee amount, typical fee is 1 nxt/10000000 NQT
512	Signature	Signature of this transaction where this field is zero, the signature must be generated by the private key of the earlier stated public key
32	EC Block Height	Block height of referenced block for economic clustering
64	EC Block ID	ID of the block referenced above
64	Flags	Bitmap of appendages of the transaction

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 reorganized 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 are 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 than 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.