How Solana confirms a block

One validator at a time is the leader. It orders transactions against a hash clock, streams the block out in pieces, and the rest vote with their stake. A new block every 250 ms.

Read how it works

Click a step on the right, or use the arrow keys, to jump to it. Hover a validator to see its stake.

Just confirmed

    transaction on its way to the leader ordered by the leader, in the block shred (a piece of the block) vote, then confirmed block shredded out by the leader vote landed in the block included but failed, fee still paid the slot leader
    What each block holds, by share Waiting for the first sampled block
    How this is counted

    Each transaction is sorted by the programs it names. Votes are the validators' own Tower BFT votes. Trading covers Jupiter, Raydium, Orca, Meteora, Pump.fun, Phoenix, Drift and similar programs, even when the same transaction also moves tokens. Tokens covers transfers and account setup with the Token programs. System is a plain SOL transfer or account creation. Anything else is Other. Program names are matched from a fixed list, so a new exchange shows as Other.

      Transaction types in each sampled block since you connected
      SlotTransactions per type
      Transactions per block Waiting for the first block
      • succeeded
      • failed (fee still paid)
      • before you connected

      Use the left and right arrow keys to read each block's count.

      Transactions in each recent block
      SlotTransactionsSucceededFailedProduced
      Recent blocks 0 tx waiting for the leader slot 0 0.000000 SOL burned 0 % of stake voted

        The parts that make this work

        Proof of History

        Every validator runs the same hash function, SHA-256, in a loop: each output is the next input. Because the work cannot be parallelised, the number of hashes is a clock that anyone can verify. A leader mixes transactions into its loop, so the block itself proves what happened before what and roughly when. Proof of History is not consensus. It is the timekeeping that lets consensus run without validators first agreeing on a clock.

        Leaders and the schedule

        Before each epoch of 432,000 slots, about 30 hours at 250 ms a slot, the network draws a leader schedule at random, weighted by stake. A leader holds four consecutive slots and produces one block per slot. Around 670 validators hold stake on mainnet, with a total of about 440 million SOL delegated. Since there is no fixed set, a validator's weight in everything, from leadership to votes, is the stake behind it.

        Turbine

        A block of a thousand transactions is too big to send to hundreds of validators one by one. The leader splits it into shreds of about 1,200 bytes, adds erasure coding so a validator can rebuild the block from a subset, and sends each shred to a first layer of validators. They forward it to the next layer, and so on, in a tree whose shape is reshuffled per shred and weighted by stake. Alpenglow's Rotor will replace this with a single relay layer.

        Tower BFT, and Alpenglow

        On mainnet today a vote is a transaction. Each validator votes for the block it sees at the head of the heaviest fork, and each vote comes with a lockout that doubles with every vote stacked on top, so backing out of a fork gets more expensive the longer you stay on it. A block is optimistically confirmed once two thirds of stake has voted for it, and rooted once 32 confirmed slots follow, about eight to thirteen seconds. Alpenglow, approved by validators in September 2025, replaces this with Votor: votes go directly between validators instead of on chain, and a block is finalized in one round with 80 % of stake or two rounds with 60 %, in roughly 150 ms. It was switched on for Solana's public testnet on 24 September 2026, and mainnet is scheduled to follow. The steps above show the Tower BFT path because that is what mainnet runs as this page is written.

        Confirmed and finalized

        Solana exposes three levels of certainty. A block is processed as soon as a node has replayed it, confirmed once at least two thirds of stake has voted for it, and finalized once it is a root. Exchanges and wallets usually act on confirmed, a second or so after the slot, and settle on finalized. A confirmed block has never been reverted on mainnet, but only finalized carries that as a protocol guarantee.

        What a transaction costs

        The base fee is 5,000 lamports per signature, which is 0.000005 SOL. Half is burned and half goes to the leader that included the transaction. A transaction can add a priority fee, set through the compute budget program as a price per compute unit, which all goes to the leader and is what gets you into a busy block first. Failed transactions still pay, which is why the charts above split them out.

        What live mode shows

        Live mode subscribes to a public RPC server over WebSocket for the current slot, its parent and the newest root, and asks over HTTP for the leader schedule, the stake behind every validator, and one full confirmed block every 1.5 seconds. Solana produces four blocks a second, so the bars are a sample of blocks, not every one; the rate in the chart caption comes from the server's own 60-second performance samples. The validators on screen are the top of the real stake list, sized by stake, and the gold ring is the real leader for the slot being shown. Shred fan-out is drawn on schedule because nodes do not publish it. The votes are real: each sampled block carries the vote transactions that landed in it, and the beams come from the validators that sent them. Signatures, fees, slots, hashes and the failed count are all from the block.

        What the animation simplifies

        Real slots overlap: the leader is shredding out one block while validators are still voting on the last few, and the vote for a block travels inside a later block. The step-by-step view runs one block at a time and shows a root after four blocks instead of 32. Forks, skipped slots, and the switching-fork rules of Tower BFT are left out. The full protocol is described in the Tower BFT documentation from Anza, which maintains the Agave validator client.