Core Contracts

Summary

The RAACMinter contract tracks excessTokens. These excessTokens are actually minted directly to the StabilityPool. The excessTokens are always increased and never decreased. This tracking would likely lead to the mintRewards function failing due to insufficient balance of RAACTokens as new ones are which would be needed will not be minted. While the mintRweardsfunction is not called from the Stabilitypool and as implemented this will not cause issues for the protocol this is still a low issue because if the mintRewardsfunction is used as it is written the RAAC rewards system would be broken. Additionally, because RAACTokensare fee on transfer tokens the protocol can save users some rewards by minting directly to the users.

Vulnerability Details

The issue exists in the interaction between two key functions:

The tick() function mints tokens directly to the StabilityPool and increases excessTokens:

The mintRewards() function checks if there are excessTokens available when determining how many tokens to mint. However, the excessRewards have already been minted to the StabilityPool and are not in this contract. This function also mints tokens to itself then transfers them which will incur an unnecessary tax:

PoC / Example scenario:

1. tick() mints 1000 tokens to StabilityPool

   • Contract has 0 tokens

   • excessTokens = 1000

2. mintRewards(user, 800) is called

   • excessTokens (1000) >= amount (800), so toMint = 0

   • No new tokens are minted to the contract

   • Transfer of 800 tokens fails as contract has 0 balance

Impact

• LOW severity since mintRewardsis not implemented on the StabilityPool

• If implemented most if not all reward distributions from mintRewardswill fail due to insufficient balance

Tools Used

• Manual code review

Recommendations

Remove the excessTokens tracking from the contract and mint tokens directly to the user in mintRewards to avoid the transfer tax.