Skip to content

Conversation

@tomhirst
Copy link
Contributor

@tomhirst tomhirst commented Mar 2, 2025

We have a client request to deploy a launchpad contract with a vanity address, but we can't do this with our existing factory deployment flow:

The salt for the vanity address needs to be pre-computed with forge create2. However, when this salt is passed to createContractDeterministic it's re-hashed with msg.sender and block.chainId. Meaning, the salt will not be the same and the vanity address with not be achieved:

bytes32 _salt = keccak256(abi.encode(salt, block.chainid, msg.sender));

These scripts directly deploy ERC721CM (non-initializable variant) directly using the pre-computed salt to achieve the vanity address via CREATE2.

@tenthirtyone
Copy link
Contributor

Cool with however you want to approach this. The smallest impact way I saw to accomplish this is to add a nonce to this line and take the parameter. Then you can grind CREATE2 addresses all day

@tomhirst
Copy link
Contributor Author

tomhirst commented Mar 3, 2025

Cool with however you want to approach this. The smallest impact way I saw to accomplish this is to add a nonce to this line and take the parameter. Then you can grind CREATE2 addresses all day

Cool. Interested to see how that would look. Couldn't we take the _salt parameter direct?

Isn't nonce only needed for CREATE?

How would you mine the CREATE2 addresses?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants