# drand turns a quorum of servers into a verifiable source of random numbers

> drand is a Go daemon that lets a group of independent operators produce publicly verifiable, unbiased random values at fixed intervals, using distributed key generation and threshold BLS signatures. It is dual licensed under Apache and MIT, ships as a released binary or a Docker image, and has a League of Entropy network behind it.

**drand/drand** — 🎲 A Distributed Randomness Beacon Daemon - Go implementation

- Repository: https://github.com/drand/drand
- Website: https://drand.love
- Stars: 848 · Forks: 137
- Language: Go
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/drand-drand

## Randomness that no single operator can predict

drand is a distributed randomness beacon daemon written in Go. Linked drand nodes collectively produce publicly verifiable, unbiased and unpredictable random values at fixed intervals, using bilinear pairings and threshold cryptography.

The motivation is spelled out in the README, and it is worth reading in full because it explains the design. Digital randomness matters for elections, lotteries, cryptographic parameter generation, embedded devices bootstrapping randomness and blockchain systems, and it matters outside software too, in statistical sampling, in assigning court cases to random judges and in random financial audits. But constructing a secure source of randomness is difficult, and the README points at a long list of attacks where the randomness generation was the culprit, including static keys, non-uniform distribution and biased output.

drand's answer is a Randomness-as-a-Service network, compared in the README to NTP servers for time or certificate authorities for verification. The network is decentralized, run by a diverse set of reputable entities with a threshold of them needed to produce a value, so there is no central point of failure. And any third party can fetch a value and verify its authenticity, which is what makes it usable in a lottery rather than merely in a demo.

The project started inside the DEDIS organization and moved under the drand organization in December 2019. The public network is run by the League of Entropy, which the README says includes Cloudflare, EPFL, Kudelski Security, Protocol Labs, Celo, UCL and UIUC.

The important caveat is that the guarantees are about the network, not about your connection to it. The value is verifiable; your ability to fetch it at the right moment is a separate problem.

## Setup is a key ceremony where nobody holds the whole key

A drand randomness beacon has two phases, and the setup phase is the one that determines whether the guarantees hold.

In setup, each node first generates a long-term public and private key pair. All of the public keys are then written into a group file together with the metadata needed to operate the beacon, and that group file has to be distributed to the participants. After the group file has been distributed, the nodes perform a distributed key generation, or DKG, protocol which creates the collective public key and one private key share per server.

The property the README highlights is that participants never see or use the actual distributed private key explicitly. They use their own key shares instead. That distinction is the whole point of a DKG: the signing key for the beacon never exists in one place, not even transiently, so there is no single machine whose compromise reveals it and no operator who could publish a biased value on their own.

It also means setup is an operation, not a command. A group file has to be agreed, distributed and then used, which for a public network means coordination between organisations in different countries. For a private deployment inside one company the coordination is easier, but the ceremony is still the part that needs a runbook.

## Generation is threshold BLS with a hash to remove byte bias

Once setup is done, the nodes switch to randomness generation mode, and the mechanism is more interesting than a hash of a timestamp.

Any node can initiate a generation round by broadcasting a message. All the other participants sign that message using a t-of-n threshold version of the Boneh-Lynn-Shacham signature scheme with their respective private key shares. Once any node, or a third party observer, has gathered t partial signatures, the full BLS signature can be reconstructed using Lagrange interpolation.

Reconstruction is the key property for verification. Because the signature is a threshold signature over a shared public key, anyone can check the resulting random value against the collective public key without talking to the nodes and without knowing anything secret. That is what makes the output publicly verifiable rather than merely trusted.

The last step is the part that people often miss. The signature is hashed with SHA-256 to ensure there is no bias in the byte representation of the final output, and that hash is the collective random value, verifiable against the collective public key.

The reason for hashing is that a signature is a point in a group, and mapping such a point to bytes does not distribute uniformly on its own. Hashing to a fixed width removes that bias, so the raw bytes you consume are as close to uniform as a hash can make them. Skipping that step would leave a statistical leak in a system whose entire purpose is to have none.

## Installing a node and where its state lives

There are three installation routes, and the README treats them as equally valid.

The first is the official release, where the instruction is simply to use the latest drand binary from the release page. The second is a manual install through Golang or Docker. The third is building the Docker image yourself, which the README gives as a single command with the version and commit taken from git.

```bash
docker build --build-arg version=$(git describe --tags) --build-arg gitCommit=$(git rev-parse HEAD) -t drandorg/go-drand:latest .
```

Where a node keeps its state is worth knowing before you start it. By default drand saves the configuration files, which include the long-term key pair, the group file and the collective public key, in the directory $HOME/.drand/.

The Dockerfile shows the runtime shape. The build stage uses a Go image and injects the commit and build date into the binary at link time, and the final image is busybox with su-exec and tini for process handling, plus the CA certificates that busybox does not ship. Two ports are exposed, 8888 and 4444, which are the public HTTP API and the private, authenticated API used between nodes. The home directory inside the container is /data/drand.

The Go module path is github.com/drand/drand/v2, so the major version is in the import path, and the go.mod file requires Go 1.26.8. The README badge says 1.25 or newer, so the module file is the stricter and more accurate figure.

## One codebase, three storage backends

The repository is organised so that the storage engine is a build time choice rather than a runtime setting, and the test matrix shows exactly which choices exist.

The Makefile has parallel sets of targets for unit tests, coverage and integration tests across boltdb, memdb and postgres, plus the same matrix for the demo application. The lint target runs golangci-lint three times, once for the default build and once for each of the memdb and postgres build tags, which confirms that the backends are compiled as separate variants of the same code.

The demo directory carries the same story, with a boltdb_test.go, a memdb_test.go and a postgresdb_test.go, a demo/ directory of configuration files, and a regression directory. The demo is the network you run locally to exercise the setup and generation phases end to end.

For a node operator the choice is fairly simple. bbolt, which is the embedded option in the dependency list, suits a single node that owns its state directory. PostgreSQL suits a deployment that wants its state in a database it already operates and backs up. The in-memory variant is for tests and for the demo.

What the repository does not spell out in the pages shown is a migration story between backends, so changing your mind later is a migration project rather than a configuration change.

## Releases, tooling and a dual licence

The project is releasing regularly. v2.1.8 was published on 2026-10-07, before v2.1.7 on 2026-07-22 and v2.1.6 on 2026-04-08, and the last push to the repository was on 2026-10-08, the day after the newest tag. A patch release roughly every three months is a normal cadence for a network daemon with a stable protocol.

The tooling around it is thorough. The repository carries a .golangci.yml, a .pre-commit-config.yaml, a .goreleaser.yml for release builds, a codecov.yml, a CODE_OF_CONDUCT.md, a SECURITY.md, a FUNDING.json, a DEVELOPMENT.md and a RELEASE.md. The lint step is a specific pinned version of golangci-lint installed by the Makefile.

```bash
go install github.com/golangci/golangci-lint/cmd/golangci-lint@v1.58.1
```

Observability is wired in rather than bolted on, with Prometheus client libraries, gRPC middleware for Prometheus, and OpenTelemetry instrumentation for both gRPC and HTTP along with an OTLP trace exporter. A network service that other organisations depend on needs to be debuggable from the outside, and the tracing setup reflects that.

On licensing, the repository contains both a LICENSE-APACHE file and a LICENSE-MIT file, which is the conventional way to offer a project under both terms, and a COPYRIGHT file. GitHub's own classification of the repository licence is recorded as a custom one it cannot categorise, which is what a dual licence often looks like to an automated classifier. Read the two licence files and pick the one that suits your distribution.

## When a randomness beacon is the wrong answer

drand is a heavy instrument, and there are two cases where it is the wrong one.

The first is when you only need unpredictable bytes inside one process. A system that generates a session token or a nonce can read from the operating system's random device, which is designed for exactly that and costs nothing. Standing up a beacon for that adds a network dependency, a key ceremony and a quorum requirement to a problem that the kernel already solves.

The second is when you need randomness that must be secret as well as unbiased. A beacon is built to be public and verifiable, which means the value it produces is published to anyone who asks. If your requirement is secrecy, this is the wrong tool, and you should look at a protocol designed for secret sharing instead.

There is a third, practical limitation. A beacon produces values at fixed intervals, and generation is a round of network messages among nodes. If a node is down or a threshold of participants cannot be reached, the round does not complete, and the application waiting on a value waits. The verification property is strong, but the liveness property belongs to the operators, not to the protocol.

Where drand earns its place is when a value has to be provably fair to everyone, including a sceptic who runs their own verifier. That is a different requirement from being random, and only a multi-party construction satisfies it.

## Conclusion

drand is the right tool when a system needs randomness that no single participant can predict or bias and that a third party can check, such as a lottery draw, a sampling audit or a key generation ceremony. It is the wrong tool for a single application that only needs unpredictable bytes from the operating system, since running a beacon involves a quorum of nodes, key ceremonies and network dependencies. Before adopting it, decide whether you consume the existing public network or run your own, read the storage backend options, because the daemon supports bbolt, in-memory and PostgreSQL stores, and pin a release tag rather than the master branch, since the module path already carries a major version of two.

## FAQ

### What is drand and what problem does it solve?

drand is a distributed randomness beacon daemon written in Go. Linked nodes produce publicly verifiable, unbiased and unpredictable random values at fixed intervals using bilinear pairings and threshold cryptography, so any third party can fetch a value and check that it was not tampered with.

### How does drand generate randomness?

Nodes sign a round message with a t-of-n threshold BLS signature scheme using their private key shares, and anyone with t partial signatures reconstructs the full signature through Lagrange interpolation. The signature is then hashed with SHA-256 to remove byte bias, and that hash is the random value, verifiable against the collective public key.

### How do I install drand?

You can use the latest drand binary from the release page, install it through Golang or Docker, or build the image yourself with docker build --build-arg version=$(git describe --tags) --build-arg gitCommit=$(git rev-parse HEAD) -t drandorg/go-drand:latest . The node stores its key pair, group file and collective public key under $HOME/.drand/ by default.

### Who operates the public drand network?

The README says a drand network is operated by a group of organizations around the world that includes Cloudflare, EPFL, Kudelski Security, Protocol Labs, Celo, UCL and UIUC, part of the League of Entropy, where the generated values can be watched in real time.

### What storage backends does the drand daemon support?

The Makefile and demo tests are split across boltdb, memdb and postgres variants, and the lint target runs separately for the memdb and postgres build tags. The embedded bbolt option suits a single node, while PostgreSQL suits deployments that keep node state in a database they already operate.

## Sources

- [drand/drand on GitHub](https://github.com/drand/drand)
- [Issues](https://github.com/drand/drand/issues)
- [Project website](https://drand.love)
- [README](https://github.com/drand/drand/blob/master/README.md)
- [Releases](https://github.com/drand/drand/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/drand-drand