Skip to main content

DuckAI

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

DuckAI — a project about a “Decentralized MCP Network” and AI agents; network: Solana, token (symbol: DUCKAI).

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 set of DuckAI Labs products: a network/framework for agent‑to‑agent communication (deMCP) + chat/agent interfaces.
  • Who it’s for: users (chat/agent), as well as developers/teams that build AI agents on top of the network/framework.
  • Why onchain/token: an onchain registry (smart contract registry) is claimed for discovery/communication; the $DUCKAI token is mentioned as part of the ecosystem/rewards, but a specific necessity in the protocol is not established.
  • What you can actually touch (Tier‑1): chat.duckai.ai (see links_*).

How it works (very briefly)

  1. The user does: uses the chat application or interacts with the agent.
  2. The system does: routes requests into the agent network/services and returns a response.
  3. The user gets: a response/search/agent actions (per the project’s claim).
  4. Where the blockchain is: a smart contract registry (for discovery/identification) is claimed, and a token on the Solana network.
  5. Token role (if any): $DUCKAI is mentioned, but the details of its necessity (payment/incentives/governance) are not established in Tier‑1.

Quick links: AI thesis fit

Project passport

Field Value
Project name DuckAI
Also known as (aliases) DuckAI Labs | $DUCKAI
Logo (logo) ../assets/463_duck-ai_logo.svg
Token symbol (ticker) DUCKAI
Category AI/Agents | Infra
Primary chain (chain) Solana
Type non-EVM
Network status mainnet
Consensus (consensus) PoS (Solana)
Launch date (launch_date) —
Project status (status) active
Token (standard) SPL
Token contract HFw81sUUPBkNF5tKDanV8VCYTfVY4XbrEEPiwzyypump
Token model (token_type) —
Max supply —
Issuance —
Tokenomics (tokenomics, brief) —
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) agent network + MCP framework
Use‑case (use_case) chat/agents for Web3
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 3 / 2 / 0 / 0
Last verified 2026-02-11

General project overview

DuckAI Labs describes the project as a “Decentralized MCP Network” and an AI agent framework for building decentralized agent organizations. The main page of the documentation lists the components: the deMCP architecture (smart contract registry + DHT discovery + distributed message routing) and application interfaces (Chat App, Agent “Ducky”).

Features/modules

  • deMCP architecture: smart contract registry + peer discovery (DHT) and agent‑to‑agent message routing.
  • Chat App and Agent (Ducky) as user interfaces.
  • The DeFAI block is marked as coming soon (in the documentation).

Typical scenarios

  • Chat: a user asks a question → receives a response/search across the web3 ecosystem.
  • Agent: a user interacts with the agent in the web/messengers → receives a response/action.
  • Developer: builds an agent/integration on top of deMCP → gets discovery/routing (implementation details — in Docs).

Getting started (wallet/network)

  • What you need: open the Chat App or the Agent (see links_*).
  • Network/chain: Solana (the token; an onchain registry is claimed, but the details are not established).
  • Fees: not established (Tier‑1).

Architecture/tech (non‑AI)

  • Components: onchain registry (claimed) + DHT discovery + routing; user applications (chat/agent).
  • Participant roles: users; developers/agent providers (not established in more detail per Tier‑1).
  • Where logic runs: agent responses — offchain; registry/discovery — claimed as onchain+P2P.
  • Dependencies: not established (Tier‑1).

Token/economics (expanded, no forecasts)

  • Token utility: the documentation mentions “earn $DUCKAI”, but a specific necessity of the token in the protocol is not established (Tier‑1).
  • Protocol necessity drivers: —.
  • Who pays fees: —.
  • Where fees go: —.
  • Issuance/burn: —.
  • Security/incentive mechanisms: —.
  • Distribution and token issuance schedule: —.
  • Treasury: —.

Governance

  • Who makes decisions: not established (Tier‑1).
  • How protocol parameters change: not established (Tier‑1).
  • Where decisions are discussed/made: GitHub/Discord/Telegram (links — in links_*).
  • Keys/multisig: not established (Tier‑1).

Security and incidents

  • Audits: not established per Tier‑1.
  • Bug bounty: not established per Tier‑1.
  • Incidents: not established per Tier‑1.
  • Threat model: offchain dependencies (models/providers) and a lack of Tier‑1 data about security; the token utility is not confirmed.

Project status and timeline

  • Current status: active (public applications/docs are available).
  • Key releases/milestones: see Releases / Changelog in links_*.
  • Roadmap: not established per Tier‑1.

Ecosystem/integrations

  • Integrations: a chat/agent and an agent network are claimed (integration details are not established per Tier‑1).
  • Partners: not established (Tier‑1).
  • Where it’s actually used: not established (Tier‑1).

AI component of the project

  • What is real AI here? AI agents/a chat application, claimed as part of the DuckAI Labs ecosystem.
  • What is truly onchain? The documentation claims a smart contract registry as part of the deMCP architecture; additionally, there is a token on the Solana network (the mint is in the passport).
  • Why is a token needed? The documentation mentions “earn $DUCKAI”, but the necessity of the token (payment/incentives/governance) in the protocol is not confirmed by Tier‑1 artifacts.
  • Red flags (based on the information found): many claims without technical details/metrics; the token utility requires separate Tier‑1 confirmation.

DecAI Fit component summary

  • DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality high 3
Onchain necessity medium 2
Token necessity low 0
Evidence Tier‑1 present (AI/OC), partially for the token 0
Details

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): There is a description of working components (deMCP + chat/agent), so “intent only without AI” is not singled out.
  • Evidence: Tier‑1 — https://docs.duckai.ai/
  • Why sufficient / why not (one line): The documentation describes working products, not only plans.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): AI agents and a chat application to “chat and search the web3 ecosystem” (per the documentation).
  • Evidence: Tier‑1 — https://docs.duckai.ai/
  • Why sufficient / why not (one line): The Tier‑1 documentation describes the chat app and the agent as product components.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): There is a Chat App (chat.duckai.ai) and a web agent (agent.duckai.ai) as entry points.
  • Evidence: Tier‑1 — https://docs.duckai.ai/
  • Why sufficient / why not (one line): Links to the applications are given in the Tier‑1 documentation.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: not established per Tier‑1.
  • Context (version/date/how measured): —.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): There are no Tier‑1 quality metrics/benchmarks.
  • Conflict note (if any): —

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

  • AI_4 (decision): 1
  • Claim (one line): The deMCP architecture (registry + DHT discovery + routing) is described as part of the network/framework.
  • Evidence: Tier‑1 — https://docs.duckai.ai/
  • Why sufficient / why not (one line): Tier‑1 has a top‑level architectural description.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Solana
  • Addresses/identifiers: token mint HFw81sUUPBkNF5tKDanV8VCYTfVY4XbrEEPiwzyypump
  • Evidence: Tier‑2 — https://solscan.io/token/HFw81sUUPBkNF5tKDanV8VCYTfVY4XbrEEPiwzyypump
  • Why sufficient / why not (one line): The token address is given in links_* via the explorer.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: a smart contract registry is claimed as part of the deMCP architecture (discovery/identification).
  • Evidence: Tier‑1 — https://docs.duckai.ai/
  • Why sufficient / why not (one line): The documentation explicitly claims an onchain registry.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: it is not proven that without onchain the product/network breaks down; this is not substantiated in Tier‑1.
  • Evidence: Tier‑1 — https://docs.duckai.ai/
  • Why sufficient / why not (one line): There is a claim about an onchain registry, but no criticality test.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The $DUCKAI token is mentioned in the documentation and is present on the Solana network.
  • Evidence: Tier‑1 — https://docs.duckai.ai/ ; Tier‑2 — https://solscan.io/token/HFw81sUUPBkNF5tKDanV8VCYTfVY4XbrEEPiwzyypump
  • Why sufficient / why not (one line): There are grounds to consider that the token exists, so “no token” = 0.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): Payment for the service with the token is not established per Tier‑1.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): There is no Tier‑1 description of tariffs/payment with the token.
  • Conflict note (if any): —

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

  • TK_2 (decision): 0
  • Claim (one line): The documentation mentions “earn $DUCKAI”, but the mechanism of incentives/collateral/penalties is not described sufficiently for TK_2=1.
  • Evidence: Tier‑1 — https://docs.duckai.ai/
  • Why sufficient / why not (one line): There is a mention, but no verifiable scheme of incentives/rules.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): Governance via the token is not established per Tier‑1.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): There is no Tier‑1 description of governance mechanics.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): The replaceability of the token is not established (no Tier‑1 description of the token utility).
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): Without Tier‑1 on token mechanics, replaceability cannot be strictly asserted.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.duckai.ai/ deMCP architecture, Chat App/Agent, mention of $DUCKAI.
Tier‑1 https://chat.duckai.ai/ What you can touch: Chat App.
Tier‑2 https://solscan.io/token/HFw81sUUPBkNF5tKDanV8VCYTfVY4XbrEEPiwzyypump Token on the Solana network (mint address).
Tier‑1 — No Tier‑1 source for claim “the token is needed for payment/incentives/governance in the protocol” was found.