Jupiter Launchpad Modelling : An Inituitive Way To Design Launch Liquidity Curves


One of the key mechanisms for the Jupiter LFG launchpad is a single sided Meteora DLMM pool. Usual price curve models, like Uniswap, Balancer, and Curve are highly rigid and inflexible, while Meteora’s DLMM curve allows for project teams to precisely distribute liquidity and tokens based on their preferences.

Since the setup of these pools is fully customisable, projects can choose exactly how they want their curve to look and find out how much they can expect to raise. To assist teams in designing their price curves, we published a simulation site: https://lfg.jup.ag/design that allows you to play around with various inputs and understand how they differ.

We want projects to design the price curve according to a set of highly intuitive parameters like initial price to start, max price to sell, and how fast the price should increase.

The Price Curve Model

Unlike other models, we do not start with complex liquidity models which are hard to intuit. Instead, we start with a highly intuitive model to determine the price curve, based on the net amount of tokens in the pool vs USDC. The rice curve is then used to create a liquidity distribution graph.

The price curve describes how the price changes as tokens are withdrawn from the DLMM pool, while the liquidity distribution graph describes how many tokens are available at each price point.

The price curve is determined by the formula P=(M-I)\left(\frac CA\right)^K+I , where:
P is the price
C is cumulative tokens withdrawn from the pool

The price curve can be adjusted using the following parameters which lends itself well to different strategies:
K is the curvature which determines the steepness/gradient of the price curve
I is the initial price the token will be offered at
M is the maximum price the token will be offered at
A is the total number of tokens in the pool.

For example, the following curve shows how the price will increase as more and more tokens get withdrawn from this pool.

This is a price curve with a steep early curve, where the price increases fast at the start. The initial price is set to is 0.1 USDC and the final price is set to 1 USDC for this graph. The first token to be withdrawn is priced at 0.1 USDC.As the curve is steep at the start , by the time 10% of tokens are withdrawn, the price will move to 0.55 USDC. This graph gives less advantage to early buyers/bots as they can only buy a small amount before the price increases sharply. Thus they cannot get much at a very low price. This gives bots less advantage as there is not much low-priced liquidity for bots to snipe.

This is a price curve with a flatter early curve, where the initial price is 0.1 USDC And the final price is 1 USDC. The first token to be withdrawn is still priced at 0.1 USDC. As the curve is less steep at the start, if 10% of tokens are withdrawn, the price will only move to 0.12 USDC. This gives more advantage to early buyers as they can pick up much more tokens at cheaper prices. Bots are able to get many tokens for cheap.

Curvature Explained

Curvature decides the change in gradient of the graph. High curvature means a larger exponent which leads to a concave graph. This leads to a graph where price increases faster at the start and slower at the end. A low K value leads to a convex shaped graph where price increases slower at the start and faster at the end.

We have 3 examples here, all with different K values (all other parameters remained the same).

Calculating Stable Liquidity Secured

One of the main reasons why projects provide liquidity using the price curve is to secure stable liquidity like USDC. The stable liquidity is secured as users withdraw tokens and deposit stable tokens into the DLMM Pool.The stable liquidity secured can be calculated using the integral of the price curve
\int_{0}^{w}(M-I)\left(\frac {C}A\right)^K+I\,dc , where w is the cumulative tokens withdrawn at that time. Projects can use this to find out how much they can secure given a certain valuation by first finding the cumulative tokens withdrawn(w) given a certain price. Then the number of tokens withdrawn can be used in the formula to find stable liquidity secure.
This is an example of a price table which shows how many tokens are withdrawn and USDC in the pool at different prices. The USDC in the pool is calculated with the integral:

Liquidity Distribution

As mentioned before, the liquidity distribution describes the number of tokens available at each price point.

We get the liquidity distribution graph by first rewriting the equation
P=(M-I)\left(\frac CA\right)^K+I to express C in terms of P. This is C=\sqrt[K]{\frac{M-I}{P-I}} The derivative of that is then the liquidity distribution which is \frac{A\sqrt[K]{\frac{M-I}{P-I}}}{K\left(P-I\right)} . This represents the amount of tokens available at each price.The integral of the graph is the total number of tokens in the pool initially. The liquidity distribution graph for a graph with a larger K value like the one shown below, is higher at the start and lower at the end. This means that more tokens are available at low prices and less at higher prices.

Liquidity Distribution Graph: X-Axis: Price, Y-Axis: Liquidity / Tokens Available

Translating Liquidity Distribution into DLMM Bins

Introduction to DLMMs

Meteora’s Dynamic Liquidity Market Maker (DLMM) involves dividing the total liquidity range of an asset pair into smaller segments called “bins”.

Users trade in a DLMM pool by swapping tokens in the active bin, and this changes the ratio only in that bin. Bins to either side of the active bin only contain one token and never both.

Each bin represents a single price point and the difference between consecutive bins is determined by the bin step, set by the pool creator.

This is an example of a DLMM pool where there are bins with token X and Y.

The size of the bins are calculated in terms of the quote token which is set by the owner. Let’s assume token Y is the quote token. The bin size is then calculated using TX PX + TY , where TX = Number Of Token X in the Bin, PX = Exchange rate of X to Y in that bin, TY = Number Of Token Y in the Bin

Creating a single sided DLMM Pool with Token X

Using the price curve generated, the tokens can be distributed into a single-sided liquidity position on the DLMM curve. Each bin represents a small portion of the liquidity distribution graph and will have the amount of tokens of the range it represents. Therefore the integral of the liquidity distribution is used to find the amount of tokens in that bin. The bin size is generated using the formula bin price x number of tokens in the bin.

Initially, the pool will only have token X so it will look like this, where there is only X in the pool and there is no USDC.

When users start withdrawing X and depositing USDC, the active bin moves to the right and the active bin will have the price at which X is valued at.

This is what the DLMM pool looks like when users have bought all the X in the first 4 bins and have bought some of the X in the 5th bin. Thus the current active bin is the 5th bin at price P5 and the current price is P5.

In the actual one sided DLMM curve, there will be hundreds or even thousands of bins.

In the DLMM pool, the price increment from 1 bin to its neighbour is not constant, in fact the price difference increases exponentially. The way we calculate the increment will be explained later.

Each bin is identified by a unique integer ID, and the bin to its right possesses an ID that is one more than its own. DLMM Pool Bin ID can be converted into the bin price using the formula
Price=\left(1+\frac{step}{10000}\right)^{ID} and ID can be obtained from price by using the formula \mathrm{ID}=\left\lfloor\frac{\log\left(Price\right)}{\log\left(1+\frac{step}{10000}\right)}\right\rfloor.

We create the DLMM pool by first getting the ID of the first bin. This is done by plugging in the initial price into this formula, \mathrm{ID}=\left\lfloor\frac{\log\left(Price\right)}{\log\left(1+\frac{step}{10000}\right)}\right\rfloor. We then find the ID of the last bin by plugging in the max price to the same formula.
We then find all the integers in between the first ID and last ID to generate the IDs for all the other bins. Using these IDs, we use the formula Price=\left(1+\frac{step}{10000}\right)^{ID} to find the price for all the bins.

For example, if the price range is from 0.1 to 1 and the bin step is 150, the first bin ID is -154 . The last bin ID is 0 . Thus, in this case there will be 155 bins in the pool with IDs of -154, -153, -152….0. This is what the bins look like with a K value of 1.6 (Note that there are many bins which make it is hard to see each individual bin)

Each bar below represents a bin and buyers start buying from the first bin. The vertical axis is liquidity in USDC and the Y axis is Bin ID.

Due to how the Bin ID is converted into price and vice versa, the bin step determines how many bins there are.

Thus, larger bin step means that the difference between adjacent bins are generally larger

This what the bins of a pool with bin step 400 looks like:

This is what the bins of a pool with bin step 1 looks like:

Example using $JUP

This is the curves that have been proposed for $JUP and was used for mockJUP:
Note that these may not be the values used for $JUP
This curve gives less advantage to early buyers and bots as the price increases faster at the start and more liquidity is towards the end

(K=0.8, I=0.1 M=0.8, A=500)

The price curve shows how the price increases as more tokens are withdrawn from the pool. The amount it increases by is affected by K, which affects the gradient of the curve.

The liquidity distribution graph shows the number of tokens that can be withdrawn or liquidity at the different prices.

In the example above , there is more liquidity at higher prices compared to lower prices as liquidity increases with price.

At the end of the curve, when all tokens have been purchased (and no additional tokens added into the pool), the price will be at your maximum price (M). Using the curve above, when 0 JUP tokens have been withdrawn , the price is at $0.1(I). When 250 Million JUP tokens have been withdrawn, the price rises to around $0.5 and at the end when all 500 Million JUP tokens have been withdrawn, the price is at $0.8 (M).

Using the parameters above, we can generate a DLMM Pool with a bin step of 25 that looks like this:

The total number of bins inside is 833.

Although in this chart it seems that there is way more liquidity at higher prices as the bins to the right are much larger, this is because the bin size is calculated using bin price times the number of tokens in the bin. Thus the bins to the right are larger as they have a larger price. Bins to the right also have more tokens as they cover a larger price range and represent a larger portion of the liquidity distribution graph

With a fixed range, bin steps will affect the number of bins. If the bin step is larger, there will be less bins, and vice versa.


The JUP Launchpad Model focuses on providing liquidity and bootstrapping rather than price discovery. It allows projects to customise their price curve to best suit their needs. The price curve can be then used to create a liquidity distribution graph which then is used to create a single sided DLMM pool where traders can withdraw tokens from. The curve can be designed to also benefit different groups differently and can be designed to either give more or less advantage to early buyers.


Nice it’s just like a algebra math and other math categories


Great explanation. It’s impressive how the Jupiter LFG launchpad offers flexibility in liquidity distribution. The emphasis on stable liquidity and the influence of curvature on price curves are insightful. It’s a well thoughtout model with clear benefits for projects.


question1:I think there is a systematic risk (not a financial risk) that the curve won’t work if airdrop selling is greater than buying in the market causing the JUP price to go below 0.4 during the time period of the JUP launch. So no matter if the initial price range start point is set at 0.1 or whatever, such a one-sided curve cannot avoid the above systemic risk. at first the bots will always buy faster than the airdrop claimers can sell, but it’s also possible that after an hour or a half, more and more airdrops will be sold than the market will buy. The curve worked well for this jup, but there’s no guarantee that it won’t happen for the next launch, right?
question2:Is the single-sided liquidity justified? One would question whether this is IDO in disguise.
question3:Why not use double-sided liquidity (like Bid Ask of Meteora)?


Nice article. Thanks