Entropy Protocol: Cryptographic Randomness
Executive Summary
Entropy is a provably-fair random number generation protocol for Solana that uses a commit-reveal scheme combined with Solana’s slot hashing to generate verifiable, manipulation-resistant randomness on-chain. Core Innovation: No single party (not the platform, not validators, not users) can predict or manipulate the final random value because:- The Entropy provider commits to a secret seed before the slot hash is determined
- Solana validators produce the slot hash after the commitment
- Both values are cryptographically combined to produce final randomness
The Problem with On-Chain Randomness
Generating truly random numbers on blockchain is fundamentally challenging:- Deterministic Execution
- Front-Running Risk
- Single-Party Risk
Blockchain programs must be deterministic for consensus. If randomness is predictable, participants can front-run and manipulate outcomes.
Entropy’s Solution: Commit-Reveal Scheme
Core Concept
- SlotHash: Unknown to Entropy provider at commit time, controlled by consensus
- Secret Seed: Unknown to validators until reveal, locked in cryptographic hash
- Sample Number: Ensures uniqueness across multiple selections
Commitment Phase
The Entropy provider generates and commits to a secret seed:1
Generate Secret
2
Lock Commitment
Provider submits commit to blockchain. Seed remains private.
3
Cannot Change
Provider is cryptographically locked into this seed. Changing it would produce different commit.
Why the Commit is Critical
Without commitment (❌ Vulnerable):Reveal Phase
After the slot hash is determined:1
Provide Seed
Entropy provider submits the actual secret seed that matches the commitment.
2
Verify Commitment
3
Compute Final Value
Protocol Instructions
open_var
Initialize randomness account with commitment.update_end_at
Set target slot for slot hash sampling.sample_var
PERMISSIONLESS - Capture slot hash at target slot.reveal_var
Reveal secret seed and compute final random value.pick_winner
Use random value to select winner.next_var
Enable backup winner selection through seed chaining.Complete Workflow
1. Asset Creation (Admin + Backend)
2. Token Sales (Users)
3. Randomness Automation Triggered
4. Winner Selection (Automated)
Seed Management
Generation
Storage
Seeds are encrypted at rest using AES-256-GCM:Lifecycle
Token Numbering & Winner Selection
1-Based Indexing
Tokens are numbered 1 to N (user-friendly):Winner Selection Formula
- Modulo produces 0 to (N-1)
- Tokens numbered 1 to N
- Adding 1 maps to correct range
Backup Winner Selection (Seed Chaining)
If winner doesn’t claim or needs to repeat:First Selection Failed
Seed Chaining Process
- Provider cannot change
original_seed(already revealed) - Cannot predict or manipulate new randomness
- Chain prevents any tampering
Timing Constraints
SlotHashes Sysvar
Solana provides recent slot hashes in a sysvar:Optimal Timing
Security Guarantees
Unpredictability
Admin cannot predict slot_hash at commit time (controlled by 300+ validators)
Unforgeability
Commitment is cryptographic hash; cannot be changed after creation
Verifiability
Anyone can verify: keccak256(seed) == stored_commit on-chain
Tamper-Proof
Seed locked in commitment before any randomness is available
Implementation Checklist
- Generate random 32-byte seed using cryptographic RNG
- Compute keccak256(seed) for commitment
- Store encrypted seed in database with AES-256-GCM
- Submit commitment to open_var instruction
- Monitor varEndAtUpdated event
- Trigger sample_var at appropriate timing
- Decrypt and retrieve seed on reveal
- Submit reveal_var with original seed
- Verify program accepts reveal (keccak256 matches)
- Handle varRevealed event to continue workflow
- Trigger pick_winner for final selection
- Implement backup selection with seed chaining
- Monitor for SlotHashes sysvar timing violations
- Implement fallback hash strategy if needed

