Infrastructure

SECURE BANKROLL

Jungle Casino uses one bankroll on each chain: the Diamond Contract. The Diamond Contract follows the diamond upgrade pattern described in EIP-2535: Diamonds, Multi-Facet Proxy.

The Diamond Contract holds the bankroll funds and handles the transactions and payouts to the players. The bankroll listens to the immutable BankrollFacet Contract to know how to execute transactions.

All Game Contracts communicate separately with the bankroll contract. For more information on how the contracts work with each other, visit the Architecture page. To see a list of all clearly labelled contracts, visit the Contracts page.

In a future update, the bankroll will probably be decentralised through bankroll pools. Liquidity providers will receive their share in revenue equal to the increase of the bankroll.

ACCESS CONTROLS

The owner of the Diamond Contract (bankroll) is a MultiSig. In the early phase the signers consist of Jungle Casino team members. The MultiSig-owner can call a few function on the bankroll:

• withdrawNativeFunds and withdrawFunds: withdraw tokens from the bankroll;

• setGame: give game contracts access to the bankroll or remove access;

• setTokenAddress: add token contracts to the bankroll to perform wagers in or remove tokens contracts.

CertiK's audit Notes: It should be observed that players' bets are not moved to the BankrollFacet contract until the games have concluded. Therefore the bets are not directly impacted by the specialized functions mentioned above.

There is no timelock since it is vital to act quickly and to be able remove games from the bankroll or withdraw funds in the early stage. Player's wagers are never at risk (see the Architecture page). Furthermore, every Game Contract has a function that the MultiSig-owner can invoke to withdraw VRF fees:

• transferFees: withdraw VRF fees paid by players in native token from Game Contracts to the bankroll.

The Game Contracts can't be upgraded and are thus immutable.

Plinko and Mines

The game contracts Plinko and Mines have a multiplier function, but these do not affect immutability or centralisation. An explanation:

1. The function Plinko.setPlinkoMultipliers() is needed because it is not possible to set all the Plinko multipliers at once. This exceeds the gas limit, because a lot of data goes into setting the multpliers. Most importantly, the function can't be re-used once the multipliers are set. The function can only be invoked once.

2. The function Mines.Mines_SetMultipliers() has no input, it is only math. Therefore, the team also considers Mines not to be affected by centralization.