🕹️ How OO Works

A deep dive into the logic, mechanisms, and real-world implications of Factlink's Optimistic Oracle on Solana.

1. What is an Optimistic Oracle? The Big Picture 🌍

Imagine a world where you can ask any question—say, "Was the price of Bitcoin on June 1, 2025, 9 AM PST above $100,000?" 📈—and get a trustworthy answer without relying on a single, centralized authority. This is the promise of an Optimistic Oracle, a decentralized system designed to provide reliable data to blockchain applications (like smart contracts) by leveraging community participation and economic incentives. 💰

The term "optimistic" comes from the system's core assumption: most participants are honest, and answers provided are likely correct unless proven otherwise. 👍 Unlike traditional oracles that might rely on a single data source or a small group of validators, an Optimistic Oracle allows anyone to propose an answer (an assertion) to a question (a query). If no one challenges the answer within a set timeframe, it’s accepted as true. ✅ If a challenge arises, a dispute resolution mechanism kicks in to determine the correct answer.

Factlink’s Optimistic Oracle, built on the speedy Solana blockchain 🚄, takes this concept and tailors it for efficiency, scalability, and seamless integration with decentralized applications (dApps). It acts as a crucial bridge 🌉 between the off-chain world (real-world data) and on-chain systems, ensuring that smart contracts can access verifiable information without trusting a single point of failure.

2. Why Factlink Optimistic Oracle? Purpose and Context 🤔

In the blockchain ecosystem, smart contracts are incredibly powerful but have a key limitation—they can’t directly access external data like stock prices 💹, weather conditions 🌦️, or election results 🗳️. Oracles solve this by fetching and verifying off-chain data for on-chain use. However, many oracles are centralized or have limited dispute mechanisms, creating risks of manipulation or error. 😬

Factlink Optimistic Oracle addresses these issues by:

Decentralizing Trust 🤝: Relying on community participation rather than a single entity.
Optimizing for Speed 💨: Assuming honesty upfront, reducing unnecessary validations unless disputes occur.
Ensuring Fairness ⚖️: Using economic incentives (bonds and rewards) to encourage truthful behavior and penalize dishonesty.
Integrating with Factum DVM 🛡️: A robust dispute resolution system (Data Verification Mechanism) for escalated conflicts, ensuring reliable outcomes.

Think of Factlink as a marketplace for truth 🛒, where participants are financially motivated to provide accurate data, and disputes are resolved through a structured, transparent process.

3. Core Components of Factlink Optimistic Oracle 🧱

Before we explore the workflow, let’s get to know the fundamental building blocks of the system. These components are the bedrock of how queries are raised, answered, disputed, and ultimately resolved.

3.1 Admin Properties and Governance 👑

These admin properties are established when the smart contract is first deployed and can only be modified by the Optimistic Oracle owner through a governance process.

Admin Properties: This is the oracle's command center 🕹️, managed by an owner (administrator). It defines key parameters like:
- Burned Bond Basis Points: A percentage of bonds that will be sent to the Oracle Fee account from either the asserter or disputer, depending on how a disputed query is resolved. This is set to 5000bps (which means 50%). 🔥
- Reward Fees Basis Points: A percentage of rewards taken as a fee by the oracle for operational sustainability. 💸 The exact percentage for reward fees is still under discussion and will be updated closer to the token launch.
- Factum DVM Address: The default dispute resolution program if no specific escalation manager is assigned to a query.

The admin can update these properties, transfer ownership, or resize storage capacities for various accounts, ensuring the system remains adaptable, healthy, and up-to-date at all times. 🛠️

3.2 Whitelists: Query Types, Mints, and Escalation Managers ✅📋

Factlink uses whitelists to control who and what can interact with the system, adding an essential layer of security and quality control:

Query Type Whitelist: Defines acceptable categories of questions (e.g., "YES_NO_QUERY"). Each type is hashed for uniqueness and its name must be between 5 and 50 characters long to prevent abuse. This query system is designed to standardize query types, which helps in asserting, disputing, and resolving queries consistently. 🏷️
Mint Whitelist: Specifies which tokens (cryptocurrencies) can be used for bonds (collateral for assertions/disputes) and rewards (incentives for correct answers). Tokens are categorized as bond-only, reward-only, or usable for both, with separate minimum fee requirements for bonds and rewards. 🪙
Escalation Manager Whitelist: Lists approved programs or entities that can handle dispute resolution if a query is challenged. By default, disputes are resolved by the Factum DVM, but query raisers can opt to bring in custom escalation managers if they wish. 🧑‍⚖️

While the admin can directly edit these lists, anyone can propose additions or removals through the FLIP (Factlink Improvement Proposals) process. These proposals can be voted on and eventually executed by the governance process, ensuring community involvement. 🗳️

3.3 Query Structure and Lifecycle ❓🔄

A query is the heart of the system—it's a request for information. Each query contains:

Query Hash: A unique identifier for the query, like a digital fingerprint. 🆔
Query Type Identifier: Links the query to a whitelisted type (e.g., the hash for "YES_NO_QUERY").
IPFS CID: A reference (Content Identifier) to detailed query data stored on IPFS (InterPlanetary File System), ensuring transparency and that the full context of the question is available off-chain. 📄
Bond and Reward Details: Specifies the collateral (bond) required to assert or dispute, and the reward for correct answers, along with the token types (mints) used for each.
Liveness Time: The duration during which an assertion can be disputed. After this period, an undisputed assertion is considered final. ⏳
Escalation Manager: The entity or program (like Factum DVM) responsible for resolving disputes if they arise.
Validation Filters: Rules determining who can assert or dispute (e.g., anyone, or only allowlisted participants). 🚦

The lifecycle of a query moves through distinct stages: raising the query, asserting an answer, disputing that answer (if necessary), escalating the dispute (if it occurs), settling the query, and finally, closing the associated accounts.

4. How Factlink Optimistic Oracle Works: Step-by-Step Process ⚙️

Now, let’s walk through the entire journey of a query within the Factlink Optimistic Oracle. Imagine you’re a user wanting to know the outcome of a specific event. Follow along as we navigate each phase!

4.1 Initialization and Setup 🚀🏁

Purpose: Before any questions can be asked, the oracle system must be properly set up by an administrator. This is a one-time process and would be done at the time of contract deployment.
Process:
- The admin initializes the system, configuring crucial parameters like bond burn rates (e.g., 5000bps), reward fees, and the default Factum DVM address for handling disputes.
- Whitelists are created for:
  - Query types (e.g., "YES_NO_QUERY," "PRICE_QUERY").
  - Acceptable tokens for bonds and rewards (e.g., USDC, USDT).
  - Escalation managers (the designated dispute resolvers).
- Storage accounts on the blockchain are allocated with initial capacities. These capacities can be resized later if the whitelists grow and more space is needed.
Outcome: The oracle is now primed and ready to accept queries, with all rules and incentives clearly defined. ✅

4.2 Raising a Query (Asking a Question) ❓🗣️

Purpose: A user (the query owner) wants to request specific data, for instance, "Was the federal reserve chair of the USA on June 1, 2025, Jerome Powell?"
Process:
- The user submits their query. This query includes a unique hash (generated from the query's input data), is linked to a whitelisted query type, and references more detailed data stored on IPFS.
- They specify the bond amount (e.g., 250 USDC) required to assert an answer and the reward amount (e.g., 5 USDC) for the eventual correct asserter. These must be in whitelisted tokens and meet any minimum requirements.
- A portion of the total reward amount is taken as a fee by the oracle (calculated based on the reward_fees_basis_points) and is split between operational accounts.
- Parameters like liveness time (e.g., 24 hours, during which the assertion can be disputed) and the escalation manager (either the default Factum DVM or a custom one chosen from the whitelist) are set.
- Validation filters are defined. These determine if asserters and/or disputers must be on an allowlist (meaning only specific, pre-approved participants can engage) or if anyone can participate.
Outcome: The query is officially recorded on the blockchain, and the reward tokens are securely escrowed. The stage is set for anyone (or specifically allowlisted participants) to propose an answer. 📝

4.3 Asserting Truth (Providing an Answer) 🙋💬

Purpose: Someone (an asserter) steps forward to provide an answer to the raised query, for example, claiming "No" (which might be represented by a numerical enum value like 0 or 1 based on a mapping defined in the query type).
Process:
- The asserter submits their claim and posts the required bond in the specified token. This bond acts as collateral, demonstrating they have "skin in the game" and are confident in their answer.
- If validation filters are active for asserters, the asserter must be on an allowlist. This allowlist is typically managed by a validation manager (a separate entity or smart contract responsible for ensuring only trusted participants can assert).
- The time of the assertion is recorded, and an expiration time is calculated (assertion time + liveness time). This marks the window during which others can dispute the assertion.
Outcome: The proposed answer is now on-chain, and the asserter's bond is escrowed. The community has until the expiration time to challenge this assertion. ⏱️

4.4 Disputing Truth (Challenging an Answer) ⚔️😠

Purpose: Another participant (a disputer) believes the asserted answer is incorrect and decides to challenge it.
Process:
- The disputer must act before the assertion's expiration time. They challenge the assertion by posting the same bond amount as the asserter, effectively doubling the total collateral at stake for this query.
- Similar to asserters, disputers might need to be on an allowlist if validation filters for disputers are enabled.
- The act of disputing automatically triggers an escalation. The query is sent to the designated escalation manager (often the Factum DVM, but could be a custom one) to resolve the conflict.
Outcome: The query is now officially marked as "disputed." The resolution process moves to the escalation phase. Both the asserter's and the disputer's bonds are locked until a final decision is reached. 🔒

4.5 Escalation to Factum DVM (Resolving Disputes) 🏛️👨‍⚖️

Purpose: When a dispute occurs, an external mechanism, typically the Factum DVM (Data Verification Mechanism), is tasked with determining the correct answer.
Process:
- The chosen escalation manager (which could be a custom program or the default Factum DVM) takes over the resolution process. If it's the Factum DVM, it usually employs a voting mechanism among Factlink stakeholders (e.g., token holders) to collectively decide the truth.
- The resolution process via the escalation manager has two primary possible outcomes:
  1. Resolved: A clear, definitive answer is determined (e.g., the DVM votes "Yes" is the correct answer). A settlement value reflecting this truth is set for the query.
  2. Unresolved: In an extremely unlikely scenario, no consensus is reached by the DVM. The query is then settled without a definitive answer, and funds (like bonds) are typically returned to the participants involved in the dispute.
Outcome: The escalation manager updates the query's status on the Optimistic Oracle with the result, marking it as settled (either with a specific resolution/value or without one). 📢

4.6 Settlement of Queries (Finalizing Outcomes) 🏆🎉

Purpose: To distribute the escrowed bonds and rewards based on the final outcome of the query, whether it was undisputed or resolved through an escalation process.
Process:
- Undisputed Query: If no one disputes the assertion by the expiration time, the system deems the assertion correct. The asserter’s bond is returned to them, and they receive the full reward. The query settles with the asserted value as the truth. ✔️
- Disputed Query with Resolution: If the Factum DVM (or other escalation manager) resolves the dispute and determines a correct answer:
  - If the asserter was correct: They get their original bond back, they receive the disputer’s bond, and they also get the reward. A portion of the bonds (the "burned bond fee," e.g., 50% of one bond amount) is sent to the oracle’s fee account.
  - If the disputer was correct: They get their original bond back, they receive the asserter’s bond, and they also get the reward. Similarly, a burned bond fee is sent to the oracle’s fee account.
  - The burned bond fee is a percentage of the bond (defined by burned_bond_basis_points) and goes to the oracle’s fee account.
- Disputed Query without Resolution: If the Factum DVM (or other escalation manager) cannot resolve the dispute (a rare case): Both the asserter and the disputer get their respective bonds back. As a default, the asserter receives the reward, since no counter-truth was definitively proven against their initial assertion. 🤷
Outcome: Funds are distributed according to the rules, the query is officially marked as settled, and the final value (if any) is recorded on-chain, ready to be used by smart contracts or dApps. 💰➡️👥

4.7 Account Closure and Cleanup 🧹💨

Purpose: To free up on-chain storage and return any remaining lamports (SOL used for rent) after a query has been fully settled.
Process:
- Once a query is settled, the original query owner has the option to close the associated accounts. This includes the query's Program-Derived Account (PDA) on the Optimistic Oracle and any related accounts on the Factum DVM (if an escalation occurred).
- This step is optional but is good practice for managing blockchain resources efficiently and recovering rent.
Outcome: Storage is reclaimed on the Solana blockchain, and the query lifecycle is fully complete. ♻️

5. Incentive Mechanisms: Bonds, Rewards, and Fees 💸🎯

The Factlink Optimistic Oracle is built upon a carefully designed economic model to ensure honesty, active participation, and the overall health of the system. Let’s break down how these incentives work:

Bonds: When asserting an answer or disputing an existing assertion, participants are required to post a bond (collateral) in a whitelisted token. This bond is very much at risk—if you’re proven wrong, you lose it to the party who was correct. This financial stake discourages false assertions or frivolous disputes. A portion of the bond from the losing party in a dispute may be "burned" (sent to an oracle fee account), further deterring bad behavior and speculative challenges. 🛡️💰
Rewards: Query owners offer rewards to incentivize individuals to provide correct answers. These rewards are paid out to the winning party (either the undisputed asserter or the correct party in a dispute) after the query is settled. The reward paid out is typically the total reward minus a fee taken by the oracle. 🏆
Fees: The oracle collects two main types of fees to sustain its operations and incentivize good behavior:
- Reward Fee: A percentage of the total reward amount, set by the admin properties, is collected by the oracle before the remainder is paid to the winner. This helps fund the ongoing operation and development of the oracle system.
- Burned Bond Fee: In the case of disputed queries that are resolved, a percentage of the bond from the incorrect party is "burned" (transferred to the oracle's fee account). This acts as a penalty for incorrect or speculative actions and contributes to the oracle's treasury. 🔥
Outcome: Participants are strongly motivated to act honestly and diligently. Lying or disputing without a valid reason risks significant financial loss (losing their bond), while truthfulness and accuracy are rewarded. This economic alignment is key to the oracle's reliability. ✅

6. Security and Trust Mechanisms 🛡️🔒

Trust is absolutely paramount in any oracle system. Factlink Optimistic Oracle employs multiple layers of security and trust-building mechanisms to prevent manipulation and ensure the reliability of the data it provides.

6.1 Validation Filters and Allowlisting 🚦👥

Validation Filters: Query Owners have the flexibility to define who can participate in their queries. They can restrict who can assert answers and/or who can dispute those assertions. Options include:
- Allowlisted Participants: Only specific, trusted individuals or entities (whose public keys are on an allowlist) can assert or dispute.
- Anyone (No Filter): Participation is open to everyone. This flexibility allows query owners to balance the need for openness with the desire for controlled, high-quality participation, depending on the sensitivity of the query.
Allowlisting: When validation filters require allowlisting, these lists are typically managed by a validation manager. This could be another smart contract or a trusted entity responsible for vetting and maintaining the list of approved participants. This helps reduce the risk of spam, Sybil attacks, or malicious actors influencing critical queries.

6.2 Disincentives for Malicious Behavior in Assertions and Disputes💸🛑

Bond Risk: The most significant deterrent against malicious behavior is the bond itself. Posting a bond means putting real money on the line. If a participant provides a false claim or a baseless dispute and is proven wrong, they lose their bond. This direct financial consequence makes dishonest participation costly and economically irrational for most actors.

7. Whitelisting and Administrative Controls ⚙️🎛️

The Factlink admin has a suite of tools to manage the ecosystem effectively, ensuring quality, security, and adaptability.

7.1 Managing Minted Tokens for Bonds and Rewards 🪙📋

Tokens (cryptocurrencies) intended for use as bonds and rewards must be whitelisted by the admin. Each whitelisted token will have specified minimum fee amounts (for both bond and reward use-cases) to prevent spamming the system with very low-value transactions.
Admins can modify the whitelist status of a token (e.g., allow a token that was previously only for bonds to also be used for rewards, or vice-versa, or delist it for a specific use). They can also remove tokens entirely from the whitelist. If a token is removed, associated fee accounts (like the oracle's fee ATA for that token) can be closed, provided their balances are zero, to reclaim rent.

7.2 Managing Escalation Managers 🧑‍⚖️📝

Escalation managers, which are the programs or entities responsible for resolving disputes, must also be whitelisted. This ensures that only trusted and verified dispute resolution mechanisms are used within the Factlink ecosystem.
Admins have the authority to add new escalation managers to the whitelist, remove existing ones, and resize the on-chain storage allocated for this whitelist as needed, maintaining flexibility and accommodating growth.
While Factum's DVM is designed to be the most robust and default solution for dispute resolution, the system allows query raisers the option to use a custom-built escalation manager (from the whitelist) if their specific needs require it.

8. Financial Operations: Withdrawals and Fees 🏦💼

The Optimistic Oracle manages funds through dedicated, program-controlled accounts to ensure security and transparency:

Oracle Authority: This account acts as a temporary custodian. It holds the bonds posted by asserters and disputers, as well as the rewards offered by query owners, during the active lifecycle of queries. Once a query is settled, this authority releases the funds to the rightful recipients according to the outcome.
Fee Authority: This account is responsible for collecting the fees generated by the oracle. These include the percentage taken from rewards and the "burned" portion of bonds from resolved disputes. Admins, through governance, can withdraw funds from this fee authority account to support the oracle's operations, development, and other ecosystem initiatives.

This separation of concerns (escrow vs. fee collection) and the use of program-derived authorities enhance the security and transparency of financial operations, preventing misuse of escrowed participant funds.

9. Real-World Applications and Use Cases 💡🌐

The Factlink Optimistic Oracle is a versatile tool that can power a multitude of decentralized applications (dApps) across various sectors by providing them with reliable real-world data:

DeFi (Decentralized Finance) 📈:
- Providing accurate and tamper-resistant price feeds for crypto assets, essential for lending protocols, decentralized exchanges (DEXs), stablecoins, and derivatives markets.
- Verifying conditions for automated financial agreements.
Insurance 📄☔:
- Verifying real-world events for parametric insurance payouts. For example, automatically triggering a payout if the oracle confirms "Did a Category 3 hurricane make landfall in Miami-Dade County on X date?".
- Confirming crop damage based on weather data for agricultural insurance.
Prediction Markets 🔮📊:
- Reliably settling bets on future outcomes, such as election results ("Who won the presidential election?"), sports events ("Which team won the championship?"), or even scientific discoveries.
Gaming & NFTs 🎮🖼️:
- Verifying off-chain events that affect NFT characteristics or game states.

Its flexibility in defining query types and utilizing various whitelisted tokens for bonds and rewards makes it highly adaptable to a diverse range of needs and complex data requirements.

10. Why Optimistic? The Philosophy Behind the Design 🤔💡

The "optimistic" approach underpinning the Factlink Oracle is rooted in principles of efficiency and a pragmatic trust in human behavior. By initially assuming that most assertions made are correct, the system cleverly avoids the need for costly and time-consuming validation processes for every single query. Dispute resolution mechanisms, which are inherently more resource-intensive, are only invoked when a claim is actively challenged—that is, when necessary. 🤺

This makes the system faster and cheaper for the vast majority of use cases where data is straightforward and participants are honest, while still providing a robust framework for resolving contentious issues. ✨

For any further questions, please contact us through our discord.

On this page