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. This constraint significantly complicates random number generation on-chain.
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 parse its data.
The sysvar holds up to 150 entries; in practice programs partially decode it to read only the newest 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; leaders could exploit it or use MEV techniques to skew outcomes.
Likewise, even approaches that add a Verifiable Delay Function (VDF) on top of the blockhash (e.g. the “Solrand” method) still note that users who know the last block hash could pre-compute the outcome and only submit when it favors them, giving them two possible outcomes.
In short, native on-chain randomness is available via sysvars but is predictable/manipulable. It should be mixed with other inputs with better randomness, otherwise this 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. These are implemented as on-chain programs (with some off-chain components), which are accessible to on-chain programs. The best-known protocols are:
- 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 (using a randomly-seeded counter + blockhash) and post the result back on-chain. Switchboard VRF provides a proof that the value was random. It is fairly widely used on mainnet, but has been replaced by their v3 service now.
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 (or off-chain client) 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. Developers must fundescrow during the instruction call to pay the oracle (which rewards the enclave operators).
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, and most on-chain cost comes from rent for the request account. 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. In practice, 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. They recently released a V2. While Pyth has price feed services on Solana, the Entropy service is for now only available on EVM chains.
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.
