Versus-X security record

The function `approveFrom()` is a public function without any access control. It can be called by anyone to manipulate allowance information between arbitrary token owners and spenders such that hackers can easily steal tokens from any token owner.

The public function `mintVersusxToUser()` does not have any access control such that anyone can call it to mint arbitrary amount of tokens to any address. And it does not update total supply after minting, which may cause other critical bugs.

In the contract **VERSUSX**, the role **MetaKeepLambdaOwner** has authority over the following functions: - setEskillzBet() In the contract **VERSUSX**, the role **Owner** has authority over the following functions: - mintMore() In the contract **VERSUSX**, the address **ESkillzBet** has authority over the following functions: - mintMore() Any compromise to the **MetaKeepLambdaOwner/Owner/ESkillzBet** account may allow a hacker to take advantage of this authority and mint an arbitrary amount of tokens to any address.

The payload of low level call should be constructed using one of `abi.encodeWithSelector()`, `abi.encodeWithSignature()`, `abi.encodeCall()`. If the first parameter is function signature string, then `abi.encodeWithSignature()` must be used. `abi.encodePacked()` only concatenates parameters tightly; it does not translate function signature to function selector and does not have proper padding for `userAddress` which is required for low level call payload. Even if an user provides correct function signature and user address, the identified low level call will always fail. And even worse, the function signature is not restricted and can point to any function, a hacker can construct a malicious function signature which points to functions like `approveMax()` to possibly steal tokens from the contract.

When tokens are minted, `_totalSupply` must be updated to reflect the total amount of existing tokens. Otherwise there will be inconsistency between the sum of token balances from all owners and `_totalSupply`, which may cause critical bugs.

The following three functions can be invoked to call the "CreateSPGame/CreateMP/JoinMPGame" function in the "ESkillzBet" contract. The implementation of these functions is unknown; however, based on the function names, they might not be functions that should be accessible to everyone: * approveAndCreateSPGame * approveAndCreateMPGame * approveAndJoinMPGame

In the contract `VERSUSX`, there are payable `receive()` and `executeMetaKeepLambdaTransaction()` functions which can receive native tokens; but there is no way to transfer native tokens out of the contract. Thus all the received native tokens will be locked and lost in the contract.

The identified EIP712 implementation in the code is not standard compliant: it is clearly different from OpenZeppelin EIP712 implementation. It may lead to major compatibility issue.

The contract declares and interacts with the out-of-scope contract `ESkillzBet`. The scope of the audit treats out-of-scope contracts as black boxes and assumes their functional correctness. However, in the real world, out-of-scope contracts can be compromised and this may lead to lost or stolen assets.

Why does the VERSUSX contract need to inherit the "MetaKeepLambda" contract? It appears that the only feature utilized is the access control (e.g., onlyMetaKeepLambdaOwner), which could be achieved with the `Ownable` or `AccessControl` modules from the OpenZeppelin library. The auditor would like to know why the inheritance of "MetaKeepLambda" is deemed necessary.