Solana achieves fast, cheap transactions through a combination of technical choices, including a unique timing mechanism and processing transactions in parallel, that let it handle far more throughput than many other blockchains, part of Solana's core design. Solana's own write-up of Proof of History explains the timing mechanism behind the throughput.
Proof of History
Solana uses a mechanism called Proof of History, which timestamps transactions before consensus, letting validators agree on ordering more quickly than networks that must establish timing through consensus alone.
The problem it solves is less obvious than it sounds, and it is the reason Solana is fast at all. Computers on a network do not share a clock, and cannot trust each other's clocks, so agreeing on what happened first normally requires a conversation: validators exchange messages, compare notes, and converge. That conversation is most of what takes time on other chains.
Proof of History removes the conversation by building a clock nobody has to trust. A validator repeatedly hashes its own output, over and over, in a sequence that cannot be parallelized or skipped ahead. Because each step must follow the last, the length of the chain is itself proof that time passed, and stamping a transaction into that sequence proves it existed at that point. Ordering stops being something to negotiate and becomes something to verify, which lets consensus start from an agreed sequence rather than establishing one.
The name is genuinely misleading and causes endless confusion: Proof of History is not a consensus mechanism and does not replace one. Solana still runs Proof of Stake for consensus. Proof of History is a clock bolted onto it, and the speed comes from the two working together.
Parallelization
Solana can process many non-conflicting transactions simultaneously rather than strictly one after another, significantly increasing overall throughput compared to fully sequential processing.
Ethereum executes transactions one at a time, in order, because any transaction might touch any part of the state and there is no way to know in advance. That is a considerable amount of idle hardware. Solana requires every transaction to declare upfront exactly which accounts it will read and write, which is why Solana transactions look more complicated under the hood. Once the network knows what each one touches, it can see that two transactions between unrelated parties cannot possibly interfere, and run them at the same time.
The gain is roughly the number of cores you can throw at it, which is also where the cost hides: the validator hardware needed to keep up is substantial, and pushing it hard is what has historically made the network fragile under load.
A third choice belongs alongside those two, and it is the least discussed. Solana does not wait for a block to be complete before passing transactions along; validators stream them continuously to the next leaders in the rotation, so the network is always working rather than pausing between blocks. Combined with a leader schedule that is known in advance, thanks to the same timing mechanism, there is no per-block negotiation about who goes next. Most of the latency other chains carry comes from waiting and coordinating, and Solana's design is largely an exercise in deleting both.
Fee model
Because the network can handle high transaction volume, individual fees stay extremely low, typically fractions of a cent, even during periods of meaningful network activity.
The design choice underneath is that Solana charges a small flat fee per signature rather than auctioning scarce block space to the highest bidder. Where Ethereum's fee is explicitly a market for a deliberately limited resource, Solana's is closer to a fixed toll, on the theory that capacity should be abundant enough that rationing is unnecessary.
That works until it does not. When demand genuinely exceeds capacity, a flat fee has no way to prioritize, so the network fills with retries instead of pricing them out, which is precisely what happened during Solana's worst congestion episodes. Priority fees were added to give urgent transactions a way to bid, which is a partial reintroduction of the thing the flat model was avoiding. The tension between abundant-and-cheap and priced-and-orderly is not fully resolved.
Trade-offs
This performance comes with trade-offs: Solana's architecture is more complex to run, has led to past network stability issues, and has a shorter track record than older, more conservatively designed chains. We set Solana and Ethereum against each other in more detail separately.
Stated bluntly, the speed is bought with hardware requirements, and hardware requirements are a decentralization cost. Fewer people can afford to validate, so validation concentrates among professional operators, and the network's resilience depends on a smaller set of participants than a design with humbler requirements would need. Whether that is an acceptable price is the entire argument, and reasonable people land on both sides.
What is not in dispute is that the engineering is real. Proof of History and parallel execution are genuine contributions, not marketing, and they made a category of application possible that simply could not run on an expensive chain. Solana is a bet that most users want speed and cost more than they want maximal decentralization, and so far a great many users have agreed.
It is also worth noting what the speed does not buy you, since the marketing rarely draws the line. Fast confirmation is not the same as strong settlement assurance: a transaction that finalizes in a second on a network with a smaller validator set is not more final than one that takes a minute on a network with a larger one, whatever the stopwatch says. Speed is a user-experience property. Security is a function of how much it would cost to overturn the result, and those are different questions that the word "fast" tends to blur together.