Muffin Pool (or Multiple Fee Factors inside a Pool) is Deliswap’s first AMM product. This is a concentrated liquidity pool inside which there are multiple swap fee tiers.
Up to now, we’ve seen the benefits from concentrated liquidity, e.g., increased capital efficiency. We see selectable fee tier as the next step toward making liquidity provision more configurable and unlocking advanced LP strategies.
The first part of this article talks about the problems that motivate me to build Deliswap Muffin Pool. The second part digs deeper into the protocol’s mechanism and technical implementation.
Motivations:
Current choices of fee tiers
Imagine being an ETH-USDC liquidity provider. There’re two pools in the market you can choose from: a 0.30%-fee pool and a 0.05%-fee pool. Your goal is to make the most money. Which pool should you choose?
Well, it depends.
0.05% or single-digit basis points has always been the de-facto standard for stablecoin pairs. But since the launch of Uniswap v3, the ETH-USDC 0.05%-fee pool has ranked the top in trading volume — 6x more traded than the 0.30%-fee pool.
Perhaps the paradigm shifted? Does 0.05% fee become the new standard for non-stablecoin pairs? Interestingly, that’s not the case. The ETH-USDC 0.30%-fee pool still has the highest total value locked (or the 2nd highest), and it doesn’t look like it’s declining.
You see, both fee tiers have their own “supporters”. Both have decent depths of liquidity, process decent amounts of trades, and co-exist well in the market.
To liquidity providers, that makes sense, because both tiers have their own strengths. The lower fee attracts more trades; the higher fee extracts more per trade. And after all, the profit of liquidity providers is simply the product of these two factors, i.e., trading volume * percentage fee.
However, fee and trading volume are like opposing forces. If one increases, the other decreases. So, liquidity providers should look for a good balance between these two factors to maximize profits.
Ok, so how to find the perfect balance? How to find the optimal fee? Well, there’s no short answer. You can get different answers based on how you model the problem. That’s a research topic we need math wizards to expand in another article.
But for now, the only salient point I want to highlight is that, in principle, there IS an optimal fee level that maximizes the fees you earn as a liquidity provider. Is that 0.05%, 0.30% or 1%? Possibly, but it’s also probably somewhere between them.
But right now, we have no other choices — the market only has these three fee tiers to choose from. Even if we know what fees work the best, we are still missing a platform that provides enough fee tiers to implement and test strategies around them.
Liquidity Fragmentation
A solution today would be to deploy more pools with different fee tiers, and let liquidity providers choose the one they want. However, it fragments liquidity.
When liquidity is spread out to several small pools, the small pools are too shallow to provide a low price impact for swaps, compared to the original big pool. That adds an extra layer of cost that discourages traders from using the pools.
DEX Aggregator
A DEX aggregator (or a smart router) can ease the liquidity fragmentation problem. They can split orders into smaller ones and route them to pools of different fee tiers. But interacting with multiple pool contracts in one tx is gas-intensive, e.g., routing to four Uniswap pools takes about 500,000 gas. Small traders can’t withstand such high gas costs.
Another constraint is that such order optimizers are usually off-chain. Protocols that need to swap tokens on-chain are unable to use it. This is crucial to certain protocols, say liquidity management vault, which almost always wants the best market rate to rebalance positions, and sometimes a few basis points cheaper can sufficiently improve profitability and compound it.
Muffin Pool
Overview
We mentioned the problem of interacting with multiple pool contracts at once. Now think about multiple pools — concentrated liquidity pools with different fee levels — are packed inside one contract. That’s Muffin Pool.
A Muffin Pool has up to six fee tiers. Each fee tier acts like a “sub-pool” and has its own liquidity and asset price. Liquidity providers can choose their preferred fee tier and price range to provide liquidity on.
The pool splits incoming orders into sub-orders and routes them into different fee tiers. Then, the fee tiers execute the sub-orders with their own liquidity. The routings are optimized so traders can get optimal exchange rates.
The goal of Muffin Pool is to offer up multiple fee tiers for liquidity providers to design and implement advanced strategies that involve finding optimal fee levels, and meanwhile keep the gas consumption per swap under a reasonable level.
Concentrated Liquidity
A brief intro to concentrated liquidity: in the traditional x*y=k pool, users provide liquidity on the (0, infinity) price range, whereas in a concentrated liquidity pool users can select their own price ranges. So, users can pick a narrower price range to amplify their liquidity. More details here.
In a Muffin pool, to add or remove liquidity, a liquidity provider picks a fee tier first, then picks a price range to place their liquidity, as if doing it in an ordinary concentrated liquidity pool. So, each tier has its own ticks that have their own liquidity.
Order Optimization
The pool splits orders into sub-orders of different sizes for different fee tiers. It uses the method of Lagrange multiplier to calculate the optimal size of each sub-order, taking account of the original order size Δ and each tier’s liquidity L, asset price P and percentage fee (1 — γ). The final formula is:
δ_i*: The optimal amount routed to tier i in an n-tier poolExample with full-range liquidity
Imagine a Muffin Pool for ETH-USDC with two fee tiers: 0.15% and 0.40%. Alice and Bob both have 1000 ETH and 4,000,000 USDC to provide to the pool. Alice chooses the 0.15% tier, while Bob chooses the 0.40% tier.
To keep it simple, let’s assume both Alice and Bob are doing full-range provision. Let’s also assume both tiers have the same asset price: 4000 USDC per ETH.
Now, Charlie comes to swap 10 ETH for USDC. By the formula above, the pool splits Charlie’s 10 ETH into two sub-orders: 4.375 ETH to 0.40% tier and 5.625 ETH to 0.15% tier.
During the swap, Charlie pays Alice 4.375 * 0.40% = 0.0175 ETH and pays Bob 5.625 * 0.15% = 0.0084 ETH. Although Alice’s tier is less traded in this swap, she still makes more profit, obviously because her tier has a higher percentage fee.
In total, Charlie pays 0.0259 ETH, or 0.259%, as the swap fee.
Implementing Swap in Concentrated Liquidity
** This section describes the implementation of swapping. You may need a bit understanding of how swapping works in an ordinary concentrated liquidity pool. It’s okay to skip if it’s too technical for you.
Swapping under concentrated liquidity is a bit tricky. When a price crosses from one tick to another, there’s some liquidity needed to be added or removed. To handle that alongside multiple fee tiers, we use a greedy strategy. The steps are:
- When an order comes, we split the order using the formula described above with the tiers’ current price and liquidity.
- We let each tier process its sub-order within its current tick, ensuring the asset price won’t move past the boundary of the current tick.
- Those tiers that cannot process the whole sub-order within a tick and have input tokens left will cross to their next ticks, adding or removing some liquidity.
- We gather the remaining input tokens from all tiers and repeat the whole process until we use up all tokens.
It’s worth noting that, in principle, greedy strategy doesn’t guarantee an optimal optimization, but it can approximate it well under a reasonable number of steps, hence keeping the gas spending low.
Side Note: Price Movements
In general, the pool distributes more trades to the lower fee tiers. And for an AMM, each trade is an impact on price. So we can expect to see the prices of the lower fee tiers swing up and down more vigorously than the higher fee tiers’.
I found that drawing this phenomenon out helps me understand how lower fee tiers capture more trades in the pool and are more sensitive to market change.
Interestingly, we can see another pattern here: there’s a maximum distance between any two tiers’ prices. These are the maximum price differences below which no arbitrage opportunities exist between tiers. And our order optimization naturally prevents such arbitrage opportunities. Mathematically, we can represent the price relationship as:
Compromise
More fee tiers inevitably mean more gas used per swap. The more tiers the pool has, the more data it loads from storage, and also the more chances a tier has to cross a tick. To offset that, particularly on Ethereum L1, we set a wider tick spacing on purpose to lower the chances of crossing ticks in a swap. The tick spacing is updatable nonetheless. We shall narrow it when the gas price drops in the future.
Closing Thought
The meta-objective of Deliswap Muffin Pool is to make AMM liquidity provision more configurable and flexible, by supporting more kinds of input parameters, and hence unlocking more possibilities for profitable LP strategies. We see the feature of selectable fee tiers as one of the next steps towards making this happen.
Our Next Step
We’ve finished the smart contracts and are now looking for audits. Meanwhile, the front-end is under development. We target to ship an alpha version of the protocol in several weeks, and we’ll be looking for early testers to try it out.
I’ll later publish a python prototype to demonstrate the swapping mechanism. There may also be another article to explain the oracle in Muffin Pool.
If you’re interested in Muffin Pool or have any thoughts and questions about it, find us on Discord or Twitter. We‘d love to hear from you.
All the best,
DW
