Uniswap version 3.0 has arrived — the popular decentralized exchange got an upgrade recently, as the latest version was unveiled on Wednesday, May 5.
As we outlined earlier this week in our look at what’s new in Uniswap v3 and what it means for you, there are two crucial additions in this upgrade — concentrated liquidity and multiple fee tiers.
Concentrated liquidity offers individual liquidity providers increased control over price ranges. Those positions are then aggregated together into one pool, allowing users to trade against one combined curve. Multiple fee tiers, meanwhile, allow liquidity providers to be more fairly compensated for the level of risk they take on.
These additions allow liquidity providers to offer liquidity with “up to 400x capital efficiency,” and significantly increase risk exposure to assets. It also enables them to add liquidity to a price range entirely above or below market price and offers improved low-slippage trade execution and lower gas fees compared to version 2.0.
We also took a closer look at some of Flipside’s unique data on how Uniswap v3 is being used, including how virtual and real liquidity are interacting, and which addresses are earning the most in fees.
This piece will detail the specific functions that can be called (Actions), corresponding log events that are emitted (Events), and smart contract read variables (State) pertaining to Uniswap V3 pools. The team at Flipside has also built tables that highlight the important characteristics of Pools (namely uniswapv3.pools and uniswapv3.pool_stats), which combine events and contract states into cleaned up, pre-adjusted views from which analytics can be more easily conducted.
Let’s take a closer look at the various v3 pools, and what goes into them.
Diving into the Uniswap V3 pools 🏊
This map describes how Uniswap v3 pools are created. Let’s break it down, starting with what exactly a pool is.
For our purposes, a Uniswap pool is a trading venue for a pair of ERC20 tokens. More specifically, it facilitates both swapping and automated market-making between any two assets that conform to the ERC-20 specification.
As with any smart contract, functions can be called (Actions in our map), log events are emitted when transactions occur (Events), and the values of contract variables can be accessed (State), based on contract ABIs. Flipside data covers all of these. For Uniswap V3 pools, let’s have a closer look at each category:
Actions
First up, on the left-hand column of our map, are Actions. Actions can be initiated by the pool Owner (only the Factor Owner may initiate these) or Anyone, which as the name implies, contain pool methods that can be called by anyone.
Owner actions can include either setFeeProtocol, which sets the denominator of the protocol’s share of fees, or collectprotocol, which collects the protocol fee accrued to the pool. Anyone Actions, meanwhile, include a much wider range of actions, including initialize (sets the initial price for the pool), mint (adds liquidity for the given recipient), collect (collect tokens owed to a position), burn (burn liquidity from the sender and account tokens owed for the liquidity to position), swap (swap token0 for token1, or token1 for token 0), flash (receive token0 and/or token1 and pay it back, plus a fee, in the call back), and IncreaseObservationCardinalityNext (receive token0 and/or token1 and pay it back, plus a fee, in the call back).
Events
Now, on to Events: For Uniswap V3, these include Initialize (emitted exactly once by a pool when #initialize is first called on the pool), Mint (emitted when liquidity is minted for a given position), Collect (emitted when fees are collected by the owner of a position), Burn (emitted when a position’s liquidity is removed), Swap (emitted by the pool for any swaps between token0 and token1), Flash (emitted by the pool for any flashes of token0/token1), IncreaseObservationCardinalityNext (emitted by the pool for increases to the number that can be stored), SetFeeProtocol (emitted when the protocol fee is changed by the pool), and CollectProtocol (emitted when the collected protocol fees are withdrawn by the factory owner).
State
Finally, we have the far right-hand column of our map, State, which contains key variables and other information pertinent to the operation of a given pool. State lets an analyst accurately answer questions like: “how much liquidity does a pool contain?”, or “what is the second token for this pool?”, or “is there any liquidity at this price?”, for example. State can be broken down into three categories Mutable, Immutable, or Derived.
Mutable States are methods that compose the pool’s state and can change with any frequency, including multiple times per transaction. They include: slot0 (exposes the 0th storage slot in the pool as a single method to save gas), feeGrowthGlobal0X128 ( fee growth for token0 as a Q128), feeGrowthGlobal0X128 (fee growth for token0 as a Q128), feeGrowthGlobal1X128 (fee growth for token1 as a Q128), protocolFees (the amount of token0 and token1 owed to the protocol), liquidity (the currently in range liquidity available to the pool), ticks (looks up information about a specific tick in the pool), tickBitmap (returns 256-packed tick initialized boolean values), secondsOutside (returns 8-packed tick seconds outside values), positions (returns the information about a position by the position’s key), and observations (returns data about a specific observation index.)
Immutable states, on the other hand, are those with parameters fixed to a pool forever, meaning the methods will always return the same values. They include factory (the contract that deployed the pool, which must adhere to the IUniswapV3Factory interface), token0 (the first of the two tokens of the pool, sorted by address), token1 (the second of the two tokens of the pool), fee (the pool’s fee in hundredths of a bip), tickSpacing (the pool tick spacing, which governs how ticks can be used), and maxLiquidityPerTick (the maximum amount of position liquidity that can use any tick in the range).
Finally, there is Derived state, which contains view functions to provide information about the pool that is computed rather than stored on the blockchain. These functions may have variable gas costs and include secondsInside (returns a relative timestamp value representing how long, in seconds, the pool as spent between tickLower and tickUpper), and observe (returns the cumulative tick and liquidity of each timestampsecondsago from the current block timestamp).
Learn more
Want to learn more about Uniswap pools? You can see all of these events and states summarized cleanly at Flipside Crypto, just sign up for a free account, and start querying. You can also check out our town hall chat, hosted on the Flipside Crypto Discord at 12 PM ET on Friday, May 14.
And don’t forget, we need your help to build the biggest and best dashboard for Uniswap v3! Just join us on Discord to get started, and be sure to follow Flipside on Twitter and subscribe to the On the Flipside blog to get the latest news, data, analysis, and insights!