The issue is a typical inflation attack, that the first staker adds the huge amount of the underlayer tokens after minting shares, and the following stakers can only mint zero share because of division precision error.
The mitigation uses a regular schedule that check if the minting shares is zero to protect the following staker from losing all their staking tokens. But it doesn't work on edge condition:
The initial process is as same as the original issue. The first staker mints only 1 wei share and drip accrued.
After the mitigation, the second staker can't deposit any amount less than dripAmount + 1, which will revert with CantMintZeroShares error. But if the second staker deposits 2 * (dripAmount + 1) - 1 xETH, the staker will only receive 1 wei wxETH because of round-down error. After the second deposit, 1 wei wxETH = (3 * (dripAmount + 1) - 1) / 2 . And the second staker losses 0.5 * (dripAmount + 1) - 0.5 xETH.
Suggestion
First I need to clarify that I think it's a low/NC risk issue because it only can loss some dusts.
Lines of code
https://github.com/code-423n4/2023-05-xeth/blob/add-xeth/src/wxETH.sol#L99-L101
Vulnerability details
Comments
The issue is a typical inflation attack, that the first staker adds the huge amount of the underlayer tokens after minting shares, and the following stakers can only mint zero share because of division precision error.
The mitigation uses a regular schedule that check if the minting shares is zero to protect the following staker from losing all their staking tokens. But it doesn't work on edge condition:
dripAmount + 1
, which will revert with CantMintZeroShares error. But if the second staker deposits2 * (dripAmount + 1) - 1
xETH, the staker will only receive 1 wei wxETH because of round-down error. After the second deposit,1 wei wxETH = (3 * (dripAmount + 1) - 1) / 2
. And the second staker losses0.5 * (dripAmount + 1) - 0.5
xETH.Suggestion
First I need to clarify that I think it's a low/NC risk issue because it only can loss some dusts.
If the team really wants to fully fix it as inflation attack, please refer to https://ethereum-magicians.org/t/address-eip-4626-inflation-attacks-with-virtual-shares-and-assets/12677 .
But I strongly not recommend such mitigation for this issue because it adds too many entities only for insignificant loss.
Assessed type
Context