RandProofRNG

RandProofRNG is the Layer 1 randomness product: a permissionless, pay-per-use verifiable randomness engine implementing the Proof-of-Fair-Randomness (PoFR) standard. Every fulfilled request produces a RandProof — a permanent on-chain artifact containing the seed, the committee signatures, and the entropy attestation, verifiable by anyone at any time.

Live Deployment

How a Request Flows (V8)

1. Your contract calls requestRandomness{value: fee}(userSeed) on the coordinator and receives an eventId. Fee must be >= MIN_FEE (spam protection); rate limited to 1 request per 10 blocks per address.
2. The keeper committee detects the DrawRequest event over WebSocket RPC.
3. Each keeper resolves the drand Quicknet round anchored to the request and signs keccak256(chainId, coordinator, eventId, drandValue, entropyBlock).
4. The first keeper holding a 4-of-12 committee quorum calls fulfill().
5. The coordinator verifies the drand Quicknet BLS signature on-chain via the EIP-2537 BLS12-381 precompile and derives the seed solely from that verified anchor — plus the block.timestamp / block.prevrandao of the fulfillment block, which no keeper could predict or pre-sign.
6. The coordinator calls back fulfillRandomness(eventId, seed) on your contract, distributes the fee 70/20/10, and stores the RandProof permanently.

Entropy Sources Today

Eleven sources are tracked per proof. The seven cryptographically signed sources are deterministic — every honest keeper derives the same values. The seed itself derives solely from the on-chain verified drand Quicknet round, so security never depends on the supplemental attestations.

Signed (7): DRAND (League of Entropy t=9-of-25), NIST Randomness Beacon (gap-anchored), Bitcoin block header Merkle root (self-hosted nodes), drand Quicknet, Polkadot block hash, Ethereum block hash, Cosmos Hub block hash.

Supplemental attestations (4): Entropy Block (active — Base block number bound into every keeper signature), ANU QRNG (staged), Multi-Chain Hash (in progress), Block-derived (staged).

Liveness Guarantees

• Fulfillment timeout: FULFILLMENT_TIMEOUT = 256 blocks (~8.5 min on Base). If keepers stall, a permissionless fulfillFromBeacon path settles the draw from the beacon anchor alone — already exercised in production: a stalled draw auto-settled at +256 blocks (tx).
• Requester refund: cancelRequest(eventId) returns the fee to the original requester once the timeout passes unfulfilled.
• No admin key on fulfill() — the fulfillment path is pure cryptography; there is no privileged call that can alter, delay, or redirect an outcome.

Integrate

interface IKeeperCoordinator {
    function requestRandomness(bytes32 userSeed) external payable returns (bytes32 eventId);
    function isFulfilled(bytes32 eventId) external view returns (bool);
    function getRandProof(bytes32 eventId) external view returns (
        bytes32 seed,
        bytes memory aggregatedSig,
        address[] memory signers,
        uint256 fulfillBlock,
        uint256 fulfillTimestamp
    );
}

Your consumer implements fulfillRandomness(bytes32 eventId, bytes32 seed) and enforces msg.sender == coordinator. See the Quickstart for a full working contract and Client Contract Integration for the complete interface including fulfill, submitEntropy, submitFraudProof, and getEntropyInputs.

Verify a Proof

Every fulfilled event is independently auditable:

• Call getRandProof(eventId) on the coordinator directly — no trust in this site required.
• Browse RandProofScan for entropy sources, signatures, seeds, and the signer committee — e.g. this live proof.
• First production draws fulfilled seeds 0xbc8f…c8f7 and 0xe9df…9098, with Quicknet rounds verified on-chain via EIP-2537.

Validation Status

181 unit tests plus a live soak suite, a live failure-path suite, and a live adversarial suite (10/10) run against the deployed mainnet contract.

Spec vs. Deployment

Whitepaper §7 specifies the Phase-4 design target: 15 entropy sources across 7 entropy domains with BLS threshold aggregation. The deployed V8 intentionally diverges where the audits found it safer — 4-of-12 ECDSA committee signatures instead of unaudited BN254 BLS libraries, and a seed derived solely from the EIP-2537-verified drand Quicknet anchor rather than a 15-way mix. All divergences are disclosed in §19.2.