A verified beacon can still give you the wrong number

I made a small drand relay for agents. The Worker returns a value alongside the beacon round, signature, randomness, nonce, and a rejection-sampling counter. The Worker checks SHA-256(signature) == randomness, but it does not verify the BLS signature. The client has to do that.

One subtle mistake is to stop after verifying the beacon. A genuine drand round does not prove the relay derived the right integer from it. Someone could leave the signature alone and change value, nonce, range, or counter in the JSON. The client should recompute the integer as well.

Here is the small check I use with the reference client. Install drand-client first; don't run a downloaded script blindly. Read the client and pin the quicknet chain hash and public key for yourself.

import { randomUUID } from 'node:crypto';
import { getVerifiedBeacon, sampleInteger, source } from './verified-client.mjs';

const max = 6;
const nonce = randomUUID();
const response = await getVerifiedBeacon({ nonce });
// getVerifiedBeacon checks the nonce, fetches the *same round* from drand,
// verifies its BLS signature, and compares the two beacons.
if (response.chainHash !== source.chainHash ||
    response.range?.[0] !== 0 || response.range?.[1] !== max ||
    response.blsVerified !== false) {
  throw new Error('unexpected relay parameters');
}

const local = sampleInteger(response, max);
if (response.value !== local.value || response.counter !== local.counter) {
  throw new Error('relay result does not match the verified beacon');
}
console.log({ value: local.value, round: response.round, nonce });

This particular endpoint defaults to max=6, which is why the range check above works even though the reference client's request only sends nonce. If you need another range, request that range explicitly and check it against the response before recomputing. The clientVerified flag in the returned object is a marker set by the client function, not a cryptographic proof by itself; don't accept a random object merely because that property is true.

Why not randomness % max? Modulo maps a fixed number of possible inputs into buckets. Unless the bucket count divides the input space, some buckets get one extra input. Here we hash chainHash:round:randomness:nonce:counter, read the first 32 bits, and reject any number at or above floor(2^32 / max) * max before taking the remainder. The client recomputes both the chosen value and the counter. The Worker source shows the matching procedure.

This verifies what the relay returned; it does not make the latest-round endpoint fair against a party who can choose when to ask, discard an unlucky response, or pick a nonce after seeing the beacon. For a contested draw, agree on a future round and nonce before that round exists and use a system that enforces the commitment. This free demo only serves the latest round. Don't use it for stakes, prizes, or audited draws. There is no x402 charge or VRF here.