drand publishes values that applications can check against a distributed public key. That makes a beacon useful as evidence, but a valid proof does not answer every security question: a team still needs to choose the right network and round, account for delayed delivery, and review how its application turns the value into a decision.
Use the worksheet below to review those boundaries. For a general introduction and the Congrid data flow, start with What Is drand? Verifiable Randomness in Congrid.
Five separate properties to review
| Property | Question | What a check does not establish |
|---|---|---|
| Network identity | Is this the public key, scheme and chain hash the application intended to trust? | A valid signature under an unintended key does not identify the intended network. |
| Proof validity | Does the beacon verify for the required round under that key and scheme? | A valid proof does not prove delivery will always succeed or the application is unbiased. |
| Future unpredictability | What does the threat model assume about access to threshold shares and early partial beacons? | A public value is not secret after publication; timing advantages require separate analysis. |
| Availability | Can the required value be produced, fetched and accepted when needed? | A missing response does not by itself mean a proof is invalid. |
| Application choice | Were the round, participants and conversion rules fixed appropriately? | Hashing or verifying a beacon does not automatically fix selective retries, biased mapping or later manipulation. |
The official drand security model separates setup from generation and discusses their different assumptions. Its setup discussion includes participant authentication, timing and group-formation assumptions; its generation discussion addresses thresholds, availability and attacks involving early access. Consult the model for the network and scheme being evaluated rather than treating a summary as a guarantee.
A valid signature is a limited claim
A signature check ties a beacon to the configured public key and the rules used by the verifier. Before relying on it, identify how that key and network identity were obtained, whether the correct round was required, and whether the randomness field is consistent with the applicable scheme. The drand specification documents network metadata and schemes, and its developer guide points applications toward verifying clients.
Keep evidence for each stage: the expected network identifier, required round, response, signature-check result, and application acceptance. A successful HTTP request is a retrieval observation, not a cryptographic verification. The beacon verification checklist walks through the distinction.
Public does not mean secret
Once a beacon is published, anyone can use it. Do not use the published output as a secret key or password. Before publication, unpredictability is conditional on the protocol's security assumptions: the security model discusses the effect of an adversary obtaining a threshold of private shares and scenarios in which an adversary can see enough partial contributions early. A valid proof alone does not measure those conditions for a specific deployment.
For an application, specify when the relevant participants and choices become fixed relative to the selected beacon round. If someone can wait for a result and then choose among rounds, restart the process, or alter the eligible set, a valid beacon may still be used in a biased workflow. The right controls depend on the application; record who can make those choices and what prevents a favorable retry.
Availability is its own dependency
A threshold network and its relays can experience delays or interruptions. Fetching the same required round from an alternative source can help diagnose a relay problem, but it does not justify substituting a different round. Distinguish beacon production, relay retrieval, local verification and application acceptance in incident records. The drand HTTP API documentation describes available API versions; the missing-beacon diagnostic organizes the subsequent checks.
Congrid's versioned drand reference describes an enabled path that waits for one required beacon and does not automatically fall back to block-hash-only assignment creation. This is a documented implementation rule, not a live availability measurement or proof of a particular chain's configuration. Waiting preserves the chosen input rule while a missing beacon may delay assignment creation.
Worked threat-model worksheet
Consider a hypothetical system assigning two website checks from a registered verifier pool. The team intends to commit the eligible pool and the required beacon round before the beacon is available. This is an application review exercise, not a report of a Congrid production test or incident.
- Identity: Write down the intended drand chain hash, public key, scheme and where each was independently confirmed. Owner: application operator. Evidence: configuration snapshot and source used to confirm it.
- Timing: Record when the candidate set and round choice became fixed, and who could change either. Evidence: versioned rule plus a timestamped or chain-state record. If the set can change after the beacon is known, investigate that control before asserting fairness.
- Proof: Retain the complete required-round response and verification result. If the wrong round is returned, reject it according to the application's rules; do not call a newer response equivalent.
- Availability: Record a timeout and a failed signature as different outcomes. Specify who investigates each and what the application does while waiting.
- Selection: Preserve the historical candidate set and weights, the domain and implementation version. Compare the reproduced selection to the recorded result using the assignment audit worksheet.
- Outcome: Separately review website-check evidence and finalized results. A valid randomness proof does not certify a website or a verifier's observation.
The example's commitment rule is a proposed review criterion, not a claim that a particular Congrid deployment has demonstrated that timing. If the required evidence is missing, document the unanswered question instead of marking the whole system secure.
Review how random values become decisions
Even when input verification succeeds, application code can introduce bias. For example, reducing a value to a smaller range with a modulo operation may create uneven outcomes when the source range is not divisible by the target range. Review the actual algorithm and consequences for its use case; drand's discussion of on-chain randomness pitfalls covers this and other common mistakes. Do not infer the distribution of a deployed application from a generic example.
For Congrid, the published round-selection code and seed function are useful starting points for a version-specific review. Verify the historical software and parameters separately. The verifier guide explains the operational role, and the publisher guide explains website participation.