Fastex security record

In the contract `Casino` the role `OWNER_ROLE` has authority over the functions shown in the diagram below.  Any compromise to the `OWNER_ROLE` account may allow the hacker to take advantage of this authority and - Withdraw owner profit to arbitrary addresses - Migrate to a new fabric contract - Withdraw instantly from player channels - Add/Set available games - Lock/Unlock FastChannel and partner - Transfer `OWNER_ROLE` to other address In the contract `FastChannelV3Fabric` the role `CasinoSigner` has authority over the following functions: - serverStep() - updateStateAsUser() - updateGameStateAsUser() - updateStateAsServer() Any compromise to the `CasinoSigner` account may allow the hacker to take advantage of this authority and modify the game states inside of the fabric contract. In the contract `BaseGame` the role `Owner` has authority over the following functions: - setBetProperties() Any compromise to the `Owner` account may allow the hacker to take advantage of this authority and modify the `minBet`, `maxBet` and `maxWin`.

The functions `updateStateAsServer()` and `updateGameStateAsServer()` should only be accessible to the backend server according to their naming. While in the current implementation, these two functions enable the player to choose the signer of the signature, who can create arbitrary messages. For instance, the signer could collude with the channel player and sign an incorrect `balanceChange_`, allowing the player channel to receive more assets from the casino contracts than intended through the function `_changeBalanceByFC()`. Besides, the signer can manipulate the internal game states using the `updateGameStateAsServer()` function, which could potentially facilitate cheating. For instance, they could increase the `freeSpinStateIndex` to obtain additional free spin opportunities. ```solidity=267 function updateStateAsServer( address channelAddress_, uint256[] memory gameNonces_, int256 balanceChange_, uint32 newNonce_, bytes memory sSign_, address signerAddress_, bytes memory uSign_) public { require(recoverSigner(signerAddress_, uSign_) == V3Channels[channelAddress_].player, 'Error: Wrong signature for setting signer'); require(V3Channels[channelAddress_].nonce + NONCE_JUMP <= newNonce_, 'Error: New nonce should be higher than existing one'); require(recoverSigner(channelAddress_, gameNonces_, balanceChange_, newNonce_, sSign_) == signerAddress_, 'Error: Wrong signature'); V3Channels[channelAddress_].nonce = newNonce_; V3Channels[channelAddress_].nonceList = gameNonces_; _changeBalanceByFC(channelAddress_, balanceChange_); emit ServerUpdatedState(channelAddress_, balanceChange_, newNonce_); } ```

The current withdraw function provides a 3-hour window (defined by FRZ_HRS) for the casino contract to update its internal states. We would like to understand if it's possible for the casino to fail to update the states within this timeframe, potentially allowing users to withdraw an incorrect amount of assets from the channel.

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

We did not find any unit test files, and there is no `test` folder in the project. ``` js npm test ./test/[fileName].js. Will test all functions in that file ```

Contracts in this project are serving as the underlying entities to interact with the backend `Casino server` and privileged role `signer`. The scope of the audit treats out-of-scope entities as black boxes and assumes their functional correctness. However, in the real world, these entities can be compromised and this may lead to lost or stolen assets.

The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.