The LFG Launchpad is our attempt as building an end to end support system for onchain launches, giving projects the best chances of success and protecting users while giving them sufficient choice and information.
We focus on the sufficiency of liquidity, not generating overt amounts of hype to the disadvantage of early buyers, and giving bots or bot users some early advantage (so they can also seed liquidity for sellers from the very first block) but not overtly so.
Overview
We have long been dissatisfied with a whole range of economical and technical issues we have observed with other token launches, and here we list our the main ones:
General Launchpad Problems:
- Token-Gated Launchpads: Probably the worst long term incentive alignment. Unfair allocations of very low priced tokens to a privileged group of crypto users has no interest in the launched project except for the hour 1 pump. Retail who are not part of the initial group becomes exit liquidity. Privileged users leave right after, rarely becoming helpful for project
- Uncapped Onchain IDOs: Attracts USDC funding without providing for buyer-remorse and secondary market support. Early hype for the project and the token during the launchpad process does not transition to an active secondary market.
- Liquidity Bootstrapping Pools: Price starts high and comes down over-time, designed to penalize and demonize bots but ends up penalizing early supporters and discouraging additional buyers.
- Deploying a token onto an CPMM: Projects have to put up USDC for the same amount of tokens they want to sell, have to decide on an initial price and the xyk curve is flat very early on and rises dramatically. Therefore, these pools often have very low liquidity, and bots are able to immediately eat up most of the early supply, and even slight later users have to buy at a dramatically higher price.
For projects launching tokens:
- They do not expose themselves to a new community of actual users and supporters
- The risk of having a price be settled in an isolated pool and having it potentially drop right as it hits the market provides a very bad starting point
- Most of the projects coming up also have a form of airdrop or a way to reward early users and adopters. The dynamics of that with the above, most significantly the isolated pools is very hard to predict or understand.
- Token launches are often hard, complex and difficult to manage, with issues like infra
For users:
- Buys at a much higher price than early participants
- Lack of backstop protection where teams get all the capital and users have no way to sell back
- Gets hyped and have to ape in very early on
- No liquidity if they wish to dump their airdrops asap
- Rekted by high gas cost due to drastically increased gas requirements at the moment, or having no visibility at all into what the requirements are at all.
Design Goals:
With these problems in mind, we designed the Jupiter launchpad with these ideas in mind:
- Full Jupiter community rallying for you, the team providing operational expertise and full support staff to answer any technical issues.
- LFG Price discovery: Everyone (airdrop recipients, bots, traders) starts at once, no complicated isolated pool mechanisms. The open market should be where discovery happens.
- Launch pool that acts as both liquidity bootstrap immediately as well as backstop. 100% customizable for projects needs, locks team LP for days and mitigate bot advantage via a range of mechanisms.
- Integration with full network of bots so you can choose your fav bot to use it with
- Fully transparent on-chain market making, completely zero shennigans.
Components
Here are the components:
Airdrop Mechanism For Millions
Building off Jito’s excellent library for airdrops, we added key features to allow it to scale to millions while claim can only be enabled at a given slot.
- Slot to start opening addresses at a given starting slot
- Reduce hot accounts for Solana in hot events like airdrop. Because if there are like hundred thousand ppl claiming at the same time on the same merkle tree, there would have a significant percentage of txs will not go through
- Reduce the length of proof for merkle tree. Length of proof depends of number of nodes: log2(num_of_addresses), so if number of addresses increases more, transaction size for a claiming transaction will blow up the Solana’s limit.
- Even we do sharding, but we still maintain the single source of truth, anyone can retrieve or verify merkle root from the single list of addresses and the number of addresses for each merkle tree
Launchpool that acts as both bootstrap and backstop liquidity for users
Jupiter Launchpad uses a Meteora DLMM pool that:
- Allow single side deposit: Unlike other clmms or amms, DLMM allow user to add liquidity by only 1 token, So for token launch, token team can decide on any price curve and deposit tokens on each bin for purchase
- Locked LP for days after token sale to maintain the backstop for tokens. Unlike other token sale platform, user can only buy, but cannot exit until the token sale done, for DLMM, the price range the team add liquidity will become the backstop for user, user can sell back the price range, token team can only get fee after that
- Limit the amount a bot can buy in 1 transaction: that due to the nature of DLMM, a swap transaction can only cross 280 bins, that limit the number of tokens a wallet can buy in one transaction. That would prevent a single bot that can buy all tokens in pool
- Activate by slot: for other amm, when LP add liquidity, there will have users/bot (who can snip the pool) arbitrage to buy tokens at the cheapest price. It would make difficult for token project to coordinate about time launch, and buffer time for everyone to prepare in a race. On DLMM, we do to activate trading by slot, that is transparent and fair for everyone
- Reduce complexity for seedings liquidity. Normally, token team will need to do multisig to manage positions and create proposal to seed liquidity in a DEX platform. On DLMM, an external operator can do that on behalf of multisig, but operator can only withdraw fund to multisig. By this design, we remove the complication at the beginning, but still the maintain the security that team can easily verify after the operator done his/her job.
Highly intuitive tool to design the liquidity pool exactly the way you want
Unlike other liquidity curves the point here is NOT price discovery or equilibrium, but rather liquidity bootstrapping and backstopping. Along with every project’s extremely different needs and context, a custom price curve tool is needed.
Enter The LFG Price Curve design, maths, paper and website is being.
This tool here to help project teams design the price curves they want, which will then automatically tell them the amount raised at different price points, executes the mathematical translation into DLMM bins etc.
For example, you can have a low starting price to incentive bots and early buyers, but the curve steeps strongly upwards with only a small number of tokens available for early takers before a more gentle slope occurs. This incentivizes early aggressive price action while leaving most tokens for users.
Alternatively, less hyped project can certainly opt for a more gentle slope with a higher starting price, which will allow everyone to acquire the tokens gradually over time without much price advantage for early buyers.
Launch Specific UX For Users
We have also put in a lot of work to make a launch specific UX work.
- Special network reporting to see the on-chain chaos
- Full trading features but focused on the pre-ordering process
- Ability to set limit orders and DCA to buy the tokens ahead of time
- Automated gas but max gas protection to help users get their txns through but not pay too much gas.
Infrastructure Scaling
We have worked with top tier RPC providers Triton and Helius to provide highly scaled up RPC support for launches, as well as enterprise level support from related infra companies like Cloudflare, Vercel and GCP.
In addition, we have cached as much of the requirements of the launch page as possible into the backend, allowing the frontend to only use the bare minimum of RPC calls.
Ecosystem Support
Jupiter launchpad will be supported by all the major bots on Solana on day 1, while we are partnering with Meteora and Kamino to ensure you have a highly profitable place to market market your tokens and airdrops the moment you get them.
Summary
We are trying to build the onchain launchpad we want - one that satisfies our needs of airdropping to large numbers of people, gather sufficient liquidity, but also places the needs of users in utmost respect and not leveraging hype or broken incentives.
There is quite a lot here, and I am sure we are missing out a lot of details, so please let us know how we can do better!
