Comparison
Four ways to get randomness on Solana today: Alea, ORAO VRF, Switchboard On-Demand, or a DIY commit-reveal. Here’s where each wins and where each loses.
Last reviewed: 2026-04-20. Competitor pricing, trust models, and integration footprints change — check each project’s own docs before sizing your budget.
The shapes at a glance
Section titled “The shapes at a glance”| Option | Cost | Latency | CU | Tx count | Per-caller unique? | Who you trust |
|---|---|---|---|---|---|---|
| Alea | tx fee | 3s | ~407K | 1 CPI | No | No one |
| ORAO VRF | tx + ORAO fee | 1–3s | Callback only | 2 | Yes | ORAO |
| Switchboard | tx + oracle fee | 1–3s | Varies | 2 | Yes | Switchboard + TEE |
| DIY commit-reveal | tx only | Your window | Your code | 2+ | Yes | Your committers |
Per-caller unique is the axis that decides most of the choice. Alea gives every caller of round N the same 32 bytes. ORAO and Switchboard give each request its own unpredictable value bound to caller context. Different tools for different jobs.
When to pick Alea
Section titled “When to pick Alea”Alea fits when all three of these are acceptable: the only cost you want to pay is a Solana transaction fee, you don’t need each caller to get a distinct random value, and drand’s trust assumption (a threshold of the League of Entropy federation must not collude) is within your threat model. That’s a narrow shape — one transaction end-to-end, no keeper, no per-draw service fee — but common enough to matter.
Concrete fits: periodic lotteries where every participant sees the same draw. Validator rotation seeds. NFT trait reveals anchored to a future round and revealed on publish. Cross-chain games where Ethereum and Solana consumers need to agree on the same value. Public-good randomness as a CPI dependency with no token to buy.
When NOT to pick Alea
Section titled “When NOT to pick Alea”If you need per-caller unique randomness (each user’s draw gets its own unpredictable value bound to their context), use ORAO VRF. Alea’s shape is “one beacon per round, shared across all callers.” A raffle where every user draws in isolation needs a different primitive. Drand beacons don’t bind to caller state.
Sub-second latency is also wrong for Alea. Drand’s cadence is 3 seconds and Alea inherits that period. If randomness must resolve within the same user-request cycle, use an oracle network with lower latency or a commit-reveal with short windows.
Alea also won’t give you private randomness. Drand beacons are public the moment they’re signed — anyone watching the chain sees the same bytes you do. Note: none of the options on this page provide private randomness on-chain. VRF outputs (ORAO, Switchboard) are public once fulfilled too. For private-to-caller randomness, use MPC or FHE constructions, not any randomness-on-Solana primitive.
If you can’t tolerate the drand trust assumption — that the threshold of the 15-org federation won’t collude — no drand-based verifier fits. That’s the floor Alea sits on.
What Alea’s doing that’s worse than the alternatives
Section titled “What Alea’s doing that’s worse than the alternatives”Not on mainnet yet. ORAO and Switchboard have been in production on Solana for years with a track record of shipped integrations; Alea is devnet-only today, with mainnet deploy next and no external audit behind it. If production maturity is your first filter, you’re not ready for Alea.
Higher per-verify CU cost. Alea burns ~407K CU per verify — heavier than ORAO’s callback path, which matters for transactions that are already bumping against CU limits.
A fixed 3-second cadence is inherited from drand, not a knob to turn. You also get one person maintaining this as a public good, not a team with support channels and SLAs — responses are best-effort. And the testing claims (fuzz, cross-verification, reproducible build) all live in the repo; what’s missing from them is an external audit. See Testing & guarantees for the full disclosure.
If any of these rule Alea out, one of the tools below will fit better.
The alternatives, in more detail
Section titled “The alternatives, in more detail”ORAO VRF — per-caller unique randomness
Section titled “ORAO VRF — per-caller unique randomness”ORAO is a VRF that produces a random output bound to the caller’s request context, with the VRF proof verified on-chain. Two transactions (request + callback). Live on Solana mainnet since 2022 with a catalog of existing integrations — on-chain games, loot boxes, per-user NFT reveals, raffles, giveaways.
Pick ORAO over Alea when you need per-caller unique randomness and want production-proven infrastructure. Read their own docs for the current trust-model details; the on-chain VRF proof check is the load-bearing piece of their security story.
Switchboard On-Demand randomness — oracle-service trust
Section titled “Switchboard On-Demand randomness — oracle-service trust”Switchboard’s On-Demand randomness product uses their oracle infrastructure with TEE-attested outputs. Total cost is the Solana tx fee plus an oracle fee. Read their docs for the current trust-model details; the specifics of how the TEE attestation is verified on-chain are where the real security story lives.
Pick Switchboard when you’re already running Switchboard feeds (price oracles, custom functions), want per-request uniqueness, and the TEE-attested oracle model fits your threat model.
Commit-reveal (DIY) — zero direct service cost, coordinator required
Section titled “Commit-reveal (DIY) — zero direct service cost, coordinator required”Users, or a coordinator, commit to a hash before the draw, then reveal the preimage. The randomness is derived from revealed preimages. Zero on-chain fee beyond transaction cost.
Pick commit-reveal when you have a small trusted set of participants, can tolerate a two-phase protocol, and want zero external-service dependency. Doesn’t scale to public applications — any committer can refuse to reveal if the outcome is bad for them (withhold attacks).
Prior art and acknowledgments
Section titled “Prior art and acknowledgments”Alea exists because of two pieces of earlier work.
Randamu runs drand itself, and built randa-mu/bls-solana, a BN254 drand verifier prototype for Solana that never shipped to any cluster. They did the hard part — proving the shape of the problem and the on-chain primitives needed for drand verification on Solana. Alea is attempting to take that work to mainnet.
kevincharm wrote the BN254 scheme into drand itself and built Anyrand, the EVM version of what Alea does. Alea’s SVDW hash-to-curve and BN254 constants port from his Solidity reference at kevincharm/bls-bn254. The cross-verification vectors used in Alea’s test suite come from kevincharm/noble-bn254-drand.
If any of these tools fit your use case better than Alea, use them.