Compare
Compare blockchains side by side.
Choose up to 4 of the 151 chains. Each is described on its own terms against the same fields, with sources for its key claims. There are no scores, rankings or winners, and anything the review did not establish is shown as unknown.
Your selection
Choose chains to begin.
Pick up to 4 chains from the list. Nothing is preselected, and the columns always appear in alphabetical order.
How to read a comparison
Design priorities (one school of thought)
One school of thought holds that blockchain designs trade between three priorities: keeping node operation open to ordinary users, resisting attacks, and processing more activity. In this view, raising base-layer throughput raises the cost of full verification, which narrows who can independently verify the chain, so capacity is better added in other layers. A counter-view holds that base-layer capacity can grow with hardware and bandwidth, that a stated protocol limit can be a real design parameter, that most users verify through light clients or proofs rather than full nodes, and that added layers bring their own trust assumptions. Each iKnow Blockchain profile states which priorities a design emphasizes and what it gives up, in words rather than a score; those fields use this school's framing.
Reading transactions-per-second claims (one school of thought)
A headline transactions-per-second figure is not comparable until it is classified. iKnow Blockchain records every speed figure as a theoretical peak, a lab benchmark or an observed window, with its hardware and bandwidth assumptions and whether a home full node could keep up, and never compares figures of different classes. The home-node question comes from one school of thought: raising base-layer throughput raises the cost of full verification, which narrows who can independently verify the chain, so a figure that ordinary nodes cannot follow is read with that cost in mind. A counter-view holds that base-layer capacity can grow with hardware and bandwidth, that a stated protocol limit can be a real design parameter, that most users verify through light clients or proofs, and that added layers bring their own trust assumptions.
Scaling families: rollups are not channels
Layer 2 is an overloaded term. Rollups execute transactions elsewhere and post data or proofs to a base layer. Payment and state channels (including application-specific state channels) keep activity between participants off-chain and use the base layer only to open, close or settle disputes. Sidechains run their own consensus behind a bridge. Saying a chain has no layer 2 must name which family is meant.
System classes: blockchains, rollups, sidechains and non-block ledgers
Not every system called a blockchain works the same way, so each iKnow Blockchain profile states a system class before comparing anything else. A blockchain L1 orders transactions into blocks under its own consensus and fork choice. A rollup L2 executes elsewhere but posts its data or proofs to an L1, so its safety leans on that L1 plus its own proof and upgrade system. A sidechain has its own validators and is only joined to another chain by a bridge, so it does not inherit that chain's security. A non-block ledger reaches agreement without miners or stakers competing to add blocks, for example through a directed graph of gossiped events or through voting rounds among trusted validators, so block-based measures such as block time, orphan rate or reorg depth may not apply.