The Numbers Crypto Networks Don’t Want to Compare

Every crypto wallet has the same button. The networks behind it ask you to trust very different things.

Editorial update — September 8, 2026: This revision checks node requirements against current official documentation and adds source links. Fiat conversions and numerical reversal probabilities were removed because the original article did not provide a verifiable basis for them.

Imagine sending £1,000 to someone you have never met.

You tap Send. A green tick appears. The payment looks finished.

It may only have reached one server. It may be sitting in a queue. It may be inside a block that can still disappear. Or a small group of validators may already have voted to lock it in.

The screen does not tell you which happened.

That is the first trick in almost every crypto speed comparison. “Instant” can describe the wallet, the arrival of a block, or the moment a payment becomes extremely difficult to reverse. Those are different events.

The more important question is usually hidden:

Who gets to decide that your payment is real, and what happens when those decision-makers stop agreeing?

The same Send button, three different bargains

Bitcoin, Kaspa and Dogecoin use proof of work. Miners compete using machines and electricity. Ordinary nodes independently reject blocks that break the rules.

Ethereum, Solana, BNB Smart Chain, TRON and Hyperliquid use stake or an elected validator set. Their speed comes partly from collecting votes from a known group instead of waiting for open mining competition.

XRP Ledger uses trusted validator lists chosen by each server operator. Most operators begin with lists published by Ripple or the XRP Ledger Foundation, although they can change them.

None of these designs is automatically honest or dishonest. Each moves the cost, power and failure points to a different place.

That is what a useful comparison should show.

What the clocks actually say

A block or slot time is not a universal settlement time.

Bitcoin targets one block every 600 seconds. Reversal becomes less likely as more proof of work follows it, but there is no fixed instant when the probability becomes zero.
Dogecoin targets one block every 60 seconds and also has probabilistic proof-of-work confirmation.
Ethereum has 12-second slots. Its stronger protocol finality works on a separate voting clock measured in epochs, not one slot.
Solana targets blocks around 400 milliseconds and exposes three confidence levels: processed, confirmed and finalized.
XRP Ledger documentation says ledger versions usually close about every 3 to 5 seconds; a transaction should be checked against a validated ledger. (XRP Ledger close-time documentation · XRP Ledger open, closed, and validated ledgers)
BNB Smart Chain now targets roughly 0.45-second blocks. Its documentation estimates fast finality around 1.125 seconds when at least two-thirds of its 45 active validators vote.
TRON assigns 3-second slots to 27 Super Representatives. Its documentation describes a block as solidified once at least 19 distinct active representatives have produced a block at that height or above on the same chain, typically in about one minute. (TRON consensus, block schedule and solidification)
Hyperliquid gives exchange actions one-block finality through HyperBFT. Its 200,000-orders-per-second figure concerns orders, cancellations, trades and liquidations, not ordinary payments.
Kaspa targets ten proof-of-work blocks each second. Confirmation remains probabilistic. Ten blocks per second does not mean mathematical finality in one tenth of a second.

The honest winner changes with the question.

A validator network can produce a hard voting result quickly. Bitcoin offers slower proof-of-work settlement with no validator committee. Kaspa keeps proof of work but allows blocks created at nearly the same moment to remain useful and be ordered together.

That last achievement is narrower than “fastest crypto”, but much more interesting.

The price of a seat at the table

Marketing often says that anyone can join a network. That can be technically true while becoming economically unrealistic.

There is also a difference between running a node and helping produce or finalize blocks. A node can check the rules without receiving a turn to write history.

The token amounts and hardware guidance below describe different participation roles. Dollar and pound conversions are omitted because the original price and exchange-rate observations are not linked. Hardware recommendations were checked against current documentation on 8 September 2026.

Ethereum

Anyone can run an Ethereum node without staking. Solo validation is different.

Activating a solo validator requires at least 32 ETH. (Ethereum home staking) Current Ethereum guidance recommends a 4 TB NVMe SSD, 64 GB RAM, a modern multi-core CPU, and about 50 Mbps download with 25 Mbps upload for solo staking.

That is accessible to a serious home operator, but the capital deposit is not pocket money. People with less ETH generally use a pool or provider, introducing another organization between them and direct protocol participation.

Ethereum also acknowledges the concentration risk created by large liquid-staking providers. A large token balance does not always mean one company runs every machine, but control over pooled stake still matters when votes determine finality.

Solana

Solana has no strict protocol minimum stake for starting a validator. The financial barrier appears elsewhere.

Current Agave documentation says voting can cost up to 1.1 SOL per day. The SOL amount is a documentation estimate of voting costs, separate from server costs and any delegated stake. (Agave validator requirements)

The recommended machine is substantial: 12 cores and 24 threads, 256 GB RAM, separate high-end NVMe storage with at least 1 TB for accounts, 1 TB for the ledger and 500 GB for snapshots, plus at least 2 Gbit/s symmetric connectivity for a staked validator. Ten-gigabit capacity is recommended for stable operation.

A validator can exist without much stake, but stake determines leader opportunities and rewards. In practice, hardware, recurring vote costs and attracting delegated stake all stand between “permissionless” and economically competitive.

BNB Smart Chain

Creating a BNB Smart Chain validator requires 2,000 BNB in self-delegation. This self-delegation requirement is separate from the total stake needed to enter the elected validator set. (BNB Smart Chain validator overview)

Paying that does not guarantee a permanent seat. The top validators by total stake and delegation form the active group, currently 45, with 21 Cabinet validators and 24 Candidates.

The official mainnet specification suggests an AWS i7i.8xlarge or i7ie.6xlarge class machine, 128 GB RAM, a 7 TB NVMe SSD capable of 40,000 IOPS and 500 MB/s, and at least 512 Mbps bandwidth.

This is fast finality purchased with a deliberately limited and capital-heavy validator set.

TRON

Anyone can apply to become a TRON Super Representative candidate by paying the one-time 9,999 TRX candidacy fee. (TRON Super Representative candidacy)

The fee only buys candidacy. Votes choose the top 27 block producers every six hours.

TRON currently recommends 32 CPU cores, 64 GB RAM, 3 TB or more of SSD storage and 100 Mbps bandwidth for a block-producing Super Representative. (TRON node deployment requirements) Those 27 accounts do more than produce blocks. Eighteen approvals are enough to pass a proposal changing network parameters, with the change taking effect at the next maintenance period.

XRP Ledger

Running an XRP Ledger validator requires no XRP deposit. Its recommended production machine is still server-grade: 8 or more CPU cores at 3 GHz or faster, 64 GB RAM, sustained 10,000-IOPS SSD or NVMe storage, and a gigabit data-centre network.

No foundation approval is required to start validating. Anyone can run xrpld, generate validator keys and broadcast validations. Those validations influence only the servers that choose to trust that validator. Approval becomes relevant if the operator wants inclusion in a widely used recommended list.

Recommended-list publishers choose the validators they include. Inclusion can make a validator more likely to be trusted by servers using that list, but it is not permission to start a validator. Operators select their trusted validators and need compatible trust assumptions to remain in agreement with their peers. (XRP Ledger consensus and validator FAQ)

The deeper cost is trust selection. Each server chooses a Unique Node List. Ripple and the XRP Ledger Foundation publish the two commonly used defaults. Operators may reject those lists, but they need enough overlap with the rest of the network to avoid following a different ledger.

Hyperliquid

Hyperliquid says running a validating or non-validating node is permissionless, but only the top 27 validators by stake enter the active set.

Its current node guide specifies 32 vCPUs, 128 GB RAM and a 1 TB SSD for a validator; it lists a separate non-validator profile. (Hyperliquid node machine specifications) There is no honest fixed dollar entry price for the active set because the stake needed to remain in the top 27 moves with delegation.

Kaspa

Running a Kaspa validation node requires no token deposit or committee election. The current Toccata operator guide lists a minimum of 8 CPU cores, 16 GB RAM, a 640 GB SSD and about 80 Mbit/s bandwidth. Its preferred profile is 12–16 cores, 32 GB RAM and a 1 TB SSD. These are node-operation recommendations; mining has separate hardware and electricity costs. (Kaspa Toccata node setup guide)

But this needs the same honest distinction applied everywhere else: running a Kaspa node is not mining. Producing blocks requires proof-of-work hardware and electricity, and profitable mining is competitive. Kaspa removes the validator stake gate, not the economic cost of mining.

Can a network be stopped?

No serious decentralized network should have a single Stop button. That does not mean every network is equally difficult to halt.

What happened on Solana

Solana provides the clearest real-world example because this is not theoretical.

On 6 February 2024, Mainnet-Beta stopped producing blocks for almost five hours. The official incident record says engineers prepared validator software version 1.17.20, validator operators upgraded, and the cluster restarted.

No lone employee resumed the chain. Recovery required operators controlling enough stake to converge on the same software, snapshot and restart point.

That is still coordinated human recovery. Core engineering teams diagnose the fault and publish instructions. Validator operators decide whether to run the proposed fix. The February 2024 incident report documents coordinated restart instructions and an agreed snapshot point. It is evidence of recovery for that incident, rather than a universal statement about every future restart. (Solana 6 February 2024 outage report)

So can Solana be stopped?

One ordinary validator cannot stop it. A sufficiently large loss of voting stake, a consensus failure or a shared software bug can halt progress. Restarting after a serious failure is not automatic. It depends on engineers producing a credible recovery path and enough validator stake accepting it.

The newest consensus proposal makes this debate even sharper. Alpenglow is still marked “Review”, not live mainnet. Its own proposal says current TowerBFT has 12.8-second consensus finality and “does not have a security proof, which is concerning.” Alpenglow proposes one-round finalization with 80 percent of stake, a two-round path with 60 percent, and an initial cap admitting only the 2,000 highest-staked validators. Those are proposed rules, not current Solana performance.

Ethereum can continue without finalizing

Ethereum requires two-thirds of stake to finalize checkpoints. If more than one-third stops voting, finality stops even though the chain may continue producing blocks.

The recovery mechanism is built into the protocol. An inactivity leak gradually reduces the balances of offline validators until online stake again represents two-thirds. There is no company switch that restores finality immediately.

This is a useful difference between “the chain is still making blocks” and “the chain is finalizing”. A wallet can keep moving while the strongest guarantee has paused.

Small sets concentrate coordination

BNB Smart Chain needs votes from 30 of its 45 active validators for its documented fast-finality path. Without enough fast-finality votes, it falls back to probabilistic finality. If enough block producers disappear, production itself can stall.

TRON rotates block production among 27 elected representatives. Solidification requires at least 19 distinct active representatives to have produced a block at or above the relevant height on the same chain. This elected group can also change network parameters when 18 approve a proposal. (TRON consensus, block schedule and solidification · TRON committee and proposals)

Hyperliquid limits active consensus to the top 27 by stake. That helps deliver very fast exchange finality. It also means the live decision-making group is small enough to name and count.

These systems do not give one operator magical unilateral control. They do make coordinated action among a few dozen entities sufficient to affect liveness or governance.

XRP Ledger chooses safety over movement

XRP Ledger documentation is unusually direct: if more than 20 percent of trusted validators do not agree with the majority, the network can temporarily halt rather than risk a double spend.

Recovery may require participants to reconfigure their trusted validator lists around parties that can reach consensus. Ripple cannot force every operator to accept a list, but Ripple and the XRP Ledger Foundation have meaningful influence because many operators use their published defaults.

Proof of work has a different failure mode

Bitcoin, Dogecoin and Kaspa do not wait for a named validator supermajority. Miners produce blocks and independent nodes enforce the rules they have chosen to run.

A developer cannot halt those networks by sending an instruction. A software release cannot force already-running nodes or miners to adopt it. If most hash power disappears, blocks slow or stop until mining returns or difficulty adjusts under the existing rules. A severe software failure can still require public coordination, but recovery is acceptance of new software across miners, exchanges, wallets and node operators, not a vote by a fixed committee.

This does not make proof of work free from concentration. Mining equipment, cheap energy and pools create their own centres of influence. The difference is where the gate sits: physical competition for work rather than membership in a stake-weighted finality group.

What Kaspa actually changed

Bitcoin's history is built as one chain. If valid blocks arrive together, one branch eventually wins and the other loses its place in the accepted history.

Kaspa keeps the blocks in a graph and produces one agreed order from work that arrived concurrently. This is why Kaspa can target ten proof-of-work blocks per second without replacing miners with a validator committee.

Kaspa targets a new block every 100 milliseconds, so a payment can receive its first confirmation almost immediately. Reversing it is not a matter of editing that transaction. An attacker would have to create a competing history with enough proof of work to overtake the history being built by honest miners, then keep winning that race as new blocks arrive.

Kaspa confirmation is probabilistic. An assessment of reversal risk must specify the attacker’s share of hash power, the adversarial and network model, and the amount of subsequent accepted work. A block-rate target alone does not establish a reversal probability or a universal safe waiting time. The protocol’s finality and pruning parameters are separate from the confirmation policy a wallet or exchange chooses. (Kaspa block-rate and pruning-depth configuration · Kaspa pruning-point proof validation)

High-rate proof of work no longer has to throw away honest blocks merely because the network received them at nearly the same time. Confirmation evidence arrives in smaller, faster steps.

That distinction matters because most fast networks changed the people who agree. Kaspa changed how proof-of-work history is organized.

Crescendo moved Kaspa mainnet from one block per second to ten on 5 May 2025. The network has operated at that rate while an ordinary pruned validation node remains within the published specification above.

That comparison must stay honest. A Kaspa validation node checks the rules, while a Solana or BNB Smart Chain validator also participates in block production and voting. They are not equal jobs. Kaspa mining is the closer economic comparison, and it has no fixed entry price because equipment, electricity and competition continually change.

Ten blocks per second naturally create more networking and processing work than Bitcoin's ten-minute rhythm. Kaspa answers the growth of history with pruning: ordinary nodes discard old block history while retaining the data needed to validate the current state. Keeping the complete historical record is a separate archival role, not a burden placed on every user.

Mining can still concentrate around efficient hardware and cheap energy, just as it can on other proof-of-work networks. Kaspa confirmation also remains probabilistic, so certainty strengthens over time rather than arriving through one committee vote. DAGKnight may improve this model further, but it remains future work until it is running on mainnet.

But the core result is already live.

The comparison here concerns consensus design and participation requirements; it does not establish a universal speed, cost or decentralization winner. (Kaspa block-rate and pruning-depth configuration) It is the network in this comparison that combines open proof-of-work block production, no validator voting committee and ten blocks per second, while allowing users to verify the rules on a consumer-class minimum node.

That combination is the argument.

Not the green tick. Not a laboratory TPS score. Not a claim that probability has disappeared.

When someone says a crypto network is fast, ask two more questions:

Who must agree?

What happens when they do not?

The answers reveal more than the stopwatch.

Sources and methodology

This comparison uses official protocol documentation, implementation sources and operator guidance checked on 8 September 2026. Hardware recommendations apply to the node roles identified in the article. Block intervals, finality, throughput and operating costs measure different things; they are not interchangeable benchmarks. Proposed upgrades are identified separately from deployed behavior.

The Numbers Crypto Networks Don’t Want to Compare

The same Send button, three different bargains

What the clocks actually say