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

PositionManager.sol

Last updated

Was this helpful?