Natural order of Kaspa.

Transactions are at the core of any blockchain-based system, allowing users to transfer digital assets from one account to another. Countless transactions are made at every moment without a glimmer of thought. For the typical user, the transaction’s lifespan seems to last only a few seconds. Yet, the information it carried lasts for the life of the blockDAG. The following are the steps that a Kaspa transaction takes from beginning to end.

The user initiates a transaction, selecting UTXOs as new outputs to the intended recipients.
The wallet software constructs the transaction and transmits the transaction to a connected node, which adds it to its local mempool, propagates it to other nodes’ mempools, and waits for inclusion in a block. If not included within 60 seconds, the transaction is removed from the mempool and should be resubmitted.
Miners request a mining block template from the node, which includes transactions from the mempool. The miner then attempts to find a valid nonce that results in a block hash below the current difficulty threshold.
When a miner successfully mines a block and finds a valid nonce, they submit the block to the node for validation.
Once the node confirms that the block is valid, it propagates the block to the network, where other nodes can also validate the block. However, if the discovery of a previously unknown block should have been placed before the block containing a desired transaction and the newly discovered older block transaction uses the same UTXOs as the desired transaction. The transaction will be canceled, and its UTXOs returned and removed. The transaction from the older block will then be confirmed, effectively preventing double-spending. Only the initial attempt to spend the UTXOs will modify the UTXO set, rendering the subsequent attempts invalid.
Nodes on the network verify the validity of the new block and its transactions, add it to their blockDAG, update the UTXO set, and remove any transactions in the mempool that were included in the new block.
As more blocks are added to the blockDAG, transactions become more and more “buried” under additional blocks, which makes it exponentially more difficult to reverse or modify them. Transactions are typically considered “confirmed” after a certain number of blocks have been added on top of the block containing the transaction (e.g., 10 confirmations is a standard threshold).
If a transaction is ever reversed or modified due to a blockDAG reorganization. In that case, any UTXOs associated with that transaction are updated or removed, depending on whether they were spent or created by the transaction in question. However, after a certain point (in Kaspa’s case, 24 hours), transactions become “cemented” and are no longer subject to reorganization. At this point, any UTXOs associated with the transaction are considered confirmed and cannot be rewritten.

Once a transaction is confirmed on a blockDAG, it becomes a permanent part of the blockDAG’s public ledger. The confirmed transaction is recorded as a block. Then is added to the existing graph of blocks to forever live on the Kaspa blockDAG.

Tip: On average Kaspa currently runs at 200 transactions per second and after Rustlang rewrite the conservative estimate is around 6400 TPS.

Feel free to comment and/or ask any questions.

You can also find me on the Kaspa discord — Bubblegum Lightning