Wallet Roundtrip Evidence

First Contact#

A wallet roundtrip begins with keys and addresses, moves into transaction construction and signing, then depends on network evidence for acceptance. A wallet cannot make a transaction accepted by display alone.

Working Model#

Wallet evidence is strongest for key/address handling and transaction construction under wallet source or docs. Consensus evidence is needed for accepted data and UTXO consequences. API or indexer evidence can be useful when its source and replay behavior are understood.

Expanded Wallet Evidence Path#

A wallet roundtrip starts with user intent and ends only when the evidence path is understood. The wallet can create keys, produce addresses, select spendable outputs, construct a transaction, sign what needs authorization, and submit through an interface. Those are real steps, but they are not the same as accepted transaction evidence.

After submission, the wallet depends on network and node behavior. A node can reject the transaction, admit it to mempool, relay it, or expose a response through RPC. A miner may include it in candidate work. Consensus processing may later produce accepted data and UTXO diffs. An indexer or API may present an observation.

The page should therefore teach what the wallet proves and what it does not. It can prove wallet-side construction or signing behavior when the source/docs support that. It cannot by itself prove consensus acceptance unless the later evidence path is checked.

This page also protects wallet how-to material from overstating success. "Transaction built" means the wallet produced a candidate object. "Transaction signed" means the authorization step succeeded under wallet/source rules. "Submitted" means an interface accepted a request. "Seen later" means an observation surface reported something. A guide page should only say the transaction has accepted consequences when the accepted-evidence and UTXO-diff path supports that exact statement.