VMREQ — The Dice Roller¶
One-line pitch: VMREQ is the game's randomness source. Whenever Dysnomia needs a random number — token supply caps, identity entropy, reward jitter — it asks VMREQ. Plumbing — you don't call it directly.
What this is¶
VMREQ generates verifiable random values for other contracts to consume. It exposes a View() function returning a Faung struct with the current randomness payload. Unlike the CHATLOG stack (YI → ZHENG → ZHOU → YAU → YANG → SIU), VMREQ sits off to the side as an entropy service.
If you've played a web3 game before¶
- Closest analogy: Chainlink VRF — verifiable random function. Public, tamper-resistant randomness.
- Or: a block-hash-based RNG with extra mixing.
- Or: a commit-reveal RNG packaged into a callable contract.
| Dysnomia term | What it maps to |
|---|---|
| VMREQ | Randomness service |
| View() | Returns the current Faung randomness struct |
| Faung | The randomness payload format |
What you actually do with it¶
- Nothing directly. VMREQ is read when other contracts need a random value.
Rewards / costs¶
- Cost: none directly.
- Reward: none — infrastructure.
Requirements & gating¶
- None for players.
Where it connects¶
Consumed anywhere the system needs entropy: token mintToCap sizes, identity generation flavor, reward jitter.
Quick FAQ¶
Q: Is VMREQ truly random? A: Within the constraints of on-chain randomness, yes — it's deterministic from inputs (so it's verifiable) but unpredictable in practice (no one can cheaply predict future outputs).
Q: Can I use VMREQ in my own contract?
A: It's public, so yes — call View() to read the current payload.
Want the Solidity? The contract reference lives at
technical/docs/core/00b_VMREQ.md.