Allowed amounts for Deposit, Transfer, and Withdrawal are increasing as the scale factor increases with accumulated interest thus DoS the smaller fund operations

[howlbot-integration[bot]]

Lines of code

https://github.com/code-423n4/2024-08-wildcat/blob/main/src/libraries/MarketState.sol#L76-L78 https://github.com/code-423n4/2024-08-wildcat/blob/main/src/market/WildcatMarket.sol#L67-L68 https://github.com/code-423n4/2024-08-wildcat/blob/main/src/market/WildcatMarketToken.sol#L74-L76 https://github.com/code-423n4/2024-08-wildcat/blob/main/src/market/WildcatMarketWithdrawals.sol#L140-L141

Vulnerability details

Vulnerability Description:

The scale factor is initialized to 1e27 when a market is created and constantly grows as interest accrues, as documented in the "Scale Factor.md" and "Core Behavior.md" files. This design causes the MarketState.scaleAmount function, which divides an amount by the current scale factor, to potentially return zero for smaller amounts as the scale factor grows. This issue affects three functions: WildcatMarket._depositUpTo, WildcatMarketToken._transfer, and WildcatMarketWithdrawals.queueWithdrawal.

In these functions:

uint104 scaledAmount = state.scaleAmount(amount).toUint104();
if (scaledAmount == 0) revert_NullMintAmount();

As the scale factor increases over time due to compounding interest, smaller deposits, transfers, or withdrawals can result in a scaledAmount of zero. This leads to the contract reverting with errors like NullMintAmount, NullTransferAmount, or NullBurnAmount, effectively preventing small asset amounts from being processed.

Impact:

Over time, as the scale factor grows with accrued interest, the minimum amount required to deposit, transfer, or withdraw tokens increases, making smaller transactions impossible. This could be a significant usability issue, especially for users who wish to make small deposits or withdrawals in a mature market. This will effectively DoS the users with smaller funds (budget) in using the wildcat protocol.

Proof of Concept (PoC):

In WildcatMarket._depositUpTo function :

uint104 scaledAmount = state.scaleAmount(amount).toUint104();
if (scaledAmount == 0) revert_NullMintAmount();

If the scale factor has grown to a large value, smaller deposits will result in a scaledAmount of zero, causing the transaction to revert.

This issue also present in the WildcatMarketToken._transfer function:

uint104 scaledAmount = state.scaleAmount(amount).toUint104();
if (scaledAmount == 0) revert_NullTransferAmount();

This issue also present in the WildcatMarketWithdrawals.queueWithdrawal function:

uint104 scaledAmount = state.scaleAmount(amount).toUint104();
if (scaledAmount == 0) revert_NullBurnAmount();

https://github.com/code-423n4/2024-08-wildcat/blob/main/src/libraries/MarketState.sol#L76-L78 https://github.com/code-423n4/2024-08-wildcat/blob/main/src/market/WildcatMarket.sol#L67-L68 https://github.com/code-423n4/2024-08-wildcat/blob/main/src/market/WildcatMarketToken.sol#L74-L76 https://github.com/code-423n4/2024-08-wildcat/blob/main/src/market/WildcatMarketWithdrawals.sol#L140-L141

Recommended Fix:

Hence it is recommended to update each of the above functions where this issue exists, to introduce lower threshold amounts which the users can operate with. If the amount is greater than these lower threshold values the scaledAmount should be rounded up to 1 even though the division by scale factor results in 0. This will enable users with smaller funds to use this protocol even after the scale factor has increased to a larger value as the protocol matures.

Assessed type

Other

[d1ll0n]

We listed in the known issues page in the documentation that we would not be accepting reports related to minor rounding errors:

Also, the supposed "dos" vector is a user depositing an amount of ~1 wei and having their transaction revert. I wouldn't call a self-dos vector a vulnerability.

[3docSec]

The finding lacks a description of how the scale factor could reasonably grow high enough to DoS "reasonably small" (a few wei's aren't) deposits.

[c4-judge]

3docSec marked the issue as unsatisfactory: Insufficient proof