Users who are using smart contract wallets e.g. EIP4337 compliant will be unable to use function calculateFunding(). This is a exclusion of some part of users, who might not be aware of such restriction. Since the usability will be restricted for them, protocol may lose part of users.
Proof of Concept
There is a check in helper that checks if sender is a contract. If so, then it requires it to be whitelisted first.
// modifier is eligible sender modifier
function _isEligibleSender() internal view {
// the below condition checks whether the caller is a contract or not
if (msg.sender != tx.origin)
require(whitelistedContracts[msg.sender], "Contract must be whitelisted");
}
In most cases, it is used on functions that anyway are only-protocol roles, which means that they are presumably going to be whitelisted anyway. But since calculateFunding() is designed to be public, adding this check may prevent users relying on smart contract wallets to use this function.
Lines of code
https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/perp-vault/PerpetualAtlanticVault.sol#L409
Vulnerability details
Impact
Users who are using smart contract wallets e.g. EIP4337 compliant will be unable to use function
calculateFunding()
. This is a exclusion of some part of users, who might not be aware of such restriction. Since the usability will be restricted for them, protocol may lose part of users.Proof of Concept
There is a check in helper that checks if sender is a contract. If so, then it requires it to be whitelisted first.
In most cases, it is used on functions that anyway are only-protocol roles, which means that they are presumably going to be whitelisted anyway. But since
calculateFunding()
is designed to be public, adding this check may prevent users relying on smart contract wallets to use this function.Tools Used
Manual approach
Recommended Mitigation Steps
Remove the check for
_isEligibleSender()
.Assessed type
Access Control