BetFin security record

In the contract `LuckyRound` the role `TIMELOCK` has authority over the functions shown in the list below. - `addService()`: This function allows adding a new address to the `SERVICE` role. - `setMinBetAmount()`: This function sets the minimum amount required to place a bet. Any compromise to the `TIMELOCK` account may allow the hacker to take advantage of this authority and could potentially add malicious addresses to the `SERVICE` role, enabling further unauthorized actions within the contract. And an attacker could adjust the minimum bet amount to either a prohibitively high or trivially low value, disrupting normal betting activities and potentially manipulating betting outcomes to their advantage. In the contract `LuckyRound` the role `SERVICE` has authority over the functions shown in the list below. - `claimBonus()`: This function allows claiming bonuses accrued to a player's account. Any compromise to the `SERVICE` account may allow the hacker to take advantage of this authority. Additionally, the `LuckyRound` contract inherits the `AccessControl` contract from OpenZeppelin, the `DEFAULT_ADMIN_ROLE` role has the following authorities within the contract: - `grantRole()`: Grants specified roles to an account, allowing it to perform actions associated with that role. - `revokeRole()`: Removes specified roles from an account, restricting it from performing certain actions. If the `DEFAULT_ADMIN ROLE` is compromised, an attacker could grant critical roles to unauthorized addresses, effectively allowing them to manipulate the contract. The attacker could also revoke roles from legitimate addresses, disrupting the normal operation and administration of the contract.

The contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. --- ```solidity=50 StakingInterface public immutable staking; ``` - The contract `Stones` interacts with third party contract with `StakingInterface` interface via `staking`. --- ```solidity=51 CoreInterface public immutable core; ``` - The contract `Stones` interacts with third party contract with `CoreInterface` interface via `core`. --- ```solidity uint256 private immutable created; uint256 private immutable subscriptionId; address public immutable vrfCoordinator; bytes32 public immutable keyHash; uint32 private constant callbackGasLimit = 2_500_000; uint16 public constant requestConfirmations = 3; uint32 private constant numWords = 1; constructor( uint256 _subscriptionId, address _core, address _staking, address _vrfCoordinator, bytes32 _keyHash, address _admin ) VRFConsumerBaseV2Plus(_vrfCoordinator) { // validation for vrf coordinator is not needed because it is already validated in the VRFConsumerBaseV2Plus contract vrfCoordinator = _vrfCoordinator; keyHash = _keyHash; subscriptionId = _subscriptionId; core = CoreInterface(_core); require(core.isStaking(_staking), "ST06"); staking = StakingInterface(_staking); created = block.timestamp; _grantRole(DEFAULT_ADMIN_ROLE, _admin); } ``` Since they are immutable or constant, the project team needs to ensure that the `vrfCoordinator` is always callable, and that the `keyHash` and `subscriptionId` are always valid, as well as that the `callbackGasLimit` is sufficient to execute the `rawFulfillRandomWords()` callback. In particular, the project team needs to prevent the risk of request failures caused by an invalid `subscriptionId`. It means the project team need to ensure that the request sent by calling `requestRandomWords()` in each round correctly triggers the callback.

The `getCurrentRound()` function calculates the current round based on the current `block.timestamp`, and its result is compared with the `_round` provided in the calldata. However, the `block.timestamp` at the time of transaction execution is unpredictable.

```solidity=268 uint256 playerBonus = (bonus * playerShare) / bonusShares; ``` Due to integer division, it may be that not all BOUNS tokens can be claimed by users, ultimately leading to a small amount of BOUNS tokens being locked in the contract.

If the number of players placing bets within the `ROUND_DURATION` does not reach the `BETS_LIMIT`, any user can use the `requestCalculation()` function to complete the random number request, execute the results, and distribute the rewards. However, because the `winnerOffset` is randomly generated, there is insufficient incentive for users to actively call `requestCalculation()`.

The contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=38 address public immutable core; ``` - The contract `LuckyRound` interacts with third party contract with `CoreInterface` interface via `core`. --- ```solidity=95 address _core, ``` - The function `LuckyRound.constructor` interacts with third party contract with `CoreInterface` interface via `_core`. --- ```solidity uint256 private immutable subscriptionId; address public immutable vrfCoordinator; bytes32 public immutable keyHash; uint32 private constant callbackGasLimit = 2_500_000; constructor( address _core, address _staking, address _admin, uint256 _subscriptionId, address _vrfCoordinator, bytes32 _keyHash ) VRFConsumerBaseV2Plus(_vrfCoordinator) { require(_vrfCoordinator != address(0), "RO01"); vrfCoordinator = _vrfCoordinator; keyHash = _keyHash; subscriptionId = _subscriptionId; created = block.timestamp; core = _core; token = CoreInterface(_core).token(); require(CoreInterface(_core).isStaking(_staking), "L01"); staking = _staking; fee = CoreInterface(core).fee(); _grantRole(DEFAULT_ADMIN_ROLE, _admin); } ``` Since they are immutable or constant, the project team needs to ensure that the `vrfCoordinator` is always callable, and that the `keyHash` and `subscriptionId` are always valid, as well as that the `callbackGasLimit` is sufficient to execute the `rawFulfillRandomWords()` callback. In particular, the project team needs to prevent the risk of request failures caused by an invalid `subscriptionId`.It means the project team need to ensure that the request sent by calling `requestRandomWords()` in each round correctly triggers the callback.