Category: Optimizations
Unnecessary casting of salt parameter
Informational Severity
Informational Impact
N/A Likelihood
Description
The type of the parameter salt in the createAccount and getAddress functions is uint256, but the functions both cast it to bytes32 in all uses of the parameter.
Recommendations
The salt parameter's type can be directly set to bytes32, eliminating the need for type conversion within the functions:
-function createAccount(bytes32 hash, uint256 salt) public returns (LightWallet ret) {
+function createAccount(bytes32 hash, bytes32 salt) public returns (LightWallet ret) {
address addr = getAddress(hash, salt);
// [...]
ret = LightWallet(
payable(
- new ERC1967Proxy{salt : bytes32(salt)}(
+ new ERC1967Proxy{salt : salt}(
address(accountImplementation),
abi.encodeCall(LightWallet.initialize, (hash))
)
)
);
}
// [...]
-function getAddress(bytes32 hash, uint256 salt) public view returns (address) {
+function getAddress(bytes32 hash, bytes32 salt) public view returns (address) {
// Computes the address with the given `salt`and the contract address `accountImplementation`, and with `initialize` method w/ `hash`
return Create2.computeAddress(
- bytes32(salt),
+ salt,
keccak256(
abi.encodePacked(
type(ERC1967Proxy).creationCode,
abi.encode(address(accountImplementation), abi.encodeCall(LightWallet.initialize, (hash)))
)
)
);
}Remediation
This issue has been acknowledged by Light, Inc., and a fix was implemented in commit 6a1a082e↗.