> 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/missing-oracle-authentication.md).
# Missing Oracle Authentication
#### **Description**
This threat arises when a smart contract receives external data (such as oracles or AI models) without verifying the cryptographic integrity and origin of the data itself, relying solely on the authority of the submitter who transmitted the data.
Many prediction market protocols state in their whitepapers that they use an “official oracle network” or “AI-based settlement,” but their on-chain logic lacks any verification that the data comes from an authorized source.
This allows attackers (or malicious operators with compromised privileges) to manipulate market outcomes by injecting arbitrary, manipulated values that bypass the actual oracle or AI model.
#### Attack Vectors
* EOA Masquerading: An operator registers their own Externally Owned Account (EOA) as an "official oracle data submitter" and submits manipulated values unrelated to the actual external data as transactions.
* AI/LLM Spoofing: While advertised as "AI-generated results," in reality, they reflect values manually entered by operators without any on-chain signatures from the AI model or zero-knowledge machine learning (zkML) proofs.
* Stale Data Injection: Profit is realized by submitting past data that has expired as if it were current data (in the absence of timestamp verification).
#### **Real World Case Study**
**1. EOA-based Oracle Submission**
* **Current situation**
* While many prediction markets state in their whitepapers that they are "Chainlink/Official Oracle Price integrated," a closer look at the actual smart contract code reveals that the updatePrice(uint256) function is simply called by a single Externally Owned Account (EOA) with onlyOwner permissions. \
\
Only a simple output value like \[1,0] or \[0,1] is recorded on-chain, and there is no cryptographic proof that the data was agreed upon by Chainlink nodes.
* **Threat scenario**
* **Private Key Compromise**: If an operator's single private key is compromised, an attacker can manipulate prices across all markets and steal liquidity with a single transaction, without needing to hack the Chainlink oracle network.
* **Insider Threat**: Even if the operator intentionally manipulates the settlement by submitting a value different from the actual oracle price, the on-chain system cannot prevent this by determining that "it is valid because the owner sent it."
**2. AI-based Oracle Submission**
* **Current situation**
* There's a growing number of platforms promoting "LLM/AI models that fairly adjudicate the market.".\
\
However, an analysis of actual on-chain transactions reveals that in most cases, the backend server-managed wallet (EOA) simply transmits the result, without any proof of AI model inference or signature. \
\
In other words, there's no data on the blockchain that can distinguish between "AI-derived results" and "manually entered results by operators."
* **Threat scenario**
* **Opaque reversal**: Even if the AI produces "Outcome A," the operator can override it in the backend logic and submit a transaction with "Outcome B," which is more favorable to them. Users cannot technically verify or dispute this, and thus have no data to support it.
* **Model Swap**: Even if a low-performance model or a simple random function is used to reduce costs instead of the advertised high-performance model, this cannot be detected on-chain.
#### **Mitigation**
* **On-chain Signature Verification**\
On-chain must include the report's signature, timestamp, value, and public key-based verification from the official oracle network, and revert if verification fails.
* **Mandatory Timestamp Inclusion**\
Enforce a timestamp field on all data submissions to prove “at what point in time the data was”
* **Time-window Enforcement**\
When the market condition is "resolved only with values observed at specific intervals (e.g., 5 minutes/15 minutes/1 hour)," a validator is added to automatically reject timestamps outside the window.
```solidity
if (timestamp < windowStart || timestamp > windowEnd):
revert("OUT_OF_WINDOW")
```
* **Extended Verification for AI/EOA Submissions**\
AI model outputs or values submitted by EOAs must also be verifiable on-chain for authenticity through the original report (body), signature, model ID, version, timestamp, etc.
---
# 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/missing-oracle-authentication.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.
