in `RTokenP1` Throttles Implementation can backfire to the protocol, causing DOS

[c4-bot-3]

Lines of code

https://github.com/code-423n4/2024-07-reserve/blob/3f133997e186465f4904553b0f8e86ecb7bbacbf/contracts/p1/RToken.sol#L121-L122

Vulnerability details

Impact

Complete Denial of service of RTokens Issuance, especially new (Low TVL ones), by malicious entity

Proof of Concept

The Problem Arises in RToken contract in issueTo due to Throttles implementation here

File: RToken.sol
105:     function issueTo(address recipient, uint256 amount) public notIssuancePausedOrFrozen {
106:         require(amount != 0, "Cannot issue zero");
//////////////////OMMIT
119: 
120:         // Revert if issuance exceeds either supply throttle
121:         issuanceThrottle.useAvailable(supply, int256(amount)); // reverts on over-issuance
122:         redemptionThrottle.useAvailable(supply, -int256(amount)); // shouldn't revert

in Line 121, we revert on over Issuance, which is a mechanism in place to prevent Large issuance causing price manipulation.

When we look at useAvailable we see that:

• We calculate hourly Limit in Line 46 By using the max of the two values here

Now the problem will arise from the fact that either a whale or MEV bots can constantly prevent the genuine issuance of RToken using the Throttle Mechanism

• This maybe through
  • • Constantly sandwiching normal users issuance

This is more problematic when the RToken is newly Deployed cause:

• pctRate will be mostly always smaller than amtRate and as a result, as long as amtRate and UoA is at a reasonable number this will be always filled easily with not much of cost.

Tools Used

Manaul Review

Recommended Mitigation Steps

Prevent issuing and redeeming in the same Txn will prevent a good portion of the attack victor and would make it less feasible.

Note! care should be taken due to the public function issueTo that allows permissionless issuing to other users that the above solution may introduce a new attack vector Dos to other users by continuously issuing to users 1 wei when they try to redeem

In addition to this, prevent one user from obtaining all the hourly limit,

Note! this may be bypassed by attacker using multiple accounts.

Assessed type

DoS