Alaya AI
Alaya AI — 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).
Alaya AI — an AI/Data project: Web3‑oriented infrastructure for data collection/labeling and auto‑labelling; token: AGT (BNB Chain).
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/network for crowdsourcing AI data (collection, labeling, validation) and claimed auto‑labelling.
- Who it’s for: AI developers/teams that need datasets; users who contribute data.
- Why onchain/token: AGT is used for staking/access to roles and governance, NFT mechanics and the claimed custom data requests.
How it works (very briefly)
- The user does: registers (by email or via a wallet) and performs data tasks (labeling/validation).
- The system does: distributes tasks and processes the results; claims auto‑labelling and quality optimization/verification (RLHF/HITL, PSO, etc.).
- The user gets: rewards (token/NFT) and access to more complex tasks if they hold the required NFTs/stake.
- Where the blockchain is: accounting of the AGT stake, NFT levels/upgrades and governance participation is described as the onchain part.
- Token role (if any): AGT is needed for staking (access to roles/tasks), NFT upgrades, governance and the claimed custom data requests.
Quick links: AI thesis fit
Project passport
| Field | Value |
|---|---|
| Project name | Alaya AI |
| Also known as (aliases) | Alaya; AGT |
| Logo (logo) | ../assets/165_alaya-ai_logo.png |
| Token symbol (ticker) | AGT |
| Category | AI/Data | Infra |
| Primary chain (chain) | BNB Smart Chain |
| Type | EVM |
| Network status | mainnet |
| Consensus (consensus) | — |
| Launch date (launch_date) | — |
| Project status (status) | active |
| Token (standard) | BEP-20 |
| Token contract | 0x5dBde81fcE337FF4bcaaEe4Ca3466C00aeCaE274 |
| Token model (token_type) | utility (governance + staking-gated access) |
| Max supply | 5,000,000,000 AGT |
| Issuance | fixed (mint at deployment) |
| Tokenomics (tokenomics, brief) | AGT staking is required for roles (validation/calibration), NFT upgrades, governance and custom data requests |
| Governance | DAO governance (claimed: voting requires an AGT stake) |
| Admins/keys | — |
| Audit | — |
| Bug bounty | — |
| Team (team) | — |
| Funding (investors/funding) | — |
| AI component (ai_component) | auto-labelling + RLHF/HITL + data sampling |
| Use‑case (use_case) | data collection/labeling for AI training |
| DecAI Fit — AI thesis fit | 5/6 — high alignment with the Decentralized AI thesis |
| DecAI Fit component summary | 2 / 2 / 3 / 3 |
| Last verified | 2026-02-11 |
Links (links_*)
| Type | Link |
|---|---|
| Website | https://www.aialaya.io/#/ |
| Docs | https://alaya-ai.gitbook.io/alaya-ai/technology |
| GitHub | https://github.com/aialaya |
| Releases / Changelog | https://github.com/aialaya/contract/releases |
| Whitepaper | https://aialaya.io/whitepaper |
| Roadmap | — |
| Security advisories | https://github.com/aialaya/contract/security/advisories |
| Explorer | https://bscscan.com/token/0x5dBde81fcE337FF4bcaaEe4Ca3466C00aeCaE274 |
| X | https://twitter.com/Alaya_AI |
| Discord | — |
| Telegram | https://t.me/Alaya_AI |
| Medium | https://medium.com/@alaya-ai |
| Audit report(s) | — |
| Bug bounty | — |
| CoinGecko (profile, reference) | https://www.coingecko.com/en/coins/alaya-ai |
| CoinMarketCap (profile, reference) | https://coinmarketcap.com/currencies/alaya-ai/ |
General project overview
Alaya AI is positioned as Web3 infrastructure for AI data: it brings together distributed communities that perform collection/labeling/validation tasks and AI developers who need datasets. In the documentation, the project describes itself as an “open, composable Web3 AI data infrastructure network” that uses gamification and onchain incentives, and also claims auto‑labelling and an optimization architecture (Interaction/Optimisation/Intelligent Modelling layers).
Note on networks (passport normalization): the AGT token is claimed/shown on BNB Smart Chain; the project materials also mention Arbitrum and opBNB (as context/integrations).
Features/modules
- Distributed Data Ecosystem: an automated flow “order → task distribution → execution → preprocessing/quality assessment → delivery”.
- Open Data Platform: customizable data pools and a “data consumer ↔ providers” link with token incentives (including custom token support for individual pools).
- Data Auto‑Labelling Toolset: auto‑labelling models, RLHF fine‑tuning and a “three‑layer optimisation architecture” are claimed.
- User roles / gating: advanced tasks require a Medallion NFT and/or an AGT stake (per the documentation).
Typical scenarios
- Scenario 1 (contributor): performs simple labeling tasks → receives rewards/achievements → as the level grows (NFT/stake), gains access to advanced tasks.
- Scenario 2 (AI developer): sets data requirements → launches collection/labeling via the platform → receives prepared data.
- Scenario 3 (governance): stakes AGT → participates in votes/proposals and “model feature proposals” (claimed).
Getting started (wallet/network)
- What you need: an account (email) or an EVM wallet; a wallet is required when withdrawing NFTs/tokens to self‑custody.
- Network/chain: the user manual states that the app supports Arbitrum and opBNB; the AGT token is on BNB Chain (BscScan).
- Fees: onchain operations depend on the chosen network (Arbitrum/opBNB/BNB Chain); the internal reward logic is described at the product level.
Architecture/tech (non‑AI)
- Components: frontend (app/dApp), task distribution system, preprocessing/quality assessment, onchain accounting of the token/stake and NFT gating (per the description).
- Participant roles: data contributors, AI data customers, advanced users/validators (gated), governance participants.
- Where logic runs: labeling tasks and preprocessing — offchain; stake/gating/NFT/governance — onchain (claimed).
- Dependencies: EVM networks (Arbitrum/opBNB/BNB Chain), wallets, explorers.
Token/economics (expanded, no forecasts)
- Token utility: AGT is described as a utility+governance token: needed for governance, “auto‑labelling model development”, NFT upgrades, custom data requests, etc.; AGT is also awarded for task completion/achievements.
- Protocol necessity drivers: the AGT stake is described as mandatory for access to roles (validation/calibration) and as a “sunken cost” for anti‑spam/security.
- Who pays fees: users performing onchain actions (stake/withdrawal/upgrades) pay network fees.
- Where fees go: no explicit onchain fee flows/treasury addresses were found in the studied Tier‑1 pages.
- Issuance/burn: max supply 5B AGT (per BscScan); a “fixed” model (mint at deployment).
- Security/incentive mechanisms: staking‑gated access; the docs emphasize the role of the stake as an anti‑malicious‑input mechanic.
- Distribution and token issuance schedule: — (not explicitly extracted from the studied Tier‑1 pages).
- Treasury: — (not explicitly extracted from the studied Tier‑1 pages).
Governance
- Who makes decisions: DAO governance (claimed: governance requires an AGT stake).
- How protocol parameters change: via proposals/votes, including “voting for auto‑labelling model features and proposals” (in the description of AGT).
- Where decisions are discussed/made: — (no forum/snapshot URL is given in the studied pages).
- Keys/multisig: —.
Security and incidents
- Audits: — (no audits are listed in links_*; the explorer shows “No Contract Security Audit Submitted” for AGT).
- Bug bounty: —.
- Incidents: —.
- Threat model: data quality/spam (addressed by economic incentives), centralization risks of the offchain pipeline, smart contract risks of the token/staking and of bridges/multi‑chain support.
Project status and timeline
- Current status: active (the platform is described in the docs; the AGT token is on BNB Chain mainnet).
- Key releases/milestones: —.
- Roadmap: — (in
links_*the Roadmap field =—).
Ecosystem/integrations
- Integrations: BNB Chain (token); Arbitrum and opBNB are mentioned in the user materials as the app’s networks; GitHub as the development channel (see
links_*). - Partners: — (not listed in the reviewed Tier‑1 sources).
- Where it’s actually used: crowdsourced data labeling/validation and data pipelines for AI teams (described in the docs; see
links_*).
AI component of the project
- What is real AI here? The Tier‑1 docs describe auto‑labelling models and an optimization architecture with RLHF/HITL iterations; in DecAIHub terms this is the “AI core of the product” (not just “AI marketing”).
- What is truly onchain? The AGT stake and NFT gating (Medallion NFT / NFT upgrades), as well as governance access, are described as onchain components.
- Why is a token needed? AGT is a security/incentive/gov token and a mechanism of access to “advanced” roles/tasks; it is also described as required for custom data requests.
- Red flags (based on the information found): AI‑washing — medium (there are strong claims about quality/an 80% verification rate without a public benchmark); onchain‑washing — medium (few specific contract addresses apart from the token). What to double‑check — the actual addresses of the staking/NFT/gating contracts and public quality metrics.
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 | 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): the AI component is described as functionality (not only intent), so AI_0 is not used.
- Evidence: Tier‑1 — https://alaya-ai.gitbook.io/alaya-ai/core-features/data-auto-labelling-toolset
- Why sufficient / why not (one line): the docs provide a description of the AI module, so the intent flag is not needed.
- Conflict note (if any): —
AI_1 — what the AI does (1/0)
- AI_1 (decision): 1
- Claim (one line): auto‑labelling models and RLHF fine‑tuning are described to increase labeling efficiency and reduce costs.
- Evidence: Tier‑1 — https://alaya-ai.gitbook.io/alaya-ai/core-features/data-auto-labelling-toolset ; https://alaya-ai.gitbook.io/alaya-ai
- Why sufficient / why not (one line): there is a Tier‑1 description of “what the AI does” in the product (auto‑labelling / RLHF/HITL).
- Conflict note (if any): —
AI_2 — demos/examples (1/0)
- AI_2 (decision): 0
- Claim (one line): there are user scenarios/an app, but a public demo specifically of the AI module (inference/auto‑labelling as an artifact) is not recorded.
- Evidence: Tier‑1 — https://alaya-ai.gitbook.io/alaya-ai/user-manual/how-to-start
- Why sufficient / why not (one line): the onboarding description is not a demo of AI quality.
- Conflict note (if any): —
AI_3 — metrics/quality (1/0)
- AI_3 (decision): 0
- Metrics: “over 80% verification rate for most common AI data categories” is claimed.
- Context (version/date/how measured): not specified (no benchmark/dataset/version).
- Evidence: Tier‑1 — https://alaya-ai.gitbook.io/alaya-ai/core-features/data-auto-labelling-toolset
- Why sufficient / why not (one line): there is a metric, but without a reproducible context — insufficient for AI_3=1.
- Conflict note (if any): —
AI_4 — tech description/architecture/versions (1/0)
- AI_4 (decision): 1
- Claim (one line): a three‑layer optimization architecture (Interaction/Optimisation/Intelligent Modelling) and the approaches used (RLHF/HITL, PSO) are described.
- Evidence: Tier‑1 — https://alaya-ai.gitbook.io/alaya-ai/technology/three-layer-optimisation-architecture
- Why sufficient / why not (one line): there is a Tier‑1 technical description of the architecture of the AI part.
- Conflict note (if any): —
Onchain necessity
OC_1 — contracts/addresses/chain (1/0)
- OC_1 (decision): 1
- Chain: BNB Chain (BSC)
- Addresses/identifiers: AGT token: 0x5dBde81fcE337FF4bcaaEe4Ca3466C00aeCaE274
- Evidence: Tier‑1 — https://bscscan.com/token/0x5dBde81fcE337FF4bcaaEe4Ca3466C00aeCaE274
- Why sufficient / why not (one line): the onchain anchor (token) is confirmed by the explorer.
- Conflict note (if any): —
OC_2 — onchain beyond just a token (1/0)
- OC_2 (decision): 1
- What useful logic is onchain: staking‑gated access to roles/advanced tasks, DAO governance, NFT upgrades (claimed as part of the mechanics).
- Evidence: Tier‑1 — https://alaya-ai.gitbook.io/alaya-ai/user-manual/usdagt-token ; https://alaya-ai.gitbook.io/alaya-ai/user-manual/task-categories
- Why sufficient / why not (one line): the docs state that the AGT stake and NFT levels/upgrades affect access and governance.
- Conflict note (if any): no addresses of these contracts in the studied pages.
OC_3 — onchain is critical (1/0)
- OC_3 (decision): 0
- “Replace the blockchain” test: the data pipeline (collection/labeling) can exist offchain; onchain adds transparent incentives/gating, but without it the product does not “break down” as a labeling service.
- Evidence: Tier‑1 — https://alaya-ai.gitbook.io/alaya-ai
- Why sufficient / why not (one line): onchain criticality is not proven as “impossible without a blockchain”.
- Conflict note (if any): —
Token necessity
TK_0 — no token (1/0)
- TK_0 (decision): 0
- Claim (one line): the project has a token, AGT.
- Evidence: Tier‑1 — https://alaya-ai.gitbook.io/alaya-ai/user-manual/usdagt-token ; https://bscscan.com/token/0x5dBde81fcE337FF4bcaaEe4Ca3466C00aeCaE274
- Why sufficient / why not (one line): the token is described in the official docs and 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): 1
- Claim (one line): AGT is required for custom data requests and for publishing data package offers (as part of the utility).
- Evidence: Tier‑1 — https://alaya-ai.gitbook.io/alaya-ai/user-manual/usdagt-token
- Why sufficient / why not (one line): the docs explicitly state “required for ... custom data requests”.
- Conflict note (if any): —
TK_2 — incentives/collateral/penalties (1/0)
- TK_2 (decision): 1
- Claim (one line): the AGT stake is mandatory for participation in data validation and access to advanced tasks; it is described as a “sunken cost” to protect against abuse.
- Evidence: Tier‑1 — https://alaya-ai.gitbook.io/alaya-ai/user-manual/usdagt-token ; https://alaya-ai.gitbook.io/alaya-ai/user-manual/task-categories
- Why sufficient / why not (one line): it is stated that AGT staking is required for roles and for security/incentive alignment.
- Conflict note (if any): —
TK_3 — governance (1/0)
- TK_3 (decision): 1
- Claim (one line): DAO governance requires an AGT stake (voting for features/proposals).
- Evidence: Tier‑1 — https://alaya-ai.gitbook.io/alaya-ai/user-manual/usdagt-token
- Why sufficient / why not (one line): the docs directly describe the governance utility.
- Conflict note (if any): —
TK_4 — token is replaceable (1/0)
- TK_4 (decision): 0
- Claim (one line): AGT is built into the platform’s access to roles/gating/governance mechanics; replacement with “any asset” is not described.
- Evidence: Tier‑1 — https://alaya-ai.gitbook.io/alaya-ai/user-manual/usdagt-token
- Why sufficient / why not (one line): AGT is described as mandatory for governance/staking/roles, which makes it “irreplaceable” in the current design.
- Conflict note (if any): the Open Data Platform supports custom token pools for individual data requests, but this does not negate AGT’s role as the core coordination token.
Evidence (table)
| Tier | Source | What it proves |
|---|---|---|
| Tier‑1 | https://alaya-ai.gitbook.io/alaya-ai | What Alaya AI is; positioning as Web3 AI data infrastructure; the role of AGT staking in tokenized model staking pools (descriptive) |
| Tier‑1 | https://alaya-ai.gitbook.io/alaya-ai/core-features/data-auto-labelling-toolset | AI component: auto‑labelling, RLHF fine‑tuning, claimed properties/metrics (without a benchmark) |
| Tier‑1 | https://alaya-ai.gitbook.io/alaya-ai/technology/three-layer-optimisation-architecture | Technical description of the AI architecture (3 layers, RLHF/HITL, PSO, etc.) |
| Tier‑1 | https://alaya-ai.gitbook.io/alaya-ai/user-manual/usdagt-token | AGT utility: max circulation 5B; staking requirements; governance; NFT upgrades; custom data requests; security/incentives |
| Tier‑1 | https://alaya-ai.gitbook.io/alaya-ai/user-manual/task-categories | Task gating logic via NFT levels and/or AGT stake |
| Tier‑1 | https://alaya-ai.gitbook.io/alaya-ai/user-manual/how-to-start | Onboarding; wallet connection; mention of the supported networks (Arbitrum/opBNB) |
| Tier‑1 | https://bscscan.com/token/0x5dBde81fcE337FF4bcaaEe4Ca3466C00aeCaE274 | Max total supply 5B; onchain anchor of the AGT token |
No comments to display
No comments to display