drand

• Name: drand
• URL: https://drand.love/
• Category: public randomness beacon / timed-release threshold primitive
• Summary: drand is the public beacon anchor. The same threshold-signature network also gives you future-round release timing. Keep it for consortium membership, relay liveness, and the fact that downstream apps inherit those assumptions when they call it neutral infrastructure.
• 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:
  • https://drand.love/
  • https://docs.drand.love/
  • https://docs.drand.love/docs/overview/
  • https://docs.drand.love/docs/timelock-encryption/
  • https://github.com/drand/drand
  • https://eprint.iacr.org/2016/1067.pdf
  • https://eprint.iacr.org/2023/189

Internal linkages

• Keep this note on shutter-network.

• That is enough. drand is the source primitive here; lower-tier delivery and packaging notes should point upward rather than the reverse.

• Last reviewed: 2026-06-17 UTC