PoolTogether - ArmedGoose's results

1. [Low] silent overflow in https://github.com/GenerationSoftware/pt-v5-vault/blob/b1deb5d494c25f885c34c83f014c8a855c5e2749/src/Vault.sol#L1154-L1155 The function explicitly casts uint256 to uint96, which may cause a silent overflow and return an unexpected value.

  function _transfer(address _from, address _to, uint256 _shares) internal virtual override {
    _twabController.transfer(_from, _to, uint96(_shares)); //@audit slient overflow

    emit Transfer(_from, _to, _shares);
  }

It is recommended to use the same value size or a safeCast library.

2. [Low] Lack of equal array check - in https://github.com/GenerationSoftware/pt-v5-vault/blob/b1deb5d494c25f885c34c83f014c8a855c5e2749/src/Vault.sol#L618C1-L619 there is iteration over _winners array and in next line its length is used to indicate current index of _prizeIndices. The problem is there is no check if these arrays have equal length and it may lead to an unexpected behavior or a rever if winners is of different length. Recommendation: Check if length of _winners is equal to length of _prizeIndices.

3. [Low] Revert when a failing reward claim may cause DoS in some cases The overall logic behind rewards claiming is that bots should take list of winners as a batch and claim rewards for all. The PrizePool.claimPrize has a revert statement if one of the winners is not a winner or winner is already claimed. If only one array entry in a bot is mistaken, or doubled, then the whole call will fail since the Vault.claimPrize performs the batch in a loop iterating over array of winners. Therefore it might be better to use a low level call, or not revert but just return a list of claimed successfully and claim failed. This way, the bots in case of one wrong entry in the list, will not have to repeat the call, and it is very likely, that they will not have a sophisticated custom logic to do so.

4. [Info] redundant code in https://github.com/GenerationSoftware/pt-v5-vault/blob/b1deb5d494c25f885c34c83f014c8a855c5e2749/src/Vault.sol#L408 - will not happen since maxDeposit = always (uint256).max in ERC4626.sol;