> For the complete documentation index, see [llms.txt](https://funarchy.gitbook.io/funarchy/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://funarchy.gitbook.io/funarchy/security-for-prediction-market/oracle-and-data/ui-latency-desynchronization.md).
# UI Latency Desynchronization
#### **Description**
In prediction markets, most users make immediate trading decisions based on prices, graphs, and indicators displayed on the UI (web/app).
However, the UI may update later than actual market conditions for the following reasons:
* API polling cycle (500ms\~3000ms)
* Indexing delays (SLA issues with third-party indexers such as Goldsky)
On the other hand, pro users, bots, and MEV participants can directly subscribe to backend Websocket or Raw Price Feeds (CEX Websocket, Chainlink Streams off-chain feed, etc.) to obtain real-time price information faster than the UI.
The time difference that occurs at this time is not a simple UI bug, but rather leads to tradable information asymmetry, forcing general users to trade under structurally disadvantageous conditions.
#### **Attack Scenario**
{% stepper %}
{% step %}
**UI Price Observation**
Regular users select positions by viewing prices and charts displayed in the UI. This UI data is updated via `Graph API + polling` or indexer-based REST API calls.
{% endstep %}
{% step %}
**Faster Off-chain Feeds Used by Attackers**
Pro traders, bots, and MEV participants use real-time streams such as CEX WebSockets and backend internal price feeds to detect price changes 1-3 seconds faster than the UI.
{% endstep %}
{% step %}
**Latency Gap (UI Update Delay)**
If there is a refresh delay of about 1-3 seconds, the UI will still show the old price, but the attacker will already be seeing the “new price” or “the price immediately after the change.”
{% endstep %}
{% step %}
**Exploit Opportunity**
Attackers can either preemptively place orders at a more favorable price than regular user orders submitted based on the stale price in the UI, or execute a large number of stale orders based on the changed on-chain state.
{% endstep %}
{% step %}
**Asymmetric Outcome**
As a result, while general user transactions are executed based on a slow UI, actual execution is based on more advanced price movements, resulting in structurally disadvantageous execution results.
{% endstep %}
{% endstepper %}
#### **Mitigation**
* **UI Price Latency Disclosure**
* Explicitly **display the data source (API, Oracle Feed, WS endpoint), last update time stamp, expected latency range (ms), and stale threshold criteria** in the UI.\
\
This allows users to immediately determine if the UI is slow, stale, or has some delayed value.
* **Real-time Websocket price transmission**
* The UI should be designed to use **the backend Websocket stream**, not polling.
* The backend should subscribe to real-time price sources such as Chainlink Data Streams, CEX Websocket, or its own price aggregator and push them to the UI to minimize the possibility of stale prices.
* **Strengthening Indexing SLA**
* Prevent UI delays caused by indexer delays by implementing Primary + Backup indexer configuration, automatic failover when API response is delayed, and UI warnings when stale data is detected.
* **UI Stale Detection & Fallback Mode**
* If the indexer-based data in the UI is not updated for a certain period of time, it is detected as stale and all UI elements (price, position, chart, tradeable button, etc.) whose accuracy is not guaranteed are immediately disabled.
* Warn the user of a “stale state” and switch to read-only mode, then automatically normalize when the indexer or Websocket stream recovers.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://funarchy.gitbook.io/funarchy/security-for-prediction-market/oracle-and-data/ui-latency-desynchronization.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
