--- title: Is KCC (KuCoin Community Chain) quantum-safe? chain: KCC (KuCoin Community Chain) ticker: KCS hardy_score: 8.5 rank: 65 of 80 tier: "5: Exposed" url: "https://hardyindex.com/chains/kcc" updated: 2026-10-23 reviewed: 2026-11-13 methodology_version: 1.8 --- # Is KCC (KuCoin Community Chain) quantum-safe? **Hardy Score 8.5 / 100. Rank 65 of 80. Tier 5: Exposed. Last editorial review 23 October 2026; sources checked 13 November 2026.** No. KCC, the EVM chain with chain ID 321 that its documentation describes as built by the developer community of KuCoin and KCS, runs a go-Ethereum fork, client v1.4.8-stable, under a Proof of Staked Authority engine. Accounts sign transactions with ECDSA on the secp256k1 curve, and each block is sealed by a validator's secp256k1 signature, which the node recovers to check the sealer. A sufficiently large quantum computer running Shor's algorithm would break both. The mainnet is live: its public RPC returned a block sealed on 23 October 2026, and a sample transfer carried an EIP-155 ECDSA signature for chain 321. We found no post-quantum position for KCC: nothing in its documentation, its node repository or its KIPs repository, which holds two KIPs: KIP-1 on the process itself and KIP-2, the meta-KIP for the Ishikari hard fork, which shares validator rewards with stakers. KuCoin's December 2025 post-quantum gateway proof of concept protects HTTPS connections to the exchange and does not mention KCC. KCS also exists as an ERC-20 token on Ethereum, where it is protected by Ethereum's signatures rather than KCC's. > This is a security-readiness assessment, not investment advice. ## Summary KCC accounts and validator block seals sign with ECDSA on secp256k1, and no post-quantum proposal, plan or research programme for the chain's signatures could be found in its documentation, node repository or improvement proposals. ## Where we are making a judgement call Four judgement calls. The first concerns scope and control rather than score. KCC is rated as a layer 1 because it runs its own Proof of Staked Authority consensus on a live public mainnet, but its validator set is permissioned and centrally administered. The documentation says each validator's identity is verified, and in the validator system contracts only an admin address can create the proposals by which candidates are admitted; the same admin can enable or disable a validator's pool, set the block reward paid from the reserve pool, switch the reserve pool off and change locking periods. On 23 October 2026 that admin was a contract account, 0x68a6a68d03d405af7e4676e5d92ad4bd7d1d004a, not a single key. The client has also rewritten contract code in place at a hard fork: the Amazon fork replaced the staking and peg-token contracts' code directly in state. A stricter reading would leave KCC out of the index; every signature scored here is the chain's own, and each is classical. The second is KuCoin's post-quantum work. KuCoin's December 2025 proof of concept protects HTTPS connections to the exchange and lists on-chain transaction signatures only as future research, without mentioning KCC, whose documentation describes it as built by KuCoin's developer community rather than by KuCoin. A reader who counts it as research for KCC would place KCC in Tier 4, with a deployment score of 2, and might score NIST alignment 3 for the Dilithium it names, which would raise the Hardy Score from 8.5 to 15.5. The third is migration. The score of 2 rather than 1 credits the record of coordinated hard forks shipped through KCC's client; at 1 the Hardy Score would be 7.0. The ERC-4337 support listed as a KCC 2.0 aim is not credited, because the documentation says KCC is still in KCC 1.0. The fourth concerns KCS on other chains: KCS is also an ERC-20 token on Ethereum, and that copy is not scored here. Separately, activity on KCC is low, with most blocks empty in the sample we read, and a chain that stops producing blocks leaves the index. ## 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. KCC recovers every transaction sender with ECDSA on secp256k1 through the go-ethereum signer it inherits, and its PoSA engine recovers each block's sealer with the same curve. A transfer read from the public RPC on 23 October 2026 carried an EIP-155 signature for chain 321. Nothing post-quantum protects KCS or any asset on KCC. Source: https://github.com/kcc-community/kcc/blob/v1.4.8-stable/core/types/transaction_signing.go ### 2. Deployment stage: 1/10 Anchor band 1: Tier 5: Exposed. Tier 5: Exposed. The signatures protecting funds and sealing blocks are quantum-vulnerable, and no KIP, documentation page, node release or research programme on post-quantum signatures for KCC was found. KuCoin's post-quantum gateway proof of concept covers connections to the exchange, not KCC's signatures, and does not mention the chain. Source: https://github.com/kcc-community/KIPs ### 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 KCC'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: nobody with authority over KCC has named a scheme at all, even as an example. KuCoin's gateway post names Dilithium for the exchange's own connections, and crediting it would score an exchange product rather than the chain. Source: https://github.com/kcc-community/kcc ### 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. KCC does have a working route for protocol change: its client has carried a coordinated fix for CVE-2021-39137 at block 2,509,228 in August 2021, the Ishikari hard fork in June 2022, which replaced the validator system contracts, and the Amazon hard fork at block 24,766,075 in October 2023. Its documentation lists ERC-4337 wallet support as a KCC 2.0 aim, but says the chain is still in KCC 1.0, so no account-abstraction route exists today. Placement in the band: The top of the band rather than a 0 or a 1: the chain has a record of coordinated hard forks shipped through its own client. Not a 3, because nobody with authority over KCC has acknowledged the quantum problem in public, let alone described a route for holders. Source: https://github.com/kcc-community/kcc/blob/v1.4.8-stable/params/config.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. KCC 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 KCC accepts the same keys and addresses as Ethereum, a key published on any EVM chain exposes the same address here. Validator signer addresses are recovered from every block seal. 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 KCS sits behind a key that has signed, here or on another EVM chain, and no measurement of the unexposed share has been published. Source: https://github.com/kcc-community/kcc/blob/v1.4.8-stable/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 KCC: no code, specification or testnet implementation was found in the node repository, the KIPs repository or the documentation. The node 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 nothing about KCC is marketed as quantum-safe, so its position does not rest on marketing. Source: https://github.com/kcc-community/kcc ## Nearest chains in the ranking The chains KCC sits among, out of 80 rated. The last column is the gap in Hardy points from KCC. | Rank | Chain | Tier | Hardy | vs KCS | |---:|---|---|---:|---:| | 61 | [Filecoin](https://hardyindex.com/chains/filecoin) | 5: Exposed | 8.5 | level | | 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)** | 5: Exposed | 8.5 | this chain | | 66 | [Kite](https://hardyindex.com/chains/kite) | 5: Exposed | 8.5 | level | | 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 | ## Signature scheme - **On mainnet today:** ECDSA on secp256k1 for accounts and validator block seals - **Post-quantum scheme:** None. No post-quantum scheme has been proposed, selected or tested for KCC. - **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, mandatory. Sender recovery through go-ethereum's signer in v1.4.8-stable, the client version KCC's public mainnet RPC reported on 23 October 2026. A transfer in block 56,731,917 read from that RPC carried v = 0x2a6, an EIP-155 signature for chain 321. The client stops at the Berlin rules and has no account abstraction or delegation. Source (source code or release): https://github.com/kcc-community/kcc/blob/v1.4.8-stable/core/types/transaction_signing.go - **Validator consensus:** [ECDSA on secp256k1](https://hardyindex.com/algorithms/ecdsa-secp256k1.md). Mainnet, mandatory. The PoSA engine recovers each block's sealer from the signature in the header's extra data with crypto.Ecrecover on secp256k1. Forty consecutive blocks read on 23 October 2026 were sealed in turn by twelve validator addresses. Source (source code or release): https://github.com/kcc-community/kcc/blob/v1.4.8-stable/consensus/posa/posa.go A role not listed here is not evidenced either way. See https://hardyindex.com/algorithms.md. ## Roadmap - **24 June 2022** (shipped): The Ishikari hard fork activates on KCC mainnet, introducing a new version of the validator system contracts. It changes no signature scheme. Source: https://docs.kcc.io/future-developments/milestone - **9 October 2023** (shipped): The Amazon hard fork activates at block 24,766,075, replacing the code of the staking contract and the peg-token contract in place and reducing reorganised blocks. It changes no signature scheme. Source: https://github.com/kcc-community/kcc/blob/v1.4.8-stable/consensus/posa/amazon.go - **No published position** (proposed): No post-quantum KIP, roadmap, research programme or testnet implementation for KCC's signatures was found at the time of writing. The KIPs repository holds two KIPs: KIP-1 on the process itself and KIP-2, the meta-KIP for the Ishikari hard fork. Source: https://github.com/kcc-community/KIPs ## If holders never migrate **No stated policy.** Nothing published for KCC addresses post-quantum migration, so nothing has been said about accounts that never move to post-quantum keys. As of 23 October 2026. ## Exposure KCC 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 KCS but never sent a transaction has not published its key. The opening signature publishes it permanently, and almost every account of consequence has signed. Because KCC 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 KCC too, even if the KCC account has never sent a transaction. Validator signer addresses are recovered from every block seal. KCC began from its own genesis in June 2021 rather than splitting from another chain's history, so the exposure inheritance rule does not apply. KCS held as an ERC-20 token on Ethereum, the KuCoin Token contract, is protected by Ethereum's signatures, not KCC's, and its exposure belongs to Ethereum's profile. ## Frequently asked questions ### Is KCC (KuCoin Community Chain) quantum-safe? No. KCC, the EVM chain with chain ID 321 that its documentation describes as built by the developer community of KuCoin and KCS, runs a go-Ethereum fork, client v1.4.8-stable, under a Proof of Staked Authority engine. Accounts sign transactions with ECDSA on the secp256k1 curve, and each block is sealed by a validator's secp256k1 signature, which the node recovers to check the sealer. A sufficiently large quantum computer running Shor's algorithm would break both. The mainnet is live: its public RPC returned a block sealed on 23 October 2026, and a sample transfer carried an EIP-155 ECDSA signature for chain 321. We found no post-quantum position for KCC: nothing in its documentation, its node repository or its KIPs repository, which holds two KIPs: KIP-1 on the process itself and KIP-2, the meta-KIP for the Ishikari hard fork, which shares validator rewards with stakers. KuCoin's December 2025 post-quantum gateway proof of concept protects HTTPS connections to the exchange and does not mention KCC. KCS also exists as an ERC-20 token on Ethereum, where it is protected by Ethereum's signatures rather than KCC's. ### Is KCC quantum-safe? No. KCC accounts sign with ECDSA on secp256k1 and validators seal blocks with secp256k1 signatures, and a sufficiently large quantum computer would break both. Nothing post-quantum protects KCS on KCC today, and nothing published for the chain proposes changing that. ### Does KuCoin's post-quantum gateway protect KCC? No. KuCoin's December 2025 proof of concept adds post-quantum key exchange to HTTPS connections between a browser and KuCoin's servers. It does not change any signature on KCC and does not mention the chain. ### Who controls KCC's validator set? Validators are chosen by KCS votes from candidates whose identities are verified, but in the system contracts only an admin address can create the proposals that admit a candidate, and the same admin can disable a validator's pool and set block rewards. On 23 October 2026 the admin was a contract account rather than a single key. ### Are KCS public keys already exposed? For almost all KCS in use, yes. A KCC address is a hash of the key and hides it until the account signs, but active accounts have transacted, and a key that has signed on Ethereum or another EVM chain is also visible for the same address on KCC. KCS held as an ERC-20 on Ethereum falls under Ethereum's signatures and Ethereum's profile. ## What this rating means if you hold KCC 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. [KCC node client](https://github.com/kcc-community/kcc): KCC (GitHub) (primary, checked 23 October 2026) 2. [KCC v1.4.8-stable release](https://github.com/kcc-community/kcc/releases/tag/v1.4.8-stable): KCC (GitHub) (primary, checked 23 October 2026) 3. [Transaction signing (core/types/transaction_signing.go, v1.4.8-stable)](https://github.com/kcc-community/kcc/blob/v1.4.8-stable/core/types/transaction_signing.go): KCC (GitHub) (primary, checked 23 October 2026) 4. [PoSA consensus engine (consensus/posa/posa.go, v1.4.8-stable)](https://github.com/kcc-community/kcc/blob/v1.4.8-stable/consensus/posa/posa.go): KCC (GitHub) (primary, checked 23 October 2026) 5. [Chain configuration (params/config.go, v1.4.8-stable)](https://github.com/kcc-community/kcc/blob/v1.4.8-stable/params/config.go): KCC (GitHub) (primary, checked 23 October 2026) 6. [Amazon hard fork patches (consensus/posa/amazon.go, v1.4.8-stable)](https://github.com/kcc-community/kcc/blob/v1.4.8-stable/consensus/posa/amazon.go): KCC (GitHub) (primary, checked 23 October 2026) 7. [Ishikari system contracts (consensus/posa/kccIshikari.go, v1.4.8-stable)](https://github.com/kcc-community/kcc/blob/v1.4.8-stable/consensus/posa/kccIshikari.go): KCC (GitHub) (primary, checked 23 October 2026) 8. [Validators system contract (Validators.sol)](https://github.com/kcc-community/kcc-genesis-contracts/blob/master/contracts/Validators.sol): KCC (GitHub) (primary, checked 23 October 2026) 9. [Proposal system contract (Proposal.sol)](https://github.com/kcc-community/kcc-genesis-contracts/blob/master/contracts/Proposal.sol): KCC (GitHub) (primary, checked 23 October 2026) 10. [Reserve pool system contract (ReservePool.sol)](https://github.com/kcc-community/kcc-genesis-contracts/blob/master/contracts/ReservePool.sol): KCC (GitHub) (primary, checked 23 October 2026) 11. [KCC Improvement Proposals (KIPs)](https://github.com/kcc-community/KIPs): KCC (GitHub) (primary, checked 23 October 2026) 12. [KCC mainnet public RPC](https://rpc-mainnet.kcc.network): KCC (chain RPC) (primary, checked 23 October 2026) 13. [Introduction](https://docs.kcc.io/overview/introduction): KCC Documents (primary, checked 23 October 2026) 14. [Consensus Engine](https://docs.kcc.io/overview/consensus-engine): KCC Documents (primary, checked 23 October 2026) 15. [Our Goal](https://docs.kcc.io/overview/our-goal): KCC Documents (primary, checked 23 October 2026) 16. [Apply For Running A Validator](https://docs.kcc.io/developers/run-a-node/run-a-validator-node/apply-for-running-a-validator): KCC Documents (primary, checked 23 October 2026) 17. [Milestone](https://docs.kcc.io/future-developments/milestone): KCC Documents (primary, checked 23 October 2026) 18. [The KCC Ecosystem: A New Era of Growth and Future Horizons](https://www.kucoin.com/blog/the-kcc-ecosystem-a-new-era-of-growth-and-future-horizons): KuCoin (secondary, checked 23 October 2026) 19. [KuCoin Releases Post-Quantum Cryptography (PQC) Gateway Proof-of-Concept](https://www.kucoin.com/blog/en-kucoin-releases-post-quantum-cryptography-pqc-gateway-proof-of-concept): KuCoin (primary, checked 23 October 2026) 20. [EIP-155: Simple replay attack protection](https://eips.ethereum.org/EIPS/eip-155): Ethereum Improvement Proposals (primary, checked 23 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). KCC (KuCoin Community Chain): quantum readiness assessment. Hardy Score 8.5 of 100, Tier 5: Exposed. Methodology v1.8. Last reviewed 23 October 2026; sources checked 13 November 2026. https://hardyindex.com/chains/kcc ```bibtex @misc{hardyindex_kcc_2026, author = {{The Hardy Index}}, title = {KCC (KuCoin Community Chain): quantum readiness assessment}, year = {2026}, howpublished = {\url{https://hardyindex.com/chains/kcc}}, 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, "KCC (KuCoin Community Chain)", https://hardyindex.com/chains/kcc, as of 13 November 2026.