book
book copied to clipboard
foundry-rs
scripts: deployer of script contract is not msg.sender
Component
Forge
Have you ensured that all of these are up to date?
- [X] Foundry
- [X] Foundryup
What version of Foundry are you on?
forge 0.2.0 (34d279a 2022-12-08T07:48:46.429075528Z)
What command(s) is the bug in?
forge script
Operating System
Linux
Describe the bug
The deployer of the Script contract is not msg.sender which means a user that uses msg.sender in the constructor will cause unexpected results. This bit me as I spent an hour trying to predict the Create2 address of my deployed contract (so I could store it in the script storage and check if it exists before I deploy).
I would suggest that the deployer of the script contract should be influenced by the --sender flag unless doing so is infeasible/would break other workflows?
I would suggest that the deployer of the script contract should be influenced by the
--senderflag unless doing so is infeasible/would break other workflows?
That would be rad, been struggling with this for months, I can't test scripts that deploy contracts which implement stuff like Ownable which uses msg.sender in the constructor. And so I thought, well, what if I try to prank before calling the run() function on the deployed script contract? But then I get FAIL. Reason: You have an active prank. Broadcasting and pranks are not compatible. Disable one or the other, which makes me think that the same problem would come up if --sender were to be used?
I'm lacking some insights here. @joshieDo could you please elaborate on why this is a limitation, or how to improve it?
EOAs can't directly use CREATE2, although they can call a contract that does a CREATE2. When a CREATE2 is in a forge script, the transaction is actually a call to this create2 deployer contract.
If one want to precompute the address of a new contract, this is the sender that must be used. Btw, there is a cheatcode for this vm.computeCreate2Address(salt, initCodeHash).
On a side note, I think that this behaviour from forge script is a bit dangerous because it's unclear what happens under the hood. I find that using a cheatcode would be safer (like vm.create2WithStandardDeployer).
