An auditor who has a drand beacon has only part of the evidence needed to reproduce a Congrid verifier assignment. The comparison also needs the round's chain context, the eligible verifier addresses, their historical bond weights, the domain, selection parameters and the implementation that made the decision. A matching result is useful evidence of reproduction; it is not, on its own, proof that the beacon or the underlying state was authentic.
This guide presents a review worksheet for the published Congrid implementation. It does not describe a completed audit or assert the configuration of a live deployment. For the broader context, read What Is drand? Verifiable Randomness in Congrid.
What is being reproduced?
The Congrid round design at revision d219b30 describes deterministic, bond-weighted selection without replacement for each eligible publisher domain. Selected addresses are sorted for the stored assignment. In the drand-enabled path, the round seed combines the required beacon with chain and anchor inputs. A different chain version or configuration must be assessed on its own evidence.
Three questions should stay separate:
- Beacon: Was the required drand round obtained and verified using the intended network and scheme?
- Selection: Do the historical inputs and exact implementation reproduce the recorded verifier addresses?
- Website result: Did the assigned verifiers actually submit valid observations, and what did the application finalize?
A successful answer to one does not automatically answer the others. The beacon verification guide addresses the first question; this article focuses on the second.
Build an evidence manifest
| Evidence | Record for the historical round | Why it matters |
|---|---|---|
| Version and context | Chain ID, software revision, applicable parameters, assignment-creation height and round start | Identifies the rules and state snapshot to reproduce. |
| Beacon | Configured network identity, required round, signature, randomness and proof result | Distinguishes an accepted fixed-round beacon from an arbitrary response. |
| Seed and anchor | Full seed, preceding anchor height and block hash, drand round and randomness | Enables comparison with the published seed calculation. |
| Candidate set | Full eligible verifier addresses and the historical eligibility evidence, including active status, bond denomination, minimum bond and suspension state | Current membership may differ from the set used at creation. |
| Weights and task | Each candidate's bond amount at that state, domain and requested verifier count | Selection depends on more than the beacon and address-set hash. |
| Observed outcome | Stored assignment's verifier addresses and the source and height of each record | Provides a concrete result to compare against the reproduced output. |
The versioned round-creation and selection code records round metadata including an eligible-address-set hash and size. In that version, the set hash is derived from sorted addresses; it does not include their bond weights. Matching that hash can help check a reconstructed address list, but it cannot establish that the historical weights are correct. Historical state may require an archive or other reliable retained evidence; if it is unavailable, mark the reproduction incomplete.
Follow the comparison in order
- Pin the rules. Identify the deployed binary or source revision for the round, and retain the applicable historical parameters. A repository default or today's configuration is not proof of an older round's settings.
- Check the required beacon. Record the application-required round and network, then verify the proof and randomness using the applicable scheme. The drand specification and security model explain the protocol and its assumptions. A relay response alone is not a proof check.
- Recompute the round seed. Use the exact chain ID, round start, anchor height and bytes, beacon round and randomness bytes with the versioned seed function. Compare it with the recorded seed before testing selection. For input encoding, see drand vs. block hashes in assignment seeds.
- Reconstruct eligibility and weights. Apply the historical rules to the candidate records at the applicable state. Compare the sorted address-set hash and size with round metadata, then separately verify each historical bond amount.
- Reproduce the domain's selection. Use the exact domain, requested count, seed, candidate ordering and versioned selection code. Compare the final sorted addresses with the stored assignment. Do not substitute the relay-primary ordering for publisher verifier selection: those are different tasks.
- Write the outcome. Record matching checks, mismatches and unavailable inputs. A missing historical bond snapshot means the reviewer cannot establish a full selection reproduction from the address-set hash alone.
For the cited code, the per-domain draw uses the round seed combined with the domain. When the requested count covers all candidates, it returns the sorted full set; otherwise it makes weighted draws without replacement and sorts the selected addresses before storing the assignment. Bond-weighted selection concerns assignment formation, not a claim that verification votes or rewards use identical weights.
Illustrative draw: why historical weights matter
This is a fictional arithmetic example, not a real beacon, a computed hash or an observed Congrid assignment. Suppose the historical ordered pool is A, B, C with weights 2, 1, 1 and the requested count is two. The first draw's intervals are A: 0–1, B: 2 and C: 3. If the first deterministic pick were 2, B would be selected and removed. The remaining pool has total weight 3; if the next pick were 0, A would be selected. The stored result would be sorted as A, B.
Now suppose a reviewer accidentally uses later weights 1, 2, 1. Even with the same candidate addresses and the same hypothetical first pick 2, the intervals differ. This shows why an address-set hash does not replace a historical bond snapshot. The example does not predict which picks a real seed produces; an actual audit must execute the exact versioned algorithm with complete inputs.
Diagnose a mismatch before drawing conclusions
| First mismatch | Check next |
|---|---|
| Beacon round or proof | Network identity, required round, key, scheme and acceptance evidence. |
| Seed | Chain ID, Content Grid start, full anchor bytes, beacon bytes and exact encoding. |
| Candidate-set hash | Historical eligibility rules, suspension time, address normalization and state height. |
| Set hash matches but selection differs | Historical bond weights, requested count, domain, code revision and candidate order. |
| Selection matches but website outcome differs | Assignment timing, submitted evidence and finalization rules; this is a separate review. |
Do not label a mismatch manipulation without evidence. It may reflect a wrong snapshot, incomplete records or a version difference. If the beacon is unavailable, use the missing-beacon diagnostic. The Congrid verifier guide and publisher guides explain the operational roles; the audit above does not require making a transaction.