---
title: Is Kite quantum-safe?
chain: Kite
ticker: KITE
hardy_score: 8.5
rank: 66 of 80
tier: "5: Exposed"
url: "https://hardyindex.com/chains/kite"
updated: 2026-10-22
reviewed: 2026-11-13
methodology_version: 1.8
---

# Is Kite quantum-safe?

**Hardy Score 8.5 / 100. Rank 66 of 80. Tier 5: Exposed. Last editorial review 22 October 2026; sources checked 13 November 2026.**

No. Kite is an EVM-compatible layer 1 built for payments by AI agents, and its accounts sign transactions with ECDSA on the secp256k1 curve through Subnet-EVM, the Ava Labs execution client that Kite runs in its own fork. Kite runs as a sovereign Avalanche L1: the P-Chain records it as a converted L1 with its own set of twelve validators, each registered with a BLS12-381 key, and the node it ships is AvalancheGo with the Kite chain as a plugin. A sufficiently large quantum computer running Shor's algorithm would break both schemes. Kite's agent features sit on top of the same keys: Kite Passport and the account-abstraction SDK delegate spending to agent and session keys, but every delegation traces back to a user key whose security Kite's own documentation rests on "the cryptographic hardness of ECDSA/EdDSA". We found no post-quantum position from Kite: no proposal, roadmap, named scheme or research programme for the chain's signatures. Avalanche announced Kite's mainnet on 28 April 2026.

> This is a security-readiness assessment, not investment advice.

## Summary

Kite, an EVM-compatible Avalanche L1 for AI agent payments, signs accounts with ECDSA on secp256k1 and registers BLS keys for its validators, and no post-quantum plan, proposal or research programme for its signatures could be found.

## Where we are making a judgement call

One judgement call concerns scope rather than score. Kite is rated as a layer 1 because it has its own validator set and runs its own instance of Avalanche consensus: the P-Chain records it as a converted L1 with twelve validators of its own, which ACP-77 does not require to validate Avalanche's Primary Network, and its state and transactions are its own. Two features cut the other way. Changes to Kite's validator set are registered on the Avalanche P-Chain, which is secured by the Primary Network's validators, and each Kite validator pays a continuous fee in AVAX there. A reader who treats Kite as a network secured partly by Avalanche would leave it out of the index rather than score it differently: every signature this profile scores is Kite's own, and each is classical. The second call is the migration score of 2, which rests on Kite having carried one coordinated network upgrade on its live mainnet and on the precompile-upgrade mechanism of the client it runs. A reader who asks for a longer record of upgrades decided by Kite itself, rather than adopted from Avalanche's schedule, would score migration 1 and lower the Hardy Score by 1.5 points. The tier itself is not a judgement call: nothing post-quantum on the chain's signatures was found from Kite, so no reading of the record lifts it to Tier 4. A note on the trust model, which no score turns on: the chain configuration, read from the mainnet RPC with eth_getChainConfig on 22 October 2026, names one admin address, 0x2ba214b0afca4cad5a6a9b8af05032ce574f16e6, an account with no contract code, for the native minter, the fee manager and the reward manager, so a single ECDSA key can mint KITE and change the chain's fee and reward settings.

## Score breakdown

| # | Dimension | Score | Weight | Contribution |
|---:|---|---:|---:|---:|
| 1 | Signature scheme | 0/10 | 30% | 0.0 |
| 2 | Deployment stage | 1/10 | 25% | 2.5 |
| 3 | NIST alignment | 0/10 | 15% | 0.0 |
| 4 | Migration path | 2/10 | 15% | 3.0 |
| 5 | Exposure | 2/10 | 10% | 2.0 |
| 6 | Verification | 2/10 | 5% | 1.0 |
| | **Hardy Score** | | | **8.5** |

### 1. Signature scheme: 0/10

Anchor band 0: Classical signatures only on mainnet, with nothing post-quantum protecting live funds. Short-lived devnets and one-off benchmarks sit here: they demonstrate research rather than something a user can hold keys on.

Kite executes transactions with a fork of Subnet-EVM, which takes its transaction types and sender recovery from Ava Labs' libevm, the go-ethereum code that recovers an ECDSA secp256k1 signer. Kite's validators are registered on the P-Chain with BLS12-381 keys. Nothing post-quantum protects KITE or any asset on Kite today.

Source: https://github.com/ava-labs/libevm/blob/main/core/types/transaction_signing.go

### 2. Deployment stage: 1/10

Anchor band 1: Tier 5: Exposed.

Tier 5: Exposed. The signatures protecting funds and the validator keys on Kite are quantum-vulnerable, and no Kite proposal, roadmap, publication or research programme on post-quantum signatures was found in its documentation or its public repositories.

Source: https://docs.gokite.ai/

### 3. NIST alignment: 0/10

Anchor band 0 to 2: No post-quantum scheme named for the chain’s fund-protecting signatures, or a proprietary scheme with no public cryptanalysis.

No post-quantum scheme has been named for Kite's account or validator signatures, so there is nothing to assess against a NIST standard.

Placement in the band: The floor of the band rather than a 1 or a 2: no scheme has been named at all, even as an example, by anyone with authority over Kite, so there is no choice to align with a standard.

Source: https://docs.gokite.ai/about/core-concepts-and-terminology

### 4. Migration path: 2/10

Anchor band 0 to 2: No agreed migration path, or the proposals on the table would strand or freeze holder funds.

No migration plan or published position exists. Kite does have working upgrade machinery: its chain configuration, read from the mainnet RPC with eth_getChainConfig, shows Avalanche's Helicon network upgrade activated on 22 September 2026, after the public launch, and Subnet-EVM can activate new precompiles at a scheduled timestamp, which is the route a post-quantum verifier would take. Smart-contract wallets from the account-abstraction SDK are still controlled by an ECDSA signer.

Placement in the band: The top of the band rather than a 0 or a 1: Kite has carried a coordinated network upgrade on its live mainnet, and the precompile-upgrade mechanism in the client it runs gives it a path to add a new signature check without a new chain. Not a 3, because Kite has not acknowledged the quantum problem in public, let alone described a route for holders.

Source: https://github.com/gokite-ai/subnet-evm/blob/master/params/extras/precompile_upgrade.go

### 5. Exposure: 2/10

Anchor band 0 to 2: Public keys are exposed for effectively all accounts, or a large, measured share of total supply sits in exposed addresses.

Kite keeps Ethereum's account model: an address is a hash of the public key, so an account that has never signed keeps its key private. Every account that has sent a transaction has published its key, and because Kite accepts the same keys and addresses as Ethereum, a key published on any EVM chain exposes the same address on Kite. Validator BLS keys are public on the P-Chain by design.

Placement in the band: The top of the band rather than a 1: never-signed addresses keep their keys hidden. Not a 3, because almost all economically active KITE sits behind a key that has signed, on Kite or on another EVM chain, and no measurement of the unexposed share has been published.

Source: https://github.com/ava-labs/libevm/blob/main/core/types/transaction_signing.go

### 6. Verification: 2/10

Anchor band 0 to 2: No post-quantum component exists, or the claims rest on marketing.

No post-quantum component exists for Kite: no code, specification or testnet implementation was found in its forks of AvalancheGo and Subnet-EVM or in its documentation. The node code is open source, but under v1.8 the openness of classical code earns nothing on this dimension.

Placement in the band: The top of the band rather than a 0 or a 1: there is nothing post-quantum to verify, but Kite does not market the chain as quantum-safe. The one mention of quantum computers in its documentation, that they "cannot resurrect expired sessions", is about session expiry, not about the signatures protecting funds.

Source: https://github.com/gokite-ai/subnet-evm

## Nearest chains in the ranking

The chains Kite sits among, out of 80 rated. The last column is the gap in Hardy points from Kite.

| Rank | Chain | Tier | Hardy | vs KITE |
|---:|---|---|---:|---:|
| 62 | [GateChain](https://hardyindex.com/chains/gatechain) | 5: Exposed | 8.5 | level |
| 63 | [Gnosis Chain](https://hardyindex.com/chains/gnosis) | 5: Exposed | 8.5 | level |
| 64 | [Injective](https://hardyindex.com/chains/injective) | 5: Exposed | 8.5 | level |
| 65 | [KCC (KuCoin Community Chain)](https://hardyindex.com/chains/kcc) | 5: Exposed | 8.5 | level |
| 66 | **Kite** | 5: Exposed | 8.5 | this chain |
| 67 | [Mina Protocol](https://hardyindex.com/chains/mina) | 5: Exposed | 8.5 | level |
| 68 | [MultiversX](https://hardyindex.com/chains/multiversx) | 5: Exposed | 8.5 | level |
| 69 | [Polygon PoS](https://hardyindex.com/chains/polygon-pos) | 5: Exposed | 8.5 | level |
| 70 | [Provenance Blockchain](https://hardyindex.com/chains/provenance) | 5: Exposed | 8.5 | level |

## Signature scheme

- **On mainnet today:** ECDSA on secp256k1 for accounts; BLS12-381 keys registered for each validator on the Avalanche P-Chain
- **Post-quantum scheme:** None. No post-quantum scheme has been proposed, selected or tested for Kite.
- **NIST standard:** None adopted.
- **Readiness tier:** Tier 5: Exposed. The signatures securing funds on mainnet today are quantum-vulnerable, and no public post-quantum plan, proposal or research programme addressing them could be found.

## Cryptography in use

- **Account signatures:** [ECDSA on secp256k1](https://hardyindex.com/algorithms/ecdsa-secp256k1.md). Mainnet, default. Sender recovery in libevm, the go-ethereum code that Kite's Subnet-EVM fork (gokite-ai/subnet-evm) builds on.
  Source (source code or release): https://github.com/ava-labs/libevm/blob/main/core/types/transaction_signing.go
- **Validator consensus:** [BLS signatures on BLS12-381](https://hardyindex.com/algorithms/bls12-381.md). Mainnet, mandatory. Each of Kite's twelve L1 validators is registered on the P-Chain with a BLS public key and proof of possession; ACP-77 uses these keys for the aggregate signatures on Warp messages that change an L1's validator set.
  Source (read on-chain): https://glacier-api.avax.network/v1/networks/mainnet/l1Validators?subnetId=21uUaTxVdR3Sp6SJhpcSrdH1g66aFoE8mPQDvwKJCjXNexo5y6

A role not listed here is not evidenced either way. See https://hardyindex.com/algorithms.md.

## Roadmap

- **15 December 2025** (shipped): The Kite blockchain is created on the Avalanche P-Chain as a Subnet-EVM chain with EVM chain ID 2366, and its subnet is converted to an L1 with a validator manager contract on the Kite chain itself.
  Source: https://glacier-api.avax.network/v1/networks/mainnet/subnets/21uUaTxVdR3Sp6SJhpcSrdH1g66aFoE8mPQDvwKJCjXNexo5y6
- **28 April 2026** (shipped): Avalanche announces that "Kite launches its mainnet as a sovereign Avalanche L1". Accounts sign with ECDSA on secp256k1.
  Source: https://www.avalanche.com/about/blog/1-9-billion-interactions-later-it-goes-live
- **No published position** (proposed): No post-quantum proposal, roadmap, research programme or testnet implementation for Kite's signatures was found from Kite at the time of writing.
  Source: https://docs.gokite.ai/

## If holders never migrate

**No stated policy.** Kite has published nothing about post-quantum migration, so nothing has been said about accounts that never move to post-quantum keys. As of 22 October 2026.

## Exposure

Kite uses Ethereum's address model: an address is the last twenty bytes of the Keccak hash of the public key, so an account that has received KITE but never sent a transaction has not published its key. The first signature publishes it permanently. Kite's design multiplies signing: users delegate to agents with keys derived by BIP-32 and to random session keys, and agents pay in many small transactions, so the accounts that hold and spend value sign often. Because Kite accepts the same keys and addresses as Ethereum, a holder who has signed with the same key on Ethereum or any other EVM chain has a published key on Kite too, even if the Kite account has never sent a transaction. The validators' BLS keys are listed on the Avalanche P-Chain. KITE held as a bridged token on another chain is protected by that chain's signatures, not by Kite's, and its exposure belongs to that chain's profile.

## Frequently asked questions

### Is Kite quantum-safe?

No. Kite is an EVM-compatible layer 1 built for payments by AI agents, and its accounts sign transactions with ECDSA on the secp256k1 curve through Subnet-EVM, the Ava Labs execution client that Kite runs in its own fork. Kite runs as a sovereign Avalanche L1: the P-Chain records it as a converted L1 with its own set of twelve validators, each registered with a BLS12-381 key, and the node it ships is AvalancheGo with the Kite chain as a plugin. A sufficiently large quantum computer running Shor's algorithm would break both schemes. Kite's agent features sit on top of the same keys: Kite Passport and the account-abstraction SDK delegate spending to agent and session keys, but every delegation traces back to a user key whose security Kite's own documentation rests on "the cryptographic hardness of ECDSA/EdDSA". We found no post-quantum position from Kite: no proposal, roadmap, named scheme or research programme for the chain's signatures. Avalanche announced Kite's mainnet on 28 April 2026.

### Is Kite quantum-safe?

No. Kite accounts sign with ECDSA on secp256k1 and its validators are registered with BLS12-381 keys, and a sufficiently large quantum computer would break both. Kite has published no post-quantum plan, proposal or research programme.

### Do Kite's agent passports and session keys protect against quantum attacks?

No. Kite Passport and the account-abstraction SDK limit what an agent or a session can spend, which contains the damage from a stolen agent key, but the delegations are signed with the same classical keys. Kite's documentation says a user's standing intent cannot be forged without the user's private key because of "the cryptographic hardness of ECDSA/EdDSA", and Shor's algorithm removes that hardness. The layered keys would matter to a migration, because a smart account can change the key it accepts, but no post-quantum key type exists to change to.

### Why is Kite rated as a layer 1 when it is built on Avalanche?

Because it runs its own consensus with its own validators. Kite is a sovereign Avalanche L1: twelve validators of its own produce and finalise its blocks, and the Avalanche P-Chain records that validator set without validating Kite's transactions. Validator registrations and their fees go through the P-Chain, and the profile's caveat sets out how that bears on the rating.

### Are KITE holders' public keys already exposed?

For almost all KITE in use, yes. A Kite address is a hash of the key and hides it until the account signs, but active accounts have signed, and a key that has signed on Ethereum or any other EVM chain is equally visible for the same address on Kite. Those keys can be recorded now and attacked later.

### What would move Kite up the index?

A published proposal or a public research programme by Kite on post-quantum signatures for its accounts or validators would meet the Tier 4 floor. A plan from Kite naming the scheme it will adopt would meet Tier 3. A post-quantum verification precompile on a Kite test network would also lift the verification and NIST alignment scores.

## What this rating means if you hold Kite

Plain-language guidance from the same publication, with no product recommendation attached.

- [Is my crypto safe from quantum computers?](https://hardyindex.com/guides/is-my-crypto-safe-from-quantum-computers.md)
- [How to protect your crypto from quantum computers](https://hardyindex.com/guides/how-to-protect-crypto-from-quantum-computers.md)
- [All guides](https://hardyindex.com/guides.md)


## Sources

1. [Kite Developer Docs](https://docs.gokite.ai/): Kite (primary, checked 22 October 2026)
2. [Core Concepts & Terminology](https://docs.gokite.ai/about/core-concepts-and-terminology): Kite (primary, checked 22 October 2026)
3. [Tokenomics](https://docs.gokite.ai/about/tokenomics): Kite (primary, checked 22 October 2026)
4. [Mainnet Network Information](https://docs.gokite.ai/kite-chain/7-kite-node/mainnet-network-information): Kite (primary, checked 22 October 2026)
5. [Mainnet Node Operations](https://docs.gokite.ai/kite-chain/7-kite-node/mainnet-node-operations): Kite (primary, checked 22 October 2026)
6. [GoKite Account Abstraction SDK: Developer Guide](https://docs.gokite.ai/kite-chain/5-advanced/account-abstraction-sdk): Kite (primary, checked 22 October 2026)
7. [Kite Chain node configuration (Dockerfile)](https://github.com/gokite-ai/gokite-chain/blob/main/Dockerfile): Kite (GitHub) (primary, checked 22 October 2026)
8. [Subnet-EVM, Kite fork](https://github.com/gokite-ai/subnet-evm): Kite (GitHub) (primary, checked 22 October 2026)
9. [Precompile upgrades (params/extras/precompile_upgrade.go), Kite's Subnet-EVM fork](https://github.com/gokite-ai/subnet-evm/blob/master/params/extras/precompile_upgrade.go): Kite (GitHub) (primary, checked 22 October 2026)
10. [libevm transaction signing (core/types/transaction_signing.go)](https://github.com/ava-labs/libevm/blob/main/core/types/transaction_signing.go): Ava Labs (GitHub) (primary, checked 22 October 2026)
11. [Kite subnet and blockchain record (P-Chain, Avalanche Data API)](https://glacier-api.avax.network/v1/networks/mainnet/subnets/21uUaTxVdR3Sp6SJhpcSrdH1g66aFoE8mPQDvwKJCjXNexo5y6): Ava Labs (Avalanche Data API) (primary, checked 22 October 2026)
12. [Kite L1 validators (P-Chain, Avalanche Data API)](https://glacier-api.avax.network/v1/networks/mainnet/l1Validators?subnetId=21uUaTxVdR3Sp6SJhpcSrdH1g66aFoE8mPQDvwKJCjXNexo5y6): Ava Labs (Avalanche Data API) (primary, checked 22 October 2026)
13. [Kite mainnet RPC (eth_getChainConfig)](https://rpc.gokite.ai/): Kite (primary, checked 22 October 2026)
14. [ACP-77: Reinventing Subnets](https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/77-reinventing-subnets/README.md): Avalanche Foundation (GitHub) (primary, checked 22 October 2026)
15. [1.9 Billion Interactions Later, It Goes Live](https://www.avalanche.com/about/blog/1-9-billion-interactions-later-it-goes-live): Avalanche (secondary, checked 22 October 2026)
16. [FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final): NIST (primary, checked 22 October 2026)

## How to cite this rating

A rating is only true as of the day it was reviewed, so both forms carry the review date and the methodology version. If you are quoting the score, quote those too.

The Hardy Index (2026). Kite: quantum readiness assessment. Hardy Score 8.5 of 100, Tier 5: Exposed. Methodology v1.8. Last reviewed 22 October 2026; sources checked 13 November 2026. https://hardyindex.com/chains/kite

```bibtex
@misc{hardyindex_kite_2026,
  author       = {{The Hardy Index}},
  title        = {Kite: quantum readiness assessment},
  year         = {2026},
  howpublished = {\url{https://hardyindex.com/chains/kite}},
  note         = {Hardy Score 8.5 of 100, Tier 5: Exposed. Methodology v1.8},
  urldate      = {2026-11-13}
}
```

---

Methodology: https://hardyindex.com/methodology (v1.8).
Cite as: The Hardy Index, "Kite", https://hardyindex.com/chains/kite, as of 13 November 2026.
