Platform: Code4rena
Start Date: 24/10/2023
Pot Size: $36,500 USDC
Total HM: 4
Participants: 147
Period: 6 days
Judge: 0xDjango
Id: 299
League: ETH
Rank: 129/147
Findings: 1
Award: $4.52
๐ Selected for report: 0
๐ Solo Findings: 0
๐ Selected for report: 0xmystery
Also found by: 0x11singh99, 0xAadi, 0xAlix2, 0xG0P1, 0xStalin, 0xWaitress, 0x_Scar, 0xhacksmithh, 0xhunter, 0xpiken, Al-Qa-qa, Arz, Avci, Bauchibred, BeliSesir, Breeje, Bughunter101, DarkTower, Eeyore, Fitro, HChang26, Imlazy0ne, J4X, JCK, Kaysoft, Kral01, Madalad, Mike_Bello90, Noro, PASCAL, PENGUN, Proxy, Rickard, Shubham, SovaSlava, Strausses, Team_Rocket, ThreeSigma, Topmark, Udsen, Walter, Yanchuan, Zach_166, ZanyBonzy, adam-idarrha, adeolu, almurhasan, arjun16, ast3ros, asui, ayden, btk, cartlex_, castle_chain, cccz, chainsnake, codynhat, critical-or-high, cryptonue, csanuragjain, deepkin, degensec, dirk_y, erebus, foxb868, ge6a, hunter_w3b, jasonxiale, kkkmmmsk, lanrebayode77, lsaudit, marchev, matrix_0wl, max10afternoon, nuthan2x, oakcobalt, oxchsyston, pavankv, peanuts, pep7siup, pipidu83, pontifex, ptsanev, qpzm, radev_sw, rokinot, rotcivegaf, rvierdiiev, sorrynotsorry, squeaky_cactus, supersizer0x, tnquanghuy0512, twcctop, twicek, young, zhaojie, ziyou-
4.5226 USDC - $4.52
Unnecessary Call of getUnvestedAmount() function for addition operation in a situation it must always return zero https://github.com/code-423n4/2023-10-ethena/blob/main/contracts/StakedUSDe.sol#L91
function transferInRewards(uint256 amount) external nonReentrant onlyRole(REWARDER_ROLE) notZero(amount) { >>> if (getUnvestedAmount() > 0) revert StillVesting(); --- uint256 newVestingAmount = amount + getUnvestedAmount(); +++ uint256 newVestingAmount = amount; ...
As noted in the code above if getUnvestedAmount() is greater than zero the code will revert meaning the transferInRewards() function can only run if getUnvestedAmount() is zero, the problem is using it in addition operation to calculate "newVestingAmount" since it would always be zero, the code should be reaccess for possible mistake in function implementation or it should be simply removed.
Risk of Token loss due to Missing Address Validity Check in Mint Function
https://github.com/code-423n4/2023-10-ethena/blob/main/contracts/USDe.sol#L28-L31
The absence of an address zero validity check in the mint function of the USDe.sol contract would allow accidental transfers to zero address (0x0). This would effectively burn tokens as reverse to minting, as they would become irretrievable. This could have a significant impact on the total supply of tokens and their value.
The mint function in the USDe.sol contract does not contain a check to prevent minting tokens to the zero address. Here is the function for reference:
function mint(address to, uint256 amount) external { if (msg.sender != minter) revert OnlyMinter(); _mint(to, amount); }
The issue was identified through manual code review
To mitigate this issue, it is recommended to include a validity check for the "to" address in the mint function. This can be done by adding a require statement that ensures the "to" address is not the zero address, i.e
function mint(address to, uint256 amount) external { +++ require(to != address(0), "Mint to the zero address"); if (msg.sender != minter) revert OnlyMinter(); _mint(to, amount); }
This will throw an exception and revert the transaction if someone tries to mint tokens to the zero address. This simple check can prevent potential token loss and maintain the integrity of the tokenโs total supply.
#0 - c4-pre-sort
2023-11-02T03:22:32Z
raymondfam marked the issue as sufficient quality report
#1 - c4-judge
2023-11-14T16:50:09Z
fatherGoose1 marked the issue as grade-b