drand quicknet is an unchained public randomness network with a three-second beacon period, as described in its official launch reference. When an application expects quicknet, choosing a reachable relay is only one part of the setup. The network metadata must also match the application's intended source of randomness.
Use this checklist to review that identity before investigating individual beacon rounds. The drand core guide explains how public randomness fits into Congrid verifier assignments; this article focuses on the metadata comparison.
Establish the expected network first
Start with a trusted reference for the application and record the environment you intend to use. Identify mainnet or testnet explicitly. The current drand developer guide distinguishes quicknet from other mainnet networks, while the launch reference documents a separate quicknet-t testnet identity.
The protocol specification distinguishes the operator-assigned beacon ID from the chain hash, which serves as a cryptographic network identifier. A familiar name is useful for navigation; the complete identity fields are what your review should compare.
Write down the expected metadata before looking at the response you are investigating. Otherwise, it is easy to copy an unexpected value into the expected-value column and accidentally approve the mismatch.
Build a quicknet metadata worksheet
The table summarizes the quicknet reference fields used in this review. Compare complete values from the linked references when preparing an integration record.
| Field | Reference value or source | Review question |
|---|---|---|
| Beacon name | quicknet |
Is this the intended mainnet environment? |
| Chain hash | Full value below | Does the complete identifier match? |
| Public key | Full public_key in the trusted reference |
Does the entire expected key match? |
| Scheme | bls-unchained-g1-rfc9380 |
Does the application support this scheme? |
| Period | 3 seconds | Are the value and units correct? |
| Genesis time | 1692803367 Unix seconds |
Is the same timing origin recorded? |
The quicknet chain hash listed in the developer guide is:
52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971
For the public key, preserve and compare the complete value. A matching prefix, suffix or abbreviated screenshot is insufficient for an identity check. Keep the source URL and observation time alongside the value so a second reviewer can repeat the comparison.
Inspect the information response without overstating the result
The quicknet information endpoint returned a beacon ID of quicknet, the chain hash above, the stated scheme, a period of 3 and a genesis time of 1692803367 when reviewed on November 3, 2026 at 15:02 UTC. Its complete public key also matched the published Congrid reference constant checked below.
That is an observed metadata comparison. It does not report a BLS verification of a randomness round or establish the configuration of a running Congrid chain. Keep those conclusions in separate fields in your review record.
The current HTTP API documentation provides information routes organized by beacon ID and chain hash. Follow the documentation for the interface you use and preserve the exact request address; avoid assuming every relay or API version has identical routes.
Compare Congrid's reference defaults with deployment evidence
Congrid's published default constants define the same quicknet chain hash, public key, scheme, three-second period and genesis timestamp used in this comparison. This establishes agreement with that source revision, not the settings of a live deployment.
The Congrid drand reference also documents a 60-second round offset. Keep this application parameter separate from quicknet's three-second beacon period. An offset and a beacon period describe different parts of scheduling, even though both are measured in seconds.
For a deployment review, record the software version and obtain the relevant configuration or chain-state evidence through the documented read-only workflow. If that evidence is unavailable, leave the deployment comparison unresolved. Changing a reference value merely to match a response removes the discrepancy without explaining it.
Route mismatches to a specific next check
Consider a hypothetical team reviewing an application that expects mainnet quicknet. One configuration sheet was copied from a testnet experiment. The relay responds normally, but the recorded identity differs from the intended mainnet reference. Successful retrieval does not resolve that environment mismatch.
Use a short decision table rather than changing several settings at once:
| Observation | Next useful check |
|---|---|
| Name looks familiar, chain hash differs | Recheck the intended network and environment |
| Chain hash matches, public key comparison fails | Preserve both complete values and investigate their sources |
| Scheme differs | Review the network reference and the application's scheme support |
| Timing fields differ | Check units, environment and configuration revision |
| All metadata fields match | Record that result, then proceed to round and proof checks |
These are diagnostic examples, not reported outages or test results. Preserve the original expected and observed values before making a configuration change.
Close the review with evidence another operator can use
A useful record contains the intended environment, trusted reference and revision, exact request URL, observation time, complete identity fields, comparison result and remaining question. Assign an owner to any mismatch and retain the previous record after a correction.
For Congrid operations, the verifier guide explains the current participation workflow. Use the monitoring checklist when reviewing service and assignment observations. Network metadata checks support that work, while website-check results, reader traffic and protocol rewards each require their own evidence.
References reviewed November 3, 2026: Congrid constants at revision d219b30 and drand documentation at revision ed2f617. The reviewed files matched their current public default-branch versions. The endpoint observation above is a metadata comparison, not a live Congrid configuration audit.