After Deposits To GMX Pool extra funds is sent to refundee which is msg.sender. Which won't work for EIP4337 [Account's Abstraction] .
Analysing the current mass adoption of account abstraction we need to make sure the current logic is compatible for such users.
https://github.com/Cyfrin/2023-10-SteadeFi/blob/main/contracts/strategy/gmx/GMXDeposit.sol#L54
refundee has been set to msg.sender. But in the case user is using account's abstraction msg.sender will be bundler which executes the actual tx not the actual signer of tx.
So adding a receiver in deposit param could make this logic executable for such cases. User can make create useroperation with a receiver address and that address can be used as refundee in the current logic.
Even current logic will break if the user is blacklisted by the token so his funds will stuck in the protocol, Adding a redundee for withdrawl the token always work best
Accounts abstraction is used by mass users and protocol is not compatible for such users.
User's funds can stuck in the prtocol if user is blacklisted by the token
Manual review
Consider adding receiver param in deposit params as well as in withdraw params
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.