Skip to main content

Capx

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

Capx — an AI/Other | Infra project on Arbitrum One, token (symbol: CAPX).

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/stack (App + Chain + Cloud) for launching and monetizing AI applications, where each AI application can be represented as a tokenized asset.
  • Who it’s for: developers of AI applications and communities/users who want to “own/trade” tokens of AI applications and use the deployment infrastructure.
  • Why onchain/token: tokens of AI applications and trading/settlement are described as an onchain component (execution layer), while CAPX is the utility token of the ecosystem (the contract is confirmed by the explorer).
  • What you can actually touch (Tier‑1): Capx App (a web interface for exploring/trading AI app tokens) and the Getting Started documentation.

How it works (very briefly)

  1. The user does: deploys an AI application and (in the Capx model) “issues” a token for this AI app.
  2. The system does: provides infrastructure for hosting/deployment and an execution layer for onchain interactions and trading of application tokens.
  3. The user gets: access to the AI application and the ability to interact with its token (ownership/liquidity/trading).
  4. Where the blockchain is: the onchain part is claimed as an execution layer (Capx Chain) for tokenization and settlement; the fact of the CAPX token is confirmed by the contract on Arbitrum One.
  5. Token role (if any): the CAPX utility token (mentioned in the docs as a gas token/economic element of the ecosystem).

Quick links: AI thesis fit

Project passport

Field Value
Project name Capx
Also known as (aliases) CAPX
Logo (logo) —
Token symbol (ticker) CAPX
Category AI/Other | Infra
Primary chain (chain) Arbitrum One
Type EVM
Network status mainnet
Consensus (consensus) L2 (Optimistic Rollup, Arbitrum One on Ethereum)
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract 0x97e66D3C4d5bCd7c64e3e55Af28544C9ADdf9281
Token model (token_type) utility (payments + staking + governance)
Max supply 8,044,119.034603058128407439
Issuance —
Tokenomics (tokenomics, brief) utility token of the ecosystem; distribution details are not established per Tier‑1
Governance —
Admins/keys —
Audit yes
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) positioning only (AI apps infrastructure)
Use‑case (use_case) tokenization + launching AI apps
DecAI Fit — AI thesis fit 4/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 2 / 2 / 1 / 3
Last verified 2026-02-11

General project overview

In its official documentation, Capx describes itself as a stack for the “AI App Economy”: App (interface), Chain (an execution layer for tokenization and settlement) and Cloud (deployment infrastructure). The key idea is to represent AI applications as tokenized objects (ERC‑20) and give them onchain liquidity/composability.

Features/modules

  • Capx App (SuperApp): an interface for exploring/interacting and trading AI tokens.
  • Capx Chain: an execution layer described as an L2 for micro‑interactions and trading.
  • Capx Cloud: infrastructure for deploying/hosting AI applications.

Typical scenarios

  • Scenario 1: a developer deploys an AI application and publishes it in the ecosystem → users get access to the application/token.
  • Scenario 2: a user uses Capx App → finds AI applications and interacts with their tokens (per the platform model).

Getting started (wallet/network)

  • What you need: start with the official documentation and Capx App.
  • Network/chain: the CAPX token is confirmed on Arbitrum One; other networks/components depend on the Capx product used.
  • Fees: network fees and platform fees (if applicable) depend on the specific onchain operations.

Architecture/tech (non‑AI)

  • Components: web application (App) + onchain layer (Chain, claimed as an L2) + infrastructure layer (Cloud).
  • Where logic runs: UI and application hosting — offchain; tokenization and settlement/trading of tokens — onchain (within the claimed model).

Token/economics (expanded, no forecasts)

  • Token fact (Tier‑1): CAPX is an ERC‑20 token on Arbitrum One.
  • Token role (Tier‑1, at the level of claims): the docs/website mention CAPX as a gas token/economic layer of the ecosystem.
  • What to double‑check: the distribution/vesting/issuance parameters of CAPX and which features require CAPX directly (rather than just the existence of the token).

Governance

  • Not established per Tier‑1 as of the verification date.

Security and incidents

  • Audits: an OpenZeppelin audit report has been published (the link is in links_*).
  • Bug bounty / incidents: not established per Tier‑1.

Project status and timeline

  • Current status: active (there is documentation, a website and the CAPX token).
  • Roadmap: not recorded by Tier‑1 as of the verification date (links_* has —).

Ecosystem/integrations

  • Audit/security: the audit report has been published (OpenZeppelin).

AI component of the project

  • What is real AI here? Capx is infrastructure for AI applications: Tier‑1 describes “AI apps” as an object of the ecosystem and the model of their tokenization/deployment.
  • What is truly onchain? The onchain layer is described as an execution layer for the tokenization of AI applications and trading/settlement; the fact of the CAPX token is confirmed by the contract on Arbitrum One.
  • Why is a token needed? CAPX is described as a utility token (including a gas token) for interactions in the ecosystem; the details of the token’s necessity for specific operations require separate verification.
  • Red flags (based on the information found): it is important to distinguish “infrastructure for AI apps” from the presence of its own AI module/metrics (AI_3=0); for the onchain part, beyond the token, specific addresses/proof that Capx Chain works are needed.

DecAI Fit component summary

  • DecAI Fit: 4/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality high 2
Onchain necessity medium 2
Token necessity low 1
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 are signs of AI reality per Tier‑1 (see AI_1..AI_4), so the AI_0 flag (intent‑only) does not apply.
  • Evidence: Tier‑1 — see Evidence/links in AI_1..AI_4.
  • Why sufficient / why not (one line): AI_0=1 is admissible only when AI_1..AI_4=0; here ai_score without AI_0 = 2.

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): Capx describes infrastructure for AI applications, but “what exactly the AI does” at the level of a specific AI component of the platform is not established.
  • Evidence: Tier‑1 — https://docs.capx.ai/
  • Why sufficient / why not (one line): without a specific description of an AI component/feature in the product (rather than “AI apps in general”) — we set 0.

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): there is Capx App — an interface for exploring/trading AI app tokens and interacting with the ecosystem.
  • Evidence: Tier‑1 — https://app.capx.ai/
  • Why sufficient / why not (one line): this is the product’s “touch surface” (app) via a Tier‑1 link.

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): quality metrics of the platform’s AI component were not found in Tier‑1.

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

  • AI_4 (decision): 1
  • Claim (one line): the docs describe the stack (App/Chain/Cloud) and the architectural model of the platform.
  • Evidence: Tier‑1 — https://docs.capx.ai/
  • Why sufficient / why not (one line): there is a tech description at the level of components/layers.

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Arbitrum One
  • Addresses/identifiers: the CAPX token: 0x97e66D3C4d5bCd7c64e3e55Af28544C9ADdf9281
  • Evidence: Tier‑1 — https://arbiscan.io/token/0x97e66D3C4d5bCd7c64e3e55Af28544C9ADdf9281
  • Why sufficient / why not (one line): the token contract and the network are confirmed by the explorer.

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

  • OC_2 (decision): 1
  • What useful logic is onchain: in the Tier‑1 docs, Capx Chain is described as an execution layer for the tokenization of AI apps and onchain trading/settlement.
  • Evidence: Tier‑1 — https://docs.capx.ai/ ; https://capx.ai/
  • Why sufficient / why not (one line): Tier‑1 describes the onchain logic as part of the product, not “just a token”.

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: the criticality of onchain as the “impossibility of replacing it with a server” is not justified in Tier‑1.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): without an explicit Tier‑1 justification that “a key property breaks down without the blockchain” — we set 0.

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, CAPX.
  • Evidence: Tier‑1 — https://arbiscan.io/token/0x97e66D3C4d5bCd7c64e3e55Af28544C9ADdf9281
  • Why sufficient / why not (one line): the name/symbol of the token and the contract are confirmed by the explorer.

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): CAPX is described as a gas token/utility token for onchain interactions in the ecosystem.
  • Evidence: Tier‑1 — https://docs.capx.ai/ ; https://capx.ai/
  • Why sufficient / why not (one line): Tier‑1 sources directly mention CAPX as a gas token/part of the execution layer.

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

  • TK_2 (decision): 0
  • Claim (one line): incentive/collateral mechanics of the token are not recorded per Tier‑1.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): without a specific description of staking/slashing/collateral — we set 0.

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): a governance role of the token is not established per Tier‑1.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): there is no Tier‑1 description of voting/governance via CAPX.

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the replaceability of the token is not established per Tier‑1.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): without a comparison “CAPX vs. alternatives” — we set 0.

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.capx.ai/ Tier‑1 description of the Capx model (App/Chain/Cloud), the tokenization of AI apps and the role of CAPX (at the level of claims).
Tier‑1 https://app.capx.ai/ “What you can touch”: Capx App as the interface of the ecosystem.
Tier‑1 https://arbiscan.io/token/0x97e66D3C4d5bCd7c64e3e55Af28544C9ADdf9281 Onchain fact of the CAPX token: contract and supply parameters on Arbitrum One.
Tier‑1 https://www.capx.ai/openzeppelin-audit-report.pdf Public audit report (OpenZeppelin).
Tier‑2 https://www.coingecko.com/en/coins/capx-ai Reference token profile and link navigation.
Tier‑2 https://coinmarketcap.com/currencies/capx-ai/ Reference token profile and link navigation.

No comments to display

Back to top