Skip to main content

Codatta

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

Codatta — an onchain “knowledge layer” protocol for data and attribution in AI: it turns contributions by humans/agents (data/labels/validations) into ownership and royalty streams; token: XNY (BEP‑20, 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 protocol that turns data into “assets”: it records contributions and ownership rights and automatically splits payouts.
  • Who it’s for: teams that buy/use datasets and APIs; contributors/validators; quality “backers” (underwriters).
  • Why onchain/token: onchain is needed so that rights/ownership shares are transferable and verifiable and payouts are deterministic; XNY is used as the “operating currency” (task launches, access, trust staking, governance).

How it works (very briefly)

  1. The user does: a contributor (human/agent) submits a contribution (samples/labels/validations), or a client launches a task/buys access to data.
  2. The system does: records the contribution as a “contribution fingerprint”, links it to identity/reputation, assembles contributions into datasets and issues onchain ownership shares.
  3. The user gets: a verifiable provenance history (lineage), access to data/APIs and/or payouts/royalties upon usage.
  4. Where the blockchain is: onchain ownership/rights and royalty accrual/distribution; onchain events for metering/usage accounting.
  5. Token role (if any): XNY is needed for onchain actions (fees/gas), trust staking/slashing, task launches, data/API access and governance.

Quick links: AI thesis fit

Project passport

Field Value
Project name Codatta
Also known as (aliases) XNY; $XNY
Logo (logo) ../assets/149_codatta_logo.jpg
Token symbol (ticker) XNY
Category AI/Data
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
Token (standard) BEP-20
Token contract 0xE3225e11Cab122F1a126A28997788E5230838ab9 (BSC)
Token model (token_type) utility (staking + slashing + governance)
Max supply 10,000,000,000 XNY (on‑chain)
Issuance fixed max supply
Tokenomics (tokenomics, brief) Allocations: ecosystem incentives 24.5%, node incentives 10%, team 18%, airdrop 10%, etc. (see tokenomics).
Governance governance via XNY stake + reputation (per the docs)
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) AI data (lineage + metering + royalties)
Use‑case (use_case) ownable datasets + revenue sharing
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 1 / 3 / 3 / 3
Last verified 2026-02-11

General project overview

Codatta is positioned as an onchain knowledge layer for the AI economy: the protocol turns “atomic” contributions (data, labeling, validations, checks) into verifiable and tradable assets, and also builds the infrastructure for attribution and automatic payouts (royalties) to those who created and validated these assets.

The key idea is to make contributions to data/quality (which today are usually “lost” in centralized pipelines) become:

  • measurable (metering of usage for training/inference/checks),
  • verifiable (lineage/provenance),
  • convertible into rights (tokenized ownership fractions),
  • monetizable (deterministic royalty payouts according to protocol rules).

Features/modules

  • Contribution Fingerprint (CF): a “who/what/when/what proof” signature for contributions.
  • Identity & Reputation: privacy + reputation and a reward multiplier; staking “for trust”.
  • Lineage & Asset Assembly: assembling contributions into versioned datasets with provenance queries.
  • Storage / Compute / Serving: storage and secure serving/compute (the docs mention secure compute/TEE/federated).
  • Access Control & Metering: a policy gate and accounting/billing events for every “read”.
  • Tokenized Ownership Proofs: onchain ownership shares (transferable fractions).
  • Royalty Engine: calculation and distribution of payouts according to rules and metering.

Typical scenarios

  • Scenario 1 (client/AI builder): launches a data collection/labeling task → receives a dataset with lineage and rights → pays for access/a license → the protocol automatically distributes payouts.
  • Scenario 2 (contributor/validator): performs tasks (data sourcing/labeling/validation) → stakes XNY for access to premium tasks/to raise trust → receives payouts/royalties, risking slashing for low quality.
  • Scenario 3 (backer): stakes XNY, “underwrites” contributors/datasets → receives a share of revenue/royalties when the assets are used.

Getting started (wallet/network)

  • What you need: an EVM wallet for actions on BNB Chain; the role/access depends on the scenario (client/contributor/validator/backer).
  • Network/chain: BNB Smart Chain (BEP‑20 XNY; the docs also mention future networks Base/Ethereum).
  • Fees: BNB Chain network gas + protocol onchain fees/ops fees, which per the docs are denominated in XNY.

Architecture/tech (non‑AI)

  • Components: smart contracts (ownership/rights/royalties/staking/disputes), an access/metering gateway, a storage/compute/serving layer, identity/reputation mechanisms.
  • Participant roles: clients (data/API buyers), contributors/providers, validators, backers (underwriters), governance.
  • Where logic runs: rights/ownership/royalties/staking — onchain; data collection/storage and computation — offchain/secure compute, with onchain accounting of metering events.
  • Dependencies: BNB Chain (onchain), offchain storage/compute, access policy, dispute procedures.

Token/economics (expanded, no forecasts)

  • XNY token utility: the docs describe XNY as the “operating currency” — gas/fees for onchain actions, task launches, data/API access, mint/transfer of rights, priority/promotion, governance.
  • Protocol necessity drivers: for key functions (launch/access/licensing/disputes/governance) XNY is declared as required; stablecoins are allowed as payment of contributor payouts, but do not replace XNY at the control points.
  • Who pays fees: clients and protocol participants interacting with onchain functions and metered access.
  • Where fees go: to validators/ops + the treasury (the split is set by governance) — per the token utility description.
  • Issuance/burn: max supply 10B (fixed); “burn” details are not declared in the sources reviewed.
  • Security/incentive mechanisms: staking & slashing (stake on data/on a contributor; penalties for proven errors/fraud/failed audits).
  • Distribution: see allocation (ecosystem incentives, node incentives, team, airdrop, etc.); changes/unlocks — via governance.

Governance

  • Who makes decisions: governance participants (voters), where voting power is tied to XNY stake + reputation (per the docs).
  • How protocol parameters change: via governance approval (the tokenomics state that changes require governance approval).
  • Where decisions are discussed/made: — (not explicitly specified within the current Tier‑1 set).
  • Keys/multisig: — (not confirmed).

Security and incidents

  • Audits: — (no Tier‑1 audit reports found).
  • Bug bounty: — (no Tier‑1 bug bounty found).
  • Incidents: — (no Tier‑1 postmortems/incidents found).
  • Threat model: risks of data quality/metering/attribution, risks of abuse (fraud/scripting), risks of centralization of the offchain layers (storage/compute), risks of keys/contract administration (not disclosed).

Project status and timeline

  • Current status: active (public website/docs + onchain token on BNB Chain).
  • Key releases/milestones: — (no Tier‑1 list of releases/milestones recorded).
  • Roadmap: see links_* → Roadmap.

Ecosystem/integrations

  • Integrations: not established (no Tier‑1 list of integrations found).
  • Partners: — (no Tier‑1 confirmed list of partners found).
  • Where it’s actually used: as a protocol for accounting lineage/metering/royalties for datasets and contributions (per the description in the docs).

AI component of the project

  • What is real AI here? The protocol is oriented toward AI production/use of data (training/fine‑tune/evaluation) and allows “human & AI agents” as participants; “AI‑assisted review” is also mentioned, but without technical details/metrics.
  • What is truly onchain? Onchain ownership rights and transfer of fractions, onchain royalty routing/payouts and governance mechanics.
  • Why is a token needed? XNY is the operating currency: fees/gas, task launches, data/API access, trust staking/slashing, governance.
  • Red flags (based on the information found): AI‑washing — medium risk (a lot of “AI context”, but few technical artifacts); what to double‑check: the actual implementations of AI‑assisted review and which parts are really AI (rather than “agents” as a role).

DecAI Fit component summary

  • DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality low 1
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 AI_1: the use of AI context/AI agents/AI review is described).
  • Evidence: Tier‑1 — https://docs.codatta.io/en/quick-guide/overview
  • Why sufficient / why not (one line): AI_0 applies 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 protocol is intended for AI data pipelines (training/fine‑tune/evaluation) and describes the participation of “human & AI agents” and AI‑assisted review.
  • Evidence: Tier‑1 — https://docs.codatta.io/en/quick-guide/overview ; https://docs.codatta.io/en/business/incentives-staking
  • Why sufficient / why not (one line): Tier‑1 sources directly tie the system to AI data and mention AI‑assisted review.
  • Conflict note (if any): The technical details of the AI review are not disclosed (AI_4=0).

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): The Tier‑1 materials reviewed contain no reproducible AI demo/quality example.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): There is a concept/description, but no demonstration of AI results.
  • 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): Quantitative metrics of the AI subsystems are not given.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): The technical description of the AI review/AI models/versions is not disclosed.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): There is a protocol/data architecture, but not an AI architecture.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: BNB Smart Chain (mainnet)
  • Addresses/identifiers: XNY BEP‑20 contract 0xE3225e11Cab122F1a126A28997788E5230838ab9
  • Evidence: Tier‑1 — https://docs.codatta.io/en/protocol-token/token-info ; https://bscscan.com/token/0xE3225e11Cab122F1a126A28997788E5230838ab9
  • Why sufficient / why not (one line): The contract and network are confirmed by the official documentation and the explorer.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: Tokenized ownership proofs (transferable shares of rights), onchain actions (CF/ownership) and royalty payments according to protocol rules.
  • Evidence: Tier‑1 — https://docs.codatta.io/en/core-systems/architecture ; https://docs.codatta.io/en/protocol-token/token-utility
  • Why sufficient / why not (one line): Onchain rights/ownership and an onchain economy that is not reducible to “just a token” are described.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without onchain, the trustless transferability of rights and the verifiability/determinism of royalty splits are lost (a trusted operator is required).
  • Evidence: Tier‑1 — https://docs.codatta.io/en/core-systems/architecture
  • Why sufficient / why not (one line): The architecture is directly tied to onchain ownership + a royalty engine as verifiable rules.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The protocol has a token, XNY (BEP‑20).
  • Evidence: Tier‑1 — https://docs.codatta.io/en/protocol-token/token-info
  • Why sufficient / why not (one line): The official token page.
  • 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): XNY is used for task launch fees and metered data/API access.
  • Evidence: Tier‑1 — https://docs.codatta.io/en/protocol-token/token-utility
  • Why sufficient / why not (one line): The token utility directly specifies launch/access as XNY‑denominated.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): XNY staking and slashing are used for trust/quality (stake on data / stake on contributor).
  • Evidence: Tier‑1 — https://docs.codatta.io/en/business/incentives-staking ; https://docs.codatta.io/en/protocol-token/token-utility
  • Why sufficient / why not (one line): Stake types and slashing signals are specified.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): Governance and voting are tied to XNY stake and reputation.
  • Evidence: Tier‑1 — https://docs.codatta.io/en/protocol-token/token-utility
  • Why sufficient / why not (one line): The token utility specifies governance & curation.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): In the protocol, XNY is declared as the mandatory currency of access/rights/trust, while stablecoins are only an option for payouts.
  • Evidence: Tier‑1 — https://docs.codatta.io/en/protocol-token/token-utility
  • Why sufficient / why not (one line): Replacing XNY would break the described “access/trust/rights currency” model.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.codatta.io/en/quick-guide/overview What Codatta is and which problems it solves (an onchain knowledge layer for AI data/attribution).
Tier‑1 https://docs.codatta.io/en/core-systems/architecture Architecture: CF, ownership, lineage, metering, royalty engine; why onchain is needed.
Tier‑1 https://docs.codatta.io/en/protocol-token/token-utility XNY utility: fees/gas, launch/access/licensing, staking/slashing, governance.
Tier‑1 https://docs.codatta.io/en/protocol-token/token-info Official token parameters (BEP‑20, contract, max supply).
Tier‑1 https://docs.codatta.io/en/protocol-token/tokenomics Allocations/tokenomics principles (10B supply).
Tier‑1 https://docs.codatta.io/en/business/incentives-staking Roles, staking‑as‑confidence and slashing signals.
Tier‑2 — —
Tier‑3 — —

No comments to display

Back to top