> 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.md).
# Oracle & Data
In prediction markets, oracles are essential components that relay external price, indicator, and event results on-chain.
However, the threat model changes completely depending on “what oracle structure is used”, “who resolves and how”, “is it automatic or manual”, and “whether it goes through governance”.
Therefore, to understand oracle risk, it is important to first understand “how did this value get on-chain?” rather than simply “is the value correct?”
Oracle structures used in prediction markets can be broadly divided into three types:
* Markets using **Hybrid Oracle**\
\
Similar to a cryptocurrency price prediction market, an oracle network generates and signs price data off-chain, a designated submitter (Relayer or EOA) submits the report value on-chain, and a smart contract verifies and confirms the signature.\
\
While this structure provides an automated flow similar to an on-chain oracle feed, the separation of the data creator (oracle network) and the submitter adds an additional trust assumption to the submission phase, introducing a structural risk that submitter errors, delays, and offline status will be directly propagated to market results.
* A market where **operators** manually submit results
\
Widely used in event-based markets like sports and politics, operators manually input values by checking official websites or data sources specified in the rulebook. \
\
While this structure offers low levels of automation but high market design flexibility, it also carries inherent risks associated with human intervention, such as abuse of operator authority, delays, and increased disputes resulting from misinterpretation.
* Markets using **governance-driven oracles**
\
If a proposed value is not disputed within a certain period of time, it is finalized. If a dispute arises, the final outcome is determined through token stakers or DAO voting. \
\
While decentralized verification has its advantages, there are economic attack vectors such as whale dominance, vote buying, and griefing using repeated dispute costs.\
\
The detailed attack models that occur in this structure are covered separately and intensively in the Governance part.
Even within the same market, data flows, attack surfaces, and risk profiles can vary significantly depending on the oracle architecture adopted.
Therefore, this part identifies representative risks that may arise in Oracle data flows and examines practical mitigation measures that can be applied during the subsequent design, operation, and verification stages.
### Oracle Design & Flow
In prediction markets, oracles retrieve and collect external data necessary to resolve the market and submit it in a usable format on-chain.
> **Off-chain data collection → On-chain submission → Smart contract consumes the resulting value to perform settlement**
This step serves as a means of bringing external event data on-chain, acting as a data bridge essential for the normal operation of prediction markets.\
The more accurate and consistent the results are delivered, the more stable the settlement logic and market mechanisms can operate.
---
# 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.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.
