Skip to main content

What rng.dev Is (and Isn't) For

Please read this carefully before using the beacon.


Understanding the Security Model

rng.dev generates new randomness every second using 8 independent blockchains:

PropertyValue
Cadence1 second
SourcesAptos, Arbitrum, Base, Bitcoin, Cardano, Ethereum, Solana, Sui
VerificationFull — anyone can recompute from inputs

Two layers of security:

  1. Economic security — $80B+ attack cost across all chains
  2. Information-theoretic security — TXID unpredictability (global user behavior)

Appropriate Use Cases

Use CaseWhy It Works
Games and entertainmentEconomic incentive to attack is negligible
Real-time gaming1-second cadence, fully verifiable
Lotteries and rafflesTransparency and verifiability
Reproducible ML/AI experimentsAudit trail, deterministic replay
Transparent selection processesAnyone can verify the selection was fair
Research and experimentationOpen source, well-documented
Community drawingsTransparency matters more than secrecy
Governance selectionFair jury/audit sampling
Distributed systemsCoordination requiring shared randomness

Why economic security is sufficient: Manipulating the beacon requires controlling blockchain consensus — $50B+ for Ethereum alone, $80B+ for all 8 chains. No rational attacker spends billions to influence an outcome worth a fraction of that cost.


Do NOT Use For

Cryptographic Key Generation

RiskWhy
Wrong tool for the jobKey generation requires local entropy, not network-derived randomness
Timing requirementsKeys often needed offline or at boot time
Forward secrecy concernsNetwork-derived randomness leaves traces

Use instead: /dev/urandom, hardware RNG, or cryptographic libraries (OpenSSL, libsodium)


National Lotteries

RiskWhy
Regulatory requirementsRequires jurisdiction-specific certified, audited systems
Scale of stakesBillions of dollars — requires formal verification
Legal liabilityMust meet specific legal requirements that vary by country

Use instead: Purpose-built lottery systems with regulatory certification

This is a regulatory constraint, not a technical one. Even perfect randomness isn't sufficient without the required certifications.


Air-Gapped Systems

RiskWhy
Network dependencyBeacon requires internet access to fetch blockchain data
Timing constraintsMay not be available when needed

Use instead: Hardware RNG, local entropy, pre-generated random pools

Note: Self-hosted deployments can add hardware entropy for defense-in-depth. See Self-Hosted Guide.


The Trust Model

When using rng.dev, you're trusting:

ComponentTrust LevelVerification
Blockchain dataHighVerify on block explorers
RPC providersMediumMultiple providers, cross-check
Combination algorithmHighOpen source, reproducible

You're NOT trusting:

  • Any single blockchain (we use 8)
  • Any single RPC provider (multiple fallbacks)
  • Our word alone (everything is verifiable)

Self-Hosted Options

For specific requirements, self-hosted operators can add optional entropy sources:

drand Integration:

  • Adds ~1.5 second average latency (waits for next drand round)
  • Provides BLS threshold signatures from 20+ operators
  • For jurisdictions specifically requiring threshold cryptography

Hardware Entropy:

  • Adds local hardware RNG entropy
  • Not publicly verifiable
  • For air-gapped or defense-in-depth deployments

See Self-Hosted Guide for configuration.


Summary

I need...Recommendation
Verifiable randomness for games✓ Use rng.dev
Real-time gaming randomness✓ Use rng.dev (1-second cadence)
Transparent lottery/raffle✓ Use rng.dev
ML/AI training seeds✓ Use rng.dev
Governance/selection processes✓ Use rng.dev
Threshold BLS signatures (regulatory)Self-hosted + drand option
Air-gapped deploymentSelf-hosted + hardware entropy
Cryptographic key material✗ Not us — use /dev/urandom
National lottery randomness✗ Not us — use certified vendors

rng.dev is provided "as is" without warranty of any kind. Users assume all responsibility for determining suitability for their use case. We disclaim all liability for losses resulting from use of this service.