The factory as it currently stands has a couple key issues, the first of which being that while it does allow anyone to deploy any hyperdrive pool, it can be difficult to determine on chain or off-chain, what a "safe" hyperdrive pool with a non-rugging token or pool is. To combat this the factory should be refactored to include the Deployer Contract within the actual factory itself (pending an external lib codesize reduction to allow this). From there, an ERC4626 factory should allow governance sanctioned "configs".
The factory should allow a caller to provide both a config hash (presumably a full config could be used as well, but would be a lot of data to provide all at once) and a token address, and be returned with a pool address. Within each pair creation event, a config hash should also be emitted, that way off-chain indexers can use this combination of config hash events + governance sanctioned config hashes to determine which pools to populate.
This also allows alternative front-ends to look for different config hashes based on their event filtering from the factory, so this refactor should follow in a couple key pars
[ ] - Move deployer into the factory (pending codesize reduction with library migration)
[ ] - Expose a mapping of token + config hash to return pool address
[ ] - Ensure an event is emitted on pair creation containing the config hash
[ ] - [OPTIONAL] On chain there can also a method on the factory for governance to sanction a specific config hash, and return a list of sanctioned config hashes
The factory as it currently stands has a couple key issues, the first of which being that while it does allow anyone to deploy any hyperdrive pool, it can be difficult to determine on chain or off-chain, what a "safe" hyperdrive pool with a non-rugging token or pool is. To combat this the factory should be refactored to include the
Deployer
Contract within the actual factory itself (pending an external lib codesize reduction to allow this). From there, an ERC4626 factory should allow governance sanctioned "configs".The factory should allow a caller to provide both a
config
hash (presumably a full config could be used as well, but would be a lot of data to provide all at once) and a token address, and be returned with a pool address. Within each pair creation event, a config hash should also be emitted, that way off-chain indexers can use this combination of config hash events + governance sanctioned config hashes to determine which pools to populate.This also allows alternative front-ends to look for different config hashes based on their event filtering from the factory, so this refactor should follow in a couple key pars