Infrastructure
ZKasino 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.
These diamond contracts made by Nick Mudge have been used. Also OpenZeppelin's ERC-20 standard is used and their Reentrancy Guard.
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 be decentralised through bankroll pools. Liquidity providers will receive their share in revenue equal to the increase of the bankroll.
The Game Contracts can't be upgraded and are thus immutable.
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.
The owner of the Diamond Contract (bankroll) is a MultiSig. In the early phase the signers consist of ZKasino team members. The MultiSig-owner can call a few function on the bankroll:
withdrawNativeFundsandwithdrawFunds: withdraw tokens from the bankroll;- 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.
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.
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.
Additionally, a diamond proxy is utilized to upgrade the bankroll contract. This allows the contract owner to utilize the
diamondCut() function to add, replace, or remove functions.Type | Chain | Address |
|---|---|---|
MultiSig 2/3 (owner) | Polygon
Arbitrum | |
MultiSig signers | Polygon
Arbitrum
|
MultiSig signers follow these policies:
- 1.All signers must use one of the following desktop wallets (Metamask, WalletConnect, etc)
- 2.All signers must use an approved browser (Brave, Firefox, etc)
- 3.All transactions must occur on a dedicated browser instance (rather than a dedicated computer).
- 4.An approved VPN should be used for all transactions.
- 5.Committed in writing that the backup of keys are in multiple locations and protected from fire and flood
- 6.All signers on all access control addresses must sign a transaction at least once every 3 months. This can be an active transaction or a test transaction.
- 7.All access control transactions must be executed in a controlled space for example home or office. They should not be signed in public spaces such as coffee shops or airport terminals.
Last modified 2mo ago