The drand API can return a specific randomness round when you put both the network identifier and round number in the request. For an application that has already chosen round R, a successful response for a newer round is not a substitute. Begin with the application's requirement, then fetch that exact round and compare the response.
This walkthrough uses mainnet quicknet round 42 as an intentionally historical, repeatable retrieval example. It is not a round to submit to Congrid today. The drand core guide explains the wider assignment workflow; the task here is constructing and reviewing an HTTP request.
Choose the network, round and API version
Write down three inputs before making the request: the intended network, its complete chain hash, and the required round number. Use the quicknet metadata checklist if the network identity is unresolved.
The official HTTP API overview distinguishes legacy v1 from REST-based v2. It currently lists v2 support on the drand.sh relays. Confirm support for the relay you use rather than assuming every public endpoint exposes both versions.
The following routes address a fixed round. The placeholders describe the URL structure; replace them with the complete values for your review.
| Interface | Fixed-round route | What identifies the network? |
|---|---|---|
| v1 | /{chain-hash}/public/{round} |
Complete chain hash |
| v2 | /v2/chains/{chain-hash}/rounds/{round} |
Complete chain hash |
| v2 | /v2/beacons/{beaconID}/rounds/{round} |
Beacon ID, such as quicknet |
See the official v1 chain-hash route, v2 chain-hash route and v2 beacon-ID route for their contracts. Both versions can identify a particular round. An API version and a drand network are separate choices.
Fetch the same historical round through v1 and v2
These shell examples issue public, read-only GET requests. They require curl; they do not install software, use a wallet or submit a beacon. The variables keep the full chain hash visible without repeating a long URL on one line.
DRAND_API='https://api.drand.sh'
DRAND_ID=52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971
DRAND_ROUND=42
curl -fsS --max-time 10 \
"$DRAND_API/$DRAND_ID/public/$DRAND_ROUND"
For v2, keep the network and round unchanged and use the documented chains route:
curl -fsS --max-time 10 \
"$DRAND_API/v2/chains/$DRAND_ID/rounds/$DRAND_ROUND"
The v1 request and v2 request were opened directly during this review on November 4, 2026 at approximately 15:03 UTC. Their returned fields differed:
| Observed field | v1 response | v2 response |
|---|---|---|
round |
42 | 42 |
signature |
Present | Present; identical full hex string |
randomness |
Present | Not included |
This observation establishes a field comparison for those two requests. It does not establish BLS proof validity, endpoint uptime over time or live Congrid configuration. Preserve the complete response when you repeat the exercise; a screenshot of an abbreviated signature is insufficient for a later proof check.
The field difference matters for consumers. A program expecting a randomness field cannot assume an unchanged parser will work after replacing a v1 URL with a v2 URL. Check its response handling and verification path before changing interfaces.
Compare the response with the requirement
Record the requested round before inspecting the returned one. If the response says 43 while the application requires 42, stop that review path and preserve the mismatch. Do not relabel 43 as 42 or change the expected round merely to make the comparison pass.
The documented v2 latest route retrieves the most recent round. That is useful when “most recent” is actually the application's rule. A fixed-round workflow needs the specified round even when a newer beacon is available. Repeating a request to latest later can also return a different round, making an incident record harder to reproduce.
Successful retrieval is one checkpoint. The official client-library guidance recommends clients that verify retrieved randomness. Keep the expected network key and scheme, proof-verification result, and application acceptance evidence alongside the HTTP observation. Matching a response's round field alone does not authenticate its signature.
Understand Congrid's documented fetch contract
The published Congrid drand reference describes one chain-selected drand round when drand is enabled. Its verifier worker queries the requirement, waits until publication time and retrieves the exact unfilled round through the v1 chain-hash route. It does not replace that requirement with latest.
At the same reviewed revision, fetchDrandRound builds that URL, checks for a successful HTTP status, decodes JSON, rejects a different returned round and requires nonempty randomness and signature fields. Those are retrieval and payload checks. The chain's separate acceptance rules check the required round and cryptographic proof.
Consequently, the v2 response shown above is not a drop-in replacement for that published fetcher's expected payload. Treat an interface migration as an implementation review with tests. This source inspection describes published code, not confirmation of which software or parameters a running deployment uses.
Diagnose one failure at a time
| Observation | Next evidence to collect |
|---|---|
| Connection or timeout failure | Exact relay, request time and client error |
| Fixed-round route returns 404 | Chain identifier, requested round and whether its publication time has passed |
| Successful response has a different round | Original request URL and full returned body |
| Expected field is absent | API version, actual field names and consumer parsing requirements |
| Retrieval passes but proof verification fails | Expected key, scheme, verifier version and exact verification error |
| Proof passes but application rejects it | Application requirement and acceptance-state evidence |
The fixed-round API references document 404 for a missing chain or round; that status alone does not identify the cause. Avoid changing the network, round and API version together, since that obscures which difference mattered.
Close the review with a compact record: environment, expected chain hash and round, exact request URL, UTC observation time, response fields, comparison outcome, verification outcome and remaining application check. Mark an unperformed check as pending. For Congrid operations, continue with the verifier guide and monitoring checklist when the question moves from HTTP retrieval to worker and assignment behavior.
Reviewed November 4, 2026. The Congrid documentation and fetcher cite revision ed2f617, shown as their latest public file revision at review. The round-42 observations are read-only retrieval comparisons; no production beacon transaction or cryptographic verification was performed for this article.