drand is a distributed randomness beacon: a system that publishes random values on a schedule so applications can verify their origin. Its name is pronounced “DEE-rand.” For Congrid readers, the practical question is where that public randomness enters the process of assigning website checks to verifiers.
This guide explains the connection using official drand documentation and Congrid's published implementation references. It also provides a small review worksheet you can use to separate a successful data fetch from evidence that an application used the intended beacon.
How drand produces verifiable public randomness
The official drand explanation describes a network of nodes that collectively generate randomness using threshold cryptography. During setup, participants establish a collective public key and individual private key shares. During generation, enough partial signatures are combined into a BLS signature; hashing that signature produces the public random value.
That gives an application a proof it can check against the intended network's public key. The network identity and verification rules matter along with the value itself. A JSON response containing a field named randomness is only the start of the integration review.
The developer guide recommends using drand client libraries that verify retrieved values. It also distinguishes the available networks, including quicknet. An application must identify which network and round its rules require before deciding that a response is usable.
Where drand fits in Congrid
Congrid's published drand reference describes an exact-round workflow when drand is enabled. The chain specifies a required beacon round, and delivery is embedded in verifierd. The chain checks the required round, the BLS signature and the randomness digest before accepting the beacon.
The diagram below summarizes that documented path. It describes the published implementation; it is not a live network-health report.
Public drand beacon for the required round
|
v
verifierd retrieves and delivers the beacon
|
v
Chain checks round, signature and digest
|
v
Accepted beacon + chain context -> round seed
|
v
Deterministic verifier assignments
|
v
Website checks and submitted evidence
The seed-derivation code combines chain ID, Content Grid round start, anchor height and hash, drand round, and drand randomness into a SHA-256 seed. These inputs give a reviewer something concrete to record rather than treating “uses randomness” as a complete design description.
The verification-round design describes deterministic, stake-weighted selection without replacement from the eligible verifier set. Reproducing a historical selection therefore also requires the relevant eligible-set and bond information. Having the beacon alone is not enough to reproduce the application's entire decision.
Keep the system responsibilities clear
A useful integration review gives each stage a specific question:
| Stage | Question to answer | Evidence to keep |
|---|---|---|
| Beacon identity | Which network and round are required? | Network reference and required round |
| Proof verification | Was the beacon checked under the intended rules? | Verification result and implementation version |
| Assignment creation | Which application inputs produced the selection? | Round metadata and historical selection inputs |
| Website verification | What did the assigned worker observe? | Website-check evidence and submission result |
| Content discovery | Which reader-facing recommendation was delivered? | Recommendation and referral records |
Congrid's homepage distinguishes off-chain recommendations, website checks and ledger consensus. Its architecture identifies drand as an input to verifier assignments. This makes the scope of the randomness step important: the seed supports assignment creation; the assigned workers still need to perform their website checks.
The verifierd reference describes polling assignments, waiting for scheduled starts, checking homepages and submitting results through commit–reveal. For operational checks on those services, use the published verifier monitoring guide.
Work through a round-selection example
Consider a hypothetical integration whose current requirement names beacon round R. An operator receives one response for R and another for R + 1. Both HTTP requests finish successfully.
The first review question is whether each response matches the application's requirement. A newer response does not automatically replace a previously specified round. Record the required round before comparing response fields, then check network identity and proof validity. Finally, look for application acceptance evidence.
This sequence prevents a common diagnostic shortcut: treating “the endpoint responded” as the answer to every later question. Keep four separate observations in the review note: what the application required, what was retrieved, what was verified, and what the application accepted. This example is a review exercise, not a reported Congrid incident.
Use a short integration review checklist
Before describing a drand integration as checked:
- Record the source revision and the deployed software version you are actually reviewing. Repository defaults describe a reference configuration; live settings need their own evidence.
- Identify the expected network and the application rule for selecting a round.
- Preserve the returned round and proof fields, plus the verification result. Record failures with their specific messages.
- Record whether the application accepted that beacon and which downstream operation used it.
- Keep availability observations separate from proof-validity observations. A missing response and an invalid proof call for different investigations.
The drand security model explains that setup and randomness generation have their own assumptions, including participant thresholds and network behavior. A verified beacon should be evaluated within those assumptions. It does not establish the availability or correctness of every system that consumes it.
Questions Congrid readers ask
Is drand the same thing as Congrid's blockchain consensus?
They have different responsibilities in the documented architecture. drand supplies public randomness for assignments; Congrid's consensus validators finalize the ledger. Evaluate each stage using its own evidence.
Do publishers need to operate a drand node?
The current publisher guide describes the domain, wallet, member badge and registration workflow. Operating a drand beacon network is a separate role from following those publisher instructions. The Congrid verifier guide covers the services used by verifier operators.
Does a valid beacon prove a website passed verification?
A beacon proof concerns the randomness step. A website's verification result requires the assigned checks and their evidence. Start with the publisher verification checklist when reviewing the homepage itself.
Use drand evidence to explain how an assignment was formed. Measure reader referrals, organic search performance and protocol rewards separately when reviewing the publication's wider results.
Implementation references reviewed November 2, 2026: Congrid drand documentation at revision ed2f617; seed, round-design and verifier references at revision d219b30. These references describe published behavior, not a confirmation of the live chain's current configuration.