You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unlike token send hooks, it is generally unsafe for us to allow pool creators to set hooks for CL pools. This is for the simple reason that once we enable permissionless CL hooks, all pools of this sort would be trivially ruggable by the creator.
Since we commonly have pools created by accounts outside of governance gain adoption (exacerbated by the fact that our router sends all such pools volume and thus liquidity), this would be extremely risky functionality to add. It also conflicts with happy path usage of CL: we don't, for instance, want a project creating a pool for their token to be able to freely rug the pool.
Thus, as a v1 for CL hooks, we should only allow governance to set hook contracts for pools. This has the downside of requiring two governance cycles to get one such pool out (first to upload the contract and then to set it), but this seems an appropriate tradeoff to make given the discussion above.
Suggested Design
Create a gov prop type that handles setting CL hook contracts
Acceptance Criteria
New gov prop is added and tested in e2e
The text was updated successfully, but these errors were encountered:
Background
Unlike token send hooks, it is generally unsafe for us to allow pool creators to set hooks for CL pools. This is for the simple reason that once we enable permissionless CL hooks, all pools of this sort would be trivially ruggable by the creator.
Since we commonly have pools created by accounts outside of governance gain adoption (exacerbated by the fact that our router sends all such pools volume and thus liquidity), this would be extremely risky functionality to add. It also conflicts with happy path usage of CL: we don't, for instance, want a project creating a pool for their token to be able to freely rug the pool.
Thus, as a v1 for CL hooks, we should only allow governance to set hook contracts for pools. This has the downside of requiring two governance cycles to get one such pool out (first to upload the contract and then to set it), but this seems an appropriate tradeoff to make given the discussion above.
Suggested Design
Acceptance Criteria
The text was updated successfully, but these errors were encountered: