A public drand beacon and a Congrid verifier assignment are connected by a delivery step. In the published Congrid design, a verifier service retrieves the required beacon and submits it to the chain, where the application checks it. The word “relay” can refer to different components in that path, so identifying the actor is the first step in understanding a delay.
This guide describes the published Congrid drand reference and verifierd implementation at revision ed2f617. It is a reference workflow, not a report of the live network's configuration or health. For the overall architecture, start with what drand does in Congrid.
Two meanings of relay
A drand HTTP relay exposes public beacon data to clients. The official API guide lists endpoints and notes that client libraries can verify beacon signatures. The drand security model distinguishes public-facing relays from drand nodes participating in randomness generation.
Congrid's delivery role is different: its verifierd service consumes a beacon and can submit it to the Congrid chain. Running that consumer is not evidence that the operator runs a drand node or belongs to the beacon network.
The documented delivery path
When drand is enabled, the Congrid reference describes these stages:
- Requirement: chain state names one drand round needed for the next Content Grid verification round.
- Wait: verifierd polls that requirement. A required beacon may be announced before its scheduled time; the worker waits rather than treating an early absence as a failure.
- Eligibility: participating verifier services calculate a deterministic primary and ordered fallbacks using the required round and active verifier information. Each service waits until its own eligible time.
- Fetch and submit: an eligible worker fetches the named network and exact round from a configured HTTP endpoint, then attempts delivery to the chain. A newer “latest” response is not a substitute for the specified round.
- Acceptance and assignment: the documented chain rules check the required round, signature and randomness digest. Once the required beacon is accepted, the application can use it with chain context to create assignments.
For the time-to-round calculation, see the round-mapping guide. For payload fields and proof checks, use the API walkthrough and signature checklist.
Who is responsible for what?
| Stage | Actor in the documented design | Evidence to retain |
|---|---|---|
| Beacon generation | drand network | Network identity and scheduled round |
| Public availability | HTTP relay | Endpoint, requested round, response or error time |
| Application delivery | Eligible verifierd primary or fallback | Requirement, rank, eligible time and submission result |
| Acceptance | Congrid chain | Required round and recorded acceptance or rejection |
| Website checks | Assigned verifier workers | Assignment and submitted check evidence |
A successful HTTP response establishes retrieval only. A valid proof is another observation; chain acceptance and subsequent assignment creation need their own evidence.
Example: an illustrative fallback timeline
Suppose a required beacon is scheduled for 12:00:00 UTC, and the requirement is still unfilled. With the reference defaults of a 60-second stagger and 180-second maximum delay, the scheduling formula in the cited implementation gives this illustrative eligibility order:
| Delivery rank | Earliest eligible time in this example |
|---|---|
| Primary, rank 0 | 12:00:00 UTC |
| Fallback, rank 1 | 12:01:00 UTC |
| Fallback, rank 2 | 12:02:00 UTC |
| Rank 3 and later | 12:03:00 UTC |
These are eligibility times, not promises of transaction submission or acceptance. Actual polling, connectivity, current verifier set, configuration and chain state affect what happens. If acceptance occurs earlier, later workers should see that the requirement has been filled. The numbers above are an example using documented defaults, not an observation of a live round or an outage.
Review a delivery without assuming the cause
Record the same time zone and chain context throughout the review:
- Capture the required Content Grid round, drand chain hash, beacon round and scheduled time; note whether the requirement is pending or already submitted.
- Record the software revision, relevant stagger and maximum-delay settings, and the active verifier snapshot used for the review. Reference defaults may differ from deployed settings.
- Compare the worker's rank and eligible time with its poll and fetch observations. A wait before eligibility can be normal.
- Separate an endpoint error, a wrong-round response, proof rejection and a chain submission failure. Preserve the exact evidence and time for each stage.
- Check whether chain state records acceptance and whether assignments were subsequently created. Avoid inferring either from a worker log alone.
The verifier monitoring guide provides a broader service-review process; the verifier page explains the operator role. A completed review identifies the stage supported by evidence, even if the cause remains unknown.