A drand response is useful only when the application can establish that it came from the intended network and corresponds to the required round. A successful HTTP response is a retrieval result; it does not by itself establish that the signature is valid or that Congrid accepted a beacon.
This guide provides an evidence checklist for a developer or operator reviewing that boundary. For the broader integration, start with what drand does in Congrid. To obtain a specific response first, use the exact-round API walkthrough.
Start with trusted inputs
Before looking at a response, record the network and environment the application intends to use, its trusted distributed public key, scheme, chain hash, and expected round. Obtain these from an independently trusted reference for the deployment under review. A public endpoint reporting a key is not, by itself, independent proof that the endpoint returned the expected key.
The drand developer guide distinguishes mainnet networks and recommends client libraries that verify retrieved values. The quicknet metadata checklist offers a field-by-field worksheet. Reference defaults describe published software; recording live settings requires separate deployment or chain-state evidence.
Work through four separate checks
| Check | Question | Evidence to retain |
|---|---|---|
| Identity | Do the expected key, scheme and network match the intended environment? | Trusted reference, full values and source revision |
| Round | Does the response match the round the application requires? | Requirement, request URL and returned round |
| Signature | Did a compatible verifier accept the proof for that key and round? | Verifier version, result and error if any |
| Randomness | Where randomness is supplied, does it match the digest of the signature? | Full input fields and comparison result |
Do not mark a later check as passed merely because an earlier one succeeded. A matching chain hash alone does not verify a beacon signature. Likewise, the digest check ties two fields together but does not authenticate a forged signature.
The official client-library documentation describes libraries that verify rounds. Select a library and configuration that support your network and scheme; retain the actual verification result rather than implementing a new cryptographic check from a search snippet. The protocol specification explains that an operator-assigned beacon ID and the chain hash play different roles.
Read the response for the API you actually used
A response's fields depend on the interface. The documented v1 example includes a round, signature and randomness; the v2 quicknet example contains a round and signature. The HTTP API overview documents both versions. If a response omits a separate randomness field, do not invent a returned value or report that a field comparison passed. Follow the supported client's scheme-specific verification and derivation behavior.
For the published Congrid implementation reviewed here, the verification code at revision ed2f617 decodes the supplied hex fields, compares the supplied randomness with SHA-256 of the signature bytes, and verifies the recovered signature using the configured public key and supported scheme. Its supported unchained scheme branches differ. The digest check occurs before signature verification in this reference; a digest match is not a substitute for the latter.
A hypothetical invalid-proof review
Suppose a team expects round 42 from a particular network. A response has round 42 and a signature field, but the configured verification library rejects the signature against the team's independently recorded key and scheme. The team must not use the value simply because the round and JSON shape look right.
Preserve the full response, expected round, complete key, scheme, client version and exact error. Confirm that the intended environment and inputs were selected. If they are correct, treat the proof as unverified and investigate the data source and verifier; do not silently swap keys or change the required round to make the error disappear. This is a hypothetical diagnostic scenario, not a report of an incident or a production test.
A second hypothetical response might have a signature and a mismatching supplied randomness field. That fails the consistency check in the cited Congrid implementation even before signature validity can be established. Record both failures separately when they occur; do not conclude that a digest mismatch alone explains every possible signature failure.
Separate proof validity from Congrid acceptance
The published Congrid drand reference describes a chain-selected fixed round when drand is enabled. It states that the chain rejects wrong or duplicate rounds and checks the signature and randomness digest before accepting a submission. Its documented path then uses an accepted beacon in deterministic verifier assignment creation.
An independently verified proof does not show that a particular live chain accepted it. For that conclusion, retain evidence of the chain requirement and acceptance state from the relevant environment, along with the software version. Conversely, a valid beacon does not establish that a publisher's website passed its later checks. The verifier monitoring guide and verifier page cover the separate operational workflow.
Close the review with an evidence record
- Name the deployment, environment, expected network and trusted key source.
- Record the application-required round and full response fields without shortening the proof.
- Record the compatible verifier and version, scheme, result and any exact error.
- Record a randomness comparison only when its inputs and derivation are appropriate to that interface.
- Mark chain acceptance as verified only when there is actual acceptance evidence; otherwise leave it pending.
- Assign an owner to mismatches and preserve the original evidence before changing configuration.
The drand security model describes assumptions and availability considerations behind the beacon. Proof validity, relay availability, application acceptance and downstream website verification answer different questions.
Reviewed November 5, 2026 against official drand documentation and Congrid's published revision ed2f617. The examples are hypothetical; no production proof verification, transaction or live configuration audit is claimed.