3. Proof-of-Fair-Randomness (PoFR)™: The Protocol Standard

3.1 PoFR Defined

Proof-of-Fair-Randomness (PoFR) is the cryptographic protocol standard, coined by Mauricio Artigas on June 16th, 2026, that defines the technical requirements for generating a RandProof.

3.2 PoFR Compared to Existing Standards

3.3 Multi-Source Entropy Aggregation: The Gold Standard

Proof-of-Fair-Randomness (PoFR)™ aggregates fifteen independent, cryptographically verifiable entropy sources across seven entropy domains to guarantee unpredictability, unbiasability, and verifiability. To our knowledge, no other documented randomness protocol aggregates more entropy sources -- judge this claim on the published architecture and the phased roadmap (Section 26), not on the count alone.

The fifteen sources are:

Source 1: DRAND Public Randomness Beacon

• Provider: DRAND Consortium (Cloudflare, Protocol Labs, EPFL, University of Chile, Kudelski Security)

• Update Frequency: Every 3 seconds

• Verification: BLS signature against DRAND's known public key

• Purpose: Primary high-entropy source

• Weight: 20%

Source 2: NIST Randomness Beacon

• Provider: U.S. National Institute of Standards and Technology (NIST)

• Update Frequency: Every 60 seconds

• Verification: ECDSA signature against NIST's public key

• Purpose: Government quantum entropy source, non-blockchain, adds institutional independence to the entropy stack

• Weight: 5%

Source 3: Chain-Native Consensus VRF

• Provider: Native to each blockchain (RANDAO, Ouroboros Praos, BABE, Slot VDF, etc.)

• Update Frequency: Per block

• Verification: Native to each chain's consensus mechanism

• Purpose: Leverages each chain's strongest entropy source

• Weight: 10%

Source 4: Participant Commit-Reveal

• Provider: Event participants

• Update Frequency: Per event

• Verification: On-chain reveal logs + XOR aggregation

• Purpose: Adds unpredictable, user-generated entropy

• Weight: 10%

Source 5: Block Timestamp

• Provider: Chain's native timestamp

• Update Frequency: Per block

• Verification: On-chain

• Purpose: Prevents replay attacks across chains

• Weight: 5%

Source 6: Ethereum RANDAO

• Provider: Ethereum consensus layer (PREVRANDAO opcode)

• Update Frequency: Per block (~12 seconds)

• Verification: On-chain (PREVRANDAO opcode, EVM-native)

• Purpose: Zero-cost EVM entropy leveraging Ethereum’s full validator set

• Weight: 5%

Source 7: Bitcoin Merkle Root

• Provider: Bitcoin network (Bitcoin RPC)

• Update Frequency: Per Bitcoin block (~10 minutes)

• Verification: Bitcoin RPC / public block explorers

• Purpose: Maximum decentralization credibility, Bitcoin PoW hash rate is unmatched

• Weight: 5%

Source 8: Multi-Chain Block Hashes

• Provider: Multiple blockchain networks (RPC)

• Update Frequency: Per block (chain-dependent)

• Verification: Native to each chain via RPC

• Purpose: Cross-chain diversification at zero cost

• Weight: 5%

Source 9: ANU Quantum RNG

• Provider: ANU QRNG (Australian National University, Quantum Random Number Generator), HTTP API. HotBits is no longer used as a source: Fourmilab retired its radioactive-decay generator at the end of 2022, and the service operating under that name today runs on Intel RDSEED (a CPU-level generator), which the operator explicitly does not certify for any purpose. RandProof does not represent a CPU-level generator as physical quantum entropy.

• Update Frequency: On demand (real-time quantum entropy)

• Verification: ANU QRNG does not cryptographically sign its output, so a single keeper's report cannot be verified on-chain the way DRAND or NIST can. RandProof mitigates this with multi-keeper attestation rather than signature verification: see Multi-Keeper Attestation below.

• Multi-Keeper Attestation (Filter Against Fabricated Values): At least 3 independently-assigned keepers fetch ANU QRNG separately, in parallel, for the same event. A keeper cannot predict what the other keepers will independently receive from a genuine quantum measurement, so fabricating a value that matches what honest keepers report is exactly as hard as guessing the real output. If 2 of 3 reports agree, that value is accepted as genuine. If the reports disagree, the contract treats this as a fraud signal rather than guessing which report is correct: ANU's weight is dropped to zero for that event (redistributed per the AV-54 external-only redistribution rule), and the disagreeing keeper enters the standard 24-hour fraud-proof challenge window. A keeper found to have submitted a mismatched value forfeits a bonded amount on confirmation; repeated mismatches trigger stake slashing. This is the same protection class as the existing multi-keeper attestation layer described in AV-71, applied explicitly to this source, and is implemented and tested as EntropyAttestation.sol v3 (see AV-108 through AV-111 in Section 29 for two rounds of adversarial review against the actual code and the 8 fixes they produced, with 31 passing tests). Reporters are explicitly assigned by an authorized assigner, cannot self-select, cannot be re-assigned within a 1-hour cooldown of release, and the assigner cannot name itself as a reporter. Role changes to the assigner are timelocked 24 hours. It is staged for Base Sepolia testnet deployment but not yet integrated into KeeperCoordinator.sol (Section 19), which now exists as a tested MVP but does not yet call into this contract.

• Purpose: True quantum entropy from an academic source (vacuum fluctuation measurement), completely independent of blockchain state and of any government or commercial entity

• Weight: 5%

Source 10: Tor Consensus Hash

• Provider: Tor Project, 9 independent directory authorities (US, EU, Asia), HTTP

• Update Frequency: Hourly (acts as a “slow-clock” anchor complementing fast blockchain sources)

• Verification: Ed25519 signatures from 9 directory authorities; publicly verifiable

• Purpose: Completely off-chain, network-layer entropy, independent of all blockchain state. Attack cost $100M+ (requires compromising 5+ Tor directory authorities)

• Weight: 5%

Source 11: BABE VRF (Polkadot Consensus)

• Provider: Polkadot BABE consensus layer (all validator authorities via on-chain VRF epoch pool)

• Update Frequency: Per epoch (~4 hours); randomness announced two epochs in advance (N-2)

• Cryptographic Primitive: Schnorrkel sr25519 VRF, each validator signs (secret_key, epoch_randomness_N-2, slot_number) producing a VRF output + proof. All per-slot outputs are aggregated into an on-chain epoch randomness pool.

• Verification: On-chain via Polkadot’s BABE consensus; VRF proof verifiable by any full node

• Purpose: Polkadot-native consensus entropy, completely independent validator set from Ethereum. Adds a second major PoS network to the entropy stack, maximizing cross-chain diversification.

• Cost: $0: free, fully decentralized, already live on mainnet

• Weight: 5%

Source 12: drand Quicknet (BLS12-381 Unchained)

• Provider: drand League of Entropy, Quicknet chain (separate from Source 1 mainnet chain)

• Update Frequency: Every 3 seconds (faster than Source 1 mainnet)

• Curve: BLS12-381 (vs. BN254 used in Source 1). Larger key size, stronger security margin, off-chain stateless verification.

• Mode: Unchained, each round is independently verifiable without requiring prior rounds. Enables stateless keeper-layer verification and eliminates chain-dependency attacks.

• On-Chain Fallback Verification: drand evmnet, a BN254-based on-chain EVM verification path enabling smart contracts to verify Quicknet outputs natively without off-chain infrastructure.

• Verification: BLS12-381 signature against Quicknet public key (off-chain, stateless); or via drand evmnet on EVM chains (BN254, on-chain)

• Purpose: Supplements Source 1 (drand mainnet) with a cryptographically distinct network using a different curve, different mode, and independent round state. Two drand networks must fail simultaneously to reduce drand’s contribution, dramatically raising attack cost on the DRAND entropy domain.

• Cost: $0: public, free, no API fees

• Weight: 5%

• ⚠ TRUST ROOT DISCLOSURE: Sources 1 and 12 (drand Mainnet + drand Quicknet) are both operated by the League of Entropy (LoE). If LoE is compromised, both sources fail simultaneously, effectively reducing the stack from 15 independent sources to 13. Combined weight of LoE-controlled sources is 25% (20% + 5%). This is a known concentration risk. The 3 native sources (13-15) and all other external sources remain fully independent of LoE.

Source 13: RandProofVRF (Native Protocol VRF)

• Provider: RandProof Network keeper nodes (native BLS threshold VRF)

• Update Frequency: Per PoFR event (on-demand)

• Cryptographic Primitive: BLS12-381 threshold VRF, each keeper node generates a VRF output using its private key share, and a threshold (t=3) of outputs are aggregated to produce the final VRF value with a proof of correctness.

• Verification: On-chain BLS aggregate signature verification (BN254 pairing on EVM chains; native BLS12-381 on non-EVM chains). Any full node can verify the VRF proof without trusted parties.

• Purpose: RandProof's own native VRF layer, purpose-built for PoFR events. Adds a protocol-specific entropy source that is fully under RandProof's control, with no dependency on external infrastructure. Unlike chain-native VRF (Source 3), RandProofVRF is generated by the keeper network specifically for each PoFR event, ensuring freshness and event-binding.

• Cost: $0: generated internally by keeper nodes during PoFR fulfillment

• Weight: 5%

Source 14: Autonomous Beacon (Self-Running Entropy Clock)

• Provider: RandProof Network autonomous beacon chain (independent keeper-driven beacon)

• Update Frequency: Every block on the RandProof beacon chain (~6 seconds)

• Cryptographic Primitive: Autonomous beacon uses a Verifiable Delay Function (VDF) seeded by the previous beacon output and the current block hash, producing a sequential proof of elapsed computation that cannot be accelerated or predicted ahead of time.

• Verification: VDF proof verification on-chain (efficiently verifiable even though the VDF computation takes sequential time); beacon output is publicly available and committed to a block hash at each interval.

• Purpose: Provides a continuous, self-running entropy stream that is independent of all external sources. The autonomous beacon operates as a slow-clock complement to fast sources like DRAND, ensuring that even if all external sources are momentarily unavailable, the beacon continues producing fresh entropy. The VDF construction guarantees that no party, including the keeper nodes operating the beacon, can predict future outputs before the sequential computation completes.

• Cost: $0: maintained by the keeper network as part of consensus participation

• Weight: 5%

• ⚠ PROTOCOL-NATIVE SOURCE DISCLOSURE: Sources 13-15 (RandProofVRF, Autonomous Beacon, Epoch Entropy Pool) are generated by the RandProof keeper network itself. Their decentralization is directly tied to the node count and trust model of each deployment phase. During Phase 0 (Genesis), these sources are effectively founder-controlled entropy generated by the federated genesis keeper set (10-12 nodes; see Section 24.1). During Phase 2+, as the network grows to 25+ permissionless nodes, these sources become progressively more decentralized. At Phase 4 target (1,000+ nodes), they are fully decentralized. This circular dependency, where the protocol's own entropy sources are only as decentralized as the protocol itself, is an accepted design tradeoff. The other twelve sources (Sources 1-12, the externally-sourced entropy inputs, DRAND, NIST, chain-native VRFs, Bitcoin, etc.) remain fully independent of RandProof's node topology at all phases; only Sources 13-15 of the full 15-source aggregate carry this node-count dependency.

Source 15 —Epoch Entropy Pool (Accumulated Cross-Epoch Entropy)

• Provider: RandProof Network epoch accumulation contract (on-chain)

• Update Frequency: Per epoch (~1 hour; configurable per chain)

• Cryptographic Primitive: Epoch entropy is accumulated by hashing all PoFR event seeds and all keeper commit-reveal values from the previous epoch into a running pool. The pool output for epoch N is: epochPool_N = keccak256(epochPool_N-1, allEventSeeds_N-1, allKeeperCommits_N-1). This creates an ever-growing, tamper-proof entropy accumulator that carries forward the entropy history of the entire network. Initialization: epochPool_0 = keccak256(blockhash(deploymentBlock + 256)), trustless future blockhash, not founder-chosen. During Epoch 0 (first hour), epoch pool weight is reduced to 2.5% until 10+ events accumulate. (AV-18 fix)

• Verification: On-chain, the epoch entropy pool is stored in a dedicated smart contract and is publicly readable by any full node or light client. Each epoch's accumulation is verifiable by replaying the hash chain from any prior checkpoint.

• Purpose: Provides deep historical entropy that compounds over time. Each PoFR event benefits not only from current entropy sources but from the accumulated entropy of every prior event in the epoch. This makes retroactive manipulation computationally impossible, an attacker would need to rewrite the entire epoch history to influence the pool. The Epoch Entropy Pool also serves as a network-wide randomness checkpoint, enabling cross-event verification and long-range auditability.

• Cost: $0: computed on-chain as part of normal protocol operation

• Weight: 5%

Aggregation Formula:

bytes32 drandEntropy = keccak256(abi.encode(drandRound, drandSignature));

bytes32 nistEntropy = keccak256(abi.encode(nistBeaconValue, nistSignature));

bytes32 chainEntropy = keccak256(abi.encode(blockVRF));

bytes32 participantEntropy = keccak256(abi.encode(reveal_1, reveal_2, ..., reveal_n)); // hash-chain, not XOR (AV-24 recommended fix, not yet implemented in production code, see AV-24, Section 29)

bytes32 timeEntropy = keccak256(abi.encode(block.timestamp, block.number, blockhash(block.number - 1))); // C-02 hardening -- timestamp mixed with block number and prior block hash, never used in isolation

bytes32 randaoEntropy = keccak256(abi.encode(block.prevrandao));

bytes32 btcEntropy = keccak256(abi.encode(bitcoinMerkleRoot));

bytes32 multiChainEntropy = keccak256(abi.encode(multiChainBlockHashes));

bytes32 qrngEntropy = keccak256(abi.encode(anuQRNG));

bytes32 torEntropy = keccak256(abi.encode(torConsensusHash));

bytes32 babeEntropy = keccak256(abi.encode(polkadotBabeEpochRandomness));

bytes32 quicknetEntropy = keccak256(abi.encode(drandQuicknetRound, drandQuicknetSig));

bytes32 randProofVrfEntropy = keccak256(abi.encode(randProofVrfOutput, randProofVrfProof));

bytes32 autonomousBeaconEntropy = keccak256(abi.encode(beaconOutput, vdfProof));

bytes32 epochPoolEntropy = keccak256(abi.encode(epochEntropyPool, epochIndex));

bytes32 combinedEntropy = keccak256(abi.encode(drandEntropy, nistEntropy, chainEntropy, participantEntropy, timeEntropy, randaoEntropy, btcEntropy, multiChainEntropy, qrngEntropy, torEntropy, babeEntropy, quicknetEntropy, randProofVrfEntropy, autonomousBeaconEntropy, epochPoolEntropy));

bytes32 seed = keccak256(abi.encodePacked(combinedEntropy, requestId));

Security Guarantee (Phase 4 target): At full Phase 4 deployment, no single party can control all fifteen entropy sources, and the protocol's randomness is designed to be infeasible to bias by any known attack. Source count alone is not the guarantee: because sources are aggregated by hashing, a party controlling even one input while observing the others before committing could attempt to grind the seed. That vector is closed by the commit-before-observe ordering, multi-keeper attestation, the fraud-proof challenge window, and economic slashing -- not by the count of sources. During Phases 0-3, fewer sources are live and the genesis keeper set is federated (see Section 24.1 and Section 26), computationally infeasible under any realistic threat model. The four-layer entropy verification architecture (on-chain verification, multi-keeper attestation, fraud-proof challenge window, economic slashing) ensures that fabricated entropy is detectable and punishable.