Arkis security record

The report gives no description here.

The report gives no description here.

The report gives no description here.

The report gives no description here.

Part of the execution flow of `Fund.forward()` involves calling `MoneyAccount.spendMoney(amount, reward, block.timestamp)`, where `block.timestamp` serves as a nonce. If `spendMoney()` is called more than once in the same block with identical parameters, any child calls to `createDebtIfNecessary()` will overwrite previous debt entries, and not all debt will be accounted for. This is in part because the `block.timestamp` acts as a salt rather than a true nonce.

Liquidity Providers accumulate rewards across epochs. Rewards are recalculated and distributed when they interact with the Pool. If it has been several epochs since the user last interacted with the pool, the function `calculateUserRewardsForTheWholeNumberOfEpochs()` calculates the rewards for elapsed epochs by applying the average TPS of the epochs across the elapsed time. However, the calculation assumes that each epoch is identical in length. Rewards should be distributed in proportion with the length of the epoch.

The function `RewardsMath.increaseInterest()` updates the state `Staking.TPSS` by adding to it a factor based on the input `_rewardsAmount`, as seen in the following line: `self.TPSS += uint240((_rewardsAmount * TPSS_DENOMINATOR) / (self.tokenVolume))`. Afterwards, a new epoch is started and a few state variables are updated in the subsequent call to `startNewEpoch()` as seen below: ``` function startNewEpoch(Staking storage self, uint256 passingEpochTPSS) private { self.linkedListTPSS[passingEpochTPSS] = self.TPSS; self.tokenVolume = 0; self.epochStartTime[self.TPSS] = block.timestamp; self.numberOfEpochs++; } ``` If the value of `_rewardsAmount` is zero, then the “new” TPSS will be the same as the old one which leads to two errors: 1. The linked list will be pointing to itself `self.linkedListTPSS[passingEpochTPSS] = self.TPSS` since `passingEpochTPSS` is equal to `self.TPSS`. 2. The epoch start time of `self.TPSS` will be overwritten with a newer timestamp. **Impact** 1. **Users would get zero rewards from the incomplete first epoch**. The function `calculateUserRewardsForIncompleteFirstEpoch()` calculates the rewards based on the multiplicative factor `userFirstEpochTPSS = nextEpochTPSS - depositEpoch.TPSS`. Any user with `depositEpoch.TPSS` equal to the old `self.TPSS` would get a factor zero and therefore zero rewards. 2. **Users would get the wrong rewards from the complete epochs**. The function `calculateUserRewardsForTheWholeNumberOfEpochs()` calculates the rewards based on the multiplicative factor `tpsForTheRemainingEpochs = ((lastRewardTime - ufeEndTime) * (self.TPSS - nextTPSSFromUserDepositEpoch)) / numberOfWholeUserEpochs`. There are three members in this equation: `numberOfWholeUserEpochs` would be the correct since it was updated correctly in `startNewEpoch()`. However: * `A = (lastRewardTime - ufeEndTime)` where `ufeEndTime = self.epochStartTime[nextTPSSFromUserDepositEpoch]`. The timestamp in `ufeEndTime` would be newer (greater) than what it should be which leads to a difference lower that expected. * `B = (self.TPSS - nextTPSSFromUserDepositEpoch)`. If we assume the value of `self.TPSS` cannot be increased to compensate for that repeated update, then the current value of `self.TPSS` and `nextTPSSFromUserDepositEpoch` could more or less compensate each other resulting in the expected value of `B`. However, if the error of updating `TPSS` with the same old value happens multiple times, factor `B` would be lower than expected. On the other hand, if the value of `self.TPSS` can indeed by increased to compensate for that repeated updated, then the value of `B` could be greater than expected and this could compensate to some extent the lower value from `A`. However, it would still result in the wrong values. Any user with `depositEpoch.TPSS` equal to the old `self.TPSS` could get a different reward amount which could potentially reduce the amount of available tokens for other users.

The report gives no description here.

Dead code should be avoided since it might consume more resources during development, testing, and compilation without contributing to the software's functionality. It makes the codebase harder to understand and may mislead developers, leading to potential bugs or wasted time. In the case of solidity, it might also increase the bytecode size increasing deployment costs. The following is a non-exhaustive list of dead or unused code instances: 1. The contract `ConvexFiImmutableState` is never imported or used anywhere in the codebase. 2. The variable `borrower` in the `AccountFactory` contract is private and is not used anywhere in the contract. 3. The abstract contract `InternalModifierDS` is never imported or used anywhere in the codebase.

The [Checks-Effects-Interactions](https://solidity.readthedocs.io/en/latest/security-considerations.html#use-the-checks-effects-interactions-pattern) coding pattern is meant to mitigate any chance of other contracts manipulating the state of the blockchain in unexpected and possibly malicious ways before control is returned to the original contract. As the name implied, only after checking whether appropriate conditions are met and acting internally on those conditions should any external calls to, or interactions with, other contracts be done. The function `Pool.deposit()` updates the state through `staking.increasePosition()` after doing the external call `token.transferFrom()`.