Kodiak MIM-HONEY Island Market

In the MagicKodiakVault harvest function the transfer function is attempted to be used for every reward token. However if there are currently zero rewards for any individual reward token that reverts on zero transfers then the harvest function will revert and prevent the claiming of all rewards.

Consider only transferring rewards for the reward token if there is a nonzero contract balance for that reward.

In the MagicKodiakVault the distributeRewards function increments the _totalAssets of the vault in a stepwise manner. This can allow for sandwhich attack arbitrage opportunities when the reward amount is large. A malicious actor can see a reward distribution in the mempool and frontrun/backrun it to immediately gain from the distributed amount without holding exposure to the vault for the same time as the users who provided the capital to generate the rewards. Furthermore, even if a private RPC is used a preliminary harvest transaction may be used as an indicator that distributeRewards is about to be called after swapping reward tokens to the target asset. This would allow a malicious actor to frontrun and backrun reward distributions without necessary knowledge of the distributeRewards transaction in the mempool, however this is not a guaranteed profit.

Be sure to use a private RPC to call the distributeRewards function. Otherwise be sure to keep the reward distributions small and infrequent. A more long term solution is to consider refactoring the reward distribution logic so that the totalAssets increment is gradual rather than instantaneous.

The Harvester address 0xB76403D52CA4D4f5C791859d93553E14742cc9d1 is currently not assigned as an operator for the vault proxy address 0x548eAf30BAD1B4f697fBAC88712fc8148Dc0aA75. Instead the deployer address 0xfb3485c2e209a5cfbdc1447674256578f1a80ee3 is currently assigned as an operator.

Add the operator role to the harvester and consider removing the operator role from the deployer.

Within bera.json, address 0x7FC70DfE186b1eF1B792d1c42C3b7De09F4a68a7 does not point to the Infrared MIM-Honey vault but instead to a mock contract.

Ensure the address is updated prior to MagicKodiakVault deployment.

Currently the redstoneHoneyAggregator is set to an aggregator that will always return a $1 fixed price which will affect the calculated price of the collateral.

Ensure the aggregator is updated to the proper Redstone address for live deployment.

”MagicKodiakCauldron” is supplied as the name to function _deployCauldron. Consequently, when the cauldron is actually deployed, it’s deployment name will be Cauldron_MagicKodiakCauldron.

Consider adjusting the name as necessary such that is adheres to Abracadabra’s standards.

Infrared vaults rely on being whitelisted so that they can interact with the Berachain reward vaults during staking and unstaking. However, setVaultWhitelistedStatus can be used by governance to revoke whitelisted status (see doc), which would ultimately prevent the ability for new stakes to occur into the MagicKodiakVault.

Clearly document this risk.

The KodiakIslandAggregator contract performs no staleness checks on the underlying aggregator feeds. Therefore this aggregator is at risk of reporting inaccurate prices when one of the underlying feeds is outdated.

Be aware of this issue and consider adding staleness validation controls depending on if a feed implements staleness checks.

The KodiakIslandAggregator contract is missing several validations which can be crucial in avoiding a mispricing or manipulation in edge case scenarios. Firstly, the latestAnswer function lacks validation that requires the totalSupply to be above a menial threshold to avoid unexpected low precision manipulations with small amounts of collateral. It also lacks validation which would prevent a divide by zero revert when the totalSupply is zero. The Maker DAO GUniLPOracle validates this by ensuring that the totalSupply is above 1e9. Secondly there are several casts performed which do not include safety reverts if an overflow would have occurred. The _getSqrtPriceX96 function does not include any reverts if the uint160 cast would overflow, though such an overflow would be extremely unlikely. Additionally, there is no validation that the result of totalValue / totalSupply does not overflow the int256 result. Both scenarios are unlikely, however should be validated against to avoid any unexpected manipulations.

**The **KodiakIslandAggregator contract reports a decimals of the IERC20Metadata(address(island)).decimals() result, however this is incorrect when the IERC20Metadata(address(island)).decimals() result is not equal to 18. Consider the existing case, when the island decimals are 18:

• normalizedReserve0 and normalizedReserve1 are 1e18 decimals
• normalizedPriceFeed0 and normalizedPriceFeed1 are 1e18 decimals
• The resulting totalValue is 1e36 decimals
• Assume totalValue is $1, e.g. 1e36
• Assume totalSupply is 1 token, e.g. 1e18
• The resulting price is 1e36/1e18 == 1e18 which is correctly $1 with 18 decimals

However for a case where the island decimals are 8:

• normalizedReserve0 and normalizedReserve1 are 1e18 decimals
• normalizedPriceFeed0 and normalizedPriceFeed1 are 1e18 decimals
• The resulting totalValue is 1e36 decimals
• Assume totalValue is $1, e.g. 1e36
• Assume totalSupply is 1 token, e.g. 1e8
• The resulting price is 1e36/1e8 == 1e28 which is incorrectly reporting a very large price for an 8 decimal feed

Instead of assigning the decimals for the feed as the IERC20Metadata(address(island)).decimals() result, either hardcode the decimals as 18 and document that this aggregator is incompatible with any other island decimals. Or assign the decimals as: 36 - IERC20Metadata(address(island)).decimals().

In the run function the LP token balance of the harvester contract before the addLiquidity call is removed from the amount which can be rewarded to the vault. This prevents LP token rewards that were harvested from being distributable back to the MagicKodiakVault. However it is unlikely that LP tokens will be supported as a direct reward token.

This finding simply serves as a warning since it is unlikely that the LP token will be a reward token for the Infrared vault. However if it is then this logic should be amended in a new harvester contract. Additionally, consider adding a token rescue function in the event that LP tokens are sent to this contract either as a reward or by accident and cannot be recovered.

In the setExchangeRouter function the approvals are removed for all existing reward tokens from the previous exchangeRouter contract. However if a reward is removed from the infrared vault with the removeReward function then this token approval will not be removed from the previous exchangeRouter upon the next exchangeRouter update.

Consider adding an additional function to remove targeted approvals from an existing or past exchangeRouter contract for cases where the reward tokens are updated.

New reward tokens may be added to the Infrared vault with the addReward function. These reward tokens will require additional approvals to be made to the exchangeRouter contract.

Currently this can be achieved by using the setExchangeRouter function to set the same exchangeRouter implementation in order to approve all new tokens. Be aware that this scenario may arise.

**The **SwapInfo struct contains two unnecessary fields, the token and amount fields, which are not used in the implementation anywhere.

Remove these unnecessary fields from the SwapInfo struct.

The IERC20 import in the MagicKodiakVaultHarvester contract is unused.

Consider removing this import.

In the deployed harvester contract the fee basis points and fee receiver have not been configured.

Consider if this is the expected state, and if not be sure to configure the fee amount and receiver as they are expected to be.