Toccata 101 · Part 1 · card 5
Press any line to break it, press it again to mend it.
Every node runs the same list. One thing fails and the whole transaction drops out.
The node doesn't know what the script is for. It confirms this script is the one the address was made from, then runs it and asks one thing: yes or no.
The transaction goes into the mempool, then to the peers. Every node validates for itself and repeats steps 2 to 4.
Miners get rewards only for blocks and transactions accepted by every node in the network, and a block that breaks the rules costs them the resources they wasted on it. It is an incentive game, and bad actors cannot sustainably play it.
The block spreads, each node re-checks each transaction, the UTXO set changes: inputs gone, outputs born. If one transaction inside a block fails the re-check, the nodes skip that transaction and keep the block. There is no limit, every transaction in a block may fail this re-check and the block stays. Kaspa's blocks are built to tolerate that, which is what lets ten of them a second run in parallel.
How many confirmations make "confirmed" is the wallet's choice, not the network's. The reference wallet code marks a payment confirmed after 100 blocks, about ten seconds, and a mined reward after 1,000, about 100 seconds. The 1,000 is the only line the network itself enforces: a mined reward cannot be spent before it, and many wallets show "confirmed" at 1,000 for everything because of it. Spending earlier is allowed, a node's mempool takes a spend of an output the moment the output exists, so a wallet may let you pay onward with coins that arrived seconds ago.
After 432,000 blocks, twelve hours at ten a second, the node itself will never undo it. Twelve hours is a wall Kaspa chose: past that depth a node refuses to switch to any other version of history, however much work it carries, so even a miner with most of the hash power cannot rewrite anything older than that. A deeper disagreement would need a network split longer than twelve hours, longer than any accident the network is built to survive on its own.
Every check on this page is a function in rusty-kaspa v2.0.1, read at that tag. Step 2: tx_validation_in_isolation.rs (validate_tx_in_isolation, in that order). Steps 3 and 4: tx_validation_in_utxo_context.rs (validate_populated_transaction_and_get_fee: coinbase maturity, input amounts, output values, mass commitment, sequence lock, fee rate, covenant info, then check_scripts), the script engine in crypto/txscript/src/lib.rs (execute_inner: the signature script, the lock, then for a p lock the revealed script on the saved stack), opcodes in opcodes/mod.rs, mass in consensus/core/src/mass/mod.rs. Step 5: mining/src/mempool/validate_and_insert_transaction.rs and the relay flow protocol/flows/src/v7/txrelay/flow.rs (peers announce ids, request what they lack, validate, then announce onward). Step 6: block templates in mining/src/mempool/model/frontier/selectors.rs, proof of work in consensus/pow/src/lib.rs. Step 7: header checks in header_processor/pre_ghostdag_validation.rs, block body checks in body_processor/body_validation_in_isolation.rs, the re-check of each transaction, the skipping of the ones that fail and the coinbase in virtual_processor/utxo_validation.rs (validate_transactions_in_parallel, verify_expected_utxo_state) and processes/coinbase.rs (one output per blue block in the merge set, subsidy plus the fees of the transactions accepted from it). Step 8: the reference wallet's 100-block maturity for received transactions in wallet/core/src/utxo/settings.rs, finality at 432,000 blocks (twelve hours) in consensus/core/src/config/constants.rs and bps.rs. The chain data comes from api.kaspa.org, read live for a pasted id and on 8 September 2026 for the example. The fingerprint check and the sums are recomputed in your browser, nothing else leaves the page.