How rng.dev Works

rng.dev generates new randomness every second by combining entropy from 8 independent blockchains.

---

The 1-Second Beacon

Property	Value
Cadence	1 second
Sources	8 blockchains (Aptos, Arbitrum, Base, Bitcoin, Cardano, Ethereum, Solana, Sui)
Verification	Full — all inputs public, recomputable
External dependencies	None — blockchain data only

How It Works

Every second:
  1. Fetch latest finalized block + TXID from each chain
  2. Fast chains (Aptos, Arbitrum, Base, Solana, Sui) provide fresh data each round
  3. Slow chains (Bitcoin, Cardano, Ethereum) provide stable base entropy
  4. Combine: SHA3(aptos | arbitrum | base | bitcoin | cardano | ethereum | solana | sui)
  5. Publish round with all inputs

Chain Finality

Chain	Block Time	Finality	Fresh Each Round?
Aptos	~160ms	~900ms	✓ Yes
Arbitrum	~250ms	~250ms	✓ Yes
Base	~2s	~2s	✓ Yes
Bitcoin	~10 min	~60 min	Every ~60 rounds
Cardano	~20s	~20s	Every ~20 rounds
Ethereum	~12s	~13 min	Every ~12 rounds
Solana	~400ms	~400ms	✓ Yes
Sui	~380ms	~400ms	✓ Yes

Security Model

The security rests on TXID unpredictability, not block hash freshness.

Why slow chain reuse doesn't weaken security:

Consider two consecutive 1-second rounds:

Round	Fast Chain TXIDs	Slow Chain Data	Result
T+0s	aptos_tx_A, sol_tx_A, sui_tx_A	Block X	Output A
T+1s	aptos_tx_B, sol_tx_B, sui_tx_B	Block X (same)	Output B (different)

Even though Block X repeats, the outputs are completely different because:

1. TXIDs from fast chains change — new transactions land in each block
2. SHA3 avalanche effect — any input change produces completely different output

The fundamental insight: Block hashes are predictable once finalized. TXIDs are not — they depend on which users submit transactions and when. An attacker who knows the slow chain data still cannot predict:

• Which transaction will be in position 1 of the next Sui block
• Which transaction will be in position 1 of the next Aptos block
• Which transaction will be in position 1 of the next Solana block

This is information-theoretically secure — predicting these values requires predicting the behavior of millions of users worldwide.

---

Verification Model

rng.dev is designed for trustless verification. You don't need to trust us:

How It Works

Each round:
  1. Fetch block + TXID from each chain
  2. Combine using SHA3-256 sequential mixing
  3. Publish round with all inputs stored
  4. Anyone can verify by recomputing

Self-Verification

All inputs are public blockchain data:

What You Verify	How
Block hashes	Check any block explorer
Transaction IDs	Check any block explorer
Algorithm	Open source, deterministic
Output	Recompute SHA3-256 yourself

Validator Network (Planned)

We're building a distributed validator network where independent operators continuously verify rounds. Self-hosted operators can participate. See Self-Hosted Guide.

---

Self-Hosted: Optional Entropy Sources

Self-hosted operators can optionally add additional entropy sources beyond the standard blockchain inputs.

drand Integration

Add drand's threshold BLS signatures for applications requiring that specific proof type.

# config/entropy.yaml
optional_sources:
  drand:
    enabled: true
    network: "quicknet"
    wait_for_next: true  # Wait for future round (front-running prevention)

Properties:

• Adds ~1.5 second average latency (waiting for next drand round)
• Provides BLS threshold signatures from 20+ operators
• Useful for regulatory requirements specifying "threshold cryptography"

NIST Beacon Integration

Add NIST Randomness Beacon for applications requiring US government attestation.

optional_sources:
  nist:
    enabled: true
    wait_for_next: true  # Wait for future pulse (front-running prevention)

Properties:

• Adds ~60 second average latency (NIST publishes every 60 seconds)
• Provides hash chain precommitment from NIST
• Useful for US government or regulated environments requiring NIST attestation

Hardware Entropy

Add local hardware RNG for air-gapped or high-security deployments.

optional_sources:
  hardware:
    enabled: true
    device: "/dev/hwrng"  # Or specific hardware RNG device
    bytes: 32

Properties:

• Truly random (quantum/thermal noise)
• Not publicly verifiable (must trust operator)
• Useful for adding defense-in-depth entropy

---

Security Summary

rng.dev's security rests on three pillars:

1. Economic Security

Manipulating blockchain block production requires controlling consensus:

Chain	Consensus	Cost to Control
Aptos	PoS	$2B+ (33% stake)
Bitcoin	PoW	$10-20 billion (51% hashrate)
Cardano	PoS	$5B+ (33% stake)
Ethereum	PoS	$50B+ (33% stake, slashable)
Solana	PoS	$10B+ (33% stake)
Sui	PoS	$2B+ (33% stake)

Total cost to influence all sources: $80B+

2. Information-Theoretic Security

Transaction IDs provide unpredictability that cannot be defeated regardless of resources:

TXID = hash(sender, recipient, amount, nonce, signature, timestamp, ...)

To predict a TXID, an attacker must predict:

• Which user will submit a transaction
• What amount they will send
• Who they will send it to
• The exact moment they will submit

This is predicting human behavior at global scale — not a computational problem, but an information problem.

3. Trustless Verification

Anyone can verify any round:

What to Check	How to Verify
Block data is authentic	Compare with public block explorers
Inputs are stored correctly	API returns all inputs for each round
Hash is computed correctly	Recompute SHA3-256 yourself

---

Further Reading

• Threat Model — Detailed attack analysis
• Appropriate Uses — What this is (and isn't) for
• Self-Hosted Guide — Optional entropy configuration