When 600 milliseconds is final enough, and when you still wait for the receipt

Three moments belong to every transaction, and they are about a third of a second apart. The hash is the moment a node accepted the signed bytes. Inclusion is the moment a block contains them. Full finality is the moment the block two ahead has been proposed, which is when undoing that inclusion would require a leader to have equivocated in a way the protocol can prove. After MIP-12 the slot is 300 milliseconds, so full finality is about 600. Speculative finality is the first of those two certificates. People say “instant” and mean any of the three. The desk cannot afford that.

A close only needs the hash

The job of Close trade is to get the sell out and get the card off the list so you do not sell twice. The hash does both. The receipt, a third of a second later on a healthy leader, tells you whether the pool paid you. You can want that knowledge. You do not need it in order to stop pressing the button. Waiting for it inside the button is how the button times out on a busy public node and puts the card back under your thumb.

So the close is aggressive about leaving the screen and conservative about the price it will accept. The price is the mark, minus one percent. The aggressiveness is only about not blocking the next decision on a poll. If the receipt later says reverted, you are back in the trade and you close once more. You have lost the gas of a failed attempt, which is hundredths of a MON, and you have not lost the position.

Hash to stop tapping. Receipt to know what you were paid. Two slots to know it will not be reordered.

A payment needs the second slot

If you are paying a person, or funding an address you do not control, the hash is not enough. Inclusion that is still speculative can, in the uncommon case of an equivocating leader, be replaced. The Foundation’s account of that case is narrow. It is not “the chain might hiccup”. It is a proven fault by the leader who proposed the block. For a cup of coffee you will not wait. For a size you would be angry to send twice, wait until a block two ahead of yours exists, and read that on an explorer rather than on a toast. Six hundred milliseconds is still a short wait. The mistake is waiting six hundred seconds because that is what another chain taught your hands.

A withdrawal of the vault needs the receipt and the owner

Moving the vault’s tokens to your wallet is a creator signature. It is not frequent, it is not a scalp, and it is worth seeing the receipt before you assume the tokens arrived. Profit off the trading key is the same shape: one signature, one recipient, the owner the contract names. Wait for that receipt. There is no second tap that would be correct if the first is still pending, because the second would queue behind the same nonce and confuse the balance you are trying to read.

What a busy RPC changes

The chain’s clock does not slow down because an endpoint is late to tell you. A timeout at one second is a property of the connection, not of finality. If the explorer shows the hash in a block, the RPC that timed out was the slow party. If no explorer shows it, the transaction was not accepted by the network you asked, and the hash may be from a request that never propagated. Then, and only then, a fresh signature is the remedy. Check first. The check is faster than the argument.