Skip to main content

PublicAI

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

PublicAI — an AI/Data / Marketplace / Infra project (a human‑in‑the‑loop marketplace for data labeling/verification for AI), token: claimed as PUBLIC (the older whitepaper uses the designation TSR).

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/marketplace for data labeling and verification (human‑in‑the‑loop) — for training and validating AI models.
  • Who it’s for: companies/labs that need a dataset/labeling; annotator‑contributors and quality validators.
  • Why onchain/token: a token economy is claimed for incentives (staking/slashing) and governance; the Tier‑1 sources contain a conflict over the token name (PUBLIC vs TSR) and over the network.

How it works (very briefly)

  1. The user does: the client publishes a task and a budget.
  2. The system does: contributors label; validators/fishers verify; reputation/penalties/rewards are applied according to the platform rules.
  3. The user gets: labeled/verified data for training/evaluating models.
  4. Where the blockchain is: the whitepaper describes smart‑contract mechanics for payouts/penalties; in the current Tier‑1 sources, verifiable onchain addresses of protocol contracts (other than the token) are not recorded.
  5. Token role: a utility/governance token is claimed for incentives and governance (with a PUBLIC/TSR naming conflict).

Quick links: AI thesis fit

Project passport

Field Value
Project name PublicAI
Also known as (aliases) PublicAI.io, PUBLIC (docs), TSR (whitepaper; conflict)
Logo (logo) ../assets/191_publicai_logo.ico
Token symbol (ticker) PUBLIC (docs) / TSR (whitepaper; conflict)
Category AI/Data | Marketplace | Infra
Primary chain (chain) BNB Smart Chain
Type EVM
Network status —
Consensus (consensus) PoSA (BNB Smart Chain; 21 validators)
Launch date (launch_date) —
Project status (status) active (public documentation and website available)
Token (standard) BEP-20
Token contract 0x87aa6aeb62ff128aaa96e275d7b24cd12a72aba1
Token model (token_type) utility (incentives + governance)
Max supply 92,329,160.046061 PUBLIC (Max Total Supply, BscScan)
Issuance —
Tokenomics (tokenomics, brief) the docs describe PUBLIC as a utility token for incentives/governance/access; details are placed in the tokenomics section
Governance DAO/governance claimed (in general terms)
Admins/keys —
Audit —
Bug bounty —
Team (team) whitepaper authors: Steven Wong, Zhen Li, Shuguang Cui (per the PDF)
Funding (investors/funding) —
AI component (ai_component) HITL data quality layer (not an AI model)
Use‑case (use_case) data annotation marketplace
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 1 / 1 / 0 / 3
Last verified 2026-02-11

General project overview

In the whitepaper, PublicAI is described as a crowdsourcing marketplace for labeling/structuring the data needed to train models (data annotation). The whitepaper introduces roles (Trainer/Validator/Fisher/Publisher), a reputation system and smart‑contract mechanics for payouts/penalties.

In the current documentation (GitBook), the project emphasizes the “Human Layer of AI”: verified participants, quality verification and economic penalties for defective work. Important: per Tier‑1 sources, this is not an AI model/inference engine, but a labor/process market around data for AI.

Features/modules

  • Labeling task marketplace with contributor and reviewer roles (whitepaper).
  • Quality and anti‑fraud logic: multi‑stage verification + slashing for defective work (whitepaper; in principle).
  • Tokenomics section in the docs: incentives/governance/access are claimed, as well as a “contribution rollup” as part of contribution accounting (docs).

Typical scenarios

  • Scenario 1 (training): the client publishes a task → contributors label → reviewers validate → the client accepts the result → payouts.
  • Scenario 2 (quality): a participant stakes the token → performs work/verifications → in case of low quality a penalty (slashing) is applied, in case of good quality — a reward (per the whitepaper/docs).

Getting started (wallet/network)

  • What you need: access to the product/an account on the platform; for the onchain part — an EVM wallet (if relying on the BSC token).
  • Network/chain: there is a conflict in Tier‑1: a BEP‑20 token exists (BscScan), while the docs mention other networks as plans/intentions.
  • Fees: depend on the specific implementation; not established per Tier‑1.

Architecture/tech (non‑AI)

  • Components: participant roles, reputation/verifications, order/payout mechanism; an onchain layer is claimed in the whitepaper, but without a list of protocol contract addresses for independent verification.
  • Where logic runs: the actual labeling — offchain (people/tools); accounting and incentives — claimed as the onchain part (whitepaper).

Token/economics (expanded, no forecasts)

  • Token utility: in the docs, PUBLIC is described as a utility token (governance/incentives/access); in the whitepaper a similar role is played by TSR (naming conflict).
  • Protocol necessity drivers: staking/slashing and incentives for quality (whitepaper; partially confirmed by the docs).
  • Note on the conflict: because of the ticker/network conflict at the Tier‑1 level, we consider the tokenomics conclusions cautious and set some of the flags conservatively.

Governance

  • Who makes decisions: DAO/governance is claimed (whitepaper/docs); the details of the procedures are not confirmed as a specific mechanism in Tier‑1 sources.

Security and incidents

  • Audits/bug bounty: no public Tier‑1 links to specific reports were found.

Project status and timeline

  • Current status: whitepaper published; docs available.

AI component of the project

  • What is real AI here? In Tier‑1 sources, AI is mentioned as an application domain and as the “Human Layer of AI”, but no AI component of the project’s own (model/inference/metrics) is shown.
  • What is truly onchain? There is an onchain token address on BNB Smart Chain; protocol onchain contracts (other than the token) are not confirmed by addresses in Tier‑1.
  • Why is a token needed? Incentives/staking/slashing and governance are claimed, but there is a conflict over the token naming (PUBLIC vs TSR) and the onchain implementation details are lacking.
  • Red flags (based on the information found): a conflict between Tier‑1 sources over the ticker/tokenomics (PUBLIC vs TSR) and over the chain; the current onchain implementation requires re‑checking.

DecAI Fit component summary

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

AI reality

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

  • AI_0 (decision): 1
  • Claim (one line): in Tier‑1 sources, AI is explicitly stated as the application domain (an HITL data quality layer for AI).
  • Evidence: Tier‑1 — http://docs.publicai.io/publicai-documentation
  • Why sufficient / why not (one line): AI is mentioned in the official materials as the target use‑case, but this is not proof of a working AI module in the product.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): it is not described what exactly the “project’s AI” does as a product function.
  • Evidence: Tier‑1 — https://publicai.io/whitepaper.pdf ; http://docs.publicai.io/publicai-documentation
  • Why sufficient / why not (one line): the whitepaper describes a human workflow and incentives, not an AI model/inference.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): no Tier‑1 demo of an AI component is recorded.
  • Evidence: Tier‑1 — http://docs.publicai.io/publicai-documentation
  • Why sufficient / why not (one line): there is no artifact of the kind “the AI module works and does X”.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — http://docs.publicai.io/publicai-documentation
  • Why sufficient / why not (one line): quality metrics for the project’s AI component are absent.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): there is a technical description of the marketplace/roles, but not an AI architecture.
  • Evidence: Tier‑1 — https://publicai.io/whitepaper.pdf
  • Why sufficient / why not (one line): this is the architecture of a labeling platform, not of an AI model.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: BNB Smart Chain (per the Explorer link)
  • Addresses/identifiers: token 0x87aa6aeb62ff128aaa96e275d7b24cd12a72aba1
  • Evidence: Tier‑1 — https://bscscan.com/token/0x87aa6aeb62ff128aaa96e275d7b24cd12a72aba1
  • Why sufficient / why not (one line): a specific onchain token address is given.
  • Conflict note (if any): the docs mention other networks as plans/intentions.

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

  • OC_2 (decision): 0
  • What useful logic is onchain: the whitepaper describes task/settlement logic, but the current Tier‑1 materials contain no list of addresses/contracts for verification.
  • Evidence: Tier‑1 — https://publicai.io/whitepaper.pdf
  • Why sufficient / why not (one line): without addresses, the confirmation of onchain logic does not reach the level of a verifiable Tier‑1 fact.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: a labeling marketplace can run on an ordinary DB/payments; there is no strict proof of onchain criticality.
  • Evidence: Tier‑1 — https://publicai.io/whitepaper.pdf
  • Why sufficient / why not (one line): the whitepaper argues for the benefits of onchain, but does not prove criticality by the OC_3 standard.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): a token is claimed, and an onchain token address exists on BSC.
  • Evidence: Tier‑1 — http://docs.publicai.io/publicai-documentation/usdpublic-tokenomics ; https://bscscan.com/token/0x87aa6aeb62ff128aaa96e275d7b24cd12a72aba1
  • Why sufficient / why not (one line): there is a Tier‑1 tokenomics page and an onchain link to the contract.
  • Conflict note (if any): ticker conflict (PUBLIC vs TSR).

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): no unambiguous, verifiable statement of “paying for the service with the token” was found in Tier‑1 sources.
  • Evidence: Tier‑1 — http://docs.publicai.io/publicai-documentation/usdpublic-tokenomics
  • Why sufficient / why not (one line): the tokenomics section is described in general terms; the payment role is not confirmed.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): quality incentives via staking/slashing are claimed.
  • Evidence: Tier‑1 — https://publicai.io/whitepaper.pdf ; http://docs.publicai.io/publicai-documentation
  • Why sufficient / why not (one line): the whitepaper describes the slashing mechanics and the role of stake; the docs confirm the quality/staking narrative.
  • Conflict note (if any): PUBLIC/TSR naming conflict.

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): governance is mentioned, but a specific governance mechanism is not confirmed in Tier‑1 sources as a working process.
  • Evidence: Tier‑1 — http://docs.publicai.io/publicai-documentation/usdpublic-tokenomics
  • Why sufficient / why not (one line): without a description of procedures/contracts, we set 0.
  • Conflict note (if any): PUBLIC/TSR naming conflict.

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 1
  • Claim (one line): no strict proof of the irreplaceability of the native token (instead of, for example, USDC/a subscription) was found.
  • Evidence: Tier‑1 — https://publicai.io/whitepaper.pdf
  • Why sufficient / why not (one line): the sources do not prove that it is the native token specifically that solves a unique protocol task.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://publicai.io/whitepaper.pdf the concept of a labeling platform with roles, reputation, payouts/penalties; the TSR terminology (conflict)
Tier‑1 http://docs.publicai.io/publicai-documentation the “Human Layer of AI” positioning and the context of quality incentives
Tier‑1 http://docs.publicai.io/publicai-documentation/usdpublic-tokenomics the existence of a tokenomics section and the claim about the PUBLIC token (in general terms)
Tier‑1 https://bscscan.com/token/0x87aa6aeb62ff128aaa96e275d7b24cd12a72aba1 the onchain token address on BNB Smart Chain
Tier‑2 https://coinmarketcap.com/currencies/publicai/ reference profile

No comments to display

Back to top