Selection modes
Every round produces the same 32-byte result; what differs is who picks the devices. Streaming is the fast default, audit is the reproducible one.
Two modes, same output
DICE supports two ways to pick which devices participate in a round. They're interchangeable — your callback code is identical — but they live at opposite ends of a latency / verifiability trade-off.
- Streaming (default): the off-chain coordinator picks the subset of online devices. Fastest path end-to-end.
- Audit: the on-chain program picks the subset using a Fisher-Yates shuffle seeded by
SlotHashes. Anyone can reproduce the selection from chain data.
Comparison table
| Streaming (default) | Audit | |
|---|---|---|
| Who picks devices | Coordinator · off-chain | Program · on-chain Fisher-Yates |
| Seed source | Coordinator-local | SlotHashes sysvar |
| Avg round latency | 4.05 s | 4.15 s (+8%) |
| p95 | 4.62 s | 4.93 s |
| Verifiable selection | — | Yes · reproducible |
| Fee | 0.002 SOL | 0.002 SOL |
| Best for | Gaming · UX-critical | Regulated · RWA · high-stakes |
Numbers above are real 50-round devnet benches on production hardware (v7.7 streaming / v7.5 audit).
Streaming mode
The coordinator maintains a rolling list of online devices, sorts them by liveness, and picks the top-n ready nodes when a request lands. Fast, simple, and works well because commit-reveal aggregation already makes the output unbiasable — which devices end up in the set doesn't matter for the security property.
Streaming is the right choice for games and interactive dApps. The trade-off is that selection is not publicly reproducible: if a regulator asks "why these four devices," the answer is "whichever four were fastest to ack" — defensible, but not by-construction.
Audit mode
The program reads the current SlotHashes sysvar as an unpredictable seed, then runs Fisher-Yates over the registered-device list to pick the exact n devices. The selection is a pure function of on-chain state, so anyone with a full node can replay it.
This is what you use when a third party (auditor, regulator, insurance carrier) needs to verify from chain data alone that a specific set of devices produced a specific result. A full walk-through of the reproduction is on On-chain selection.
✓ Flip per-round
You can switch modes per request by passing the selection preference in the client-side account list — you don't need to deploy a new program or run a new coordinator for it. Most teams start streaming and move individual high-stakes rounds to audit.
How to choose
- Default: streaming. It's the faster, simpler answer and it retains the full cryptographic guarantee.
- Switch to audit if you need to answer an auditor's "reproduce it from chain data" question, if you're serving a regulated RWA flow, or if your users won't accept coordinator authority over device selection.
- Don't split by stakes. Decide on the property your dApp needs once — latency or reproducibility — and commit to it. Mixed modes in a single user session are surprising to end users.