Hooks
Introduction
Flaunch extensively uses Uniswap V4 hooks in the PositionManager
to allow for custom logic to be actioned during any swap and interaction against our pools.
Uniswap V4 introduces Hooks, a system that allows developers to customize and extend the behavior of liquidity pools.
Hooks are external smart contracts that can be attached to individual pools. Every pool can have one hook but a hook can serve an infinite amount of pools to intercept and modify the execution flow at specific points during pool-related actions.
Key Concepts
Each liquidity pool in Uniswap V4 can have its own hook contract attached to it. Hooks are optional for Uniswap V4 pools.
The hook contract is specified when creating a new pool in the
PoolManager.initialize
function.Having pool-specific hooks allows for fine-grained control and customization of individual pools.
Position Manager
The PositionManager is a Uniswap V4 hook that controls the user journey from token creation, to fair launch, to ongoing swaps.
Public Functions
This does not included public functions found in the hooks implemented; these can be found under this subpage.
flaunch
Creates a new ERC20 memecoin token creating and an ERC721 that signifies ownership of the flaunched collection. The token is then initialized into a UV4 pool.
poolKey
Returns the PoolKey mapped to the token address. If none is set then a zero value will be returned for the fields.
getFlaunchingFee
Gets the ETH fee that must be paid to flaunch a token.
getFlaunchingMarketCap
Gets the ETH market cap for a new token that will be flaunched.
Structs
Which Hooks are Used
This breaks down the functionality included on each Uniswap V4 hook call.
beforeInitialize
We prevent external contracts from initializing a pool with this hook contract.
afterInitialize
Emit PoolState update to Notifier subscribers and subgraph
beforeAddLiquidity
If in fair launch window, we need to prevent liquidity being added by external parties
afterAddLiquidity
Emit PoolState update to Notifier subscribers and subgraph
beforeRemoveLiquidity
If in fair launch window, we need to prevent liquidity being removed by external parties
afterRemoveLiquidity
Emit PoolState update to Notifier subscribers and subgraph
beforeSwap
Check if the token is scheduled to be flaunched and only allow a swap to take place if there is a premine call available
If the FairLaunch window has ended, but our position is still open, then we need to close the position
We attempt to fill the swap request from our FairLaunch position. If the swap parameters surpass the FairLaunch position, or the window has closed since the last swap, then this call will also close the position and create our new range.
We want to see if we have any token1 fee tokens that we can use to fill the swap before it hits the Uniswap pool. This prevents the pool from being affected and reduced gas costs. This also allows us to benefit from the Uniswap routing infrastructure. This frontruns Uniswap to sell undesired token amounts from our fees into desired tokens ahead of our fee distribution. This acts as a partial orderbook to remove impact against our pool.
afterSwap
Captures fees from the swap to either distribute or send to ISP
Once a swap has been made, we distribute fees to our LPs and emit our price update event
If we have a feeCalculator, then we want to track the swap data for any dynamic calculations
Emit PoolState update to Notifier subscribers and subgraph
beforeDonate
Not used
afterDonate
Emit PoolState update to Notifier subscribers and subgraph
Last updated