Description
Many contracts, e.g. MoneyMaker, have Context or ContextUpgradeable in their inheritance chain. Context and ContextUpgradeable define the _msgSender and _msgData functions. This makes it easy to switch their semantics, e.g. if Trader Joe decides to support metatransactions in the future. If a contract inherits from Context or (or ContextUpgradeable), uses of msg.data and msg.sender should be replaced by internal calls to _msgData and _msgSender, respectively. This will ensure that if the semantics is changed in the future, the codebase will remain consistent.
Recommendation
Short term, replace all instances of msg.sender with _msgSender() in the contracts that inherit from Context or ContextUpgradeable. This will ensure future-proofness against future code changes.
Long term, ensure that all contracts' code is consistent with the code of their inherited contracts.
I2: Use _msgSender over msg.sender
Description Many contracts, e.g. MoneyMaker, have Context or ContextUpgradeable in their inheritance chain. Context and ContextUpgradeable define the _msgSender and _msgData functions. This makes it easy to switch their semantics, e.g. if Trader Joe decides to support metatransactions in the future. If a contract inherits from Context or (or ContextUpgradeable), uses of msg.data and msg.sender should be replaced by internal calls to _msgData and _msgSender, respectively. This will ensure that if the semantics is changed in the future, the codebase will remain consistent.
Recommendation Short term, replace all instances of msg.sender with _msgSender() in the contracts that inherit from Context or ContextUpgradeable. This will ensure future-proofness against future code changes. Long term, ensure that all contracts' code is consistent with the code of their inherited contracts.