The BTB contract at initialization sets the values of the pyth entropy and provider contracts. These generate the random used in the finalization of the spin execution. There is no setter for changing these values. For now, they are singular per chain, but any extreme circumstance that would requir

The admin of the protocol can update the spin fee by calling the `updateSpinFee` function. The spin fee is directly used during the current round and as such should not be changed during the round itself to not created disadvantages for early players. The function does check for it to be called af

When a spin is bought and played, depending on certain probabilities, the duration of the current round may increase or decrease. A variable, `impactedTime`, was created to track the time that has increased or decreased. This variable however is increased and decreased incorrectly due to how max ro

Throughout the codebase there is dead or redundant code: 1. The `BlastTheBalloonBase` inherits the `PausableUpgradeable` OpenZeppelin but it is never used by the `BTB` contract. Consider removing it. 2. `_msgSender` is used instead of `msg.sender`. If the project does not intend to support meta-tra

Throughout the codebase there are typographical errors: - BTBStorage.sol#L104: `Infdormation` -> `Information` - BTBStorage.sol#L290: `Palyer` -> `Player` - BTB.sol#L359: `ould` -> `old` - BTB.sol#L495: `exeted` -> `execute`

Within the `BTB` contract there are 2 cases where storage variables are shadowed (redeclared locally with the same name) by local variables. In the `buySpin` function the `spinFee` fee and in the `entropyCallback` function the `jackpotType` variable. In both of these cases there are no issues as t

When specific contract or round configurations are changed in the `BTB` contract, there are no events emitted. Events help on-chain analyzers and forensics in case of issues.

User won prizes can be claimed using the `claimPrize` function. This function will validate that guaranteed prizes exist before allowing the claim to be executed. Prizes such as prizes from previously won rounds and current minor jackpot wins. There are rewards that can change during a round, the ma

A user acquisition of a spin is a time sensitive operation, done within a specific time duration. If the transfer to the treasury does fail, this should not result in the transaction failing as the treasury transfer is not critical to game functionality.

On Blast, smart contracts can receive almost all the gas fees that users spent while interacting with it. This mechanism is, however, deactivated by default with the fees being sent to the blockchain sequencer. In order for the a smart contract to retain the fees, it must call the `configureClaimab

Smart contracts on Blast can earn yield on the native ETH that they hold. This feature however is opt-out by default on smart contracts in order to maintain as much as possible backward compatibility with code that may rely on the ETH balance to not change. In the case of Blast, yield is gained thro

A user can claim his prizes by calling the `claimPrize` function. Within this function, there is a check that there are enough funds in the contract for the rewards to be given out. This is done for better error handing on the dapp and improving gas consumption. ```solidity require(address(thi

Throughout the codebase there are several different versions of Solidity being targeted by the source files. In some cases ranges are accepted via the `^` operator.

When the admin creates a new game round, they provide the timestamp when the round starts. The only validation done specifically on the start time is that it must not be in the past. Since there are no limits to when the round can start, if an admin mistakenly provides an invalid value and starts i

When a users buys a spin via the `buySpin` function, the provided native ETH is split into 4 distinct payment destinations (with default values): - protocol treasury gain: 1% - major jackpot for next round: 3% - current major jackpot portion: 71% - current minor jackpot portion: 25% These 4 perce

For a user to claim his cumulated prizes prizes, he must call the `claimPrize` function. This function does not allow users to withdraw any potential rewards from the current game round. This check, however, is incorrectly implemented and a user can call the function and get the pending rewards exa

After a spin has been executed and depending on certain probabilities, the duration of the current round decreases. The chances of a round duration decreasing are 20% by default and can take the round duration down significantly or even to 0. This effectively moves the end date in the past and close

Users are allowed to buy a spin during the existence of a round, meaning between its start and end time (start time plus duration), including the end time. When a spin is bought, a random number generation is initiated via the pyth entropy contract. It takes the pyth contract [exactly 1 block](http

When a user buys a spin for a round, he must also supply a random number that will be used by pyth in the generation of the final random number. The final random number is used to determine if the user has won any prise. The user supplied random number will be used to determine which position in the

There are multiple smart contracts deployed that have not been verified on GnosisScan

Current test coverage is very limited. In the latest branch "for-audit" hardhat test cases from Aave have been removed, potentially due to compilation conflicts, as well in foundry, many of the test cases don't make the use of assert() to check for acceptable returns.

With the introduction of limits on deposits, borrow and collateral, there is no event emitted to register this admin action.

In LendingPoolAddressesProvider ( 0x3673C22153E363B1da69732c4E0aA71872Bbb87F ) you have 3 important roles: * Pool admin: can initialize, update, disable and configure assets/reserves * Emergency Admin: has the ability pauses or unpauses all the actions of the protocol, including aToken transfer

In the WETHGateway contract, there is a unchecked transfer of funds when attempting to withdraw directly to ETH.

Upon deposit of an asset to the LendingPool contract, there is the possibility that the amount received by the contract is not the same as the amount deposited, in most cases less. This would only happen with non-standard ERC20 tokens like deflationary or rebasing tokens. While currently the additio

Throughout the code there are multiple mentions of Aave. While this is ok, since the code is a fork of Aave, we would recommend clarifying some comments around contract ownership. Multiple comments stating that the contract is owned by Aave Governance which is no longer true, should be clarified to

The usage of illiquid tokens as collateral in the protocol can lead to serious protocol manipulation. We have seen this with various lending protocols, whereby manipulating the price of a collateral asset (mostly performed via Flashloans) can lead to over-emitting of aTokens and potentially drain fu

There are functions that go beyond the limits of the current code generator. The EVM stack only has 16 slots to fit local variables, parameters and/or return values. You can, of course, rely on having the optimizer turned on and circumvent the problem that way. However, some tools are not able to ut

With the implementation of the usage of aTokens when liquidating or repaying debt, there is no variable in the event emitted that registers the use of a aToken, instead of the normal debt token.

If fee-on-transfer tokens or rebasing tokens are used, protocol may have missing rewards that are not accounted for, causing users to be unable to claim what they thought they are able to. For example, in the staking contract, when rewards are added, `amount` is added to `availableRewards`. This is

Some tokens such as the old aave token LEND will revert when a value of 0 is transferred. If such tokens are used, it can prevent `withdraw` or `deposit` in some cases. This will happen on the condition that \> `uint256 pendingAmount = user.amount.mul(pool.accERC20PerShare).div(1e36).sub(user.rewar

`STAKING\_TERM` is used to determine how long a token should be staked, before rewards are given. If this value is set to too large, no stakers can receive rewards in a reasonable timespan. This means that the reward tokens can potentially be stuck in the contract, since reward tokens can only be wi

The amount of tokens minted to the `msg.sender` i.e. deployer of contract is different from what is intended. The comment says to mint `1 million` tokens but the tokens minted is `1 billion`.

In the calculations for staking rewards, a sanity check is done as seen below. ```solidity // Sanity check. Do not transfer more than what's in the contract if (totalRewards > availableRewards) { totalRewards = availableRewards; } ``` This ensures that the rewards given to stakers cannot exce

The contract uses `^0.8.18` version which has inbuilt arithmetic overflow and underflow protection at compiler level. Thus, usage of `SafeMath` library is not required since any arithmetic underflow or overflow due to addition, substraction or multiplication will lead to error.

Each time funders fund the farming contract, `endBlock` duration is extended based on the amount funded, some multiples of `rewardPerBlock`. This reward will only be fully utilised if in the duration from `startBlock` to `endBlock`, there must be at least 1 user who has deposited liquidity into the

Reward tokens and lpTokens are ERC20 tokens which may have different behaviour for different tokens. Some tokens may revert on transfer while some may return true/false while some may not return anything. In this case, it is advisable to use `SafeERC20` library for token transfers. This library is u

In solidity, all variables defaults to the 0 value. There is no need to explicitly set them to 0 since they have an addtional gas cost.

In function `pending`, variable `lastBlock` is calculated as the minimum of current block(i.e. block.number) and endBlock (i.e. `lastBlock = min(block.number, endBlock)`). The `if` condition check is as follows: `if (lastBlock > pool.lastRewardBlock && block.number > pool.lastRewardBlock && lpSupp

`erc20`, `rewardPerBlock`, `endBlock` and `startBlock` are set in the constructor and can’t be modified later. The arguments passed are not checked if they are valid and non-zero. Also, contract can be funded only when `block.number < endBlock`. So, if `startBlock` is set to `block.number`, then con

The function `fund` doesn’t check if the amount to fund is multiple of `rewardPerBlock`. Thus, if the amount to fund isn’t the multiple of `rewardPerBlock`, then the remainder of `amount/rewardPerBlock` gets lost in the farming contract and can’t be used as a reward. The ideal behavior is to refund