The lack of a liquidity check (i.e., verifying poolBalance >= tAmount) before minting or swapping tokens can result in attempting to mint or swap more tokens than the contract has in reserve. This can lead to failed transactions or even unintended behavior within the contract, especially if there is no safeguard against running out of target tokens.
Root Cause
In StableCoinHandler _verifyStablecoinSwap 184Line there is a missing check for if the pool has enough amount to exchange the user amount
The root cause of this issue is the absence of a validation step that confirms whether the contract has enough target tokens (poolBalance) to fulfill the requested tAmount for the swap. Without this check, the contract proceeds with the mint or swap operation based solely on the amount specified in the StablecoinSwap struct, assuming it has adequate reserves when that might not be the case.
Internal pre-conditions
Roles to be set
External pre-conditions
User needs to call stableCoinSwap inputting wallet and
address liquiditySafe;
address destination; //@note //where the swapped currency will go (Address)
address origin; //@note user providing for swap currency
uint256 oAmount;// @note // amount of the currency that user provides
address target; //@note currency that user wants to receive
uint256 tAmount; //@note amount that wants to receive
address stablecoinFeeCurrency; //@note currency that fee will be paid in
address stablecoinFeeSafe; //@note The address where the fee for the swap should be sent
uint256 feeAmount; //@note amount of fee that will be got
}
_verifyStablecoinSwap where some checks are done and where this check about the amount is missing
Attack Path
Repeated Calls to Drain Liquidity: The attacker could repeatedly initiate swaps or minting functions, draining the contract’s pool without regard to the actual token balance. Each swap might succeed until the pool is emptied, at which point future swaps would fail for other users.
2.Excessive Minting: If the protocol is designed to mint or swap tokens on-demand, an attacker could initiate a large swap amount that exceeds the available pool, potentially causing an erroneous or unintended state if the contract tries to mint tokens or if it reverts improperly.
3.Denial of Service (DoS): By draining the pool, an attacker could trigger a DoS scenario, where legitimate users can no longer access liquidity for swaps due to depleted reserves.
Impact
Liquidity Drain: If the contract does not check and continues issuing tokens despite a low reserve, it could deplete its pool, resulting in a state where no users can complete swaps.
2.Debt or Insolvency: For protocols where swaps are expected to be backed by reserves, a lack of sufficient checks could put the system in a debt state, as it owes users tokens that it cannot actually fulfill.
3.System Instability: Without proper liquidity checks, users could attempt transactions that fail unexpectedly, reducing trust in the system's stability and reliability.
PoC
No response
Mitigation
Adding a check to ensure poolBalance >= tAmount before initiating the swap is essential to safeguard against these issues. This check should be part of the _verifyStablecoinSwap function or directly within the swap logic, so it prevents any swap attempt when liquidity is insufficient. Additionally, rate-limiting or controls on large swaps could help reduce the risk of rapid liquidity depletion from malicious actors.
0xKann
Medium
Missing Liquidity Check in StablecoinHandler Allows for Potential Pool Drain and Denial of Service (DoS)
Summary
In StableCoinHandler _verifyStablecoinSwap 184Line
The lack of a liquidity check (i.e., verifying poolBalance >= tAmount) before minting or swapping tokens can result in attempting to mint or swap more tokens than the contract has in reserve. This can lead to failed transactions or even unintended behavior within the contract, especially if there is no safeguard against running out of target tokens.
Root Cause
In StableCoinHandler _verifyStablecoinSwap 184Line there is a missing check for if the pool has enough amount to exchange the user amount
The root cause of this issue is the absence of a validation step that confirms whether the contract has enough target tokens (poolBalance) to fulfill the requested tAmount for the swap. Without this check, the contract proceeds with the mint or swap operation based solely on the amount specified in the StablecoinSwap struct, assuming it has adequate reserves when that might not be the case.
Internal pre-conditions
Roles to be set
External pre-conditions
User needs to call stableCoinSwap inputting wallet and
_verifyStablecoinSwap where some checks are done and where this check about the amount is missing
Attack Path
2.Excessive Minting: If the protocol is designed to mint or swap tokens on-demand, an attacker could initiate a large swap amount that exceeds the available pool, potentially causing an erroneous or unintended state if the contract tries to mint tokens or if it reverts improperly.
3.Denial of Service (DoS): By draining the pool, an attacker could trigger a DoS scenario, where legitimate users can no longer access liquidity for swaps due to depleted reserves.
Impact
2.Debt or Insolvency: For protocols where swaps are expected to be backed by reserves, a lack of sufficient checks could put the system in a debt state, as it owes users tokens that it cannot actually fulfill.
3.System Instability: Without proper liquidity checks, users could attempt transactions that fail unexpectedly, reducing trust in the system's stability and reliability.
PoC
No response
Mitigation
Adding a check to ensure poolBalance >= tAmount before initiating the swap is essential to safeguard against these issues. This check should be part of the _verifyStablecoinSwap function or directly within the swap logic, so it prevents any swap attempt when liquidity is insufficient. Additionally, rate-limiting or controls on large swaps could help reduce the risk of rapid liquidity depletion from malicious actors.