Every crypto wallet has the same button. The networks behind it ask you to trust very different things.
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 normally validates a ledger in roughly 3 to 5 seconds.
- 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. A block is described as irreversible after the producer and 18 different later representatives have acknowledged it, roughly 54 seconds with uninterrupted slots.
- 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 following asset values use a market snapshot taken at 16:54 UTC on 4 September 2026. They will move with prices.
Ethereum
Anyone can run an Ethereum node without staking. Solo validation is different.
The minimum stake is 32 ETH, worth about $78,762 (£58,252) in the snapshot. 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. At the snapshot price, that is about $112 per day, or $40,933 per year, before server costs.
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. That was about $1.44 million (£1.07 million) at the snapshot price.
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 9,999 TRX, about $3,306 (£2,445) at the snapshot price.
The fee only buys candidacy. Votes choose the top 27 block producers every six hours.
TRON recommends 32 CPU cores, 64 GB RAM, at least 3.5 TB of SSD storage and 100 Mbps bandwidth for a block-producing Super Representative. 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.
Ripple and the XRP Ledger Foundation each decide which validators appear on the lists they publish. Their typical criteria include at least a year of high uptime and agreement with the network, domain verification, an independently identifiable operator and a physical location that does not duplicate too many existing validators. A list publisher may also interview the operator. Inclusion makes other servers more likely to trust that validator, but it does not create the validator or give it permission to run.
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 low-latency node guidance starts at 32 logical CPU cores, 128 GB RAM and 500 MB/s disk throughput. 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 and does not depend on being elected to a committee. The recommended minimum for a pruned 10-block-per-second node is 8 CPU cores, 16 GB RAM, a 256 GB SSD and roughly 40 Mbit/s bandwidth. The preferred configuration is 12 to 16 cores, 32 GB RAM and a 512 GB SSD.
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. A recent official testnet restart guide makes the mechanism visible: validators load an agreed snapshot and wait for 80 percent of activated stake to appear before block production resumes.
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 and needs acknowledgment from 19 for irreversible blocks. The same narrow political layer can alter chain parameters when 18 approve a proposal.
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.
In a deliberately extreme case where an attacker already controls 45% of the entire network hashrate, the upper bound for a successful reversal is about 13% after ten confirmations, reached in roughly two to three seconds. After roughly ten seconds, it falls to about 0.0000002%. Against a smaller attacker, it falls much faster.
This is why a Kaspa payment can look instant and become extremely secure within seconds, even though proof-of-work confidence remains probabilistic. The separate 12-hour finality point is a deep consensus safety boundary, not the normal waiting time for a payment.
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.
Kaspa is not the fastest possible database (maybe it is), the cheapest possible server (maybe it is), or the only decentralized network (maybe it is). 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.
