Skip to main content

APRO

APRO (AT) — 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).

APRO — an AI/Other | Infra project: oracle services (Data Push/Data Pull: price feeds) and a separate product, APRO AI Oracle, for “LLM/AI agents”, which promises to deliver real‑time data with validation/signatures. Token: AT (BEP‑20 on BNB Smart Chain and ERC‑20 on Ethereum; claimed as a staking token for node operation/security and for participation in governance; payment role — “advanced phases”).

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 oracle platform with price feeds (push/pull models) and API services for obtaining data (including for AI agents).
  • Who it’s for: dApp/DeFi developers and teams that need verifiable quotes/reports; AI agent developers who need access to real‑time data (as claimed).
  • Why onchain/token: onchain is used for the contract addresses of price feeds and for report verification (signatures/timestamps) before writing to the contract; the AT token is claimed as a staking token for running oracle nodes and as part of governance (Tier‑1), while the role of a “payment token” is described as a later phase.
  • What you can actually touch (Tier‑1): the Quickstart for the APRO AI Oracle API (docs.apro.com/ai-oracle/.../quickstart) + demo code on GitHub (apro_contract/demo).

How it works (very briefly)

  1. The user does: integrates price feeds (Data Push) into a smart contract or obtains signed reports (Data Pull) via the API.
  2. The system does: independent node operators collect data; for the pull model a report is formed (price/timestamp/signatures), which can be submitted for verification to an onchain contract.
  3. The user gets: onchain access to quotes/data via aggregator addresses and/or the ability to verify a report and then read the price from the contract.
  4. Where the blockchain is: the addresses of price feed contracts and the logic of report verification/price updates (EVM contracts); the AT token — ERC‑20 on Ethereum.
  5. Token role: the existence of the token is confirmed onchain; why exactly it is needed in the product (payments/staking/governance) — not established per Tier‑1.

Quick links: AI thesis fit

Project passport

Field Value
Project name APRO
Also known as (aliases) APRO Oracle | APRO AI Oracle | AT
Logo (logo) ../assets/56_apro_logo.svg
Token symbol (ticker) AT
Category AI/Other | Infra
Primary chain (chain) Ethereum
Type EVM
Network status mainnet
Consensus (consensus) PoS (Ethereum)
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract Ethereum: 0x0581CCdf2d9BcA21baEfF8b32b2551fd49CF70aa; BNB Smart Chain: 0x9be61A38725b265BC3eb7Bfdf17AfDFc9d26C130
Token model (token_type) utility (staking + governance)
Max supply 1,000,000,000
Issuance fixed cap
Tokenomics (tokenomics, brief) max supply 1B; TGE 2025‑10‑24; initial circulating 230M; allocation: staking rewards 20%, ecosystem 25%, investors 20%, public 15%, team 10% (Tier‑1).
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) AI oracle for LLM/agents
Use‑case (use_case) price feeds + report verification
DecAI Fit — AI thesis fit 5/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 2 / onchain_score 3 / token_score 2 / evidence_score 3
Last verified 2026-02-11

General project overview

APRO is a set of oracle services for delivering data to smart contracts and applications. The documentation describes two main modes: Data Push (contracts read the price from an onchain aggregator at an address) and Data Pull (the price is delivered as a report with price/timestamp/signatures; the report is then verified onchain and written to the contract). A separate product, APRO AI Oracle, is positioned as an “AI oracle” for LLMs and autonomous agents: the goal is to give models access to real‑time data with validation, so that “grounding” reduces hallucinations (per Tier‑1).

Features/modules

  • APRO Data Push: price feeds with onchain aggregator addresses and an integration example via AggregatorV3Interface.
  • APRO Data Pull (EVM): reports (price/timestamp/signatures) that can be verified in an onchain contract, after which the price can be read.
  • APRO AI Oracle: API access to data for AI models/agents; the docs claim LLM/agents + grounding scenarios.
  • Dev artifacts: public smart contracts and demo scripts on GitHub (apro_contract/demo).

Typical scenarios

  • Scenario 1 (Data Push): a dApp connects the address of a price feed contract → reads latestRoundData() and uses the price in its logic.
  • Scenario 2 (Data Pull): a dApp obtains a report via the API → submits the report for verification to an onchain contract → uses the verified price in a transaction or reads it later.
  • Scenario 3 (AI agents): an AI agent requests data via the AI Oracle API → uses it for answers/decisions (as claimed in the docs).

Getting started (wallet/network)

  • What you need: an EVM environment (contract/scripts) and access to the docs; for AI Oracle API v2 — an API key (per the docs).
  • Network/chain: price feeds are available on various EVM networks (list of contracts in the docs); the AT token — ERC‑20 on Ethereum.
  • Fees: onchain — network gas for report verification/contract calls; offchain — API calls (there may be pricing/credits, described in the AI Oracle Quickstart).

Architecture/tech (non‑AI)

  • Components: price feed contracts (aggregators) on EVM networks; an onchain report verifier for the pull model; an offchain API/Live‑API service for issuing reports; a repository of contracts/demos.
  • Participant roles: independent node operators (data collection/signing), dApp developers, users who submit reports for verification.
  • Where logic runs: offchain — data collection and report preparation; onchain — verification of signature/validity and storage/reading of the price in the contract.
  • Dependencies: EVM networks (contract addresses in the docs), web API/APRO Live‑API.

Token/economics (expanded, no forecasts)

  • Token utility: the Tier‑1 tokenomics describes $AT as a token with the utility of staking for node operation/network security and governance; the payment role is described as “advanced phases”.
  • Protocol necessity drivers: a stake $AT requirement is claimed for operating oracle nodes (Tier‑1); for data pull, the onchain costs are described in the docs as paid in the network’s gas tokens (not $AT).
  • Who pays fees: network users pay gas for onchain operations (report verification/contract calls); for Data Pull service fees, the docs state that they are paid in native gas tokens and their ERC‑20 wrappers; the AI Oracle API has a rate‑limit/credit model (Quickstart).
  • Where fees go: — (not established).
  • Issuance/burn: the Tier‑1 tokenomics specifies a max supply of 1B and the distribution/vesting; burning is not described as a key mechanism.
  • Security/incentive mechanisms: staking rewards of 20% of supply (48‑month vesting) are claimed as the source of incentives for node operations and network security; data security is described as multi‑source + consensus + signatures.
  • Distribution and token issuance schedule: — (not established per Tier‑1).
  • Treasury: — (not established).

Governance

  • Who makes decisions: — (governance/DAO processes are not described as Tier‑1 in the reviewed sources).
  • How protocol parameters change: via updates of contracts/infrastructure and documentation (the detailed procedure is not established per Tier‑1).
  • Where decisions are discussed/made: — (not established).
  • Keys/multisig: — (not established per Tier‑1).

Security and incidents

  • Audits: — (no audit report is listed in links_*; no Tier‑1 audit of the key contracts was found).
  • Bug bounty: — (links_* shows —; no Tier‑1 program was found).
  • Incidents: — (no public postmortems identified per Tier‑1).
  • Threat model: compromise of the offchain API/access keys (AI Oracle v2), errors/manipulation in data sources and in consensus aggregation, risks of report verification and dApp integrations (errors in using reports/validity), proxy/upgrade risks of the token/contracts (including admin control).

Project status and timeline

  • Current status: the Data Service and AI Oracle documentation is available; the AT token exists on Ethereum (Etherscan); the contract/demo repositories are public.
  • Key releases/milestones: there are no GitHub Releases for apro_contract; the price feed contract addresses are regularly updated in the docs.
  • Roadmap: — (the Roadmap row in links_* = —; no separate Tier‑1 roadmap was extracted).

Ecosystem/integrations

  • Integrations: EVM networks/smart contracts (list of supported chains and price feed addresses in the docs); REST API and WebSocket (for the pull model); GitHub demos and integration examples.
  • Partners: — (confirmed partnerships/integrations were not extracted as Tier‑1).
  • Where it’s actually used: integration of price feeds into EVM contracts (Data Push) and onchain verification of pull reports for using prices in dApp business logic.

AI component of the project

  • What is real AI here? the Tier‑1 docs describe the “AI Oracle” as a layer that gives LLMs/agents real‑time data with consensus validation in order to reduce hallucinations; at the same time, no metrics/quality assessment of the “AI part” have been published.
  • What is truly onchain? the addresses of price feed contracts and onchain verification of pull reports (price/timestamp/signatures) before writing to the contract; the AT token — ERC‑20 on Ethereum.
  • Why is a token needed? the Tier‑1 tokenomics describes the need to stake $AT to run oracle nodes (security) and participation in governance; the payment role is claimed as a later phase, while the Data Pull docs state that service fees are paid in the network’s gas tokens.
  • Red flags (based on the information found): AI‑washing (many strong claims about LLMs/hallucinations without metrics/an “out‑of‑the‑box” agent demo), token‑washing (it is unclear where AT is mandatory); what to double‑check: token utility in the whitepaper/docs, the incentive economics of node operators, audit/security of the key contracts.

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 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): the intent flag is not needed, since there are separate Tier‑1 pages describing the APRO AI Oracle product and a Quickstart.
  • Evidence: Tier‑1 — https://docs.apro.com/ai-oracle/readme/what-is-apro-ai-oracle
  • Why sufficient / why not (one line): AI is described as a product/component, not only as a plan.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): APRO AI Oracle claims a data layer for LLMs/agents: real‑time verifiable data (multi‑source + consensus + signatures) for “grounding” and reducing hallucinations.
  • Evidence: Tier‑1 — https://docs.apro.com/ai-oracle/readme/what-is-apro-ai-oracle
  • Why sufficient / why not (one line): Tier‑1 describes a specific function of an AI‑oriented component (data grounding for LLM/agents).
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): the Quickstart provides a reproducible example of AI Oracle API calls (v1/v2), and GitHub has demo scripts for reading data.
  • Evidence: Tier‑1 — https://docs.apro.com/ai-oracle/getting-started/quickstart, https://github.com/APRO-Oracle/apro_contract/tree/main/demo
  • Why sufficient / why not (one line): these are a reproducible tutorial/example (Tier‑1) for integration.
  • Conflict note (if any): v2 requires an API key; some scenarios go through one’s own backend.

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://docs.apro.com/ai-oracle/readme/what-is-apro-ai-oracle
  • Why sufficient / why not (one line): Tier‑1 has no quantitative quality metrics/benchmarks for the AI component.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): no technical description of specific models/versions/inference methods was found; only the concept and the data/validation flow are described.
  • Evidence: Tier‑1 — https://docs.apro.com/ai-oracle/readme/what-is-apro-ai-oracle
  • Why sufficient / why not (one line): without a versioned technical spec/model parameters we record 0.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: EVM (including Ethereum; also a list of contracts on other networks)
  • Addresses/identifiers: the AT token (Ethereum): 0x0581CCdf2d9BcA21baEfF8b32b2551fd49CF70aa; the price feed contracts are listed in the docs (many networks/addresses).
  • Evidence: Tier‑1 — https://etherscan.io/token/0x0581CCdf2d9BcA21baEfF8b32b2551fd49CF70aa, https://docs.apro.com/en/data-push/price-feed-contract
  • Why sufficient / why not (one line): there are onchain identifiers (token + price feed addresses) in Tier‑1.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: reading price feeds at aggregator addresses (Data Push) and onchain verification of pull reports (price/timestamp/signatures) with the data written to the contract.
  • Evidence: Tier‑1 — https://docs.apro.com/en/data-push/getting-started, https://docs.apro.com/en/data-pull-evm-chain/getting-started
  • Why sufficient / why not (one line): the docs describe onchain calls/verification as part of the product, not just token issuance.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without onchain, the verifiability/usability of oracle data in smart contracts is lost: there is nowhere to verify a report and store the “verified price” for subsequent logic.
  • Evidence: Tier‑1 — https://docs.apro.com/en/data-pull-evm-chain/getting-started
  • Why sufficient / why not (one line): Tier‑1 directly describes onchain report verification and storing the price in the contract as the basis of the scenarios.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, AT (ERC‑20 on Ethereum).
  • Evidence: Tier‑1 — https://etherscan.io/token/0x0581CCdf2d9BcA21baEfF8b32b2551fd49CF70aa
  • Why sufficient / why not (one line): the onchain fact of the token is confirmed by the explorer.
  • 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): the Data Pull docs state that service fees are paid in native gas tokens and ERC‑20 wrappers; in the tokenomics post, “payment in $AT” is described as advanced phases (not a current must‑have).
  • Evidence: Tier‑1 — https://docs.apro.com/en/data-pull-evm-chain/on-chain-costs, https://medium.com/@APRO_Oracle/at-tokenomics-unveiled-building-a-sustainable-value-ecosystem-for-next-generation-oracle-3eb4ebad85d9
  • Why sufficient / why not (one line): this does not confirm that paying for services in the AT token is currently mandatory → we record 0 (conservatively).
  • Conflict note (if any): a shift is possible in the future if $AT becomes the “primary payment method” (as claimed).

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

  • TK_2 (decision): 1
  • Claim (one line): the Tier‑1 tokenomics claims that operators are required to stake $AT to run oracle nodes (network security); a staking rewards pool of 20% of supply is also allocated.
  • Evidence: Tier‑1 — https://medium.com/@APRO_Oracle/at-tokenomics-unveiled-building-a-sustainable-value-ecosystem-for-next-generation-oracle-3eb4ebad85d9
  • Why sufficient / why not (one line): there is a direct Tier‑1 statement about the staking requirement and reward allocation.
  • Conflict note (if any): details of the staking/slashing mechanics and the onchain staking contracts were not extracted.

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): the Tier‑1 tokenomics describes governance via community voting (including “pace of release … subject to community voting”) and links participation to staking.
  • Evidence: Tier‑1 — https://medium.com/@APRO_Oracle/at-tokenomics-unveiled-building-a-sustainable-value-ecosystem-for-next-generation-oracle-3eb4ebad85d9
  • Why sufficient / why not (one line): there is a Tier‑1 statement about governance/voting tied to the token/staking.
  • Conflict note (if any): the specific governance venue/procedure (Snapshot/DAO, etc.) is not specified.

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the token is tied to staking for node operation/security and is claimed as a governance token; a strict replaceability test was not performed → we record 0 (conservatively).
  • Evidence: Tier‑1 — https://medium.com/@APRO_Oracle/at-tokenomics-unveiled-building-a-sustainable-value-ecosystem-for-next-generation-oracle-3eb4ebad85d9
  • Why sufficient / why not (one line): without technical details of staking/validators and without a comparison of alternatives we leave 0.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.apro.com/ai-oracle/readme/what-is-apro-ai-oracle Tier‑1: the AI Oracle thesis (for LLMs/agents), how it works (multi-source, consensus, signatures), use-cases.
Tier‑1 https://docs.apro.com/ai-oracle/getting-started/quickstart Tier‑1: Quickstart/guide for the AI Oracle API (a reproducible example of calls).
Tier‑1 https://github.com/APRO-Oracle/apro_contract/tree/main/demo Tier‑1: demo scripts/integration artifacts (an example of obtaining data).
Tier‑1 https://docs.apro.com/en/data-push/getting-started Tier‑1: Data Push — onchain price feeds and an example of reading data from a contract.
Tier‑1 https://docs.apro.com/en/data-pull-evm-chain/getting-started Tier‑1: Data Pull — report (price/timestamp/signatures), onchain verification and usage scenarios in a contract.
Tier‑1 https://docs.apro.com/en/data-push/price-feed-contract Tier‑1: list of price feed contract addresses on various networks (onchain identifiers).
Tier‑1 https://medium.com/@APRO_Oracle/at-tokenomics-unveiled-building-a-sustainable-value-ecosystem-for-next-generation-oracle-3eb4ebad85d9 Tier‑1: $AT tokenomics (max supply 1B, BEP‑20/ERC‑20 formats, addresses, TGE, allocation; staking requirement; governance claims; payment intent “advanced phases”).
Tier‑1 https://docs.apro.com/en/data-pull-evm-chain/on-chain-costs Tier‑1: Data Pull onchain costs/service fees are paid in the network’s gas tokens (not $AT) — important for TK_1.
Tier‑1 https://etherscan.io/token/0x0581CCdf2d9BcA21baEfF8b32b2551fd49CF70aa Tier‑1: the onchain fact of the ERC‑20 AT token on Ethereum (address/contract).
Tier‑2 https://coinmarketcap.com/currencies/apro/ Context/profile (not proof).
Tier‑3 — —

No comments to display

Back to top