-
Notifications
You must be signed in to change notification settings - Fork 7
Description
Issue Description
In our implementation of Diamond Standard EIP-2535, I've noticed a consistent pattern of directly using msg.sender instead of a more versatile _msgSender() function. This direct usage of msg.sender could potentially lead to unexpected behavior.
Detailed Explanation
The Solidity language provides a msg.sender keyword that delivers the address of the function's direct caller. However, in contexts of proxies and delegatecall, directly using msg.sender can be misleading.
The Diamond Standard (EIP-2535) uses delegatecall extensively for executing facets. Here, msg.sender in a function called via delegatecall returns the immediate caller (i.e., the proxy contract), not the original caller (which is the EOA or the contract that triggered the transaction).
This is where _msgSender() comes in. This function cleverly determines the correct original caller even in the context of delegatecall. It's designed to be compatible with various proxy patterns, including the transparent proxy pattern and meta-transaction designs.
I'll make a PR that follows this pattern.