Skip to main content

DxChain

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

DxChain — an infrastructure project; documentation/a repository and an ERC‑20 token contract on the Ethereum network are recorded per links_*.

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: an EVM‑compatible L1/appchain project (DxChain 3.0) with DPoS consensus and a claimed smart contracts/cross‑chain/DeFi/NFT ecosystem.
  • Who it’s for: dApp developers and network participants (delegators/validators) who vote/stake and support the network.
  • Why onchain/token: DX is described as the native token of the network for fees (handling fees), economic incentives and participation in elections/validation; total supply DX = 100B.

How it works (very briefly)

  1. The user does: executes transactions and interacts with dApp/contracts (EVM compatibility) and/or stakes/votes with DX.
  2. The system does: selects validators via DPoS (election cycle 24h) and processes blocks/transactions.
  3. The user gets: transaction execution and/or participation in validation rewards (block rewards) when voting/staking.
  4. Where the blockchain is: the DxChain protocol/network are described in the Tier‑1 litepaper; the ERC‑20 contract of the DX token on Ethereum is recorded separately.
  5. Token role: handling fees, economic incentives and voting/staking in DPoS; a burn mechanism is claimed for a validator’s underproduction of blocks in an epoch.

Quick links: AI thesis fit

Project passport

Field Value
Project name DxChain
Also known as (aliases) DX
Logo (logo) ../assets/696_dxchain-token_logo.png
Token symbol (ticker) DX
Category Infra
Primary chain (chain) DxChain
Type EVM
Network status mainnet
Consensus (consensus) DPoS
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract 0x973e52691176d36453868D9d86572788d27041A9
Token model (token_type) utility (fees + staking + governance)
Max supply 100 000 000 000 DX
Issuance —
Tokenomics (tokenomics, brief) DX is used as an exchange unit, handling fees and incentives for onchain activities; ecosystem pool = 45B DX; a reward burn mechanism is described for failure to meet validator requirements.
Governance DPoS election + proposals/validators contracts (per the litepaper description)
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) —
Use‑case (use_case) data storage infrastructure
DecAI Fit — AI thesis fit 0/6 — no AI reality and no AI intent (ai_score=0)
DecAI Fit component summary ai_score 0 / onchain_score 2 / token_score 3 / evidence_score 2
Last verified 2026-02-11

General project overview

DxChain describes DxChain 3.0 as an EVM‑compatible network with a smart‑contract platform and DPoS consensus. The litepaper describes the role of the DX token (fees/staking/voting), total supply 100B and the basic mechanics of the economic system/validators. The ERC‑20 contract of the DX token on Ethereum is also recorded.

Features/modules

  • EVM compatibility (dApp migration).
  • DPoS consensus and validator selection via voting/election.
  • The DX economic system: fees + incentives + voting; a reward burn mechanism for a validator’s underproduction of blocks.

Typical scenarios

  • Scenario 1: a user stakes/votes with DX → participates in validator elections and reward distribution.
  • Scenario 2: a developer deploys an EVM contract/dApp → users pay fees with the DX token (handling fees).

Getting started (wallet/network)

  • What you need: access to the DxChain network and the project’s documentation/tools; an Ethereum wallet is needed only for operations with the ERC‑20 DX contract.
  • Network/chain: DxChain; Ethereum — for the ERC‑20 token.
  • Fees: DX is used for handling fees on the network; Ethereum fees — for ERC‑20 operations.

Architecture/tech (non‑AI)

  • Components: an EVM‑compatible L1, a DPoS layer and built-in contracts for staking/voting/validators/proposals (per the litepaper); separately — the ERC‑20 DX contract on Ethereum.
  • Participant roles: delegators/holders (voting), candidates/validators (block generation/verification), dApp users.
  • Where logic runs: transactions/contracts and governance — onchain on DxChain; ERC‑20 operations — onchain on Ethereum.
  • Dependencies: —.

Token/economics (expanded, no forecasts)

  • Token utility: an exchange unit between users; economic incentives for onchain activities; handling fees; voting/staking in DPoS.
  • Protocol necessity drivers: DX is described as the native token of DxChain for incentives/fees and participation in DPoS.
  • Who pays fees: token users for ERC‑20 operations.
  • Where fees go: to Ethereum validators (network fees).
  • Issuance/burn: a burn mechanism is described: if a validator does not produce the required number of blocks in an epoch, all generated block rewards are burned and the validator’s status is revoked.
  • Security/incentive mechanisms: users can vote with DX to receive block rewards or become a validator; governance describes validator requirements (stake and the share for voters).
  • Distribution and token issuance schedule: —.
  • Treasury: —.

Governance

  • Who makes decisions: community voting + proposals/DAO (per the litepaper Governance).
  • How protocol parameters change: via onchain proposals and voting (DAO).

Security and incidents

  • Audits: —.
  • Bug bounty: —.
  • Incidents: —.
  • Threat model: —.

Project status and timeline

  • Current status: active (based on the presence of public materials and the token).
  • Key releases/milestones: not established per Tier‑1 as of the verification date.
  • Roadmap: see the Roadmap link (in links_*).

Ecosystem/integrations

  • Integrations: —.
  • Partners: —.
  • Where it’s actually used: not established per Tier‑1 as of the verification date.

AI component of the project

  • What is real AI here? No Tier‑1 confirmation of an AI component was found.
  • What is truly onchain? DxChain describes a DPoS network with a smart‑contract platform and governance contracts; the ERC‑20 DX contract on Ethereum is confirmed separately.
  • Why is a token needed? DX is described as the native token of the network for fees, incentives and voting/staking; total supply 100B.
  • Red flags (based on the information found): mixing an “AI label” with an infrastructure blockchain without Tier‑1 AI artifacts.

DecAI Fit component summary

  • DecAI Fit: 0/6 — no AI reality and no AI intent (ai_score=0)
Component Level Score
AI reality low 0
Onchain necessity medium 2
Token necessity high 3
Evidence Tier‑1 present 2
Details

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): No Tier‑1 mention of AI as intent/applicability was found.
  • Evidence: Tier‑1 — https://dxchain.gitbook.io/dxchain-wiki/the-basics/dxchain-v3-litepaper
  • Why sufficient / why not (one line): Per Tier‑1 sources, an AI component is not confirmed.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): An AI component is not established per Tier‑1.
  • Evidence: Tier‑1 — https://dxchain.gitbook.io/dxchain-wiki/dxchain-3.0-litepaper
  • Why sufficient / why not (one line): There is no Tier‑1 description of AI tasks/models.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): An AI demo is not applicable: an AI component is not established.
  • Evidence: Tier‑1 — https://dxchain.gitbook.io/dxchain-wiki/dxchain-3.0-litepaper
  • Why sufficient / why not (one line): —.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —.
  • Context (version/date/how measured): —.
  • Evidence: Tier‑1 — https://dxchain.gitbook.io/dxchain-wiki/dxchain-3.0-litepaper
  • Why sufficient / why not (one line): No Tier‑1 quality metrics for the AI component were found.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): A tech description of an AI component is not applicable: an AI component is not established.
  • Evidence: Tier‑1 — https://dxchain.gitbook.io/dxchain-wiki/dxchain-3.0-litepaper
  • Why sufficient / why not (one line): —.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: DxChain
  • Addresses/identifiers: — (network module addresses were not recorded within this card)
  • Evidence: Tier‑1 — https://dxchain.gitbook.io/dxchain-wiki/the-basics/dxchain-v3-litepaper/4.-dxchain-design-principles-and-architecture/4.2-dpos-consensus-algorithm
  • Why sufficient / why not (one line): The Tier‑1 documentation describes DxChain Mainnet and DPoS consensus (voting/election, built-in contracts).
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: smart contract platform (EVM compatibility) + onchain mechanics for DPoS elections/validators and governance contracts.
  • Evidence: Tier‑1 — https://dxchain.gitbook.io/dxchain-wiki/the-basics/dxchain-v3-litepaper
  • Why sufficient / why not (one line): The litepaper describes smart contract platform + DPoS + built-in contracts (proposals/validators/voting/rewards).
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: not established per Tier‑1 as of the verification date.
  • Evidence: Tier‑1 — https://dxchain.gitbook.io/dxchain-wiki/dxchain-3.0-litepaper
  • Why sufficient / why not (one line): There is no Tier‑1 justification of onchain criticality.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): An ERC‑20 contract is recorded in links_*, so the token exists.
  • Evidence: Tier‑1 — https://etherscan.io/token/0x973e52691176d36453868D9d86572788d27041A9
  • Why sufficient / why not (one line): The onchain contract page confirms the existence of 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): DX is used for handling fees on the network.
  • Evidence: Tier‑1 — https://dxchain.gitbook.io/dxchain-wiki/the-basics/dxchain-v3-litepaper/5.-economic-system
  • Why sufficient / why not (one line): The economic system explicitly states that DX is used for handling fees.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): Users vote/stake DX to participate in DPoS and receive block rewards; a reward burn mechanism is described for failure to meet validator requirements.
  • Evidence: Tier‑1 — https://dxchain.gitbook.io/dxchain-wiki/the-basics/dxchain-v3-litepaper/5.-economic-system ; https://dxchain.gitbook.io/dxchain-wiki/the-basics/dxchain-v3-litepaper/4.-dxchain-design-principles-and-architecture/4.2-dpos-consensus-algorithm
  • Why sufficient / why not (one line): Tier‑1 sources describe voting/staking for rewards and sanctions/burn for violating requirements.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): Governance is described via proposals/DAO and community voting; validator/delegator participation is tied to DX (stake/votes).
  • Evidence: Tier‑1 — https://dxchain.gitbook.io/dxchain-wiki/the-basics/dxchain-v3-litepaper/6.-governance ; https://dxchain.gitbook.io/dxchain-wiki/the-basics/dxchain-v3-litepaper/4.-dxchain-design-principles-and-architecture/4.2-dpos-consensus-algorithm
  • Why sufficient / why not (one line): Tier‑1 governance describes proposals/voting and requirements for validators with a stake in DX.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): The token is built into the fees/staking/voting mechanics; replaceability without changing the protocol is not confirmed.
  • Evidence: Tier‑1 — https://dxchain.gitbook.io/dxchain-wiki/the-basics/dxchain-v3-litepaper/5.-economic-system
  • Why sufficient / why not (one line): In the litepaper, DX is described as a fees + incentives + voting asset, so conservatively TK_4=0.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://dxchain.com/ Project website (navigation).
Tier‑1 https://dxchain.gitbook.io/dxchain-wiki/dxchain-3.0-litepaper Litepaper/documentation (project context).
Tier‑1 https://dxchain.gitbook.io/dxchain-wiki/the-basics/dxchain-v3-litepaper/4.-dxchain-design-principles-and-architecture/4.2-dpos-consensus-algorithm DPoS consensus and voting/election; built-in contracts for staking/voting/proposals/rewards.
Tier‑1 https://dxchain.gitbook.io/dxchain-wiki/the-basics/dxchain-v3-litepaper/5.-economic-system The role of DX (fees/incentives), total supply 100B, ecosystem pool 45B, reward burn mechanism.
Tier‑1 https://dxchain.gitbook.io/dxchain-wiki/the-basics/dxchain-v3-litepaper/6.-governance Governance: community voting, proposals/DAO, validator requirements (stake DX).
Tier‑1 https://github.com/DxChainNetwork/godx Project repository (codebase).
Tier‑1 https://etherscan.io/token/0x973e52691176d36453868D9d86572788d27041A9 Existence of the ERC‑20 token/contract DX on Ethereum.

No comments to display

Back to top