Security & Threat Model
Overview
This document describes the trust assumptions, known attack vectors, and limitations of rng.dev. Read this carefully before using the beacon for any application.
The 1-Second Beacon
rng.dev generates new randomness every second using 8 independent blockchains:
| Property | Value |
|---|---|
| Cadence | 1 second |
| Sources | Aptos, Arbitrum, Base, Bitcoin, Cardano, Ethereum, Solana, Sui |
| Verification | Full — all inputs public, recomputable |
Security Model
rng.dev provides two layers of security:
1. Economic Security: Manipulating blockchain consensus requires $80B+ in capital across all chains. No rational attacker spends billions to influence outcomes worth a fraction of that cost.
2. Information-Theoretic Security: Transaction IDs are determined by global user behavior — which users submit transactions, when, and with what parameters. Predicting TXIDs requires predicting the behavior of millions of independent actors. This is not a computational problem; it's an information problem that cannot be solved regardless of resources.
Trust Assumptions
The beacon assumes:
- At least 1 honest data source from 16 — Each of 8 chains contributes 2 data points (block hash + TXID). If even one is unpredictable, the output is unpredictable.
- SHA3-256 behaves as a random oracle (standard cryptographic assumption)
- RPC providers return authentic blockchain data (verifiable on block explorers)
What We Do NOT Require
- Trust in the beacon operator (all inputs are public and verifiable)
- Trust in any single blockchain (we use 8)
- Trust in any single RPC provider (multiple fallbacks)
- Trust in most sources being honest (1 of 16 is sufficient)
Attack Analysis
| Attack | Description | Feasibility | Mitigation |
|---|---|---|---|
| Last-revealer | Miner withholds block to influence output | Low | Multi-source diversity; attacker must control finalization across multiple chains |
| Grinding | Miner tries multiple blocks to find favorable hash | Very Low | Cost scales with number of sources; economically impractical |
| RPC manipulation | Malicious provider returns fake data | Low | Multiple fallback providers; verifiable on explorers |
| Single-source compromise | One blockchain's randomness is biased | Low | 15 other data points still contribute; only need 1 honest source |
| Operator manipulation | We publish favorable results | Low | All inputs stored; anyone can verify |
| Prediction | Observe inputs before output | Low | TXID-based unpredictability |
Last-Revealer Attack
A miner who discovers a block could theoretically:
- Observe the current beacon inputs
- Calculate what the output would be with their block
- Decide whether to publish or withhold
Why this is impractical:
- Bitcoin uses 6-confirmation finality (~60 min lag)
- Attacker would need to hold a valid block for ~1 hour
- Block becomes stale and worthless if not published quickly
- Must simultaneously influence multiple chains
Grinding Attack
An attacker could try to:
- Generate many candidate blocks
- Calculate beacon output for each
- Publish the most favorable one
Why this is impractical:
- Must generate valid blocks (requires hash power or stake)
- Must do this for multiple chains simultaneously
- Cost: millions of dollars for minimal influence
- Each additional source exponentially increases difficulty
Economic Analysis
Manipulating the beacon requires influencing blockchain block production:
Cost per chain (approximate):
| Chain | Consensus | Cost to Guarantee Block | Notes |
|---|---|---|---|
| Bitcoin | PoW | $10-20 billion (51% hashrate) | 600 EH/s network; requires millions of ASICs |
| Ethereum | PoS | ~$50B+ (33% stake) | 33M ETH staked; slashing destroys attacker's stake |
| Solana | PoS | ~$10B+ (33% stake) | Leader selection based on stake weight |
| Cardano | PoS | ~$5B+ (33% stake) | Probabilistic block production |
| Aptos | PoS | ~$2B+ (33% stake) | BFT consensus |
| Sui | PoS | ~$2B+ (33% stake) | Narwhal/Bullshark consensus |
Note on Bitcoin (Proof of Work): You cannot simply "pay to mine a block." You must either:
- Control >50% of global hashrate (~$15B in hardware + $50M/month electricity), OR
- Get lucky with your existing hashrate (probabilistic, not guaranteed)
Note on PoS chains: The capital requirements must be:
- Purchased — Buying 33% of staked ETH (~$50B) would cause massive market impact
- Locked — Staked capital is frozen for weeks/months
- Slashable — Misbehavior results in automatic destruction of stake
Multi-chain multiplication:
The beacon combines 8 independent chains. To control the output:
| Chains Controlled | Influence on Output | Capital Required |
|---|---|---|
| 1 of 8 | Minimal (~12% of input) | $1B+ (smallest chain) |
| 2 of 8 | Partial (~25% of input) | $2B+ |
| 4 of 8 | Significant (~50% of input) | $10B+ |
| 8 of 8 | Full control | $80B+ (all chains) |
Expected value is always negative:
EV = P(success) × Value(manipulation) - Cost(attack)
For a $1,000,000 prize (controlling 1 chain):
EV = 0.125 × $1,000,000 - $1,000,000,000 = -$999,875,000
For a $100,000,000 prize (controlling all 8 chains):
EV = 1.0 × $100,000,000 - $80,000,000,000 = -$79,900,000,000
Bottom line: Influencing even ONE chain requires $1B+ in locked capital. Ethereum alone requires $50B+ locked and at risk of slashing. Controlling all 8 chains would require $80B+.
Transaction ID Security
All modes use transaction IDs (TXIDs) as an entropy layer. This provides security guarantees independent of block production control.
Why TXIDs Are Unpredictable
Transaction IDs derive from customer transactions — submitted by users around the world, not by block producers. Even an attacker who controls block production cannot predict or control these inputs:
| Property | Block Hash | Transaction ID |
|---|---|---|
| Origin | Block producer | External users/customers |
| Control | Producer can grind (expensive) | Producer has no control |
| Prediction | Possible with enough hashpower/stake | Impossible — depends on global user behavior |
| Manipulation | Requires controlling consensus | Requires controlling customer behavior worldwide |
Attack Scenarios
Scenario 1: Attacker controls block production on one chain
With block hashes alone, this provides ~17% influence over the combined output. With TXIDs:
Block hash: Attacker can influence
TXID in position 1: Attacker CANNOT predict
Result: Even controlling the chain, the TXID is determined by:
- Which customer transactions arrive
- When they arrive
- Network propagation timing
- Mempool ordering (varies by node)
Scenario 2: Attacker controls block production on ALL eight chains ($80B+)
Even with nation-state resources controlling all eight blockchains:
All 8 block hashes: Attacker can influence
All 8 TXIDs: Attacker still CANNOT predict
The first transaction in each block depends on:
- Global customer activity (cannot be predicted or controlled)
- Mempool state at block creation time
- Network propagation across thousands of nodes
- Fee market dynamics (which TX pays most)
Why TXIDs Cannot Be Controlled
Unlike block hashes, transaction IDs are determined by:
- Transaction content — The sender, recipient, amount, data, nonce, signature
- Cryptographic hash — TXID = hash(transaction data)
- User decisions — When users choose to transact
An attacker would need to:
- Predict when customers worldwide will submit transactions
- Predict what amounts, recipients, and data they will include
- Control which transaction arrives first at block production time
This is information-theoretically impossible.
Transaction Selection Rules
| Chain | Selection | Rationale |
|---|---|---|
| Bitcoin | 2nd transaction | 1st is always coinbase (miner-controlled) |
| Ethereum | 1st transaction | User transactions start at index 0 |
| Solana | 1st non-vote transaction | Vote transactions are validator-controlled |
| Aptos | 1st transaction | User transactions start at index 0 |
| Cardano | 1st transaction | User transactions start at index 0 |
| Sui | 1st transaction | User transactions start at index 0 |
Verification Model
Self-Verification
rng.dev is designed for trustless verification. You don't need to trust us or any third party:
- All inputs are public — Block hashes and TXIDs from 8 blockchains
- All inputs are stored — Every round includes the exact inputs used
- Algorithm is deterministic — SHA3-256 sequential mixing, fully specified
- Anyone can recompute — Fetch inputs, run the algorithm, compare output
This means:
- You can verify any round yourself using public blockchain data
- No trusted third party required
- No special cryptographic knowledge needed
- Just check block explorers and run a hash function
Validator Network (Planned)
We're building a distributed validator network where independent operators continuously verify rounds. This will provide:
- Continuous monitoring — Automated verification of every round
- Public attestations — Signed statements from known entities
- Anomaly detection — Immediate alerts if verification fails
Self-hosted beacon operators can participate as validators. See Self-Hosted Guide for details.
Known Limitations
| Limitation | Impact | Mitigation |
|---|---|---|
| Blockchain dependencies | If all 8 chains fail, no randomness | Extremely unlikely; degraded mode with partial sources |
| RPC provider trust | Must trust at least one provider per source | Multiple fallbacks; users can verify on explorers |
| Statistical verification only | Cannot prove randomness, only show "no detected bias" | Continuous statistical testing; all inputs verifiable |
Appropriate Uses
| Use Case | Why It Works |
|---|---|
| Lotteries & gambling | Unbiasable, verifiable, audit trail |
| Real-time gaming | 1-second cadence, fully verifiable |
| Scientific experiments | Reproducible, transparent random seeds |
| AI/ML training | Consistent random initialization across runs |
| Governance selection | Fair jury/audit sampling |
| Games & entertainment | Transparent randomness players can verify |
Do NOT Use For
| Use Case | Why Not | Alternative |
|---|---|---|
| Cryptographic key generation | Wrong tool — keys require local entropy | /dev/urandom, hardware RNG |
| National lotteries | Regulatory requirements | Jurisdiction-certified vendors |
| Air-gapped systems | Requires network access | Hardware RNG, local entropy |
Self-Hosted: Optional Entropy Sources
Self-hosted operators can optionally add additional entropy sources. See Self-Hosted Guide for configuration.
drand Integration (Optional)
For operators with specific regulatory requirements for threshold BLS signatures:
optional_sources:
drand:
enabled: true
network: "quicknet"
wait_for_next: true
Hardware Entropy (Optional)
For air-gapped or high-security deployments:
optional_sources:
hardware:
enabled: true
device: "/dev/hwrng"
Incident Response
If we detect anomalies:
- Statistical tests fail → Investigate, may pause generation
- Source unavailable → Continue with remaining sources, flag in API
- Multiple sources unavailable → Halt generation, notify users
- Suspected manipulation → Full audit, public disclosure
Historical incidents will be documented in our GitHub repository.
Responsible Disclosure
Found a security issue? Report it through GitHub Security Advisories.
We appreciate responsible disclosure and will acknowledge researchers who help improve security.
Further Reading
- How It Works — Technical details
- Appropriate Uses — What this is (and isn't) for
- Self-Hosted Guide — Optional entropy sources
- Verification Guide — Verify rounds yourself