Trust
Security model
What you trust
- A majority of the drand operators do not collude. The beacon is a threshold signature. If enough operators combined their shares early, they could compute a future round. That is a far higher bar than trusting one sequencer, one oracle company or one of us, but it is a real assumption.
- The BLS12-381 maths and the precompiles. The pairing check is standard; the precompiles are part of the chain.
- The contracts are correct. Two small files, 20 tests, no audit.
What you do not trust
- Us. There is no owner, no admin function, no upgrade proxy, no pause, no fee. We cannot change a draw, block a reveal or choose a number.
- The relays. They only carry data. A forged signature fails the pairing check.
- The page. Everything it shows can be recomputed with the engine or the contract.
Attacks considered
| Attack | Why it fails |
|---|---|
| Pick the round after seeing signatures | On chain, commit requires a round at least 2 rounds ahead of block.timestamp. Off chain, publish the commitment first. |
| Replay an old signature for a new round | The signature only validates for its own round number. |
| Forge a signature | The pairing check rejects it; one flipped bit is enough to fail. |
| A point outside the subgroup | The pairing precompile refuses it. Calls are gas-capped so the failure cannot burn the caller's whole transaction. |
| Front-run the reveal | The result does not depend on who reveals. Anyone can; the first one just pays the gas. |
| Bias through modulo | Rejection sampling discards the incomplete top block of the range. |
| Grind the list to reach a favourable seed | The list is hashed into the commitment before the round exists; changing it changes the hash and breaks the commitment. |
Residual risks
A sequencer can delay or reorder your commit transaction, which only shifts when the commitment lands, not what the round contains. If the commit lands after the round's time the contract rejects it, so you can only lose time, not fairness.