Skip to main content

Chainbase (Chainbase Network)

Chainbase (Chainbase Network / C Token) — 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).

Chainbase — an AI/Data | Infra project that positions itself as a hyperdata network for the AI era (it structures onchain signals into “AI‑ready data”). Token (symbol: C).

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: data infrastructure (API + tools + datasets) for access to multichain data; described in Tier‑1 sources as a “Hyperdata Network for AI”.
  • Who it’s for: application/analytics developers (wallets, explorers, reporting), teams that build data pipelines, as well as AI agents/protocols as data consumers.
  • Why onchain/token: the C token is claimed as the protocol currency of DataFi (payment for dataset access/queries, incentives, and staking/execution security via the AVS layer).
  • What you can actually touch (Tier‑1): the API Reference (there is a demo key demo) https://docs.chainbase.com/api-reference/overview + the Manuscript GUI QuickStart (installation via a script, launch with ./manuscript) https://docs.chainbase.com/core-concepts/manuscript/QuickStart.

How it works (very briefly)

  1. The user does: obtains an API key and requests data via the Web3 API, or creates a “manuscript” (data pipeline) via the GUI/CLI.
  2. The system does: returns structured data (balances/transactions/prices/holdings, etc.) and/or assembles datasets; for the network mode, the docs describe an AVS layer of tasks/verification of operator quality.
  3. The user gets: data for their own product (wallet/analytics/agent) or their own dataset/export.
  4. Where the blockchain is: onchain records the economic/security primitives (the C token; in the AVS description — contracts for tasks/responses/verification and slashing).
  5. Token role: the tokenomics describes the utilities: dataset access, ecosystem incentives, execution security via staking; the governance claim requires additional verification of the mechanics.

Quick links: AI thesis fit

Project passport

Field Value
Project name Chainbase (Chainbase Network)
Also known as (aliases) Chainbase Data Network; Chainbase Data Platform; Hyperdata Network; C Token
Logo (logo) ../assets/86_chainbase_logo.png
Token symbol (ticker) C
Category AI/Data | Infra
Primary chain (chain) BNB Smart Chain
Type EVM
Network status mainnet
Consensus (consensus) PoSA (BNB Smart Chain; 21 validators)
Launch date (launch_date) 2025-06-24
Project status (status) active
Token (standard) BEP-20
Token contract 0xc32cc70741c3a8433dcbcb5ade071c299b55ffc8
Token model (token_type) utility (payments + staking + governance)
Max supply 1 000 000 000
Issuance capped (fixed total supply; unlock schedule)
Tokenomics (tokenomics, brief) utilities: dataset access + incentives + staking/security; distribution: 40% ecosystem/community, 13% airdrops, 12% workers
Governance community process (CIP; rough consensus + running code)
Admins/keys —
Audit —
Bug bounty —
Team (team) core contributors + community
Funding (investors/funding) —
AI component (ai_component) AI-ready structured data + AVS verification
Use‑case (use_case) query + build multichain datasets
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 1 / onchain_score 3 / token_score 2 / evidence_score 3
Last verified 2026-02-11

General project overview

Chainbase is a data infrastructure project that, in its Tier‑1 documentation, describes itself as a hyperdata network for the AI era: the goal is to turn fragmented onchain signals into structured, verifiable and “AI‑ready” data. At the application level, this is expressed in the Web3 API (REST/stream) and in tools/concepts for building datasets.

The Tier‑1 docs also describe elements of a “network” layer: Manuscript (a tool/layer for building data assets) and the AVS design, where a Coordinator hands out tasks to operators, collects signed responses and verifies the result onchain, with the possibility of slashing for non‑compliance.

Important: in the available Tier‑1 sources, Chainbase does not demonstrate its own AI model/inference as the main product. AI here is the context of application (“AI era”, “AI-ready data”), so in DecAI Fit this is counted as AI intent (AI_0), not as “AI reality”.

Features/modules

  • Web3 API (REST/Stream): access to onchain data (balances/transactions/prices/holdings, etc.) without running your own indexing.
  • Data Platform / Datasets: infrastructure and layers for working with multichain data.
  • Manuscript (GUI/CLI): creation of “manuscripts” (data pipelines) with data sources, SQL transformations and export of the result.
  • AVS layer (design): tasks/challenges, onchain verification of results and slashing as quality control of operators.

Typical scenarios

  • Scenario 1 (developer): obtains an API key → calls the Web3 API → receives data for a wallet/explorer/analytics/agent.
  • Scenario 2 (data engineer): installs the Manuscript GUI → creates a manuscript YAML/config → assembles a dataset and exports the result.
  • Scenario 3 (operator/worker): participates in data execution (the tokenomics describes worker incentives and security staking).

Getting started (wallet/network)

  • What you need: an API key (the docs list a demo key demo for testing) and an environment for the Manuscript GUI (per the QuickStart: Linux + Docker/Docker Compose).
  • Network/chain: onchain facts of the token — BNB Smart Chain; the API — offchain HTTP endpoints.
  • Fees: BNB Smart Chain fees for onchain operations with the token; API pricing/limits depend on the platform (not assessed in this card).

Architecture/tech (non‑AI)

  • Components: Web3 API/data platform; Manuscript; in the AVS design — Coordinator, Manuscript Node, contracts (e.g. ChainbaseServiceManager) for tasks/responses.
  • Participant roles: data consumers (agents/apps/protocols), developers (create manuscripts), workers/operators (execute), delegators (delegate tokens for the security layer).
  • Where logic runs: processing/indexing — offchain (API/nodes); verification/slashing and economic primitives — onchain (per the AVS description).
  • Dependencies: blockchain data sources + execution/verification infrastructure; a Docker environment for Manuscript.

Token/economics (expanded, no forecasts)

  • Token utility (Tier‑1): the tokenomics records the utilities of $C: dataset access, ecosystem incentives, execution security (staking) and a governance claim; also “DataFi currency”.
  • Protocol necessity drivers: the tokenomics places the C token at the center of data access/incentives/security (staking/AVS).
  • Who pays: data consumers (agents/apps/protocols) — for access/queries; security‑layer participants — via staking.
  • Where they go (per the model): to incentives/operators and security mechanics; specific fee formulas/distribution tables were not found in Tier‑1 sources.
  • Issuance: Tier‑1 tokenomics: Total supply = 1,000,000,000 C; an unlock schedule is described.
  • Security/incentive mechanisms: dual‑staking (concept) + AVS mechanics of tasks/slashing (for non‑compliance).
  • Distribution (Tier‑1): 40% ecosystem+community, 13% airdrop incentives, 12% worker incentives, 17% early backers, 15% core contributors, 3% liquidity; initial unlocked supply 16%.
  • Treasury: —.

Governance

  • Tier‑1 governance: the “rough consensus and running code” approach + a CIP process are described; stakeholder groups are listed (workers/developers/consumers/delegators).
  • Conflict of wording: the tokenomics claims “token holders vote”, but the governance page says the model avoids voting; without a description of a specific module/voting addresses, we treat governance as a process‑oriented model and do not count TK_3.

Security and incidents

  • Audits: —.
  • Bug bounty: —.
  • Incidents: —.
  • Threat model: risks of correctness/feasibility of tasks and of centralization of the “data/API” layer; the AVS design describes a “consensus game” with verification and slashing.

Project status and timeline

  • Current status: the documentation and API are available; the C token exists on BNB Smart Chain (contract deployed 2025‑06‑24).
  • Key milestones: deployment of the C token contract (onchain tx) + publication of the tokenomics/docs.
  • Roadmap: see links_* (official navigation artifact).

Ecosystem/integrations

  • Integrations: via the API and the Manuscript workflow; example use cases in the docs include wallets, security analytics, AI applications, social, infra and DeFi.
  • Partners: —.
  • Where it’s actually used: per the Tier‑1 docs — as a data layer; specific public integrations were not verified in this card.

AI component of the project

  • What is real AI here? In Tier‑1 sources, AI is listed as context/applicability (“AI era”, “AI-ready data”), but no Tier‑1 evidence of an own AI model/agents as a product is presented → AI intent.
  • What is truly onchain? The C token on BNB Smart Chain (contract + creation tx) and the onchain verification of tasks/responses with economic sanctions described in the docs in the AVS design.
  • Why is a token needed? In the tokenomics: dataset access/payment, incentives, staking/security; the governance claim requires clarification of the mechanics (conflict of wording).
  • Red flags (based on the information found): AI‑washing (AI as an “era”, without an AI module); onchain‑washing (part of the network logic is described without publicly listed contract addresses in Tier‑1 sources); the governance claim conflicts across sources.

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 medium 2
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, Chainbase is positioned as a hyperdata network for the AI era and an “AI-ready data layer”.
  • Evidence: Tier‑1 — https://docs.chainbase.com/introduction/about ; https://docs.chainbase.com/introduction/tokenomics ; https://bscscan.com/token/0xc32cc70741c3a8433dcbcb5ade071c299b55ffc8
  • Why sufficient / why not (one line): this is Tier‑1 AI intent/applicability, without evidence of an own AI module.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): the project provides an AI model/agent/inference as an implemented subsystem.
  • Evidence: Tier‑1 — — (in the available Tier‑1 sources, AI is the context, the product is the data/API layer)
  • Why sufficient / why not (one line): there is no Tier‑1 evidence of “what the AI does” as an AI subsystem.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): there is a demo/guide specifically for the AI component (model/agent).
  • Evidence: Tier‑1 — — (there are demos/quickstarts for the API/Manuscript, but not for an AI module)
  • Why sufficient / why not (one line): the reproducible examples relate to the data/API layer, not to an AI subsystem.
  • 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): there are no Tier‑1 quality metrics for an AI subsystem.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): there is a technical description/architecture of an AI subsystem.
  • Evidence: Tier‑1 — — (there is an architecture of the data/AVS layer, but not of an AI module)
  • Why sufficient / why not (one line): the architecture does not describe an AI component as such.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: BNB Smart Chain
  • Addresses/identifiers: the C token (BEP‑20) 0xc32cc70741c3a8433dcbcb5ade071c299b55ffc8
  • Evidence: Tier‑1 — https://bscscan.com/token/0xc32cc70741c3a8433dcbcb5ade071c299b55ffc8 ; https://bscscan.com/tx/0x6702e697d6270664c1ca9fe0917db8969849dc91330622dfb69dd39cc1d0d897
  • Why sufficient / why not (one line): the explorer confirms the contract and the deployment timestamp.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: the AVS design describes contracts/calls for tasks and responses (createNewTask, respondToTask) and onchain verification of results, slashing for non‑compliance.
  • Evidence: Tier‑1 — https://docs.chainbase.com/core-concepts/avs-design
  • Why sufficient / why not (one line): Tier‑1 describes onchain mechanics beyond the token (even without publicly listed contract addresses).
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without public onchain verification/slashing, trustless quality control of operators breaks down and non‑compliance cannot be penalized in a trusted way.
  • Evidence: Tier‑1 — https://docs.chainbase.com/core-concepts/avs-design
  • Why sufficient / why not (one line): the AVS model relies on economic sanctions and public verifiability.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, C (a BEP‑20 contract on BNB Smart Chain).
  • Evidence: Tier‑1 — https://bscscan.com/token/0xc32cc70741c3a8433dcbcb5ade071c299b55ffc8
  • Why sufficient / why not (one line): the explorer records the token.
  • 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): C is used for dataset access (payment for/consumption of structured data).
  • Evidence: Tier‑1 — https://docs.chainbase.com/introduction/tokenomics
  • Why sufficient / why not (one line): the tokenomics directly lists dataset access as a core utility.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): C is used for incentives and the security layer (staking; quality control/slashing in the AVS description).
  • Evidence: Tier‑1 — https://docs.chainbase.com/introduction/tokenomics ; https://docs.chainbase.com/core-concepts/avs-design ; https://docs.chainbase.com/core-concepts/dual-staking
  • Why sufficient / why not (one line): the tokenomics records “execution security (staked)” and incentives; the AVS design describes slashing/a quality game.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): the C token provides onchain voting/protocol governance.
  • Evidence: Tier‑1 — https://docs.chainbase.com/introduction/tokenomics ; https://docs.chainbase.com/contributing/governance
  • Why sufficient / why not (one line): the tokenomics claims “token holders vote”, but the governance page says the model avoids voting; without a description of the mechanics/voting addresses we set 0.
  • Conflict note (if any): conflict of wording tokenomics vs governance.

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the C token is embedded in the access/incentives/staking model and does not look replaceable per the Tier‑1 description.
  • Evidence: Tier‑1 — https://docs.chainbase.com/introduction/tokenomics
  • Why sufficient / why not (one line): the utilities are defined as “core utilities of $C”.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.chainbase.com/introduction/about Positioning of Chainbase as a hyperdata network for the AI era; dual‑chain and use cases are claimed, including AI as applicability.
Tier‑1 https://docs.chainbase.com/introduction/tokenomics Tier‑1 tokenomics: utilities of $C (dataset access, incentives, execution security via staking, governance claim), total supply 1B, distribution and unlock schedule.
Tier‑1 https://bscscan.com/token/0xc32cc70741c3a8433dcbcb5ade071c299b55ffc8 Onchain fact of the Chainbase Token (C) as a BEP‑20 on BNB Smart Chain (contract, decimals, max total supply on this network, project description).
Tier‑1 https://bscscan.com/tx/0x6702e697d6270664c1ca9fe0917db8969849dc91330622dfb69dd39cc1d0d897 Deployment timestamp of the C token contract: Jun‑24‑2025 (launch_date).
Tier‑1 https://docs.chainbase.com/api-reference/overview API Reference: Web3 API/SQL API overview + a note that the demo key can be used for demos.
Tier‑1 https://docs.chainbase.com/api-reference/web3-api/basic/transaction/get-transactions-by-account A reproducible example of an API endpoint (cURL + the required x-api-key header, example demo).
Tier‑1 https://docs.chainbase.com/core-concepts/manuscript/QuickStart Manuscript GUI QuickStart: installation via a script + environment requirements.
Tier‑1 https://docs.chainbase.com/core-concepts/manuscript/QuickStart/create_manuscript Step‑by‑step guide to creating a Manuscript (data sources, SQL transformations, export).
Tier‑1 https://docs.chainbase.com/core-concepts/avs-design AVS design: tasks/responses/onchain verification, operator quality evaluation, slashing.
Tier‑1 https://docs.chainbase.com/contributing/governance Governance approach: rough consensus + running code, CIP process, stakeholder groups.

No comments to display

Back to top