Onchain Architecture

Onchain Game Architecture

Monk Onchain Game Architecture

1. Game setup & Wager:

   • A player initiates a game by sending a wager amount, VRF fee, and any relevant game parameters to the specified Monk game contract.

   • The wager and VRF fees are transferred to the Monk Game Hub contract. Any excess VRF fees are refunded to the player.

   • The Monk game contract calls the _requestRandomness function on the GelatoVRFConsumerBase contract. The GelatoVRFConsumerBase contract emits a RequestedRandomness event that acts as a beacon, signaling the Gelato VRF system about the need for a random number.

2. Fulfill randomness and payout wager

   • The VRF oracle generates a random number (sourced from Drand) and sends it to the game contract. The game contract uses the random number to generate the final result. The entire result selection process is transparent, fair, and immutable.

   • The Monk Game Hub gets notified of the game result and updates player stats, pays out winnings, and adds a portion of the wager to the Player Pool.

Note: If a VRF request fails or is not fulfilled, a player can cancel and refund the pending wager

---

Player Pool & Proposal Architecture

The Player Pool Proposal system allows the gamblers to submit and vote on proposals that handle the MONK tokens accumulated in the Player Pool.

Proposals can be either custom smart contracts or be deployed through our proposal launchpad.

Player Pool & Proposals Architecture

1. Submitting a Proposal

   • A user submits a proposal type & config to the Monk Game Hub.

   • When submitting a custom proposal, the deployed contract address is immediately stored in the Monk Game Hub, no additional deployment needed.

   • When submitting a non-custom proposal, the proposal type and config are sent to the proposal launchpad. The proposal launchpad routes the submission to the correct pre-approved proposal factory which then deploys the proposal and returns the contract address that is stored in the Monk Game Hub.

2. Ending Player Pool Round

   • The entire "Player Pool" is sent to the contract with the most votes.

   • A ProposalExecuted event is emitted and acts as a beacon for the Monk Data Oracles; if the winning proposal consumes from these oracles, the request is fulfilled.

   • The Player Pool round state is reset and the next round begins.