Skip to main content

Kite (Kite AI)

Kite (KITE) — 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).

Kite (Kite AI) describes itself as an L1 blockchain for “agentic payments”: payments/identity/policy infrastructure for autonomous AI agents as economic actors. The documentation lists the KiteAI Testnet test network, token KITE and Chain ID 2368.

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: payment and coordination infrastructure based on a PoS EVM‑compatible L1 for AI agents (agent‑native payments, identity, programmable constraints).
  • Who it’s for: developers of AI agents/services who want to safely delegate payment actions to agents; network participants (validators/delegators/module operators).
  • Why onchain/token: onchain is used as the settlement/audit layer and the PoS security mechanism; the KITE token — for staking, governance and incentives, as well as the module economy.

How it works (very briefly)

  1. The user does: launches an agent scenario and sets constraints (limits/policies) for the agent’s payments and actions.
  2. The system does: executes payments/authorization via onchain accounts and cryptographic identity/delegation; records an audit trail.
  3. The user gets: autonomous agent payments with “guardrails” and verifiability (as described in the whitepaper).
  4. Where the blockchain is: the Kite L1 + state channels/accounts/consensus; testnet parameters are listed in the docs (chain id, RPC, explorer).
  5. Token role: KITE for staking (PoS security), governance and incentives (tokenomics).

Quick links: AI thesis fit

Project passport

Field Value
Project name Kite (Kite AI)
Also known as (aliases) Kite Chain, KITE
Logo (logo) ../assets/16_kite_logo.svg
Token symbol (ticker) KITE
Category AI/Other | Infra
Primary chain (chain) Kite
Type Appchain
Network status testnet
Consensus (consensus) PoS (Kite)
Launch date (launch_date) —
Project status (status) active
Token (standard) native
Token contract native (no contract)
Token model (token_type) utility (payments + staking + governance)
Max supply 10000000000 (KITE cap)
Issuance fixed (capped supply)
Tokenomics (tokenomics, brief) staking/governance + utilities for modules and agentic AI payments
Governance token‑based governance (KITE)
Admins/keys —
Audit —
Bug bounty —
Team (team) Kite AI Team
Funding (investors/funding) —
AI component (ai_component) agentic payments + identity/guardrails
Use‑case (use_case) payments + coordination of AI agents
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 1 / 3 / 3 / 2
Last verified 2026-02-10

General project overview

Kite describes the problem as “human‑centric infrastructure” (credentials, payments, trust) that limits the autonomy of AI agents in economic actions. The whitepaper proposes an infrastructure for “agent‑native” payments: hierarchical identity (user/agent/session), programmable constraints for financial actions and agent‑native payment rails (state channels) for micropayments. The Kite Chain documentation describes the testnet parameters and the development tooling on the EVM‑compatible chain.

Features/modules

  • Kite Chain: an EVM‑compatible network (testnet, per the docs), positioned as a PoS L1.
  • Agent identity / delegation: a user‑agent‑session model and cryptographic delegation (whitepaper).
  • Programmable constraints: spending/access rules enforced via smart contracts/accounts (whitepaper).
  • Micropayments/state channels: low‑latency micropayments as payment rails for agent workflows (whitepaper).
  • Modules (per tokenomics): a modular ecosystem of AI services (data/models/agents) interacting with the L1.

Typical scenarios

  • Scenario 1: a developer integrates an AI service/agent → receives “pay‑per‑request” payments/micropayments via agent‑native rails.
  • Scenario 2: a user delegates payment actions with limits to an agent → the agent pays for services within the constraints.
  • Scenario 3: network participants stake KITE → secure PoS and receive rewards (tokenomics).

Getting started (wallet/network)

  • What you need: connect a wallet to the KiteAI Testnet and obtain test tokens via the faucet (docs).
  • Network/chain: KiteAI Testnet (Chain ID 2368).
  • Fees: Kite Chain network fees (test fees on the testnet).

Architecture/tech (non‑AI)

  • Components: the Kite Chain L1 (EVM), account abstraction/rule smart contracts, state channels, tooling (RPC/explorer/faucet), repos/releases.
  • Participant roles: users and their agents, service providers/merchants, validators and delegators, module operators.
  • Where logic runs: settlement and rules — onchain; part of the agent logic and SLA metrics — offchain, but with onchain enforceable components (whitepaper).
  • Dependencies: RPC infrastructure, block explorer, open‑source code.

Token/economics (expanded, no forecasts)

  • Token utility: the tokenomics describes the KITE utilities: module liquidity requirements, ecosystem access/eligibility, incentives, AI service commissions, staking and governance.
  • Protocol necessity drivers: validators/delegators stake KITE (PoS); the token is used for governance and the module economy.
  • Who pays fees: users/network participants pay fees on the Kite network (per the docs, token = KITE).
  • Where fees go: — (not recorded as a passport fact).
  • Issuance/burn: total supply capped at 10B; a reward mechanism (“piggy bank”) and a transition to a revenue‑driven model are described (tokenomics).
  • Security/incentive mechanisms: staking for security; emissions/rewards and commissions on AI service transactions (tokenomics).
  • Distribution: the tokenomics describes the distribution (ecosystem/community, investors, modules, team/advisors).
  • Treasury: —.

Governance

  • Who makes decisions: token holders (KITE governance utility per the tokenomics).
  • How protocol parameters change: via governance votes and upgrades (process details are not established as a passport fact).
  • Where decisions are discussed/made: docs/whitepaper + GitHub.
  • Keys/multisig: —.

Security and incidents

  • Audits: —.
  • Bug bounty: —.
  • Incidents: —.
  • Threat model: risks of delegating rights to agents, session key leaks, the implementation of state channels and smart contracts; centralization risks of some platform services (if any).

Project status and timeline

  • Current status: testnet (Ozone Testnet), mainnet “coming soon” per the project’s materials.
  • Key releases/milestones: —.
  • Roadmap: see links_* (network/whitepaper center).

Ecosystem/integrations

  • Integrations: EVM tooling (RPC, explorer), smart contracts and dApps; compatibility with the x402, A2A, MCP and OAuth 2.1 standards is claimed (whitepaper).
  • Partners: —.
  • Where it’s actually used: the testnet network and dev integrations; production adoption is not confirmed by Tier‑1.

AI component of the project

  • What is real AI here? The project is oriented toward “agentic AI” as a class of users (AI agents) and their payment/identity needs; this is AI intent/an AI use‑case, not proof of the project’s own AI model.
  • What is truly onchain? The Kite Chain L1 (PoS) as the settlement/audit layer and smart‑contract guardrails; testnet parameters are listed in the docs.
  • Why is a token needed? KITE is used for PoS security staking, governance and incentives for the module economy.
  • Red flags (based on the information found): AI‑washing — medium risk (agents vs an “AI model”); onchain‑washing — low risk (it is an L1); token‑washing — low risk (token utilities are described in detail in Tier‑1).

DecAI Fit component summary

  • DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality medium 1
Onchain necessity high 3
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): 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 = 1.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): the project describes payment infrastructure for AI agents, but does not record an “AI model/inference” as part of the protocol.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): AI here is the user’s role (agent), not an ML component in the protocol.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): A Tier‑1 demo of working AI agents on Kite as a reproducible artifact has not been recorded.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): there are descriptions and testnet info, but no demo of an “AI model”.
  • 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 quality metrics for AI models.
  • Conflict note (if any): —

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

  • AI_4 (decision): 1
  • Claim (one line): the whitepaper describes the agentic payments architecture (identity layers, constraints, state channels).
  • Evidence: Tier‑1 — https://kite.foundation/whitepaper
  • Why sufficient / why not (one line): there is a detailed technical description of components oriented toward AI agents.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: KiteAI Testnet
  • Addresses/identifiers: Chain ID 2368; RPC https://rpc-testnet.gokite.ai/ ; explorer https://testnet.kitescan.ai/
  • Evidence: Tier‑1 — https://docs.gokite.ai/kite-chain/1-getting-started/network-information
  • Why sufficient / why not (one line): Tier‑1 docs provide the network parameters.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: settlement and enforceable guardrails via smart contracts/accounts; state channels for payments.
  • Evidence: Tier‑1 — https://kite.foundation/whitepaper
  • Why sufficient / why not (one line): the whitepaper describes smart contract constraints and onchain settlement as the foundation.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without the blockchain, cryptographically enforceable constraints, auditable trails and the settlement layer for agentic payments are lost.
  • Evidence: Tier‑1 — https://kite.foundation/whitepaper
  • Why sufficient / why not (one line): onchain is explicitly stated as a base part of the trustless payment infrastructure.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the network uses the native token KITE.
  • Evidence: Tier‑1 — https://docs.gokite.ai/kite-chain/1-getting-started/network-information ; https://kite.foundation/tokenomics
  • Why sufficient / why not (one line): the docs record token=KITE; the tokenomics describes the token’s utility.
  • 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): the token participates in the economics of agentic payments and commissions for AI services (module economy).
  • Evidence: Tier‑1 — https://kite.foundation/tokenomics
  • Why sufficient / why not (one line): the tokenomics describes AI service commissions and value capture mechanics.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): staking KITE is used for PoS security and eligibility for roles (validators/delegators/modules).
  • Evidence: Tier‑1 — https://kite.foundation/tokenomics
  • Why sufficient / why not (one line): the tokenomics explicitly describes staking and participant roles.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): token holders vote on upgrades and incentive structures (governance utility).
  • Evidence: Tier‑1 — https://kite.foundation/tokenomics
  • Why sufficient / why not (one line): the tokenomics describes the governance utility.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the replaceability of KITE without loss of PoS security/incentives is not established by Tier‑1.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): a Tier‑1 argument for full replaceability of the token is needed.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.gokite.ai/kite-chain/1-getting-started/network-information KiteAI Testnet parameters: Chain ID 2368, RPC, explorer, token=KITE.
Tier‑1 https://kite.foundation/tokenomics PoS EVM‑compatible L1; cap supply 10B; KITE utilities (staking/governance/fees/modules) and distribution.
Tier‑1 https://kite.foundation/whitepaper AI intent: agentic payments; technical architecture of identity/constraints/state channels and interoperability (x402/A2A/MCP/OAuth).
Tier‑1 https://github.com/gokite-ai/gokite-chain source code of the chain (project repository).
Tier‑1 https://github.com/gokite-ai/gokite-chain/releases client releases/changes (changelog).

No comments to display

Back to top