History and confirmations

Four things that are not the same#

Signed. Your wallet produced a signature. For a pool position that is a transaction; for a profile change or a market proposal it is a message that never touches the chain. Nothing has moved.

Sent, pending. The transaction has a hash and is waiting to be mined. The control shows the hash so you can find it in the block explorer and so you know the first press landed. Pressing again would send a second transaction.

Mined. The chain included the transaction. This is not the same as it having worked: a transaction can be mined and revert, in which case the chain charged for it and did nothing. The interface reports that as a failure, in those words. If no receipt has arrived after two minutes, the control reports that the transaction was sent but the receipt never arrived, keeps the hash on screen, and asks you to check it — the transaction may still land.

Indexed. A separate history service has read the event, verified the block it came from, and made it available to the activity list, the charts and the performance figure. Until then those screens either read the chain directly in bounded windows or say they cannot.

What the history service is#

An optional, read-only service that follows the pool contract's events for one named deployment, stores them with their block timestamps and transaction and log indexes, and answers the venue's activity and chart queries. It never holds a key and cannot send anything. It is configured per build with the deployment it indexes, and every response it gives is checked against the build: the chain id and the contract address must match, the index must report itself complete, and a revision that changes mid-read causes the read to be discarded rather than stitched.

When it is configured, the venue also opens a small server-sent-events stream that says only "the history changed" so open pages re-fetch a fresh snapshot. The stream never replays individual trades and is not a promise of settlement finality. It polls once a second, closes in hidden tabs, rotates after two minutes, and the web process serves at most 64 of them at once.

What "confirmed" does not mean#

A reading is a cached chain observation. A UI status such as FINALIZED is not a claim of chain consensus finality: provisional, confirmed and finalised are different properties of a chain and a provider, and the venue will not call a short delay finality. Where a screen shows "Done — it is on chain", it means the receipt reported success; it does not mean the block cannot reorganise.

Ordering#

Several transactions can share one block timestamp. The service orders them by block, then transaction index, then log index. The interface never fabricates sub-second execution times.

Off-chain records#

Examples of signed records stored server-side rather than on chain include your public profile and a market proposal. Both are signed messages verified against your wallet address; both are visible as records rather than as chain events. See Wallets and profile and Propose a question.