The design, in full.
How Cockroach Chain works: consensus, the EVM, the COCKROACH token, staking and standby rewards, the fee burn and governance. Read it here or download the PDF.
Abstract
Cockroach Chain is a proof-of-stake Layer-1 blockchain that runs the Ethereum Virtual Machine on top of the Cosmos SDK and CometBFT consensus. It offers single-block finality, predictable fees under EIP-1559, native IBC interoperability and a monetary policy that holders control within limits fixed in code.
This paper describes the architecture, the token, the staking and standby-validator economics, the fee burn, governance and the roadmap. It is a living document; the version date is shown below.
VERSION 1.0 · OCTOBER 2026
Motivation
Most smart-contract platforms force a trade-off. EVM chains have the tools and the developers but often probabilistic finality and volatile fees. Cosmos chains have fast finality, sovereignty and IBC but a smaller developer base.
Cockroach Chain combines both: Solidity developers deploy unchanged code, while users get one-block finality, stable costs and access to the wider Cosmos network.
Architecture
Consensus
CometBFT, a Byzantine fault tolerant consensus engine. A block is final when validators holding more than two-thirds of stake sign it. Target block time is about five seconds.
Execution
The EVM module from Cosmos EVM executes Solidity and Vyper contracts and exposes standard Ethereum JSON-RPC. Precompiled contracts give Solidity direct access to staking (0x…0800), distribution (0x…0801), IBC transfer (0x…0802), bank (0x…0804) and governance (0x…0805).
Accounts
One secp256k1 key controls both an Ethereum-style 0x address and a Bech32 cockroach1 address, so the same funds are reachable from MetaMask and Keplr.
Interoperability
Native IBC lets assets and messages move between Cockroach Chain and other IBC-enabled chains without a trusted bridge operator.
The COCKROACH token
COCKROACH (denomination acockroach, 18 decimals) is used for gas, staking and governance. Genesis supply is 10,000,000 COCKROACH. There is no maximum supply: new tokens are created only as staking rewards, and part of every fee is burned.
| Allocation | Share | Tokens |
|---|---|---|
| Ecosystem & community | 25% | 2,500,000 |
| Team | 15% | 1,500,000 |
| Treasury | 15% | 1,500,000 |
| Private sale | 10% | 1,000,000 |
| Validator bootstrap | 10% | 1,000,000 |
| Airdrop & marketing | 10% | 1,000,000 |
| Public sale | 5% | 500,000 |
| Exchange liquidity | 5% | 500,000 |
| Market maker | 5% | 500,000 |
Staking economics
Rewards are paid on staked tokens, not on total supply. Each block, the mint module issues new COCKROACH so that bonded stake earns the target rate:
Each year the rate steps down by a fixed 0.012 (0.1% a month), without compounding, until it reaches a floor of 0.06 (0.5% a month) in year 16. Governance can raise or lower the rate at any time but never above the cap.
Validator commission is fixed at 10% for every validator, enforced by a staking hook. A delegator therefore earns 1.8% a month in year 1 and the validator 0.2% on delegated stake, plus the full rate on its own stake. Unbonding takes 7 days.
Standby validators
The active set is capped at 100 validators to keep consensus fast. Validators ranked 101 to 200 by stake can join the standby set if they self-stake at least 5,000 COCKROACH and keep a node online.
Every hour, a standby node signs a recent block hash with its consensus key and submits it on-chain. At the end of each day, the module pays standby validators and their delegators the same base rate as the active set, pro-rated by hours online. Jailed or tombstoned validators earn nothing.
Fee burn
Gas follows EIP-1559: a base fee set by demand plus an optional tip. 50% of every fee is burned in the block it is paid; the rest goes to validators and delegators. Governance can set the burn share between 0% and 100%. Tokens sent to the public burn address are also removed, and the chain tracks the total burned.
Governance
Stakers vote on text, parameter, upgrade, community-pool and freeze proposals. Standard votes run for 5 days with a 33.4% quorum and a 50% pass threshold; expedited votes run for 1 day and need 66.7%. A dedicated module lets governance freeze addresses linked to exploits or sanctions. Freezes stop future transfers; they never reverse past transactions.
Roadmap
| Phase | Milestone |
|---|---|
| 1 · Devnet | Core modules, standby validators and burn tested on a multi-node network |
| 2 · Public testnet | External validators, faucet, explorers, live governance |
| 3 · Security audit | Independent review of all custom modules and genesis |
| 4 · Mainnet | Genesis, public sale distribution and exchange listing |
Risks
Software can contain bugs; token prices can fall; regulations can change; governance outcomes can be unfavourable to some holders. See the full Risk Disclosure. Nothing in this paper is an offer of securities or financial advice.
Building on these ideas?
The developer guide covers the code behind every section.