Skip to main content

Solana Clusters

A Solana cluster is a set of independently owned computers working together to verify the output of user-submitted programs. A Solana cluster can be utilized any time a user wants to preserve an immutable record of events in time or programmatic interpretations of those events.

It can also be argued that a Solana cluster is a set of validators that serve client transactions and maintain the integrity of the registry. Solana maintains several different clusters with different purposes.

Two or more clusters can coexist if they have a common genesis block. Otherwise, they simply ignore the existence of the other. Transactions sent to the wrong address are rejected.


Solana maintains dedicated API nodes to fulfill JSON-RPC requests for each public cluster, and third parties may as well. Here are the public RPC endpoints currently available and recommended for each public cluster:

  • Devnet endpoint — single Solana-hosted API node; rate-limited.
    Devnet serves as a playground for anyone who wants to take Solana for a test drive as a user, token holder, app developer, or validator. Tokens are not real.
  • Testnet endpoint — single Solana-hosted API node; rate-limited.
    Testnet is used to stress-test recent release features on a live cluster, with particular focus on network performance, stability, and validator behavior. Tokens are not real.
  • Mainnet Beta endpoints — Solana-hosted API node cluster backed by a load balancer; rate-limited. — Project Serum-hosted API node.
    This is a permissionless, persistent cluster for early token holders and launch partners. Tokens are real SOL.


Fast, reliable synchronization is one of the main challenges for achieving high throughput. Traditional blockchains synchronize on large chunks of transactions called blocks. As a consensus algorithm, they use Proof-of-Work or Proof-of-Stake.
Unlike traditional synchronization methods, Solana takes a complete approach, which it calls Proof-of-History. Solana uses an optimistic method of processing blocks. (It was introduced in 1981 and is called Optimistic Concurrency Control.)
The peculiarity of this method is that Solana technically never sends a block, but uses the term to describe the sequence of entries that validators vote on to achieve confirmation. By processing the transactions optimistically, there is effectively no delay between the time the last entry is received and the time when the node can vote. In the event consensus is not achieved, a node simply rolls back its state.

More details
A Solana cluster
Solana clusters
Solana cluster RPC endpoints