In brief
Transaction evidence moves through layers: wallet intent, node or mempool response, block inclusion, virtual processing, and accepted UTXO effects.
First Contact#
A block being present in the blockDAG is not the same statement as "this transaction has accepted consequences." The publication must keep those ideas separate.
Working Model#
Block processing, GHOSTDAG ordering, selected-parent-chain changes, acceptance data, and UTXO diffs are connected but separate. The stage model protects applications from relying on an earlier observation as if it were later consensus evidence.
Expanded Block Boundary#
A block can be seen as added to the blockDAG while the transaction-level question still needs careful wording. Block presence, graph relationship, GHOSTDAG processing, selected-parent-chain changes, acceptance data, and UTXO consequences are connected, but they are not the same statement.
This distinction matters because a user or application may be tempted to treat an early block observation as proof of final transaction consequences. The guide avoids that shortcut. It asks whether the claim is about a block object, a graph relation, a selected-parent-chain consequence, accepted transaction data, a UTXO diff, or an indexer/API presentation.
When source review is needed, the page should route to Rusty Kaspa body processing, GHOSTDAG, virtual processing, and acceptance-data paths. Until those paths support the exact wording, keep the statement narrow.
The practical review question is: what would make the claim false? If the claim says a block exists, block/body evidence may be enough. If it says a transaction became accepted, the reader needs later accepted-data or UTXO-diff evidence. If it says an application can act safely, the reader also needs to know which observation surface the application reads and whether that surface preserves the relevant state. This page should therefore prevent a block-level statement from silently becoming an application-level guarantee.