Skip to main content

OORT

OORT — 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).

OORT — an AI/Data | Infra project around a decentralized “data cloud” for AI datasets (data collection/preprocessing/verification) and its own L1 infrastructure (Olympus Protocol); token (symbol: OORT) on Ethereum (ERC‑20).

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: a platform for collecting and preparing data (images/audio/video) for training/improving AI models, with onchain provenance accounting and quality checks (per the documentation).
  • Who it’s for: AI teams/companies that need datasets, and a community of contributors performing micro‑tasks (collection/validation/labeling).
  • Why onchain/token: the blockchain is used for traceability/verification of data and the network rules, and the OORT token — for payments/staking/governance (at the same time, Tier‑1 explicitly states that payment in fiat is possible).
  • What you can actually touch (Tier‑1): OORT DataHub (web version/mobile app) — https://datahub.oortech.com/home

How it works (very briefly)

  1. The user does: enters OORT DataHub (web/app), performs data collection/validation/labeling tasks or publishes datasets.
  2. The system does: aggregates data from the global community; records provenance and applies “blockchain‑based” quality checks (per the DataHub documentation).
  3. The user gets: rewards/points/status (tiers) and the ability to monetize their contribution (per the DataHub description).
  4. Where the blockchain is: in Tier‑1 sources, DataHub is described as built “on Olympus Protocol (native Layer 1)” and as using blockchain traceability/verification of data.
  5. Token role (if any): the token is used for paying for services (at a discount), staking/collateral and governance; at the same time, it is stated that services can be paid for in fiat.

Quick links: AI thesis fit

Project passport

Field Value
Project name OORT
Also known as (aliases) OORT Tech; OORT DataHub; $OORT
Logo (logo) ../assets/129_oortech_logo.svg
Token symbol (ticker) OORT
Category AI/Data | Infra
Primary chain (chain) OORT
Type Appchain
Network status mainnet
Consensus (consensus) PoH (Proof of Honesty)
Launch date (launch_date) 2023-11-27 (mainnet launch per the roadmap)
Project status (status) active
Token (standard) ERC-20
Token contract 0x5651fa7a726b9ec0cad00ee140179912b6e73599
Token model (token_type) utility (payments + staking + governance)
Max supply 20,000,000 OORT (Max Total Supply on Ethereum)
Issuance burn (buyback & burn; quarterly, cap 40%)
Tokenomics (tokenomics, brief) payment for services (including at a discount), staking/delegation and governance; a regular buyback & burn is claimed
Governance governance via the OORT Foundation platform (vote/delegate)
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) data collection/labeling/preprocessing for AI
Use‑case (use_case) datasets for AI model training
DecAI Fit — AI thesis fit 5/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary 2 / 2 / 2 / 3
Last verified 2026-02-11

General project overview

OORT positions itself as a “data cloud for decentralized AI”: an ecosystem that allows collecting, preprocessing and monetizing data for AI/ML training. The product layer is represented by OORT DataHub — a platform where the community performs data collection/validation/labeling tasks (images/audio/video), and customers/projects receive verifiable datasets.

In the Tier‑1 documentation, DataHub is described as built on its own L1 (Olympus Protocol) and relying on the OORT Edge infrastructure for data storage/processing. The blockchain is claimed as a layer for data provenance traceability and “blockchain‑based” quality verification.

Features/modules

  • OORT DataHub: collection and preprocessing of data for AI (collection, labeling/classification, validation).
  • OORT Edge: decentralized infrastructure for data storage/processing (underlying DataHub).
  • Olympus Protocol: an L1 blockchain (OORT mainnet), described as the base layer of the ecosystem.
  • Governance: the OORT Foundation platform for proposals and votes.

Typical scenarios

  • Scenario 1 (contributor): the user installs the app/uses the web → performs micro‑tasks (collection/validation/labeling) → receives rewards/points/tier progress.
  • Scenario 2 (data consumer): a project/team uses DataHub to obtain/collect a dataset → receives a data set with claimed traceability and quality control.
  • Scenario 3 (economy participant): a token holder stakes OORT (pools/delegation or as node provider collateral) → participates in rewards and/or governance.

Getting started (wallet/network)

  • What you need: access to OORT DataHub (web/app) and, if a tier upgrade/staking is needed, OORT tokens and a wallet.
  • Network/chain: the OORT token is represented on Ethereum (ERC‑20); the documentation also describes OORT’s own network (Olympus Protocol).
  • Fees: network fees depend on the specific operation (for example, Ethereum gas for onchain operations with the ERC‑20).

Architecture/tech (non‑AI)

  • Components: DataHub (web/app), the OORT Edge infrastructure (storage/processing), Olympus Protocol (L1) and the onchain layers of the token/staking/governance.
  • Participant roles: data contributors, validators/quality control participants, node providers (“miners”), token holders, developers, governance users.
  • Where logic runs: data collection and preprocessing — in applications/services (offchain); accounting/traceability/verification and network rules — claimed as “blockchain‑based” and tied to Olympus Protocol (L1).
  • Dependencies: mobile apps (iOS/Android), the DataHub web interface, the public Olympus Protocol repositories.

Token/economics (expanded, no forecasts)

  • Token utility: payment for services (with a possible discount when paying with the token), staking (pools/delegation or collateral for node providers), participation in governance.
  • Protocol necessity drivers: in Tier‑1 sources, the token is described as the base utility asset of the ecosystem (payments/staking/governance), but at the same time it is explicitly stated that users can pay for services in fiat.
  • Who pays fees: users/participants performing onchain operations (for example, on Ethereum when interacting with the ERC‑20).
  • Issuance/burn: a buyback & burn mechanism is claimed: up to 30% of profit for buyback/burn, frequency — once every 3 months, cap — 40% of total supply.
  • Security/incentive mechanisms: staking via pools/delegation and staking as collateral for node providers (per the documentation).
  • Distribution: the documentation has an allocation chart; the details of vesting/unlocks are not disclosed by Tier‑1 sources within this card → —.
  • Treasury: OORT Foundation (in the context of buyback & burn and governance) — the details of fund management are not disclosed within this card → —.

Governance

  • Who makes decisions: OORT holders via the OORT Foundation governance platform (vote/delegate).
  • How protocol parameters change: via proposals and voting (proposal deposits are mentioned in the tokenomics).
  • Where decisions are discussed/made: the governance platform and proposals.
  • Keys/multisig: not established per the Tier‑1 sources of this card → —.

Security and incidents

  • Audits: — (no Tier‑1 links to an audit of the key contracts/protocol were found in this card).
  • Bug bounty: — (no Tier‑1 program page was found).
  • Incidents: not established per the Tier‑1 sources of this card → —.
  • Threat model: data quality risks (sybil/spam/forgeries), risks of centralization/control over network parameters, bridge/token contract risks and risks of offchain components (app/accounts).

Project status and timeline

  • Current status: mainnet (the roadmap indicates the Olympus Protocol mainnet launch on 2023‑11‑27).
  • Key releases/milestones: mainnet launch (2023‑11‑27, roadmap); the Halley update (v1.1.8) in Olympus Protocol (GitHub Releases).
  • Roadmap: a public roadmap page in the documentation.

Ecosystem/integrations

  • Integrations: DataHub web/app interfaces; the public Olympus Protocol repositories.
  • Partners/clients: the Tier‑1 “What is OORT?” lists partners/clients (Binance Smart Chain, OKX, Bitget, Tencent Cloud, etc.) — a separate check of each case is required if needed.
  • Where it’s actually used: DataHub as a product with public access (web/app) and described task scenarios.

AI component of the project

  • What is real AI here? The project is about data for AI: collection/labeling/preprocessing and verification of datasets for AI/ML training (not about its own model/inference).
  • What is truly onchain? Tier‑1 sources describe its own L1 (Olympus Protocol) and “blockchain‑based” traceability of data provenance and quality control in DataHub; there is also the onchain OORT token (ERC‑20).
  • Why is a token needed? In the Tier‑1 tokenomics, the token is described as a utility for payments, staking/collateral and governance, but services can also be paid for in fiat (so the token is partially replaceable).
  • Red flags (based on the information found): the risk of a gap between “blockchain‑based” claims and the actual share of onchain logic; the risk of substituting “AI” (the project is about data, but not necessarily about AI models); the risk that reward mechanics dominate over dataset quality.

DecAI Fit component summary

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

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): not applicable: AI relevance is confirmed by the description of a working product (see AI_1/AI_2), not only by “intentions”.
  • Evidence: Tier‑1 — https://docs.oortech.com/oort/services/oort-datahub
  • Why sufficient / why not (one line): there is a description of a working AI‑data product → AI_0 is not needed as “intent”.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): DataHub collects and preprocesses data (including labeling/classification/validation) to improve AI/ML models.
  • Evidence: Tier‑1 — https://docs.oortech.com/oort/services/oort-datahub; https://www.oortech.com/datahub
  • Why sufficient / why not (one line): Tier‑1 sources directly describe data collection/preprocessing for AI training/ML.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): there is an accessible product demo artifact: the web version of DataHub and links to the mobile apps.
  • Evidence: Tier‑1 — https://www.oortech.com/datahub; https://datahub.oortech.com/home
  • Why sufficient / why not (one line): the Tier‑1 website gives a direct “Use on web” link to DataHub → this is a reproducible example.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://docs.oortech.com/oort/services/oort-datahub
  • Why sufficient / why not (one line): Tier‑1 describes the product and the task types, but gives no quantitative quality metrics/benchmarks.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): Tier‑1 sources contain no detailed technical description of an AI model/versions; the product pipeline of data collection/preprocessing is described.
  • Evidence: Tier‑1 — https://docs.oortech.com/oort/services/oort-datahub
  • Why sufficient / why not (one line): the absence of a technical description of models/architecture → AI_4 = 0.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Ethereum (ERC‑20 OORT); Tier‑1 sources also claim its own L1 “Olympus Protocol / OORT mainnet”.
  • Addresses/identifiers: OORT token (ERC‑20): 0x5651fa7a726b9ec0cad00ee140179912b6e73599; OORT mainnet explorer: mainnet-scan.oortech.com.
  • Evidence: Tier‑1 — https://etherscan.io/token/0x5651fa7a726b9ec0cad00ee140179912b6e73599; https://docs.oortech.com/oort; https://github.com/oort-tech/Olympus/releases/tag/v1.1.8
  • Why sufficient / why not (one line): there is a verifiable onchain artifact (the ERC‑20 contract) and a Tier‑1 description of the L1/repository.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: traceability of data provenance and “blockchain‑based quality verification” in DataHub; governance (proposals/voting); staking/rules for node providers are described as part of the ecosystem.
  • Evidence: Tier‑1 — https://docs.oortech.com/oort/services/oort-datahub; https://docs.oortech.com/oort/about-oort/tokenomics; https://www.oortfoundation.org/governance
  • Why sufficient / why not (one line): Tier‑1 sources describe onchain functions broader than token issuance/circulation.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: a micro‑task platform for data collection/labeling can also operate in a centralized model; Tier‑1 sources do not prove that a key property breaks down without a blockchain.
  • Evidence: Tier‑1 — https://docs.oortech.com/oort/services/oort-datahub
  • Why sufficient / why not (one line): “criticality” per the replacement test is not proven → OC_3 = 0.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a utility token, OORT.
  • Evidence: Tier‑1 — https://docs.oortech.com/oort/about-oort/tokenomics
  • Why sufficient / why not (one line): the Tier‑1 tokenomics describes the token’s utilities → TK_0 = 0.
  • 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): the token is used to pay for services in the ecosystem (usually at a discount compared to paying in fiat).
  • Evidence: Tier‑1 — https://docs.oortech.com/oort/about-oort/tokenomics
  • Why sufficient / why not (one line): Tier‑1 directly describes “Service Payment” and a discount when paying with the token.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): OORT staking is used via pools/delegation and as collateral for node providers (“mining collateral”).
  • Evidence: Tier‑1 — https://docs.oortech.com/oort/about-oort/tokenomics
  • Why sufficient / why not (one line): Tier‑1 describes staking and bonding pools/collateral for node providers.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): OORT is used for voting/delegation in governance and for the proposal deposit.
  • Evidence: Tier‑1 — https://www.oortfoundation.org/governance; https://docs.oortech.com/oort/about-oort/tokenomics
  • Why sufficient / why not (one line): the governance page and the tokenomics describe participation in governance with the token.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 1
  • Claim (one line): the token as a means of payment is partially replaceable, because Tier‑1 sources explicitly allow paying for services in fiat.
  • Evidence: Tier‑1 — https://docs.oortech.com/oort/about-oort/tokenomics
  • Why sufficient / why not (one line): “Users can always pay fiat …” → the irreplaceability of specifically the token is not proven → TK_4 = 1.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.oortech.com/oort OORT is described as a data cloud for decentralized AI; Olympus Protocol is called a “native Layer 1”; the PoH (Proof of Honesty) consensus is mentioned.
Tier‑1 https://docs.oortech.com/oort/services/oort-datahub DataHub: collection/preprocessing/verification of AI data; “blockchain‑based quality verification”, traceability of data provenance.
Tier‑1 https://www.oortech.com/datahub Public description of DataHub as a service for AI training data + links to web/app (demo artifact).
Tier‑1 https://datahub.oortech.com/home Accessible web interface of the product (demo/app).
Tier‑1 https://docs.oortech.com/oort/about-oort/tokenomics Token utilities (payments/staking/governance) and the direct statement that services can be paid for in fiat; buyback & burn parameters.
Tier‑1 https://www.oortfoundation.org/governance Governance: voting/delegation with OORT and a link to the proposals platform.
Tier‑1 https://etherscan.io/token/0x5651fa7a726b9ec0cad00ee140179912b6e73599 Onchain fact: the ERC‑20 OORT contract and max total supply on Ethereum.
Tier‑1 https://github.com/oort-tech/Olympus/releases/tag/v1.1.8 Tier‑1 development artifact: a release/upgrade of Olympus Protocol (mainnet software).

No comments to display

Back to top