ss.oAmount is being overwrite in defiToStablecoinSwap() with fBalance-iBalance. which will be the balance user will get after defiSwap.
So lets consider a scenario , user want to swap X Token to Usdc token in defiswap and in StablecoinSwap eUsdc token will be swapped with eMxn.
Now in defiToStablecoinSwap(), _verifyStableCoinSwap() is there , which will check ss.origin input amount with totalSupply, that is should not go below minLimit. But here the catch is that ss.Origin amount which is passed in ss struct will not be used to mint , on the other side , the amount which will be minted is the overwrriten value. Which can higher than the original SS.origin value.
`for eg for defiToStable
1) 20X tokens is used in defiSwap for eUsdc and obtain eUsdc will be used to obtain eMxn from stableCoinSwap. swapper role in SS has put ss.origin amount has 40 .
2) now after after defi swap lets say, user wallet will get 60 tokens, can be any reason like sudden price change in Xtoken , and more eUsdc will swapped to user. In aggregrator there will check for minAmountOut and not max. Now 60 will be new value for SS.origin.
3) which will be used in stableCoin Swap. now there is no check while burning , so if there would case, that 40 would be max amount to reach minLimit so fucntion will proceed further but amount which will be burned would be 60. so it will go below minLimit.
External pre-conditions
No response
Attack Path
No response
Impact
Total supply can go below minlimit which is set by the Maintainer Role, which against the assumption of protocol.
PoC
No response
Mitigation
Check regarding minimum totalSupply should be done with overwrite SS.origin and not which is given in parameter. Which can be done while burning which is done _stableCoinSwap()
0xlucky
High
TotalSupply of StableCoin can go below minLimit due to improper check
Summary
The check regarding , ensuring the total supply does not drop below the minimum limit after burning the specified amount is being bypassed.
Root Cause
ss.oAmount is being overwrite in defiToStablecoinSwap() with fBalance-iBalance. which will be the balance user will get after defiSwap.
So lets consider a scenario , user want to swap X Token to Usdc token in defiswap and in StablecoinSwap eUsdc token will be swapped with eMxn.
Now in defiToStablecoinSwap(), _verifyStableCoinSwap() is there , which will check ss.origin input amount with totalSupply, that is should not go below minLimit. But here the catch is that ss.Origin amount which is passed in ss struct will not be used to mint , on the other side , the amount which will be minted is the overwrriten value. Which can higher than the original SS.origin value.
https://github.com/sherlock-audit/2024-11-telcoin/blob/main/telcoin-audit/contracts/stablecoin/StablecoinHandler.sol#L194C1-L208C1
https://github.com/sherlock-audit/2024-11-telcoin/blob/main/telcoin-audit/contracts/swap/AmirX.sol#L111C3-L128C6
Internal pre-conditions
`for eg for defiToStable 1) 20X tokens is used in defiSwap for eUsdc and obtain eUsdc will be used to obtain eMxn from stableCoinSwap. swapper role in SS has put ss.origin amount has 40 .
2) now after after defi swap lets say, user wallet will get 60 tokens, can be any reason like sudden price change in Xtoken , and more eUsdc will swapped to user. In aggregrator there will check for minAmountOut and not max. Now 60 will be new value for SS.origin.
3) which will be used in stableCoin Swap. now there is no check while burning , so if there would case, that 40 would be max amount to reach minLimit so fucntion will proceed further but amount which will be burned would be 60. so it will go below minLimit.
External pre-conditions
No response
Attack Path
No response
Impact
Total supply can go below minlimit which is set by the Maintainer Role, which against the assumption of protocol.
PoC
No response
Mitigation
Check regarding minimum totalSupply should be done with overwrite SS.origin and not which is given in parameter. Which can be done while burning which is done _stableCoinSwap()