Skip to content
Launch app
Browse documentation

LIVE and freshness

Read connection status, update times and delayed-data notices.

Reviewed .

The live dot#

A market page shows a live dot beside the title while the market is open on chain and accepting positions — its status is open, the opening time has passed and the cut-off has not. The badge must be read alongside the feed's freshness status; it is not a guarantee of real-time execution. It goes out at the cut-off and on any settled or voided market.

The refresh status#

The venue re-reads market state every five seconds while the tab is visible, and again whenever the tab becomes visible or the history service announces a change. The status label beside a market's figures reads:

  • 5s updates — the last read succeeded and the next is scheduled;
  • Updating… — a read is in flight;
  • Offline · last reading — the last read failed. The figures on the page are the last successful reading and are not being updated.

A failed read never blanks the page. What you see is the most recent state the interface could confirm, and the label is what tells you how old it is.

Age labels#

Times on the trades tape and in activity lists are shown as an age — "4s", "1m", "2h" — that keeps counting from the moment the page rendered, so a label read a minute after the page loaded says a minute more than it did. Reduced-motion behavior may limit visual updates; use the underlying timestamp for exact timing.

The countdown to the next timing event — the end of the opening plateau, the cut-off, the resolution deadline — runs live for the same reason, and the interface asks the chain for its clock rather than trusting your device's, because a notice period or a deadline is a comparison the contract makes against the block timestamp.

What "activity" means#

The activity feed on a market is built from the pool's own events — charges and par exits — read from the chain in bounded windows. The reader keeps a cursor per chain scope and discards history on first connection, on a chain reset, or after a long absence, rather than stitching two histories together. Repeated events from a retried request are dropped by id.

What freshness is not#

  • A timestamp is the block timestamp, to the second. Several transactions can share a second; ordering within it comes from the transaction and log indexes, never from a clock on our side.
  • Nothing on chain 4663 derives time from the block height, because that opcode reports the Ethereum L1 height there and updates only intermittently. Every clock in the product is the block timestamp.
  • "5s updates" is a polling cadence, not a promise of finality. A reading is a cached chain observation; settlement finality is a separate property described under History and confirmations.