> 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/single-data-source-dependency.md).
# Single Data Source Dependency
### Single External Data Source Failure
#### Description
Prediction markets specify their settlement criteria in a rulebook.\
Some markets are structured to designate a single Web2 data source as the source of truth, such as "the true outcome of this event depends on the values of a specific website or API."
At this time, if the source experiences server downtime, DoS attack, update delay, or administrator manual update failure, a structural risk arises where the settlement standard cannot be secured even if the on-chain oracle/smart contract is normal, or old values are fixed as the settlement standard.
#### Attack Scenario
**Inducing a DoS attack on a Web2 site to prevent updates.**
* If the settlement standard is a single website, an attacker can cause a DoS on that website, halting updates. \
\
If the website is not updated, the values referenced by the Rulebook will be fixed to their previous values, allowing the attacker to manipulate positions in a favorable direction based on these fixed values.
#### Mitigation
* **Multi-Source Rulebook Specification**
* Rather than relying solely on a single site or API, specify at least two to three independent Web2 sources in parallel. \
\
Incorporating a median/majority selection rule during settlement prevents single-data source errors from being directly reflected in the settlement.
* **Resolve Timeout & Safe-Mode Handling**
* Establish safe termination procedures, including automatic refunds, market cancellations, and limited administrator intervention, to prevent market disruption in the event of prolonged single-source failures.
* **Dispute-able structural design**
* Someone should be able to challenge that the provided value is incorrect. The DAO/governance can review dispute evidence (articles, page snapshots, official documentation), or use an economic incentive-based challenge structure like UMA OO.
* **Source Disclosure & Risk Notice**
* When creating a market, clearly disclose the data sources users rely on and the potential for single-source failure.
***
### Single Oracle Network Dependency
#### Description
In crypto price prediction markets, the settle value is increasingly being determined automatically by oracle networks (e.g., Chainlink).
In this structure, the market resolve proceeds in the following flow:
> **The oracle network (off-chain) generates and signs the price → The designated submitter (EOA/Relayer) submits it on-chain → The smart contract verifies the signature → Immediate settlement**
Problems with this architecture arise when both the oracle network and the submitter rely on a single provider. Excessive reliance on a single provider creates the following risks:
* **Oracle network failure = entire market paralysis**\
If the Data Streams provider cannot generate signed prices due to an off-chain price engine error, external API rate-limit, network delay, etc., the submitter will not be able to submit any data.
* **Submitter (EOA/Relayer) failure = delay or inability to settle**\
If the Submitter fails to send a transaction due to gas shortage, nonce collision, or RPC failure, the price exists but is not transmitted to the market, so it remains in a pending state until the operator intervenes.
* **No fallback provider**\
Unlike traditional Chainlink Aggregators, the Data Streams architecture lacks multi-node consensus (aggregation layer) or on-chain backup feeds. \
\
Price generation is performed via a single path by an off-chain provider, and the submitter also has a single execution path. \
\
Therefore, if a provider fails to produce a signed report or a submitter fails to submit it on-chain, there is no alternative data path, resulting in an immediate liveness failure.
This problem is not a structural vulnerability that deals with the risk of values not coming in (oracle liveness), but rather the risk of values not coming in (oracle correctness).
#### Scenario
{% stepper %}
{% step %}
There is a BTC price prediction market that automatically settles the market every 15 minutes using Chainlink Data Streams.
{% endstep %}
{% step %}
The Data Streams network successfully generated and signed BTC prices off-chain, but the submitter (EOA/Relayer) in that market was unable to send transactions(tx) due to RPC failure, wallet/key file error, lack of gas, or local keeper script failure.
{% endstep %}
{% step %}
Because the contract doesn't receive the signed data, `reportPayout` isn't updated. The prediction market either remains in a perpetually pending state, failing to resolve even after the end time, or the market itself must be canceled/refunded after a policy-defined timeout.
{% endstep %}
{% endstepper %}
#### Mitigation
* **Redundant Submitter Infrastructure**
* While there's only one EOA that handles settlement transactions, the backend infrastructure that operates on its behalf is multiplexed. Backend workers submitting identical signed values are operated in two to three regions, allowing the same scheduler to run on multiple instances. However, a nonce lock/mutex layer ensures that only one actual transaction occurs. \
\
Since the same EOA is used even if there is an RPC failure on a specific node, a network failure in a specific area, or a specific server is down, the contract logic can be significantly improved to ensure submitter liveness without any changes.
* **Strengthening the RPC/Network Failover System**
* A submitter bot should not use a single RPC. \
\
Configure at least three RPC providers (primary → secondary → tertiary), apply automatic failover logic, and immediately switch to a fallback RPC in case of RPC latency/error.
```js
try {
await primaryRpc.send(tx);
} catch (e1) {
await backupRpc1.send(tx);
} catch (e2) {
await backupRpc2.send(tx);
}
```
* **On-chain Liveness Timeout & Safe-Mode**
* If no submissions arrive within a certain period of time, the protocol automatically enters "settlement failure mode," or, in the event of a timeout, automatically transitions to fallback procedures such as cancel/refund, jam/pause, or opening a dispute window. \
\
This method addresses the issue of markets remaining indefinitely pending when a submitter dies.
***
### Single Indexer Dependency
#### Description
Prediction market UIs and backends typically read and display on-chain status through off-chain data indexers, such as:
> **On-chain event → Indexer → Backend API → UI**
Over-reliance on a single indexing service or single data path can lead to structural problems where the UI and backend display distorted states even when the on-chain information is correct.
Relying on a single indexer presents the following risks:
* Incorrect prices, positions, and settlement results are displayed in the UI.
* SPoF: On-chain activity is normal, but the UI is down.
UI glitches can directly undermine market trust by making it appear to users that their positions, balances, and settlement results have disappeared, even when there are no issues on-chain.
***
#### Real World Case Study
{% hint style="info" %}
[**Polymarket's data indexing infrastructure failure**](https://www.gate.com/learn/articles/the-tragedy-of-polymarket-s-data-indexing/11051)
{% endhint %}
Polymarket relied heavily on Goldsky, a single indexing service, to retrieve market data, positions, balances, etc. At one point, the Goldsky infrastructure experienced an outage for approximately six hours, resulting in incorrect data being displayed on the front end.
This error wasn't a problem with the blockchain or the market itself, but rather a temporary malfunction in the indexing layer, resulting in misinformation. Users lost confidence in the balance and position status displayed on the UI, and some experienced significant confusion, mistakenly believing they held nonexistent positions or unable to confirm settlement status.
This incident clearly demonstrates that even if the data source is on-chain, if the indexing layer that processes and delivers that data is concentrated in a single provider, a single outage can quickly spread to the entire market, causing errors and user harm.
#### Mitigation
* **Multi-Indexer Architecture**
* By diversifying off-chain data paths—such as indexers, Graph API, REST polling, and proprietary backends—to absorb single indexer failures, the UI automatically recovers through alternative data sources even if one indexer stops.
* **Source Disclosure & User Notices**
* When creating a market, it should be made clear to users that UI data is indexer-based and may result in display errors in the event of off-chain failures, and that actual settlements/positions/balances are based on on-chain and fallback logic is implemented in the event of indexer failures.
---
# 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/single-data-source-dependency.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.
