Comparing chains by transactions per second is like comparing cars by top speed and ignoring whether they have brakes. Speed is not an achievement, it is a purchase, and every network that has it paid for it with something specific. Knowing what was paid tells you far more than the number does.
A distributed ledger is not slow because nobody optimised it. It is slow because every participant has to receive every transaction, check it independently, and arrive at the same conclusion as everybody else, across a network where messages take time to travel and some participants are hostile.
That constraint sets the floor. If a thousand independent machines scattered across the world must all agree before a transaction is final, the speed of agreement is bounded by how long it takes information to reach the slowest of them. Every design that goes faster has changed one of the terms in that sentence, and the interesting question is always which one.
Nobody made a chain fast by writing better code. They made it fast by requiring fewer participants, weaker guarantees, or more expensive hardware.
The choices are not unlimited. There are essentially three levers, and every fast chain has pulled at least one of them.
Fewer validators means less communication and faster agreement. It also means a smaller set of parties who would have to collude, be compromised, or be compelled by the same authority. This is the most common lever and the one most often left out of the marketing.
Requiring high-specification hardware and very fast connections raises throughput because each node can process more. It also raises the price of joining, which concentrates validation among those who can afford it and makes the network progressively less open over time even though nothing formally excludes anybody.
Some chains treat a transaction as settled almost immediately and accept that a rare reorganisation can undo it. Others make reversal economically catastrophic but take longer to reach that state. Both are defensible; only one of them lets you advertise sub-second confirmation.
Bitcoin produces a block roughly every ten minutes and treats confirmation as probabilistic: each additional block makes reversal more expensive, and no block ever makes it strictly impossible. This is frequently presented as an outdated design that newer chains have surpassed.
It is more accurate to describe it as a different purchase. The ten-minute interval means a node running on modest hardware anywhere in the world, on an ordinary connection, can keep up and verify everything independently. That property is the entire point, and it is what a chain gives up when it requires a data-centre connection to participate.
Whether that trade is worth making depends on what the chain is for. For a settlement layer where the cost of a reversal is enormous and transactions are infrequent and large, slow and independently verifiable is the right answer. For an application where somebody is waiting at a screen, it is not.
The techniques differ and they all reduce to the same three levers.
Solana processes transactions that do not touch the same state simultaneously rather than one after another, and overlaps the stages of block production instead of running them in sequence. This is genuine engineering rather than a trade-off, and it is paid for by validator hardware requirements far above what an ordinary machine can meet.
Rollups execute transactions elsewhere and post compressed results to Ethereum, which verifies them. Throughput rises because the expensive part happens once for a batch. The cost is a new set of assumptions: about who sequences the transactions, about the correctness of the proof or the challenge process, and about whether you can exit if the operator stops cooperating.
Some networks reach agreement quickly because only a few dozen parties participate in it, often ones that had to be approved. The performance is real and the property being sacrificed is the one that made the technology interesting: that no identifiable group can be compelled to act together.
The number every project publishes is how many nodes or validators exist, and it is close to meaningless on its own. A network with ten thousand validators where nine thousand run the same software on the same hosting provider in the same jurisdiction is more fragile than one with two hundred spread across independent implementations and countries. The count is easy to produce and easy to inflate; the distribution is what determines whether a single failure takes the network with it.
Three distributions are worth more than the headline. Client diversity, meaning how many independent implementations of the software are in use: if one implementation runs the overwhelming majority, a defect in it is a defect in the whole network, and this has produced real outages on real chains. Hosting concentration, meaning how many validators sit inside the same handful of cloud providers, because a provider's outage or policy decision then removes a large fraction of the network at once. And stake or hash concentration, meaning how few parties would have to act together to control the outcome.
All three are published or measurable, and all three are routinely omitted from comparisons in favour of the node count. That omission is not accidental: they are the numbers on which fast chains do worst, because the levers that buy speed are precisely the ones that concentrate participation.
This gives a more useful question than how decentralised is it, which nobody can answer. Ask instead how many independent decisions would have to go the same way for this network to stop or to reverse something. That number is small enough to state, it varies by more than an order of magnitude between networks that describe themselves identically, and it is the quantity that the word decentralisation is standing in for.
Most of this is architecture, and architecture matters to a trader only where it touches money moving. Four places do.
How long capital is in transit between venues determines whether you can act on a price difference and how much of the day your funds are unavailable. This is the most direct effect and it is the one people underestimate, because it costs opportunity rather than fees.
Cheap chains are cheap when nobody is using them. What matters is the fee during the exact hours you would want to transact, which are the busy ones. A chain with a low advertised fee and no mechanism for handling congestion becomes unusable at the moment it is needed.
Several high-throughput networks have halted entirely and required coordinated restarts. A halt is not a slow transaction, it is no transactions, and it happens during periods of extreme activity, which is when positions need to move. This risk does not appear in any performance comparison.
The chain's finality and the platform's crediting policy are different things. A venue may wait considerably longer than the protocol requires, and that waiting period is what you actually experience regardless of what the chain can do.
Transactions per second is a laboratory number and it is almost always measured under conditions nobody trades in. The useful comparisons are dull and specific: what a transfer cost during the busiest hour of last month, how long the network has been continuously available, how many independent parties would have to agree to reverse something, and what happens to your funds if the operator of the layer you are on stops responding.
All four are answerable, none of them appear in a throughput chart, and together they describe the thing you are actually exposed to. A chain that is slower on paper and has never stopped is a different proposition from one that is faster on paper and has halted twice.
Ask what the chain does on its worst day, not its best. Throughput is measured on the best day, and you will use it on both.
The vocabulary of layers suggests a hierarchy where the upper ones inherit the safety of the lower one. That inheritance is real and it is partial, and the part that is missing is where the risk lives.
A rollup posting to Ethereum inherits Ethereum's guarantee that the posted data cannot be altered. It does not automatically inherit a guarantee that the sequencer will include your transaction, that you can exit without the operator's cooperation, or that a bug in the bridging contract cannot be exploited. Those are properties of the specific implementation, they vary enormously between projects that use the same vocabulary, and they are where the losses have actually occurred.
The practical reading is that layer two is a category, not a rating. Two networks described identically can differ on whether an emergency exit exists, how long it takes, and who can stop it, and those differences matter far more than the throughput figures that get compared instead.
It is different, not better. Speed is bought with fewer validators, higher hardware requirements, or weaker finality guarantees. Which purchase is right depends on the use: a settlement layer for large infrequent transfers wants independent verifiability, an application with somebody waiting at a screen wants speed.
Because the interval is set so that a node on ordinary hardware and an ordinary connection, anywhere in the world, can keep up and verify everything independently. That property is the design goal. Shortening the interval would exclude those participants, which is exactly what faster chains do.
Throughput under test conditions, usually with simple transactions and healthy network conditions. It says nothing about fees during congestion, about whether the network has ever halted, or about how many parties would need to agree to reverse something. All three matter more to a trader.
Mainly by executing transactions that touch different state in parallel rather than sequentially, and by overlapping the stages of block production. That is real engineering. It is paid for with validator hardware and bandwidth requirements well above what an ordinary machine provides, which concentrates who can participate.
Partially, and the missing part is where the risk sits. They inherit the guarantee that posted data cannot be altered. They do not automatically inherit a guarantee that your transaction will be included, that you can exit without the operator, or that the bridging contract is free of defects. Those vary enormously between projects.
Several high-throughput networks have stopped entirely and needed coordinated restarts. A halt means no transactions rather than slow ones, and it tends to occur during extreme activity, which is when positions most need to move. No throughput comparison shows this.
Whichever one both venues support with the shortest crediting policy and a fee you can predict during busy hours. The chain's own finality is only half of it: the platform decides how many confirmations it waits for, and that waiting period is what you actually experience.
Low fees when nobody is using a network mean nothing. The number that matters is what a transfer cost during the busiest hour of the past month, because that is when you will want to move. A chain with no mechanism for pricing congestion becomes unusable exactly when it is needed. There is also a second-order effect that only shows up later: a chain that is cheap because it is subsidised, or because its fee market has never been tested at scale, is quoting a price that has not yet met the demand it is designed for. Judge the fee on a busy day, and judge it again a year later.