feat: add UniswapV4DeployerCompetition #117
Conversation
this commit adds a contract that creates a competition to generate the vanity address for Uniswap V4. It does so using CREATE2 salts, pre-calculating the address at which the contract will be deployed and applying a score to the address based on its vanity. leading 0's are weighted most heavily, followed by other 0's and 4's. The winner receives an NFT, a bounty, and deployer privileges
|
hackathon project :D |
| uint256 public immutable exclusiveDeployDeadline = competitionDeadline + 1 days; | ||
| bytes32 public immutable initCodeHash; | ||
|
|
||
| constructor(bytes32 _initCodeHash, address _v4Owner) payable ERC721("UniswapV4 Deployer", "V4D") { |
There was a problem hiding this comment.
hmmmmmm trying to think through how we can get everything to do the same address on every chain. we would definitely love to not have params here 🤔
this commit removes the ETH payout, NFT mint, and exclusive deploy rights
|
Probably want to add some frontrunning protection to |
src/libraries/VanityAddressLib.sol
Outdated
| // Requirement: The first nonzero nibble must be 4 | ||
| // 10 points for every leading 0 nibble | ||
| // 40 points if the first 4 is followed by 3 more 4s | ||
| // 20 points if the first nibble after the 4 4s is NOT a 4 | ||
| // 20 points if the last 4 nibbles are 4s | ||
| // 1 point for every 4 |
There was a problem hiding this comment.
Confirming a design decision, but from the PR description:
leading 0's are weighted most heavily, followed by other 0's and 4's
While the most optimal address has many leading 0s (0x000000000000000000000000000000000000004444 with 360 points), 0x4444000000000000000000000000000000000000 gets a score of 64 whereas 0x0004000000000000000000000000000000000000 would only get a score of 31 pts.
The implemented scoring system optimizes for:
- Leading 0s only if there are more than 6 of them. (> 60pts)
- a group of 4s after the first zero (or at the beginning if there is no leading 0) (60 pts)
- fewer than 6 leading 0s (10-60 pts)
- 4 4s at the end (20 pts)
- Other 4s that don't qualify for 2 or 4
It does not give any weight to "other 0's" after the leading ones.
There was a problem hiding this comment.
yea that sounds right. do you have any suggestions here?
This commit removes the storage variable for bestAddres, calculating it on-the-fly instead. It also just takes the initial `salt = 0` value as a default score-to-beat rather than a sentinel for any salt is allowed as a simplification
- comparison strictness match comments - unchecked vanity math
| 31728 |
this commit adds a contract that creates a competition to generate the
vanity address for Uniswap V4. It does so using CREATE2 salts,
pre-calculating the address at which the contract will be deployed and
applying a score to the address based on its vanity.
Related Issue
Which issue does this pull request resolve?
Description of changes