Research/Education/Cronos/Cronos consensus and validators: how each chain reaches agreement
# Cronos

Cronos consensus and validators: how each chain reaches agreement

BloFin Academy08/03/2026
A plain-English guide to how Cronos reaches consensus and who validates it: the Tendermint BFT engine both chains share, the open top-100-by-stake validator set on Cronos POS, the permissioned by-invitation set on Cronos EVM, instant finality, delegation, and how governance changes consensus parameters.

Cronos reaches consensus with a Byzantine fault tolerant engine, but its two live chains are validated in opposite ways. Cronos POS is an open proof-of-stake chain, secured by an active set capped at the top 100 validators by stake. Cronos EVM is a permissioned proof-of-authority chain, run by a small, invitation-only validator set.

The engine underneath both chains is the same idea. Validators run a Tendermint-style round of votes, and a block is final when signatures represent enough voting power, subject to the protocol's BFT fault assumptions. What changes between the chains is who is allowed to be a validator. On Cronos POS, anyone can enter the set by staking CRO. Holders steer it by delegating. On Cronos EVM, the set is curated, and new validators join only by invitation.

That one difference, an open set versus a curated one, is the real story of Cronos consensus, and it decides who you are trusting on each chain.


Two chains, two ways of choosing validators

Cronos is not one blockchain but a small family, and its two live chains pick their validators in opposite ways. Cronos POS is open, so staking CRO lets you join or influence the set. Cronos EVM is closed, so a vetted group runs it and you join by invitation only.

Chain Consensus engine Who validates How you get in
Cronos POS Tendermint BFT, open proof of stake An active set capped at the top 100 by stake Stake enough CRO, or delegate to a validator
Cronos EVM Tendermint BFT, permissioned proof of authority A small, vetted set (docs list around 33) By invitation only, applications are not currently open

Both chains run the same kind of consensus engine. It is a Tendermint-style protocol that settles blocks fast and for good, not the slow, probabilistic confirmations of a mining chain. If the idea of validators staking to secure a network is new, the primer on proof of stake covers the mechanics both chains build on.

So the engine is not what sets Cronos apart, since plenty of chains share it. What matters is the answer to one question: who is allowed to validate? Cronos runs more than one chain for different jobs, and the wider guide to how Cronos works puts them in context. The rest of this guide takes each chain's answer in turn.

How Cronos POS reaches consensus

Cronos POS reaches consensus through Tendermint Core, a Byzantine fault tolerant proof-of-stake engine. Validators take turns proposing a block, then vote on it in rounds. Once validators representing more than two-thirds of voting power sign, the block is final under Tendermint's fault assumptions. There is no waiting for mining-style confirmations.

This is the standard Cosmos-style setup. Cronos POS is built on Tendermint Core. Its validators run a fault tolerant protocol among themselves to agree on the order of transactions, and a block is final as soon as it is committed, subject to the network's fault assumptions (source: Cronos POS Chain Docs). The generic mechanics are the same ones behind Ethereum's proof of stake, so this guide stays on what Cronos does with them.

The set that does this work is not unlimited. Cronos POS is a public, permissionless chain. Its mainnet supports up to 100 active validators, the top 100 ranked by how much CRO is staked to them (source: Cronos POS, EVM & zkEVM FAQ). More can register, but only the top 100 by stake take part in consensus at any time. A validator's turn at proposing blocks comes up in proportion to its stake. So, the more CRO behind it, the more often it leads a round.

The payoff of this design is speed with certainty. On a mining chain you wait for several blocks before a payment feels safe, because an early block can still be undone. On Cronos POS there is no such limbo. Once validators commit a block, its transactions are final under the protocol's fault assumptions.

Delegation: how holders shape who validates

On Cronos POS, you do not need to run a validator to take part in consensus. You delegate CRO to one, and your stake is added to its voting power. That is how ordinary holders decide which validators make the active set, and which ones get to propose and sign blocks.

A validator's voting power is just the amount of CRO bonded to it, its own coins plus everything delegated by holders (source: Cronos POS Chain Technical Glossary). The more power it has, the more often it is picked to propose the next block. So delegation is not a passive deposit. It is a vote for which validators should hold the top 100 seats.

This is where consensus and staking meet, but they are not the same thing. Delegating shapes the validator set and shares in its rewards, and the full reward and risk picture lives in the guide to staking CRO. Here the point is narrower. Your stake is what puts a validator in the set, and the general role behind it is covered in the overview of how Ethereum validators work.

The catch built into that bargain is shared risk. If your validator double-signs, a slice of the CRO delegated to it, including yours, can be slashed. Extended downtime can also jail a validator. That shared fate is why the choice of validator is the real decision a delegator makes.

How Cronos EVM validates, and why it is permissioned

Cronos EVM takes the opposite approach. It uses proof of authority, which Cronos calls a permissioned version of proof of stake. Instead of an open, stake-weighted set, a small group of vetted operators runs the chain. The current documentation lists around 33 validators, all infrastructure providers, and new ones join by invitation rather than by staking.

Under the hood, Cronos EVM is an Ethermint chain on the Cosmos SDK, so it still runs a Tendermint consensus engine. Cronos describes its model as proof of authority, a permissioned variant of proof of stake (source: Cronos EVM Docs). The engine is familiar. The guest list is not.

The validator set is small and closed. The docs say there are around 33 validators supporting the network, all leading infrastructure providers, and that becoming one is by invitation only, with applications not currently open (source: Cronos EVM General FAQ). Admission is separate from the public token, so you cannot stake your way in the way you can on Cronos POS.

Treat that count as a snapshot, not a fixed fact. Cronos's own sources have listed the figure differently over time, so the honest read is a small set in the low tens, not a permanent 33. The reason for keeping it small is coordination. Fewer, known validators can agree faster and run the chain reliably. That is the trade a permissioned model makes on purpose.

What finality means, and the trade-off between the two models

Both chains give you instant finality: once a block is committed, its transactions are settled under the protocol's fault assumptions. The difference is decentralization. The open Cronos POS set spreads trust across many stakers, while the smaller, permissioned Cronos EVM set is quicker to coordinate but rests on fewer, hand-picked operators.

Neither model is simply better. A larger, open set is harder for any single party to capture, but it can be slower and messier to run. A curated set is fast and predictable. But you are trusting a short list of operators to stay honest and online. What you are really choosing between is broad security and tight coordination, and Cronos runs one of each.

The practical takeaway is to know which chain you are on. If your CRO is staked or moving as native CRO, an open validator set stands behind it. If you are using an app on Cronos EVM, a permissioned one does.

How governance can change the rules of consensus

Consensus rules are not carved in stone, at least on Cronos POS. Its parameters, like the size of the active set or the penalty for misbehaving, are set on-chain and can be changed by a vote of staked CRO. A single proposal can tune one setting or approve a full software upgrade.

The lever is on-chain governance. Any holder can submit a proposal with a deposit, and bonded CRO then votes yes, no, no with veto, or abstain, with the outcome written into the chain's own rules (source: Cronos POS Chain Governance Module). Proposals can change network parameters at run time, spend from a community pool, or schedule a code upgrade.

One published example in the governance docs shows a passed proposal setting the MaxValidators parameter, the maximum number of validators, from 100 to 151. That is worth pausing on. The top-100 cap that defines the Cronos POS active set is itself a setting a vote can move, which is why this guide treats it as a current parameter rather than a permanent feature.

Cronos EVM works differently. Its validators are admitted by invitation, with applications not currently open, rather than through a public CRO vote. For the fuller mechanics of on-chain governance and the base chain itself, see the guide to the Cronos POS chain. The short version: on one chain, holders can change the rules of consensus, and on the other, a smaller group does.


Frequently asked questions

What should I check before I delegate CRO to a validator?

Start with behavior, not just the advertised reward. Check whether the validator has stayed online, how much commission it keeps from rewards, whether its voting record matches your view, and whether its stake is already unusually concentrated. Then make a small delegation first and confirm that it appears in your wallet. A validator can be active yet still be a poor fit if its fees, reliability, or governance choices do not meet your criteria.

Should I put all of my delegated CRO with one validator?

No rule requires all of your delegated CRO to sit with one operator. Splitting it across more than one validator can keep a single operator from determining every reward and slashing outcome. It also creates more work, since you need to track each validator's commission, uptime, and governance record. It does not remove network-level risk. Choose a number you can monitor rather than treating a long validator list as safety by itself.

What is a validator commission?

A commission is the share of staking rewards a validator keeps before the remainder is credited to delegators. It is not a fee taken from the CRO you originally delegated, but it affects the rewards you receive. A lower displayed commission is not automatically better: check whether the rate can change, whether the operator is reliable, and whether its history makes the headline rate meaningful. Read its current settings before you delegate.

What happens if my validator drops out of the active set?

If its total stake falls below the current active-set cutoff, it can remain registered but no longer take part in consensus. Your delegation does not automatically move elsewhere. Recheck the validator's status, then decide whether to wait, redelegate, or begin unbonding under current network rules. Do not assume a familiar validator stays active forever, because its position changes as other holders add or remove stake.

Can a validator see or take my CRO when I delegate?

Validators process public blockchain data, so they can see the transaction information that is recorded on-chain. They do not receive your recovery phrase or gain the ability to move wallet funds just because you delegate to them. A request for a seed phrase or remote wallet access is a separate security danger, not a normal part of delegation. Keep signing credentials private and use the official wallet flow to manage any staking action.

Do I have to wait for extra confirmations after a Cronos transfer?

First make sure the wallet or explorer marks the transaction as confirmed and the recipient sees the expected balance. A submitted transaction is not complete simply because the wallet popup closed. Once a Cronos block is committed, BFT finality means arbitrary extra mining-style confirmation counts do not offer the same kind of protection as they do on proof-of-work chains. If an exchange or app requests a specific confirmation workflow, follow that workflow.


Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Updated July 2026. Primary sources: the Cronos POS chain documentation, the crypto-org-chain project on GitHub, and the Cronos EVM documentation. All facts independently verified against cited documentation current as of July 2026.

This article is educational and general in nature, not financial or investment advice. Cryptocurrencies like CRO carry real risks, including price volatility, validator slashing, changes to network parameters through governance, smart-contract bugs, and the chance of losing funds sent on the wrong network. Nothing here is a recommendation to buy, sell, stake, or hold any asset. Do your own research, and consider a licensed professional before making financial decisions. BloFin does not provide investment advice.