Skip to main content

Oraichain

Oraichain (Oraichain Token, ORAI) — 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).

Oraichain — an AI/Other L1 (Cosmos SDK) with an AI oracle: it lets smart contracts make requests to AI APIs via validators and receive the result recorded onchain; token: ORAI.

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 L1 blockchain and an oracle network for “data requests”, where AI APIs are a special case (with test cases for quality control).
  • Who it’s for: smart contract/dApp developers who need to receive offchain results (including AI) as an onchain artifact.
  • Why onchain/token: onchain is needed for the provability/determinism of the result and for reward distribution; ORAI is used as gas/fees, validator staking and governance.

How it works (very briefly)

  1. The user does: sends (or a smart contract sends) an AI request/“oracle script” to the Oraichain network and specifies a fee.
  2. The system does: the selected validators execute the request: they run the test cases, call the AI providers/sources and form a report.
  3. The user gets: a result recorded in an onchain transaction/event (as a “proof of execution”), readable from smart contracts and applications.
  4. Where the blockchain is: execution and reporting are recorded in Oraichain; incentives/penalties and fee distribution are onchain rules.
  5. Token role (if any): ORAI — fees for transactions and AI requests, validator staking/delegation, voting on updates/parameters.

Quick links: AI thesis fit

Project passport

Field Value
Project name Oraichain
Also known as (aliases) Oraichain Token; ORAI
Logo (logo) ../assets/147_oraichain-token_logo.bin
Token symbol (ticker) ORAI
Category AI/Other
Primary chain (chain) Oraichain Mainnet
Type Appchain
Network status mainnet
Consensus (consensus) Tendermint BFT (DPoS-like validator/delegator model)
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract Native: — ; ERC‑20: 0x4c11249814f11b9346808179cf06e71ac328c1b5 ; BEP‑20: 0xa325ad6d9c92b55a3fc5ad7e412b1518f96441c0
Token model (token_type) utility (fee-mechanism)
Max supply Max supply: 19,779,272 ORAI (docs, 8/2023); the ERC‑20 contract displays a “Max Total Supply” of 86,000,000 ORAI (the historical initial supply before the burn; an exact reconciliation is needed).
Issuance capped (per the docs max supply) + historical burns; minting/rewards are tied to validator fees/reports (see tokenomics).
Tokenomics (tokenomics, brief) ORAI — gas/fees for AI requests and transactions; validator/delegator staking; governance.
Governance DAO (onchain governance by token holders — per the docs)
Admins/keys —
Audit yes (audit repository)
Bug bounty yes (announced)
Team (team) —
Funding (investors/funding) —
AI component (ai_component) AI oracle requests (test cases + providers)
Use‑case (use_case) trustless AI-API results for smart contracts
DecAI Fit — AI thesis fit 5/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary 2 / 3 / 3 / 3
Last verified 2026-02-11

General project overview

Oraichain is a public blockchain protocol positioned as an “AI‑Layer 1” and an oracle network: it lets smart contracts make requests to external data sources, including AI APIs, and receive the result as an onchain artifact. The documentation emphasizes that ordinary smart contracts cannot directly execute AI models/external APIs because of determinism requirements and environment constraints, and that oracles serve as a bridge between onchain and external computation.

The network is described as built on the Cosmos SDK with Tendermint BFT consensus; validators and delegators take part in ORAI staking and at the same time serve oracle requests. Oraichain’s distinctive mechanic is quality control of AI providers via test cases, which are attached to requests and/or supplied by separate participants (test providers); if the tests fail, the request is cancelled, and sanctions (slashing) are provided for degraded quality/availability.

Features/modules

  • AI‑oracle requests / oracle scripts: a request format with sources (AI providers), test cases and a fee.
  • Marketplace concept: the whitepaper describes an AI Marketplace and a test case market (as part of the ecosystem).
  • Network participants: validators, delegators, AI providers, testcase providers.
  • Onchain “proof of execution”: the request result is recorded in a transaction/report, from where smart contracts can read it.
  • Incentive economy: fees/rewards are distributed among validators, data/test providers and the community pool.
  • Slashing: validators are declared responsible for the quality/availability of AI APIs and for speed/availability.

Typical scenarios

  • Scenario 1 (dApp/smart contract): sends an AI request (oracle script) → the validator(s) run the tests and call the AI API → the result is recorded onchain and used in the dApp logic.
  • Scenario 2 (AI provider): publishes an AI data source/API → receives a reward when its API is used in requests (if it passes the tests).
  • Scenario 3 (validator/delegator): stakes ORAI → takes part in consensus and in executing oracle requests → receives rewards/fees (and bears the slashing risk).

Getting started (wallet/network)

  • What you need: a wallet for Oraichain (Cosmos ecosystem) and/or a smart contract/integration via oracle scripts.
  • Network/chain: Oraichain Mainnet (as well as ORAI wrappers on Ethereum/BSC for cross‑chain scenarios).
  • Fees: ORAI is used as the transaction fee; additionally, a fee is set in the AI request parameters and distributed among participants (validators, AI‑API providers, testcase providers).

Architecture/tech (non‑AI)

  • Components: Oraichain L1 (Cosmos SDK), validators/delegators, oracle scripts (calls to AI providers + test cases), the reporting mechanics (MsgResultReport) and fee distribution.
  • Participant roles: users/smart contracts (send requests), validators (execute/validate), AI providers (external AI APIs/sources), testcase providers.
  • Where logic runs: the request is initiated onchain; AI API calls are executed by validators (offchain interaction), while the result/report and fee distribution are recorded onchain.
  • Dependencies: external AI APIs and data sources; validator infrastructure; cross‑chain tokens (ERC‑20/BEP‑20 ORAI) — for bridges/listings, but the core of the network is the Oraichain mainnet.

Token/economics (expanded, no forecasts)

  • Token utility: ORAI is used as the transaction fee (including launching AI requests), as staking collateral for validators/delegators and as a governance token.
  • Protocol necessity drivers: the security and operation of the validator network rely on ORAI staking; execution of AI requests is charged a fee in ORAI.
  • Who pays fees: the initiators of transactions and AI requests (user/smart contract) — the fee is set in the request parameters (MsgSetAIRequest).
  • Where fees go: the docs describe distribution among request‑executing validators, AI‑API providers, testcase providers and block‑proposing validators; the remainder and taxes go to the community pool.
  • Issuance/burn: the tokenomics (08/2023) specify a max supply of 19,779,272 ORAI and links to historical burn events; at the same time, the ERC‑20 contract on Ethereum displays a max total supply of 86,000,000 ORAI (the historical supply before the burn — an exact reconciliation of “how to count max supply” between the native/erc20 representations is required).
  • Security/incentive mechanisms: staking and delegation; slashing for validator misbehavior (including AI API quality/availability, latency/availability).
  • Distribution and issuance: the tokenomics give the structure of the circulating supply and the planned release schedule (08/2023).
  • Treasury: a DAO Treasury (in the distribution) and the community pool (receives taxes/remainders) are mentioned.

Governance

  • Who makes decisions: the DAO/validators and stakeholders (per the docs: “ORAI DAO”; updates and parameter changes — via voting).
  • How protocol parameters change: via the network’s governance procedures (voting by token holders).
  • Keys/multisig: not recorded in the Tier‑1 sources used.

Security and incidents

  • Audits: the project has a public repository with audits (list/files — Tier‑1).
  • Bug bounty: a public bug bounty program is announced (Tier‑1 post).
  • Incidents: not collected as part of filling in this card.
  • Threat model: risks of quality/availability of external AI APIs, risks of validator centralization/collusion, risks of the correctness of test cases and reputation mechanisms.

Project status and timeline

  • Current status: mainnet (the documentation describes the Oraichain mainnet and tokenomics).
  • Roadmap: a roadmap link is in links_* (requires a separate item‑by‑item review).

Ecosystem/integrations

  • Integrations: the docs claim cross‑chain compatibility (the whitepaper speaks of cross‑chain compatibility).
  • Where it’s actually used: requires a separate sampling of integrations/cases (the current Tier‑1 set has no list of integrators).

AI component of the project

  • What is real AI here? Oraichain does not “host a model inside a contract”; it performs AI‑oracle requests: validators call external AI APIs and check quality via test cases, after which they publish the result onchain.
  • What is truly onchain? The request/result are recorded in transactions/reports, there are onchain incentives and slashing; the target property is “proof of execution” and tamper protection when obtaining an AI result.
  • Why is a token needed? ORAI is used as gas/fee for AI requests and transactions, as validator staking and as a governance instrument.
  • Red flags (based on the information found): AI‑washing — check to what extent “AI quality” is actually measured by test cases in practice; onchain‑washing — check the boundaries of onchain/offchain execution and guarantees; token‑washing — check the correspondence between the claimed max supply and the actual supply in the different native/erc20 representations.

DecAI Fit component summary

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

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): — (there is a Tier‑1 description of a working AI‑oracle request mechanism, so AI_0 does not apply).
  • Evidence: Tier‑1 — https://docs.orai.io/oraichain/system-overview ; https://docs.orai.io/docs/WhitePaper/Introduction
  • Why sufficient / why not (one line): AI_0 is used only if AI_1..AI_4 = 0.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): The network serves AI‑oracle requests: validators call external AI APIs and publish the result onchain (proof of execution), controlling quality via test cases.
  • Evidence: Tier‑1 — https://docs.orai.io/oraichain/system-overview ; https://docs.orai.io/docs/WhitePaper/Introduction
  • Why sufficient / why not (one line): The documentation describes that an AI API is requested and how the result is recorded in the blockchain.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): The Tier‑1 pages used contain no reproducible demo/example of a request to a specific AI API with verifiable outputs.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): There is a description of the mechanism, but no public “example → result”.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): The documentation describes quality control via test cases, but no quality metrics/benchmarks are given.
  • Conflict note (if any): —

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

  • AI_4 (decision): 1
  • Claim (one line): The AI API request flow is described: the oracle script includes sources, test cases and fees; the validator executes the request, tests the providers and writes the result to the blockchain.
  • Evidence: Tier‑1 — https://docs.orai.io/oraichain/system-overview
  • Why sufficient / why not (one line): There is a technical description of the request/validation/result‑recording mechanism.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Oraichain mainnet (Cosmos SDK) + cross‑chain representations of ORAI (Ethereum/BSC)
  • Addresses/identifiers: ERC‑20 ORAI 0x4c11249814f11b9346808179cf06e71ac328c1b5; BEP‑20 ORAI 0xa325ad6d9c92b55a3fc5ad7e412b1518f96441c0
  • Evidence: Tier‑1 — https://docs.orai.io/oraichain/tokenomics ; https://etherscan.io/token/0x4c11249814f11b9346808179cf06e71ac328c1b5
  • Why sufficient / why not (one line): The tokenomics give the contract addresses and distinguish native/erc20/bep20; Etherscan confirms the ERC‑20 contract.
  • Conflict note (if any): The tokenomics specify a max supply of 19,779,272 (native), while on Etherscan the contract’s “Max Total Supply” = 86,000,000 (the historical supply before the burn) — the wording needs reconciliation.

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

  • OC_2 (decision): 1
  • What useful logic is onchain: AI‑oracle requests and reports (proof of execution), fee distribution and validator slashing for quality/availability.
  • Evidence: Tier‑1 — https://docs.orai.io/oraichain/system-overview ; https://docs.orai.io/oraichain/tokenomics
  • Why sufficient / why not (one line): The documentation describes onchain artifacts of results and onchain incentives/penalties.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without the blockchain, the determinism/verifiability of the result is lost (smart contracts cannot safely call external AI APIs); Oraichain records the result in a transaction as a “proof of execution” and protects against tampering.
  • Evidence: Tier‑1 — https://docs.orai.io/docs/WhitePaper/Introduction ; https://docs.orai.io/oraichain/system-overview
  • Why sufficient / why not (one line): Tier‑1 directly explains the non‑determinism problem and the role of recording the result onchain.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The project has a token, ORAI (native + ERC‑20 + BEP‑20).
  • Evidence: Tier‑1 — https://docs.orai.io/oraichain/tokenomics
  • Why sufficient / why not (one line): The tokenomics describe the forms of ORAI and give the contract addresses.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): ORAI is the transaction fee for AI requests and any transactions in the network.
  • Evidence: Tier‑1 — https://docs.orai.io/oraichain/tokenomics
  • Why sufficient / why not (one line): The tokenomics list the “Transaction fee” and “AI request” utilities.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): ORAI staking/delegation for validators + slashing for misbehavior (AI API quality/availability, latency).
  • Evidence: Tier‑1 — https://docs.orai.io/oraichain/system-overview ; https://docs.orai.io/oraichain/tokenomics
  • Why sufficient / why not (one line): The system overview describes slashing and the role of validators; the tokenomics describe staking.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): Participation in network governance: protocol updates and parameter changes are voted on by token holders.
  • Evidence: Tier‑1 — https://docs.orai.io/oraichain/tokenomics ; https://docs.orai.io/ (Introduction, “ORAI DAO”)
  • Why sufficient / why not (one line): The tokenomics list governance as an ORAI utility; the introduction contains a statement about the ORAI DAO.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): ORAI is built into the L1 as fees + staking + governance; replacing it with “any token” breaks the basic mechanics of the protocol.
  • Evidence: Tier‑1 — https://docs.orai.io/oraichain/tokenomics
  • Why sufficient / why not (one line): The utility includes roles characteristic of a network’s native token.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.orai.io/docs/WhitePaper/Introduction The non‑determinism problem for smart contracts and the role of oracles/AI APIs (why the mechanism is needed).
Tier‑1 https://docs.orai.io/oraichain/system-overview Architecture of an AI‑oracle request: test cases, validators, recording of the result onchain (“proof of execution”), slashing.
Tier‑1 https://docs.orai.io/oraichain/tokenomics ORAI utility (fees, staking, governance), max supply (8/2023), ERC‑20/BEP‑20 ORAI addresses, distribution/issuance.
Tier‑1 https://etherscan.io/token/0x4c11249814f11b9346808179cf06e71ac328c1b5 Onchain confirmation of the ORAI ERC‑20 contract and the max total supply per the contract.
Tier‑1 https://github.com/oraichain/audits The existence of public audit materials (repository).
Tier‑1 https://blog.orai.io/introducing-bug-bounty-program-for-oraichain-and-its-ecosystem-6f65316ef0d Announcement of the bug bounty program.
Tier‑2 — —
Tier‑3 — —

No comments to display

Back to top