On-Chain Randomness on Solana: Predictability, Manipulation & Safer Alternatives (Part 1)

Randomness is a foundational building block for games, auctions, lotteries, and dynamic NFTs but generating it securely on-chain, especially on a fast, deterministic chain like Solana, is far from straightforward. In this two-part series, we dissect the available randomness sources on Solana and examine which ones are safe to trust, when, and why. In Part 1, we focus on native sysvars and third-party RNG protocols currently live on mainnet.

Randomness From The Chain

Generating true randomness on Solana presents a fundamental challenge: All validators must produce identical results to maintain consensus. This reproducibility requirement prevents programs from accessing local entropy sources, as other nodes couldn't verify that values were generated fairly.

SlotHashes Sysvar

The SlotHashes Sysvar stores 32-byte hashes from Solana's Proof-of-History mechanism for each slot. Programs can access this data by including the SysvarSlotHashes111111111111111111111111111111 account and parsing its data.

The sysvar holds up to 150 entries. However, the issue with using these hashes is that their value is entirely deterministic and computed with values that can be manipulated through transaction content, ordering, and metadata modifications.

Clock Sysvar

The Clock Sysvar provides the current slot number and Unix timestamp. Developers often combine recent slot hashes with timestamps to seed randomness. Metaplex's Candy Machine v2, for instance, used the difference between the last slot hash and clock time for NFT mint ordering. But as with slot hashes, this value can be easily skewed by validators.

Limitations and Security

Using blockhashes or slot hashes for randomness is insecure because block leaders can influence them. Validators could withhold a block until the hash is favorable, or insert transactions to bias a future hash.

In practice, any randomness derived solely from the latest slot hash can be predicted by miners/validators. For this reason, depending on the recent blockhash is extremely insecure. Likewise, even approaches that add a Verifiable Delay Function (VDF) on top of the blockhash still note that users who know the last block hash could pre-compute the outcome and only submit when it favors them.

In short, native on-chain randomness is available via sysvars but is predictable/manipulable. It should never be used alone when security or value is at stake.

Live RNG-as-a-Service Protocols on Solana

Several on-chain oracles offer verifiable or trustworthy randomness as a service on Solana.

Switchboard VRF (v2)

A verifiable random function oracle network. Developers create a VRF account and submit a request; off-chain oracles compute a VRF signature and post the result back on-chain. Switchboard VRF provides a proof that the value was random. It has been replaced by their v3 service.

Program ID: SW1TCH7qEPTdLsDHRgPuMQjbQxKdH2aBStViMFnt64f

Switchboard Randomness Service (SRS, v3)

A newer service using Intel SGX enclaves for randomness. SRS is designed for single-transaction requests: your program invokes the simple_randomness_v1 instruction with a callback. Switchboard's oracle enclaves generate random bytes and immediately invoke your callback in the same transaction. This "trusted execution" approach cuts latency and costs compared to v2.

Program ID: RANDMo5gFnqnXJW5Z52KNmd24sAo95KAd5VbiCtq5Rh

ORAO VRF

A multi-node VRF oracle from ORAO Network. Developers use ORAO's SDK to request randomness via a CPI call. ORAO VRF produces a random output with proof. The base VRF fee is 0.001 SOL. ORAO advertises sub-second fulfillment times and "Byzantine Quorum" security.

Program ID: VRFzZoJdhFWL8rkvu87LpKM3RbcVezpMEc6X5GVDr7y

Pyth Entropy

Provides on-chain randomness via a two-party commit–reveal protocol. A Pyth provider commits a long hash-chain of random values ahead of time, then mixes one revealed value with the current blockhash to produce the output. Note: the Entropy service is for now only available on EVM chains.

Comparing the Options

Up Next

In Part 2, we will go through the pros and risks behind RNG-as-a-service methods on Solana. We will break down the tradeoffs between verifiability, latency, trust models, and implementation complexity to help you make informed decisions for secure randomness integration.

Stay tuned for more deep dives, real-world bugs, and smart contract best practices.

Follow @AdevarLabs on X / LinkedIn - Ship Safely.