Chainlink-VRF-compatible
randomness for Robinhood Chain.

Pricing

Same model as Chainlink VRF: you pay the exact gas your callback consumed plus a premium, plus a flat fee. Billed on fulfillment, straight from your subscription.

payment = (gasUsed × gasPrice + l1Fee)
          × (100 + premium) / 100
          + flatFee

Why Randomhood

What is Randomhood?

Randomhood is a randomness service for Robinhood Chain with the Chainlink VRF v2.5 interface. Your contract requests random words from a coordinator, a registered oracle fulfills them with a signed proof the coordinator checks on chain, and your contract receives the result in a callback. The proof is an ECDSA signature, not an elliptic-curve VRF proof, so read the trust model before you use it for anything valuable.

How much does a request cost?

The gas your callback actually consumed plus a 24% premium, plus a flat fee of 0.0005 ETH, charged to your subscription when the request is fulfilled. Subscriptions are funded with native ETH, or with the configured ERC20 token where one is set.

Do I have to rewrite my consumer?

No. The request struct, the extra-arguments tag and the callback entry point are byte-for-byte the Chainlink VRF v2.5 shapes, so existing tooling and integration code carry over. Point your constructor at the coordinator and change nothing else.

What do I pay with?

The ETH you already hold on Robinhood Chain. No bridge and no second token to acquire. An ERC20 can be configured instead, with a price feed and a stale-price fallback, the way LINK payments work.

How fast is a fulfillment?

A few blocks after the request, once the confirmations you asked for have passed. On testnet a demo roll settled about thirty blocks after it was made.

Can the operator cheat?

Yes, in one specific way: it can choose the result. Nobody else can forge or predict one, because every response is signed by the registered oracle key and bound to a block hash the chain itself attests. But an ECDSA signature is not unique. The key holder is free to pick the nonce, so it can sign the same seed many times, see every outcome those signatures produce, and submit the one it likes. That is selection, not a slight bias, and it is the trust assumption of this design. Do not use Randomhood as it stands where a chosen outcome would be profitable enough to be worth taking.

What would remove that trust?

A proof that is unique per seed, so there is nothing to choose between. Two routes are open. The coordinator supports a bridge mode where a relay on the parent chain buys real Chainlink VRF v2.5 randomness and delivers it over the canonical Arbitrum bridge, with exactly one VRF request per request id so nobody can re-roll; it is written and tested but not yet deployed. The other is replacing the signature check with an on-chain ECVRF or BLS verifier. Either way the consumer interface does not change, because the proof check is one isolated function.

What if my callback reverts?

The request closes and your subscription is still billed, exactly as with Chainlink VRF. Never re-request randomness for the same outcome.