Skip to main content

Sora Oracle

Sora Oracle (SORACA) — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Sora Oracle — an AI/Agents / Infra project on the BNB Smart Chain network. Per Tier‑1 sources, it is a permissionless oracle SDK for resolving outcomes/data (including prediction markets), where autonomous AI agents perform the search/verification of sources, and settlements for data access are organized via HTTP 402 micropayments (s402) and onchain settlement.

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: an SDK and a set of smart contracts for a permissionless oracle and prediction markets on BNB Chain.
  • Who it’s for: developers who build prediction markets/automated resolvers and want an “oracle without a trusted operator”.
  • Why onchain/token: onchain records settlement/contracts and provides verifiability; payment for micro‑requests is described via USDC and the s402 contract. The role of the SORACA token as a necessity for the protocol is not established in Tier‑1.
  • What you can actually touch (Tier‑1): Quick Start (SDK installation and market creation) — https://github.com/SoraOracle/SoraOracle/blob/main/QUICK_START.md

How it works (very briefly)

  1. The user does: integrates the SDK into an application and sets a question/market (example — in the README/Quick Start).
  2. The system does: AI agent(s) find relevant data sources, verify them (TLS, hashing, IPFS proofs per the description) and build consensus.
  3. The user gets: a resolution/data and the ability of onchain settlement for markets.
  4. Where the blockchain is: settlement of micropayments and oracle/market operations are executed via smart contracts on BNB Chain.
  5. Token role (if any): in Tier‑1, the description of s402 payments is tied to USDC; the necessity of the SORACA token for the protocol function is not established.

Quick links: AI thesis fit

Project passport

Field Value
Project name Sora Oracle
Also known as (aliases) SORACA
Logo (logo) ../assets/417_sora-oracle_logo.ico
Token symbol (ticker) SORACA
Category AI/Agents | Infra
Primary chain (chain) BNB Smart Chain
Type EVM
Network status mainnet
Consensus (consensus) PoSA (BNB Smart Chain; 21 validators)
Launch date (launch_date) —
Project status (status) active (based on the presence of mainnet contracts/repository)
Token (standard) BEP-20
Token contract 0xabebed1684a789b3cf178db810f3cbb30cc14444
Token model (token_type) —
Max supply —
Issuance —
Tokenomics (tokenomics, brief) s402 payments are described via USDC; the role of SORACA in the protocol is not established by Tier‑1
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) AI agents for API discovery + resolution
Use‑case (use_case) oracle / prediction market resolution
DecAI Fit — AI thesis fit 4/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 3 / 3 / 0 / 2
Last verified 2026-02-11

General project overview

Sora Oracle describes itself as a permissionless oracle SDK for building prediction markets and “trustless data feeds” on BNB Chain. The Tier‑1 materials emphasize: AI agents for automatic discovery of API sources, cryptographic verification, and the s402 (HTTP 402) micropayment model, where access to data is paid for and settlement is recorded onchain.

Features/modules

  • s402 micropayment settlement (the S402Facilitator contract on BNB Chain).
  • SDK (TypeScript) and integration examples (Quick Start).
  • Permissionless oracle: AI‑powered API discovery + verification (TLS/hashing/IPFS proofs per the description).
  • A set of smart contracts for different types of markets/resolution (per the README).

Typical scenarios

  • Scenario 1: a developer creates a market via the SDK → users place bets → the oracle resolves the outcome → the results are settled onchain.
  • Scenario 2: an application makes a paid data request via s402 → receives a verified response → uses it in automation/analytics.

Getting started (wallet/network)

  • What you need: a Node.js dev environment (for the SDK) and an EVM wallet for BNB Chain for onchain operations.
  • Network/chain: BNB Chain mainnet (Chain ID 56, per the README).
  • Fees: gas in BNB for transactions; per the Tier‑1 description, s402 also uses USDC for micropayments.

Architecture/tech (non‑AI)

  • Components: oracle/markets and s402 settlement smart contracts; SDK; backend middleware (example); frontend example (per the repository).
  • Participant roles: developers (integrate), market users, data providers/agents (per the description of the permissionless approach).
  • Where logic runs: onchain — settlement and markets/contracts; offchain — search/verification of sources and computation of consensus by agents.
  • Dependencies: BNB Chain RPC/explorer; IPFS (mentioned for proof storage); USDC (for s402 micropayments).

Token/economics (expanded, no forecasts)

  • Token utility: the role of the SORACA token in the protocol is not established per Tier‑1 sources.
  • Protocol necessity drivers: per the Tier‑1 description, payments in s402 are organized via USDC.
  • Who pays fees: users/creators of markets and participants of onchain operations (gas); users of paid data requests (s402).
  • Where fees go: the contract description on the website specifies a protocol fee (1%) to the treasury for s402 settlement.
  • Issuance/burn: — (not established per Tier‑1 sources).
  • Security/incentive mechanisms: there are stake‑based dispute/reputation contracts in the repository, but the parameters are not established per Tier‑1 sources.
  • Distribution and token issuance schedule: — (not established).
  • Treasury: the treasury is mentioned as an address in the s402 contract (management details are not established per Tier‑1 sources).

Governance

  • Who makes decisions: — (not established per Tier‑1 sources).
  • How protocol parameters change: — (not established).
  • Where decisions are discussed/made: the GitHub repository and public channels (Website/X).
  • Keys/multisig: — (not established).

Security and incidents

  • Audits: — (not established per Tier‑1 sources).
  • Bug bounty: — (not established).
  • Incidents: — (not established).
  • Threat model: smart contract risks (payments/markets), risks of correctness/substitution of data sources (mitigated by TLS/hashing and multi‑source consensus per the description), risks of centralized components (middleware/agents).

Project status and timeline

  • Current status: mainnet (based on the presence of a deployed contract and the README).
  • Key releases/milestones: SDK v5.0 (per the README).
  • Roadmap: — (not established per Tier‑1 sources).

Ecosystem/integrations

  • Integrations: BNB Chain RPC/USDC (for s402); SDK for TypeScript/React.
  • Partners: — (not established per Tier‑1 sources).
  • Where it’s actually used: SDK integration for creating markets and paid access to data (per the Quick Start/README).

AI component of the project

  • What is real AI here? autonomous AI agents for decomposing queries, discovering and verifying API sources and building multi‑source consensus (per the README/description on the website).
  • What is truly onchain? settlement of micropayments (s402) and oracle/markets operations via smart contracts on BNB Chain.
  • Why is a token needed? in Tier‑1, the description of payments is tied to USDC; the necessity of the SORACA token as a protocol element is not established.
  • Red flags (based on the information found): the Tier‑1 role of the token is not established; parts of the system work offchain (agents/middleware), which requires control of trust/reproducibility and an audit of the contracts.

DecAI Fit component summary

  • DecAI Fit: 4/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality high 3
Onchain necessity high 3
Token necessity low 0
Evidence Tier‑1 present (partially) 2
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): AI is described as part of a working component (permissionless oracle), not only a “plan”.
  • Evidence: Tier‑1 — https://github.com/SoraOracle/SoraOracle
  • Why sufficient / why not (one line): AI_0 applies to intent without evidence; here Tier‑1 contains a description of the AI part as SDK functionality.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): AI agents automatically discover/verify API sources and help resolve questions/markets (permissionless oracle).
  • Evidence: Tier‑1 — https://github.com/SoraOracle/SoraOracle
  • Why sufficient / why not (one line): the README describes “AI-powered API discovery” and agent‑based resolution as a key function.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): there is a Quick Start with SDK integration examples (market creation, s402 parameters, etc.).
  • Evidence: Tier‑1 — https://github.com/SoraOracle/SoraOracle/blob/main/QUICK_START.md
  • Why sufficient / why not (one line): this is a reproducible “what you can touch” tutorial for a developer.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://soraoracle.com/
  • Why sufficient / why not (one line): the website has marketing figures (for example, “500 queries/second”), but there are no quality benchmarks of AI resolution with a methodology.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 1
  • Claim (one line): there are tech specs/architecture of the permissionless oracle and its components (agents/verification/storage).
  • Evidence: Tier‑1 — https://github.com/SoraOracle/SoraOracle/blob/main/SORA_ORACLE_TECHNICAL_SPECIFICATION.md
  • Why sufficient / why not (one line): the repository documentation describes the architecture and components.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: BNB Chain mainnet
  • Addresses/identifiers: 0x605c5c8d83152bd98ecAc9B77a845349DA3c48a3 (S402Facilitator); 0xabebed1684a789b3cf178db810f3cbb30cc14444 (SORACA)
  • Evidence: Tier‑1 — https://github.com/SoraOracle/SoraOracle ; https://soraoracle.com/
  • Why sufficient / why not (one line): Tier‑1 sources provide the addresses of the mainnet contracts and links to the explorer.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: settlement of s402 micropayments and the smart contracts of markets/resolution (not only token issuance).
  • Evidence: Tier‑1 — https://github.com/SoraOracle/SoraOracle ; https://soraoracle.com/
  • Why sufficient / why not (one line): Tier‑1 lists the contracts (S402Facilitator and market/oracle contracts) and the settlement logic.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without onchain, permissionless/trustless settlement and the verifiability of resolution/payments — a key property of the oracle/markets per the description — are lost.
  • Evidence: Tier‑1 — https://github.com/SoraOracle/SoraOracle
  • Why sufficient / why not (one line): the README emphasizes “trustless data feeds / no centralized gatekeepers” and the onchain settlement components.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the SORACA token exists on BNB Chain.
  • Evidence: Tier‑1 — https://github.com/SoraOracle/SoraOracle ; https://soraoracle.com/
  • Why sufficient / why not (one line): Tier‑1 sources provide the token address and indicate it as the CA.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): s402 payments are described via USDC, not via SORACA.
  • Evidence: Tier‑1 — https://github.com/SoraOracle/SoraOracle
  • Why sufficient / why not (one line): the README directly describes s402 payment settlement in USDC.
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 0
  • Claim (one line): incentives/collateral/penalties specifically in the SORACA token are not established per Tier‑1 sources.
  • Evidence: Tier‑1 — https://github.com/SoraOracle/SoraOracle
  • Why sufficient / why not (one line): the README lists staking/slashing contracts, but it is not established that they are tied to SORACA as a mandatory token.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): governance via the SORACA token is not established per Tier‑1 sources.
  • Evidence: Tier‑1 — https://github.com/SoraOracle/SoraOracle
  • Why sufficient / why not (one line): the README mentions a DAOGovernance contract in the repository, but without a confirmed link to SORACA as a governance token.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 1
  • Claim (one line): the key utility (s402 micropayments) is described in Tier‑1 via USDC; the necessity of SORACA for the protocol function is not shown.
  • Evidence: Tier‑1 — https://github.com/SoraOracle/SoraOracle
  • Why sufficient / why not (one line): if payments/settlement run on USDC, the project’s token looks replaceable until a Tier‑1 description of its utility appears.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://github.com/SoraOracle/SoraOracle description of the product (permissionless oracle SDK), AI‑powered API discovery, links to the mainnet contract
Tier‑1 https://github.com/SoraOracle/SoraOracle/blob/main/QUICK_START.md reproducible tutorial (SDK install + market creation)
Tier‑1 https://github.com/SoraOracle/SoraOracle/blob/main/SORA_ORACLE_TECHNICAL_SPECIFICATION.md tech spec/architecture of the oracle/agent components
Tier‑1 https://soraoracle.com/ description of s402 micropayments and a link to the verified contracts (BSCScan)
Tier‑1 https://bscscan.com/address/0x605c5c8d83152bd98ecAc9B77a845349DA3c48a3#code onchain fact: the S402Facilitator contract (verified code)
Tier‑2 https://www.coingecko.com/en/coins/sora-oracle aggregator (context/for reference)
Tier‑2 https://coinmarketcap.com/currencies/sora-oracle/ aggregator (context/for reference)

No comments to display

Back to top