A drand round number identifies a scheduled beacon within a particular network. It is not the same thing as a Congrid verification round. To map the latter to the former, you need a verification start time, the drand network's genesis time and period, and the offset used by the application.
This guide works through the arithmetic with an invented fixture. It does not describe an observed production requirement. For the wider context, start with what drand does in Congrid.
Start with two separate clocks
A Congrid verification round is an application schedule. A drand beacon round belongs to a particular drand network. The same numeric label in both systems has no inherent relationship.
The drand specification says round 1 starts at the network's genesis time. For a timestamp at or after genesis, the scheduled drand round is:
round = floor((timestamp - genesis) / period) + 1
All three values must use the same unit, normally Unix seconds. This maps a time to a scheduled round; it does not prove the beacon was actually delivered or accepted.
Apply the Congrid cutoff
The published Congrid reference describes subtracting the configured offset from the next verification round's start. That cutoff selects the latest scheduled drand round at or before it. The versioned scheduling implementation implements this mapping and rejects a cutoff before genesis.
- Record the intended Content Grid verification start in UTC and Unix seconds.
- Subtract the configured offset to get the latest allowed beacon time.
- Subtract the drand genesis time, divide by the positive period, round down, and add one.
- Recover the scheduled beacon time as
genesis + (round - 1) × period. Confirm it is no later than the cutoff. - Compare the result with the chain's actual requirement and network identity before fetching anything.
The reference describes quicknet defaults, including a three-second period and a 60-second offset. Defaults in documentation are not evidence of the values currently configured on a particular deployment. Obtain the relevant chain state and historical parameters for the round under review. The quicknet metadata checklist explains which network fields to record.
A worked example in UTC
Use a fictional genesis of Unix 1700000000, or November 14, 2023, 22:13:20 UTC; a three-second period; and a 60-second offset. Suppose the verification start is Unix 1700000073, or 22:14:33 UTC.
- Cutoff: 1700000073 − 60 = 1700000013 (22:13:33 UTC).
- Elapsed time since genesis: 13 seconds.
- Required drand round: floor(13 / 3) + 1 = 5.
- Round 5's scheduled time: 1700000000 + (5 − 1) × 3 = 1700000012 (22:13:32 UTC).
The scheduled beacon time is one second before the cutoff. This fixture does not claim that such a network exists or that a real beacon was produced.
Test the boundaries
Keep the same fictional genesis, period and offset. These examples vary only the verification start; each cutoff is 60 seconds earlier.
| Verification start, Unix seconds | Cutoff relative to genesis | Required drand round | Scheduled time relative to genesis |
|---|---|---|---|
| 1700000071 | +11 seconds | 4 | +9 seconds |
| 1700000072 | +12 seconds | 5 | +12 seconds |
| 1700000073 | +13 seconds | 5 | +12 seconds |
At the exact boundary, round 5 is eligible. One second earlier, round 4 is the latest scheduled round. Before genesis, the cited Congrid implementation returns an error instead of applying this arithmetic to a negative interval.
Separate calculation, retrieval and acceptance
A correct calculation identifies a scheduled round, not a successful delivery. A clock, network identifier, offset or timestamp mismatch can lead two reviewers to different results. A relay can be unavailable even after the scheduled time. Record the requested chain hash, target round, returned fields and timestamps; do not substitute a latest response for the required fixed round.
Use the exact-round API guide to inspect a response and the beacon verification checklist to distinguish network identity, proof validity and digest checks. Finally, inspect the application's recorded requirement and submission status: a valid signature alone does not establish chain acceptance.
Review checklist
- Are the verification start, offset, genesis and period from the right chain and the relevant point in time?
- Are timestamps consistently in UTC and Unix seconds, rather than milliseconds?
- Does the cutoff fall at or after genesis, and is the period positive?
- Have you tested one second before, exactly at, and one second after a beacon boundary?
- Does the calculated beacon time fall at or before the cutoff, with the next scheduled beacon after it?
- Do the chain requirement, fetched network and round, proof checks, and recorded acceptance agree?
For operational context, see the verifier guide and monitoring checklist. Treat differences as evidence to investigate, not as proof of a production incident.