/
beginner · ~8 min read

Start here — what is VRF, and why hardware?

Before we get into code: a 3-paragraph orientation. If you already know what a VRF is, skip to Quickstart.

The problem, in plain words

Smart contracts can't generate a random number by themselves. Every node that validates the blockchain must compute the exact same state — so if you call Math.random(), each node gets a different value and consensus breaks. You need randomness that comes from outside the chain but that nobody (including the oracle) can predict or manipulate.

That's what a VRF (Verifiable Random Function) is for. A VRF produces a random value and a proof that the value came from a specific, committed-ahead source. If anyone cheats, the proof fails verification and the chain throws it out.

your dAppasks for a numberVRF oraclerolls, signs, sendsyour dAppverifies, uses itrequestvalue + proof
FIG 01 · the VRF pattern · request → signed result → on-chain verify

Why DICE uses hardware instead of software

Most VRFs use a cryptographic key held by an oracle. The oracle claims: I committed to this key, here's the signature. That works, but it puts a lot of trust in the oracle operator — if they leak or misuse the key, they can bias outcomes.

DICE replaces the software key with an ESP32-S3 microcontroller that generates random bytes from a hardware noise source inside the silicon. The chip then signs the value with a key it generated itself and never exposes. The oracle cannot leak a key it has never seen.

dimensionsoftware VRF (typical)DICE · hardware
source of randomnessprivate key + HMACsilicon RNG + in-chip signing
key custodyoracle operator holds itdevice holds it · never exits
collusion riskoperator + validatoroperator + ≥4 physical devices
bias resistancetrust the oraclecommit-reveal · no single node biases
cost per requestvariable · subscription0.002 SOL · flat
FIG 02 · a side-by-side · not exhaustive

What a DICE round actually does

A single request plays out in four moves. The whole thing takes about four seconds, end to end.

01

request

your program calls request_randomness. 0.002 SOL charged.

02

commit

six nodes each generate a byte, hash it, and publish the hash.

03

reveal

once all six commits are on-chain, each node reveals its byte.

04

finalize

program XORs the bytes, signs the result, delivers to your callback.

FIG 03 · one round · ~4 seconds · six nodes

Note

You do not need to understand commit-reveal in detail to use DICE. The SDK hides all of it behind a single request_randomnesscall. This section exists only so you know what you're asking for when you call it.

What you can do with it

A

Gaming · game outcomes

Dice rolls, card shuffles, raid-boss selection. Players can verify results came from hardware.

B

DeFi · raffles & lotteries

Weekly prize pools, airdrop lotteries, launchpad picks. Unbiased and auditable.

C

NFT · trait generation

Assign rarity, pick mint order, reveal traits. Cryptographically fair.

Next steps