ZKasino Documentation
WebsitedAppTwitterTelegram
  • Welcome
  • Tokenomics
  • ZKasino Bridge
  • ZKasino Chain Testnet
  • ZKasino
    • Roadmap and FAQ
    • Responsible Gaming
    • Live Support
    • IPFS hosting
    • Mainnet Guide
    • Official Links
  • Platform
    • Glossary
    • Betting
    • Chains and Bet tokens
    • Self Exclusion
  • Developer
    • Contract addresses
    • Audits
    • Infrastructure
    • VRF Oracle
    • Architecture
    • Metaplay
    • Probability, Odds and House Edge
      • Dice
      • Plinko
      • Video Poker
      • Slots
      • Mines
      • Rock Paper Scissors
      • Coin Flip
    • Kelly-based bankroll management
    • Changelog
      • Game contracts v2.1
      • Game contracts v2.0
      • Contracts v1.0
      • Integrated VRFs (old)
      • Testnet Guide (outdated)
    • Testing
      • BNB Chain private fee testing
      • v2.1 private testnet WIP
      • v2.0 public testnet
      • v2.0 private testnet
      • multi-chain private mainnet with VRF
      • v1.1 public testnet
      • multi-chain private testnet with VRF
      • v1.0 public testnet
      • wip v1.0 private testnet
      • v2.1 public testnet
Powered by GitBook
On this page
  • Bankroll
  • Immutable Game Contracts
  • Access Controls
  1. Developer

Infrastructure

PreviousAuditsNextVRF Oracle

Last updated 1 year ago

Bankroll

ZKasino uses one bankroll on each chain: the Diamond Contract. The Diamond Contract follows the diamond upgrade pattern described in . 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 made by have been used. Also OpenZeppelin's is used and their .

For more information on how the contracts work with each other, visit the page. To see a list of all clearly labelled contracts, visit the 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.

Immutable Game Contracts

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.

Access Controls

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:

  • withdrawNativeFunds and withdrawFunds: 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.

  • 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.

MultiSig

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.

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 ). Furthermore, every Game Contract has a function that the MultiSig-owner can invoke to withdraw VRF fees:

EIP-2535: Diamonds, Multi-Facet Proxy
diamond contracts
Nick Mudge
ERC-20 standard
Reentrancy Guard
Architecture
Contracts
Architecture page
0x2f52AaC7cD0F8a83C15eE933F0b9c00F6A5A2f95
0xF0275f92bc1C69d2B7aF3eA9116e9174374cb479
0x62c4d57a469A21c0D1A5F39362195538174535E8
0x8cCf7C95C0C8EE89d3662b315bAfEc929464dee7
0xbbeB869bDe515b330b65f067AAef845D8c559CC5
0x62c4d57a469A21c0D1A5F39362195538174535E8
0x8cCf7C95C0C8EE89d3662b315bAfEc929464dee7
0xbbeB869bDe515b330b65f067AAef845D8c559CC5