A block hash and a drand beacon answer different questions in a verifier assignment design. A block hash anchors a calculation to a particular chain history; a drand beacon supplies a public, verifiable value from an external randomness network. In the documented Congrid design, the drand-enabled seed combines both inputs. Assessing that design means checking when each input becomes known, how it is authenticated, and what happens if the beacon is unavailable.
For the broader context, start with What Is drand? Verifiable Randomness in Congrid. This guide focuses on comparing inputs and reviewing a seed, not on proving an individual assignment was correct.
Compare the two inputs
| Question | Chain anchor | drand beacon |
|---|---|---|
| What does it identify? | A specified block height and hash in a chain's history. | A specified round and public randomness from a particular drand network. |
| What evidence matters? | Chain ID, anchor height, block hash and the applicable chain history. | Network identity, required round, signature, randomness and verification against the configured key and scheme. |
| What can delay use? | Availability and finality of the relevant chain history depend on that chain. | Beacon generation, retrieval, verification and acceptance are separate dependencies. |
| What should a reviewer ask? | Who could influence block production or timing, and when was the hash known? | Was the round fixed before participants could adapt, and was its proof checked? |
A block hash can be useful as an anchor without being a safe standalone randomness source for every application. The risks depend on the chain, participants, timing and stakes. drand's discussion of on-chain randomness describes predictable or manipulable inputs and other implementation pitfalls. Public randomness is also not secret: once a beacon is available, anyone can read it.
How the documented Congrid seed combines them
In the published seed implementation at revision d219b30, the drand-aware function hashes a formatted sequence containing the chain ID, Content Grid round start, anchor height, anchor hash, drand round and drand randomness. The same file also contains an anchor-only function and an older compatibility function. Their existence alone does not establish which path a running chain used.
The Congrid drand reference at revision ed2f617 describes the enabled path: the chain requires a particular drand round, checks its signature and randomness, and waits for it before creating assignments. In that documented path it does not silently fall back to block-hash-only randomness when the beacon is missing. The chain anchor remains an input after the beacon is accepted.
These are source and documentation claims, not a statement about a particular deployment's current version or settings. To establish an actual round's path, obtain its chain configuration, software revision and historical state. An anchor-only helper is not evidence that a missing beacon was bypassed on an enabled chain.
Worked input review
Imagine a fictional test fixture, not a production round: chain ID demo-chain, Content Grid start 1700000000, anchor height 100 with hash bytes 0a0b, drand round 42, and randomness bytes 0102. The drand-aware helper formats its inputs conceptually as:
demo-chain|1700000000|100|0a0b|42|0102
It hashes the UTF-8 payload with SHA-256 to derive a seed. The short byte values here are labels for illustrating the encoding, not a valid beacon or evidence of a successful signature check. In a real review, use the complete bytes and the exact implementation revision; leading zero bytes and numeric formatting matter. Do not substitute an independently fetched latest beacon for the required round.
If two reviewers start with the same complete inputs and code, the seed calculation should reproduce. If their results differ, compare the chain ID, round-start timestamp, height, full anchor hash, drand round, full randomness bytes and encoding in that order. Matching seeds alone do not establish that the inputs were authentic, that the eligible verifier set was correct, or that a selection was fair.
A practical evidence checklist
- Identify the implementation. Record the chain ID, software revision, relevant drand-enabled setting and the Content Grid round start. Verify these for the historical round under review rather than relying on defaults.
- Anchor the chain context. Record the exact height and full block hash, with a source for the historical chain state.
- Identify the beacon. Record the configured network identity and required drand round. Keep the published beacon, its signature and the proof-verification result with the record. See the beacon verification checklist.
- Reproduce the seed. Use the exact code revision and complete bytes; compare the result with the recorded chain outcome where that evidence is available.
- Review the next stage separately. Capture the historical eligible verifier set, bonds and selection rules before attempting to reproduce assignments. A seed is only one input to the outcome.
- Record missing evidence. If the required beacon has not been accepted, use the missing-beacon diagnostic and distinguish an unavailable value from a failed proof.
Security and availability are separate
The drand security model states assumptions about setup, participating nodes and network behavior. Checking a signature can establish that a beacon matches the configured key and scheme; it cannot by itself prove that a key was chosen correctly, that the required round was fixed at the right time, or that the surrounding application is free of bias. Likewise, a deterministic hash cannot make already-known inputs secret or automatically eliminate a participant's influence over input selection.
An external beacon adds a delivery dependency. Under Congrid's documented enabled rules, waiting protects the prescribed input choice, but an unavailable required beacon can delay assignment creation. Review that tradeoff against the application requirements and maintain an evidence trail; do not infer uptime or a production incident from this example.
Congrid's verifier guide explains the verifier role, while the round-mapping guide shows how the documented required round is calculated. For general publisher and verifier workflows, see the Congrid guides.