Frequently asked questions

#Can I test without ESP32-S3 hardware?

Yes. tests/harness/mock_firmware_node in the DICE repo simulates 10 devices running the real CBOR protocol and ECDSA signing. It runs on your laptop, talks to your local validator, and exercises every code path the real fleet does. Use it for CI and for local development. When you deploy to devnet, point your channel at the public DICE devnet coordinator — no hardware changes on your side.

#What if my dice_callback panics?

The randomness isn't lost. It landed on the DiceChannel account in a prior transaction — still on chain, still signed by the hardware, still publicly readable. Two ways to recover:

1. Ship a fixed callback in a program upgrade and call deliver_callback again with the stored round_id. DICE re-CPIs you with the exact same bytes, so the replayed handler sees deterministic input.

2. If the panic was a transient account state issue (e.g. your game PDA wasn't initialised yet), fix the precondition and retry — same result.

#How do I make it provably unbiased?

Three properties already hold:

1. Any one honest device in the N-of-N set makes the output uncontrollable by all others combined — SHA-256 aggregation, not XOR.

2. Commits land on chain before any reveal is published — no node can pick its share after seeing others.

3. Every reveal is signed by hardware — software-only impersonation is not possible.

For the strongest version of the guarantee, switch to audit mode. It adds on-chain device selection so the whole round is reproducible from chain data.

#Is the randomness compatible with my EVM port?

Yes. DICE emits a 32-byte uint256-sized randomness in the same shape Chainlink VRF and Pyth Entropy use on EVM chains. If you're porting a game from Ethereum, the outcome formula is usually a copy-paste — the only thing that changes is the callback signature (EVM uses a function selector + ABI-encoded args; Solana uses an Anchor discriminator + Borsh).

#Is DICE on mainnet?

The program is deployed and audited on devnet with the IDs listed on the overview page. Mainnet rollout is gated on fleet size — we aim for 20+ physical devices online before flipping the switch. Track the current status on the explorer.

#What happens if the coordinator goes down?

Your caller experiences round timeouts — RoundTimedOut after the configured window. The channel balance is not debited on a timed-out round, so you don't pay for a round that didn't finish. New requests will queue and resume when the coordinator comes back up.

The protocol supports coordinator rotation: the channel stores a single coordinator pubkey that can be re-bound by the authority. We run redundant coordinators in production.

#Can one program have multiple callbacks?

Yes. The callback method name is always dice_callback (because the discriminator is baked into DICE's CPI), but you can have multiple channels per program, each with its own channel_index, and dispatch inside dice_callback based on result.channel_key. Use this pattern to split low-stakes and high-stakes flows, or to isolate different games inside a single program binary.

#What does it cost to run a node?

The ESP32-S3 dev board is about $10 at bulk; our production housing adds ~$40. A node needs a USB host, which is any Linux server with a spare port — a Raspberry Pi 4 works. The coordinator talks to the node over USB serial only; no public IP required.

Operator economics: at 4 nodes per round, 0.002 SOL × 70% ÷ 4 = 0.00035 SOL per round. At 2,500 rounds/day and $150 SOL, a single node earns ~$130/month before compute. A Raspberry Pi + internet runs ~$10/month — operators break even within weeks at healthy throughput.