FAQ

How do I get verifiable randomness on Solana?

Install @vrand.io/web and call await vrand.random() — one wallet signature, a bonded prover answers with a VRF proof, and the SDK verifies that proof locally before the promise resolves. On-chain programs add the vrand-anchor crate: one attribute injects the accounts, one call sends the request. Start at the web quickstart or the Anchor quickstart.

Why can't I just use Math.random() or a blockhash?

Math.random() is invisible to your users and manipulable by whoever runs the code. Blockhashes, slots, and timestamps are influenced or predictable by validators. A VRF produces randomness with a proof anyone can check, so nobody — including the operator — can substitute a convenient outcome.

What happens if the prover never answers?

Declare an at-risk amount and it is reserved against the prover's SOL bond; if the prover misses its delivery window, anyone can trigger a slash that pays you exactly that amount, automatically. With at-risk 0 (the free tier) you simply retry and reclaim the stranded rent. Details: Economics.

How fast is it?

A prover typically answers within a slot or two; end to end in a browser — signature, confirmation, fulfillment, local verification — is a few seconds on devnet.

How much does it cost?

A flat per-request fee (fractions of a cent) plus a reclaimable ~0.004 SOL rent deposit; optional delivery coverage adds a premium of a few basis points of the covered amount. 100% of fees go to the prover that delivered — the protocol holds nothing.

Can I get many numbers for one signature?

Three ways, with different meanings:

• draw() — one request shaped into many outcomes of a single event (a shuffle plus picks); one fee.
• randoms(n) — n independent numbers, each its own proven request and its own fee, packed into as few signatures as possible.
• startSession() — one signature funds a session key; then everything runs prompt-free until you end() it.

Is the randomness biased when shaped into dice or shuffles?

No. Outcome shaping uses rejection sampling (never bare modulo), with byte-identical Rust and TypeScript implementations pinned to each other by cross-language golden tests. See Verifying outcomes.

Can the prover cheat?

A prover cannot lie — the VRF has exactly one valid output per input, and the on-chain verifier rejects everything else. A prover can see its own outcome moments early (it computes the proof), which is the honest limitation of every single-key VRF service; our threshold (FROST) prover is built to close exactly that. Full candor in the security model.

Is VRAND live on mainnet?

Yes — live on mainnet (try it), with devnet available for free experimentation via the app's network switch.

Is it open source?

Apache-2.0, end to end — protocol, verifier, SDKs, prover daemon, threshold crypto.

Who is behind the first provers?

The VRAND team operates the bonded prover fleet. The registry itself is permissionless by protocol design.