Distributed and Verifiable Randomness Oracles

Generating true randomness onchain is inherently challenging due to the deterministic nature of EVM and EVM-like environments. Pseudo-random values like the last blockhash can be manipulated by miners, and centralized randomness sources are susceptible to attacks since a single non-random outcome cannot be distinguished from a random one. DIA Random solves this by using a distributed randomness beacon with multiple independent high-entropy sources, ensuring that no single party can bias or predict the output.

DIA leverages drand's distributed randomness beacon, operated by the League of Entropy, a group of independent actors. In every 30-second epoch, each node generates a partial signature and broadcasts it to the network. Once a threshold number of signatures are collected, the randomness beacon is computed as the hash of the aggregate signature. This value is then propagated, verified by any node, and shipped onchain by DIA's decentralized feeder network as an oracle smart contract.

DIA Random can be deployed on any smart contract-enabled blockchain supported by DIA's infrastructure, including both EVM and non-EVM compatible networks. It is currently live on chains such as Aleph Zero, Alephium, Astar, Aurora, Evmos, Fuse, Moonbeam, Polygon, Shiden, and Vara Network. New chain integrations can be requested through DIA's support channels.

All randomness values are verifiable offchain before they become available to smart contracts. Each round produces a randomness value alongside a BLS signature provided by drand. Clients can verify that the randomness they received was genuinely produced by the drand network using the public HTTP APIs or libp2p's Gossipsub protocol. This means the oracle itself is not capable of manipulating the generated result.

DIA Random supports any onchain application requiring unpredictable and unbiased random numbers. Common use cases include onchain gaming, lotteries, prediction markets, NFT minting and launches, random trait generation, fair reward distribution, and any protocol that needs provably fair selection mechanisms.

Key risks include the oracle temporarily stopping data delivery, a specific round being missed, or the oracle serving compromised data. Mitigations include checking that the oracle has recent updates in its history, designing your dApp to fall back to the next available round if a specific one is unavailable, and verifying the associated BLS signature provided by drand. A full risk evaluation of the underlying drand protocol is available in the drand documentation.