Tutorial shows agents how to verify relayed drand randomness in 30 lines

A tutorial published on dev.to walks through verifying randomness drawn from drand's public beacon inside an agent or script in roughly 30 lines of code, so that a random decision — who reviews a pull request, which test case runs, how a tie breaks — can be checked by anyone instead of resting on trust in whichever HTTP endpoint happened to serve the number.

What drand publishes

drand is a public randomness beacon operated by the League of Entropy, a group of independent organizations. According to the dev.to post, its quicknet chain publishes a round every three seconds. Each round consists of a BLS signature over the round number, and the randomness value is the SHA-256 hash of that signature. Because checking a round requires only the chain's public key, anyone can verify one offline, without asking drand for permission.

Where the trust gap appears

Most agents do not call drand directly; they call an HTTP relay that forwards beacon data. That reintroduces the very trust question the beacon was meant to remove. The post's author runs one such relay, Proof Random API, a free prototype with no accounts or payment that returns the latest quicknet round as flat JSON. Notably, the response includes a verified: false field: the relay does not check signatures and says so plainly. Verification, the author argues, belongs on the consumer's side, against keys the consumer pinned in advance.

Verifying a relayed beacon

The core rule from the tutorial is to never read the public key from the party whose data you are checking. Instead, hard-code quicknet's chain hash and public key, both published by drand. Then, using the official drand-client package from npm, fetch the same round number the relay returned directly from drand's own HTTP endpoint with signature verification enabled, and compare the signature and randomness values.

If the relay lied, tampered with a value, or replayed the wrong round, the comparison fails and the code throws an error. Once the check passes, the relay is reduced to a delivery convenience rather than a trust anchor. The full client, including input checks and timeouts, is published as verified-client.mjs in the author's GitHub repository, and the author notes that anyone who prefers to skip the relay entirely can point fetchBeacon at drand directly — the verification code stays the same.

Getting an unbiased integer

Naively computing randomness % 6 skews results toward lower values. The tutorial instead hashes the chain hash, round number, randomness, a caller-supplied nonce and an attempt counter with SHA-256, reads a 32-bit integer from the digest, and applies rejection sampling: values at or above the largest multiple of the desired range are discarded and the counter increments, up to a limit of 1000 attempts. Since every hashed input is public, anyone holding the round number and the nonce can recompute exactly the same integer — the post frames it as a die roll that anyone can replay.

The limits of the approach

Verification proves the number came from drand; it does not prove the caller did not shop for a favorable round. An agent can query the latest-round endpoint, dislike the result, and query again, and nothing in that endpoint design prevents it. For draws that must be fair even against their own operator, the post recommends that all parties agree on a future round number and the nonce before that round is published, then verify that specific round when it appears. The author's relay only serves the latest round today, so it suits sampling and tie-breaks rather than prizes, and the post is explicit that the relay makes no claim to be a VRF.

Why it matters

As agents take on more decisions that look arbitrary from the outside — assignments, ordering, sampling, allocation — the question of proving a choice was genuinely random becomes an operational requirement rather than a nicety. drand's design turns that into a reproducible check: a third party with the round number, the nonce and the pinned keys can re-derive the outcome and confirm nothing was fudged. The tutorial's broader lesson generalizes beyond randomness: intermediaries are fine for convenience, but anything they hand you should be verifiable against parameters you chose yourself. The stated limits — re-rolling the latest round, and the need to commit to future rounds for high-stakes draws — mark exactly where this pattern is safe and where stronger commitments are required.