KCC (KuCoin Community Chain)

Is KCC (KuCoin Community Chain) quantum-safe?

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.

At a glance

Cryptography in use

• Account signatures ECDSA on secp256k1 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 code or release
• Validator consensus ECDSA on secp256k1 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 code or release

A role not listed is not evidenced either way. Every scheme, and which other chains share it, is in the cryptography registry.

Score breakdown

How it compares

Roadmap

1. 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

2. 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

3. 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

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. Published beside the score, not in it. Every chain's stance is compared on the commitments page.

Exposure

Exposure measures how much of the chain's value already sits behind a public key that an attacker can record today and break later. This is the part of the threat that a future upgrade cannot undo.

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.

Questions

Sources

1. KCC node client KCC (GitHub) · primary · checked 23 October 2026
2. KCC v1.4.8-stable release KCC (GitHub) · primary · checked 23 October 2026
3. Transaction signing (core/types/transaction_signing.go, v1.4.8-stable) KCC (GitHub) · primary · checked 23 October 2026
4. PoSA consensus engine (consensus/posa/posa.go, v1.4.8-stable) KCC (GitHub) · primary · checked 23 October 2026
5. Chain configuration (params/config.go, v1.4.8-stable) KCC (GitHub) · primary · checked 23 October 2026
6. Amazon hard fork patches (consensus/posa/amazon.go, v1.4.8-stable) KCC (GitHub) · primary · checked 23 October 2026
7. Ishikari system contracts (consensus/posa/kccIshikari.go, v1.4.8-stable) KCC (GitHub) · primary · checked 23 October 2026
8. Validators system contract (Validators.sol) KCC (GitHub) · primary · checked 23 October 2026
9. Proposal system contract (Proposal.sol) KCC (GitHub) · primary · checked 23 October 2026
10. Reserve pool system contract (ReservePool.sol) KCC (GitHub) · primary · checked 23 October 2026
11. KCC Improvement Proposals (KIPs) KCC (GitHub) · primary · checked 23 October 2026
12. KCC mainnet public RPC KCC (chain RPC) · primary · checked 23 October 2026
13. Introduction KCC Documents · primary · checked 23 October 2026
14. Consensus Engine KCC Documents · primary · checked 23 October 2026
15. Our Goal KCC Documents · primary · checked 23 October 2026
16. Apply For Running A Validator KCC Documents · primary · checked 23 October 2026
17. Milestone KCC Documents · primary · checked 23 October 2026
18. 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 KuCoin · primary · checked 23 October 2026
20. EIP-155: Simple replay attack protection Ethereum Improvement Proposals · primary · checked 23 October 2026

@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}
}