Randomness
A value nobody can steer
No commercial VRF provider is deployed on Robinhood Chain, so draws commit to a future drand round and verify its signature on-chain.
Why not the alternatives
Chainlink VRF, Pyth Entropy, Supra dVRF and Gelato VRF all exclude this chain as of writing. Chainlink has other services live here, but not VRF.
A blockhash-based commit-reveal would work mechanically but carries a sequencer-bias problem on a chain with a centralised sequencer — the party ordering transactions also influences the value being committed to.
The flow
- On a draw request, commit to a drand round at a future timestamp — roughly two rounds ahead, about six seconds.
- Anyone may submit the signature for that round: the operator’s relayer or an unrelated third party.
- The contract verifies the BLS-on-BN254 signature against the known public key through the pairing precompile.
- randomness = keccak(signature).
Why this holds
The round is fixed before the request resolves, and no party can influence what its value will be — not the sequencer, not the relayer, not the operator. The relayer is fully untrusted: a wrong signature simply fails verification, and censorship is defeated because submission is permissionless.
Accepted risk
This leans on the League of Entropy threshold — a public good, not a paid service with guarantees. The beacon’s longevity is a soft commitment.
Mitigation is structural: the randomness router keeps beacon adapters swappable, so the source can be replaced without migrating pool state.
What the callback may not do
The randomness callback stores the random word and nothing else. It does not select, transfer, swap or settle. Token purchases in particular are pull-based and run in a separate transaction.
A swap inside a randomness callback is an unbounded-gas liability and a reentrancy surface, so the boundary is enforced as an invariant rather than left to convention.