drand
- Name: drand
- URL: https://drand.love/
- Category: public randomness beacon / threshold-cryptography infrastructure / timelock-encryption primitive / crypto-adjacent network utility
- Summary: drand is best understood not as a generic RNG API, but as a shared public-beacon and timed-release cryptographic service run by a voluntary consortium. Its core mechanism is a threshold-signature network that collectively emits publicly verifiable randomness at fixed intervals and, in its newer timelock mode, lets users encrypt to a future round so data can only be decrypted when that round’s beacon is released. That makes drand a useful comparison case for randomness, sealed-bid, voting, and MEV-mitigation systems: the real control surfaces are consortium membership, distributed key generation and resharing, client-versus-relay verification, threshold assumptions, and whether downstream apps treat the beacon as a trust-minimized public primitive or quietly centralize around a few operators and relays.
- What it does:
- Runs a distributed randomness beacon that generates collective, publicly verifiable, unbiased, and unpredictable random values at fixed intervals
- Uses distributed key generation and threshold BLS signatures so no single node can produce or bias the final beacon output alone
- Is operated in production by the League of Entropy, a consortium of organizations that jointly maintain the public network
- Exposes public randomness through HTTP / REST, gRPC, and client libraries so downstream applications can fetch and verify beacons
- Supports timelock encryption by mapping future rounds to future times and using the future round’s randomness as a decryption key material source
- Frames use cases broadly across lotteries, voting, sealed-bid auctions, responsible disclosure, embedded-device bootstrapping, and MEV-prevention-style delayed reveal workflows
- Key claims:
- drand’s main reusable primitive is not only randomness; it is a shared public clock-plus-threshold-signature network. The timelock mode makes that especially clear because the same beacon infrastructure becomes timed-release cryptography.
- The biggest governance surface is the operator layer. The docs explicitly say applicants must apply to be considered for League of Entropy membership, so the beacon may be publicly consumable while remaining permissioned at the consortium layer.
- The GitHub README is especially useful because it makes the mechanism explicit: DKG creates a collective key, nodes produce threshold BLS signatures each round, and the signature is hashed into the published random output.
- drand is analytically useful for crypto research because it turns “public randomness” into a legible infrastructure stack with membership rules, threshold assumptions, relay distribution, and liveness risk, rather than a black-box helper service.
- The timelock encryption docs are a strong reason to keep drand in the active corpus. They make clear that future-round release timing can support sealed-bid auctions, voting, vulnerability disclosure, and MEV-prevention claims while also exposing a sharp failure mode: if a threshold of malicious nodes colludes or the network shuts down, the security or recoverability assumptions change materially.
- drand belongs in the corpus because it separates several layers that are often flattened together in cryptographic infrastructure discussions: beacon generation, consortium governance, client verification, timed-release encryption, and application-level fairness claims.
- Whitepaper: drand has relevant academic papers, but no single current product whitepaper appears to dominate the official docs. The strongest primary materials were the official site, docs, protocol repository, and linked papers on scalable bias-resistant randomness and timelock encryption; see
../whitepapers/drand-primary-sources-2026-05-10.md. - Sources:
Internal linkages
-
Keep this note on the strongest few downstream or adjacent reads: nois, pyth-entropy, and shutter-network.
-
drand is the source primitive. Those notes matter because they show what gets added afterward: delivery middleware, provider policy, or timed-release packaging.
-
Last reviewed: 2026-06-01 UTC