How Signum Transaction Processing Works

Every Signum wallet acts as a node supporting transaction processing when connected to the network.

A Signum transaction, such as a payment from party A to party B, is initiated by entering transaction details in a Signum wallet.  The intended transaction is broadcast to the network as a transaction object with a transaction ID and the transaction details.  Synchronized nodes evaluate the transaction’s attributes to determine if it is valid.

All values for the transaction detail inputs are bounds checked.

• Are all mandatory details specified?
• Is the specified transaction fee greater than or equal to the minimum transaction fee?
• Is the transaction deadline at least one minute into the future?

If there are no exceptions, transaction processing continues as follows:

• The sending account’s public key is calculated using the supplied secret passphrase.
• The sending account’s balance is retrieved from a scan of the blockchain.

The following items are checks for the sending account’s balance:

• Is the sending account’s balance greater than zero?
• Is the sending account’s confirmed balance greater than or equal to the transaction amount plus the transaction fee?
• Is the sending account’s confirmed balance sufficient to cover the transaction amount plus the transaction fee for the current transaction and any other transaction from the same account that has not yet been confirmed?

If the sending account has a sufficient balance, processing continues as follows:

• A transaction object is created that includes all of the transaction’s details.  The transaction is assigned a transaction number.
• The transaction is signed using the sending account’s private key.
• The encrypted transaction data is placed within a message that instructs network peers to process the transaction.
• The transaction is broadcast to all network peers.

Note:  If any detail checks fail, the network will respond with an error code and a message.

Valid transactions are added to the ‘unconfirmed transaction store,’ a holding area within the ‘mempool .’ When a new block is generated, these transactions are prioritized by the block generator.  As many as possible are added, subject to a limit on the number of transactions per block (255) and the maximum number of bytes.

Phased transactions are included first, selected according to the block height at which they were accepted into the blockchain.  If two-phased transactions were accepted at the same block height, the transaction with the lower index number is selected first.  After all phased transactions are included, regular unconfirmed transactions are included, selected according to the specified fee, and then by timestamp if multiple transactions have the same specified fee.  Note:  The selection order is not retained when a block is finalized.  Transactions will be ordered only by timestamp.  The new block is added to the chain of blocks that make up Signum’s immutable distributed shared ledger.  Any transaction that was not included remains in the holding area pending inclusion in a future block.

Transactions are considered to have one confirmation when they are first included in a block.  Each subsequent block adds another confirmation to the transaction.  Signum transactions are considered reliable after 10 confirmations.  Up to 1,440 blocks can be “reorganized” by the network in case of problems, so a transaction with 1,440 confirmations is considered irreversible.

The byte order of a send transaction is as follows: