Berachain Cauldron

The MagicInfraredVault’s distributeRewards function increases the _totalAssets value immediately upon execution. This immediate increment creates an opportunity for sandwich attack arbitrage, especially when rewards are substantial. Attackers can monitor the mempool, identify pending reward distribution transactions, and frontrun or backrun them to profit instantly without holding the vault exposure equivalent to genuine vault depositors who provided capital to generate the rewards. Even if a private RPC is used, preliminary transactions such as harvest might signal an impending reward distribution, indirectly informing attackers of upcoming profitable trades. While such indirect signals may not guarantee profit, they still significantly increase the likelihood of arbitrage opportunities.

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 MagicInfraredVault’s distributeRewards function increases the _totalAssets value immediately upon execution. This immediate increment creates an opportunity for sandwich attack arbitrage, especially when rewards are substantial. Attackers can monitor the mempool, identify pending reward distribution transactions, and frontrun or backrun them to profit instantly without holding the vault exposure equivalent to genuine vault depositors who provided capital to generate the rewards. Even if a private RPC is used, preliminary transactions such as harvest might signal an impending reward distribution, indirectly informing attackers of upcoming profitable trades. While such indirect signals may not guarantee profit, they still significantly increase the likelihood of arbitrage opportunities.

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.

Within the BEX Vault contract, the joinPool function contains the whenNotPaused modifier. Consequently, whenever the Vault is paused, calls to joinPool revert, effectively blocking any functionality that relies on depositing tokens (joining) into the pool. However, the exitPool function has no such pause check and continues to work even if the BEX Vault is paused. In the MagicBexVaultLevSwapper (particularly the swap function) and the MagicBexVaultHarvester (the run function), both rely on BexLib.joinPool to complete their flows:

• MagicBexVaultLevSwapper.swap needs to join the BEX pool after swapping MIM for underlying tokens.
• MagicBexVaultHarvester.run must join the BEX pool to compound yield after swapping reward tokens. Because the BEX Vault can be paused at any time, any calls to joinPool will fail while paused. That means both MagicBexVaultLevSwapper.swap and MagicBexVaultHarvester.run revert under pause conditions, causing a Denial of Service for those functions.

Document that if the BEX Vault is paused, MagicInfraredVault depositors will not be able to receive any yield.

When one of the two swappers used in the liquidation function of the Cauldron receives the collateral tokens, it's withdrawing them from the DegenBox. When withdrawing, the degenbox has a requirement that the shares after the withdrawal must be at least MINIMUM_SHARE_BALANCE (or 1000), unless it's a full withdrawal. Because of this, there may be some situations where the swapper is trying to withdraw an amount which triggers this revert and result in a failed liquidation.

The swapper parameter in CauldronV4.liquidate is permissionless, so if a liquidation fails because of this, a different swapper can be provided. Therefore, it's enough to document the issue as a potential behavior.

The MagicBexVaultSwapper.swap and MagicBexVaultLevSwapper.swap functions are permissionless which allows giving an approval to whatever to address the callers wants.

Document this.

The exchangeRouter address, intended for token swaps during the reward harvesting process, is currently unset (zero address) in the harvester contracts. An unset or incorrect exchangeRouter address will prevent swaps from executing correctly, causing reward harvesting operations to fail disabling the rewards distribution.

Ensure the exchangeRouter address is properly set to a valid router.

The run function in the MagicBexVaultHarvester can be called by the owner or an address with the operator role to harvest rewards from the staking contract and distribute them to the vault. However, users can also call the getRewardForUser function in the InfraredVault contract, specifying the MagicInfraredVault contract’s address. This leads to an unfinished sequence where rewards are transferred to the MagicInfraredVault contract but are not harvested until run is called next on the MagicBexVaultHarvester. As a result, these rewards may not be properly accounted for when determining the swap parameters.

Ensure that the run function parameters account for any pending rewards in the MagicInfraredVault contract to maintain accurate swap calculations.

When the InfraredVault accumulates rewards in the RewardVault, the InfraredVault.notiyfyRewardAmount() function is called to update the reward rate. Because of this design some users may not be properly rewarded for their contributions. For example,

• rewardDuration in RewardVault is 7 days
• only staker in RewardVault is InfraredVault and only staker in InfraredVault is MagicInfraredVault
• user A and user B deposit equal amount of LP in the MagicInfraredVault
• These are staked in the RewardVault on the behalf of InfraredVault
• The RewardVault receives 600 BGT in rewards
• After one week passes the rewards are claimed and notified to the InfraredVault
• Reward distribution in InfraredVault has just began
• If user B leaves the MagicVault they won't receive any additional rewards (even if harvest is called before the withdraw) even if he contributed for them

In the above example, the user loses rewards for the whole rewardPeriod in the RewardVault. There is no perfect solution to this as it's the way Infrared operates. Calling harvest() frequently is one way to reduce the losses because each harvest() claims the rewards from the RewardVault to InfraredVault. You can do that and also document this behavior so users are aware of it.

Withdrawers lose their rewards which have accumulated between the previous Harvester.run call and the current moment because at the time of the next Harvester.run call, their balance will be reduced.

Make sure to harvest the rewards frequently.

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.

All the contracts assume that tokens do not apply transfer fees or rebases. Tokens that implement fees upon transfers (commonly referred to as “fee-on-transfer tokens”) or other mechanics like rebasing would lead to incorrect balance calculations, breaking core functionality.

Explicitly document that fee-on-transfer tokens are not supported or enforce restrictions to disallow fee-on-transfer and rebasing tokens.

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.

Within the MagicInfraredVault contract, the harvest function collects reward tokens from staking.getAllRewardTokens, swaps them via aggregator calls, and then re‐deposits them as the Vault’s underlying asset (_asset). If the staking contract unexpectedly returns a reward token that is exactly the same address as _asset, the assets would be sent to the harvester and they would be wrongly seen as rewards as in the distributeRewards call the following update would be performed: _totalAssets += amount;. The code does not check that each reward token differs from the main _asset. If _asset appears among the reward tokens, the logic within the harvest and distributeRewards functions will malfunction, causing broken harvesting flows and incorrect accounting.

MagicInfraredVault should explicitly validate that none of the tokens in staking.getAllRewardTokens equals _asset.

The exchangeRouter address, intended for token swaps during the reward harvesting process, is currently unset (zero address) in the harvester contracts. An unset or incorrect exchangeRouter address will prevent swaps from executing correctly, causing reward harvesting operations to fail disabling the rewards distribution.

Ensure the exchangeRouter address is properly set to a valid router.