1.FULL_RESTRICTED Stakers can bypass restriction through approvals
The openzeppelin ERC4626 contract allows approved address to withdraw and redeem on behalf of another address so far there is an approval。
Encountering an unfamiliar EIP requires a thorough understanding of its code before proceeding with the subsequent audit.
2.Soft Restricted Staker Role can withdraw stUSDe for USDe
The code does not satisfy that condition, when a holder has the SOFT_RESTRICTED_STAKER_ROLE, they can exchange their stUSDe for USDe using StakedUSDeV2。
When faced with strictly limiting conditions, it is essential to consider whether there are any possible ways to bypass them through various means.
3.users still forced to follow previously set cooldownDuration even when cooldown is off (set to zero) before unstaking
The main issue with this question is that when setting global parameters, the impact on previous users was not taken into consideration
4.Malicious users can front-run to cause a denial of service (DoS) for StakedUSDe due to MinShares checks
This issue arises from the fact that the first user of the vault can have a certain impact on subsequent users. Therefore, it is important to be mindful of the effects of the initial configuration when handling shares.