Introduction

BKC is a proof-of-stake blockchain built on the Cosmos SDK and CometBFT, with an Ethereum Virtual Machine (cosmos/evm) running inside it. What sets it apart is the signature scheme: every account key and every validator key is ML-DSA-65, the lattice-based post-quantum signature standard published as NIST FIPS 204.

Why post-quantum

Ethereum and almost every Cosmos chain secure accounts with elliptic-curve signatures (secp256k1 or ed25519). A large enough quantum computer running Shor's algorithm recovers an elliptic-curve private key from its public key — and a public key is revealed the first time an account signs anything. ML-DSA is built on module lattices, for which no efficient quantum attack is known.

BKC applies that to custody from genesis:

• Accounts can only be ML-DSA-65 keys. The ante handler rejects secp256k1 and ed25519 signers, legacy Amino JSON signing and every sign mode except SIGN_MODE_DIRECT.
• Validators' consensus keys are ML-DSA-65 too, through forks of CometBFT and the Cosmos SDK.
• Governance cannot widen this: re-enabling a pre-quantum key type needs a binary upgrade, not a vote.

What it costs

Post-quantum signatures are large. An ML-DSA-65 public key is 1,952 bytes and a signature is 3,309 bytes, against 33 and 64 for secp256k1. A simple transfer is about 5.5 KB on the wire, and gas is charged per byte, so transactions cost more gas than on an ECDSA chain (a send uses roughly 230,000–285,000 gas). The fee per gas unit is low to compensate — see Gas & fees.

The EVM, and the one difference

BKC runs a full EVM. Contracts are ordinary Solidity, deployed and called with ordinary tools, and the explorer is Blockscout. Reads (eth_call, eth_getLogs, receipts, blocks) are standard Ethereum JSON-RPC.

The difference is in how a write is signed. No BKC account has an ECDSA key, so nothing can produce the signature an Ethereum transaction carries, and the node refuses eth_sendRawTransaction. Instead, a write is a Cosmos message — /bkc.bkc.v1.MsgExecuteEvmCall — signed with ML-DSA-65. The chain executes it in the EVM and emits a normal Ethereum transaction hash, receipt and logs, so everything after the send keeps working.

You rarely see this. The JavaScript SDK hands you an ethers Signer that does the wrapping, and the Hardhat plugin does it inside Hardhat's provider. Read Transactions & EVM calls for what happens underneath.

Where to go next

• Build a dApp or deploy a contract → Quickstart
• Understand accounts and addresses → Accounts & keys
• Integrate an existing backend → API endpoints