Kite’s bet is that we don’t just need smarter agents—we need rails built for agent behavior: payments that can move in tiny pieces, nonstop, and an identity system that makes an agent verifiable, governable, and containable. That’s why they describe what they’re building as an “AI payment blockchain”: an EVM-compatible Layer-1 designed around agentic payments, where identity and permissions aren’t optional add-ons—they’re the foundation.
Their answer is to build what they call an AI payment blockchain : an EVM-compatible Layer-1 where the default assumptions are agents will transact constantly, in tiny amounts, at machine speed, and where identity + permissions are treated as core protocol features instead of afterthoughts.
The part Kite leans on hardest is that agents don’t behave like humans. Humans do occasional payments. Agents do streams of payments: thousands of requests, small charges, fast settlement, and lots of automation. Kite’s whitepaper frames it as moving from big billing cycles to packet-level economics, where every interaction can be priced and settled.
Where this gets interesting is the identity design. Instead of one wallet that does everything, Kite describes a three-tier identity model: user → agent → session. The user is the root authority, the agent is delegated authority, and the session is an ephemeral identity meant for a single task or short period. The idea is to stop one compromised key = total wipeout. A session can be time-boxed and capped, and an agent can be boxed in by global rules that it can’t override.
They describe this delegation chain as cryptographic, with agent addresses derived from the user wallet via hierarchical derivation (BIP-32), while sessions use random keys that expire after use. That separation is meant to keep authority clear: the agent can operate, but only inside boundaries the user has set, and only by spawning sessions that are explicitly authorized.
Those boundaries are the second big pillar: programmable constraints. Kite’s language is pretty direct here—agents will hallucinate, make mistakes, or get compromised, so you don’t trust the model, you enforce rules in code. In the whitepaper, those rules are things like spending limits, time windows, operational constraints, and they’re positioned as non-bypassable because they’re enforced at the smart contract level (code becomes law).
Then there’s the payment engine. Kite is not trying to just make gas cheaper. They push state channels as the practical way to make micropayments feel native: open a channel once, stream signed micro-vouchers off-chain for each request or interaction, then settle the final balance on-chain when the session ends. That turns a million tiny payments into something that doesn’t cost a fortune in fees. In the whitepaper, they repeatedly claim sub-100ms style latency targets and economics around ~$0.000001 per message/transaction in the channel model (these are design targets/claims, not something you should treat as guaranteed performance in every scenario).
They also talk about dedicated payment lanes—basically isolating blockspace for transfers so agent payments don’t get wrecked by unrelated congestion. The intention is predictable costs and smoother always-on settlement patterns.
Another thread Kite ties itself to is x402, which comes from Coinbase’s developer docs and is meant to make paying for web resources feel like a simple HTTP flow. In x402, a service can respond with HTTP 402 Payment Required, tell the client what payment is needed, and the client (human or machine) can pay programmatically and retry—no accounts, no subscription gymnastics, no credential sprawl. Coinbase describes x402 as instant, automatic stablecoin payments directly over HTTP, built around reviving the 402 status code.
Kite’s own narrative is basically: if the internet moves toward agents paying per request, then you need a settlement layer that can keep up with per-call monetization—and that’s exactly what their state-channel rails + stablecoin-oriented design are aiming at.
On the what’s real today? side, Kite’s docs show a live testnet with concrete network details. The Network Information page lists KiteAI Testnet, Chain ID 2368, the RPC endpoint, explorer, and a faucet, while mainnet is still described as coming soon.
They’ve also pushed a product layer they call Kite AIR (Agent Identity Resolution). This is less chain-core and more how merchants and services actually plug in. A PayPal newsroom release from September 2, 2025 says Kite AIR has two core components—Agent Passport (verifiable identity with operational guardrails) and an Agent App Store where agents discover and pay for services like APIs, data, and commerce tools—and claims it’s live through open integrations with PayPal and Shopify, allowing merchants to opt in and be discoverable to AI shopping agents with purchases settled on-chain using stablecoins and programmable permissions.
General Catalyst’s write-up from the same date echoes the same framing (identity, governance, payments aligned at the protocol layer) and repeats the claim that the platform is already live on commerce platforms including Shopify and PayPal, with on-chain settlement using stablecoins.
Now, the token side—KITE is presented as the network’s native token, but Kite’s own materials are pretty explicit about how they want it understood. In their MiCA whitepaper, Kite says KITE is a fungible token native to the network, intended to serve as the network’s native currency, and also states it is not pegged, not redeemable, and not intended as a medium of exchange outside the project ecosystem.
Kite’s own tokenomics doc lays out a two-phase rollout. Phase 1 utilities are introduced at token generation so early participants can engage immediately; Phase 2 utilities come with mainnet. Phase 1 includes things like (1) module liquidity requirements (module owners locking KITE into permanent liquidity pools paired with module tokens to activate modules), (2) ecosystem access/eligibility (builders and AI service providers holding KITE to be eligible to integrate), and (3) ecosystem incentives (distributions to users and businesses contributing value).
Phase 2 is where staking, governance, and fee/value-capture mechanics show up. Their doc describes protocol commissions taken from AI service transactions, with the possibility of swapping those stablecoin revenues into KITE before distribution, and then staking for validators/module owners/delegators, plus governance votes on upgrades and incentive structures.
They also describe a “continuous reward” mechanic in a pretty memorable way: rewards accumulate in a “piggy bank,” and you can claim any time, but claiming and selling permanently voids future emissions for that address—basically trying to force a tradeoff between quick liquidity and long-term alignment.
On supply and allocation, Kite’s official tokenomics page states total supply is capped at 10 billion KITE, and shows allocation as Ecosystem & Community 48%, Investors 12%, Modules 20%, and Team/Advisors/Early Contributors 20%.
For a dated, very specific “snapshot” moment: Binance’s official Launchpool announcement (dated Oct 31, 2025) says Binance would list KITE at 2025-11-03 13:00 UTC, confirms total/max supply as 10,000,000,000, Launchpool token rewards as 150,000,000, and states initial circulating supply at listing as 1,800,000,000 (18%).
So when you look at Kite, the cleanest way to see through the noise is to hold two truths at once. One: there’s real, testable substance already on the table—public testnet details, live endpoints, clear network parameters. Two: the bigger promises—mainnet readiness, long-run performance at scale, and widespread adoption of agent-payment standards—still have to earn their proof in the open.
