In brief
Transaction evidence moves through layers: wallet intent, node or mempool response, block inclusion, virtual processing, and accepted UTXO effects.
Required Stage Model#
wallet build/sign -> RPC submit -> mempool admit/reject -> template candidate -> mined block/DAG add -> virtual selected-parent-chain change -> acceptance data/UTXO diff -> RPC/indexer/API observation
First Contact#
A transaction is not one event. It moves through stages, and each stage has a different evidence surface. The guide must name the stage before making the claim.
Working Model#
A wallet builds and signs a transaction. RPC submission sends it to a node. The mempool may admit or reject it under node policy. A block template may include it as candidate miner work. A mined block may be added to the blockDAG. Virtual selected-parent-chain processing may produce acceptance data and UTXO diffs. RPC, indexers, and APIs may then expose observations.
Mechanics#
The dangerous shortcut is to say "accepted" without saying accepted where. Mempool admission is local/node policy. Block inclusion is not the same as accepted transaction evidence. Indexer visibility is not a substitute for protocol evidence. Durable application logic needs the later evidence path, especially accepted data and UTXO changes.
Expanded Lifecycle Walkthrough#
The transaction lifecycle is the spine of the guide:
wallet build/sign -> RPC submit -> mempool admit/reject -> template candidate -> mined block/DAG add -> virtual selected-parent-chain change -> acceptance data/UTXO diff -> RPC/indexer/API observation
Each arrow changes the evidence question. Wallet build/sign asks whether the transaction was constructed and authorized as intended. RPC submit asks whether it was sent to an interface. Mempool admit/reject asks whether a node accepted it into candidate policy state. Template candidate asks whether a miner-facing block template may include it. Mined block/DAG add asks whether block processing sees it inside a block relationship. Virtual selected-parent-chain change asks whether consensus processing produces accepted consequences. Acceptance data/UTXO diff asks what spendable-state changes follow. RPC/indexer/API observation asks how a tool presents what it observed.
This bridge is deliberately strict because application mistakes often come from collapsing two stages. "Submitted" is not "mempool accepted." "Mempool accepted" is not "included in a block." "Included in a block" is not automatically "accepted transaction evidence." "Observed by an API" is useful, but it is still an observation surface unless the source path and replay behavior are understood.
