🌊 Pool Launch
Pool Launch is Flap's second launch protocol, independent of the bonding curve. A token does not start on a curve: one transaction creates the tax token, adds its liquidity directly to a DEX pool, burns the LP, and the token trades on the DEX from the first block.
Because there is no curve, the initial liquidity has to come from somewhere else. That is the point of Pool Launch: you decide how the initial liquidity is raised, with your own launch page.
Pool Launch is in beta and is permissioned. You cannot launch on it directly yet: your Launcher Factory must first be audited by Flap. See Getting access.
Build your own launch page: Launcher and Launcher Factory
A Launcher is your launch page on-chain. It holds the logic that runs before the token exists: a presale, a mint, a game sale, a crowdfund, an allowlist round, or any other way to raise funds. Users interact with your Launcher directly, and the Launcher keeps all of that state itself (pricing, caps, contributions, claims). When its condition is met, typically when the funds raised reach the threshold it needs, the Launcher launches the token straight into the pool, using the raised funds as the pool's liquidity.
Launchers are created by a Launcher Factory: your contract that deploys one Launcher per launch, with that launch's settings (name, target, duration, …). Only the Pool Launch Portal can call your factory, and only once Flap has enabled it; users start a new launch through the Portal, never through the factory directly.
| Contract | Who writes it | What it does |
|---|---|---|
| Launcher Factory | You | Deploys a new Launcher for each launch. Audited once by Flap and enabled on the Portal, then reused for every launch. Built on LauncherFactoryBase, which Flap requires. |
| Launcher | You | Your launch page: raises the funds under your rules, then launches the token through the Pool Launch Portal. One Launcher launches one token, once. Can describe itself (name, target, title, summary) for terminals. |
| Pool Launch Portal | Flap | Records each Launcher and the factory that created it, then creates the token, seeds the pool and burns the LP. It does not read your Launcher's internal state; it only checks the launch itself. |
| Vault (optional) | You | Receives a share of the token's tax revenue and, optionally, a reserve of tokens. See Reserve tokens for a mechanism. |
How a launch runs
- Create a Launcher. Your app calls
Portal.newLauncher(factory, data). The Portal checks that your factory is enabled, asks it to deploy a Launcher (datais whatever your factory expects, for example the token name and the raise target), records which factory created it, and emitsFlapNewLauncherCreatedwith the Launcher's own description, so terminals and monitoring can list it straight away. - Raise funds. Users interact with the Launcher: they contribute, mint, buy in a presale or play the game. Your rules decide what happens if the target is not reached, for example a refund after a deadline.
- Launch. Once the threshold is reached, the Launcher itself calls the Portal's
launchTaxTokenV2. In that one transaction the token is created, the raised funds and the pool's share of the supply are added to the DEX pool, and the LP is burned. Each Launcher can launch only once. - After the launch, the Launcher can let contributors claim their share of the tokens, and the token trades on the DEX.
Two things help terminals show a Launcher properly:
- Description. A Launcher can describe itself: the token name and symbol, the quote token and raise target, the share of the supply that goes into the pool, and a short title and summary (in English and Chinese). The Portal copies it into the creation event. It is display data only and never affects the launch, and a Launcher without one still works. See Describe the Launcher.
- Creator. The Launcher can declare the user who started the sale as the token's creator, so terminals show that user instead of the Launcher contract.
Example: a contribution round
MintLauncher (with its MintLauncherFactory) is a complete Launcher for a simple contribution round:
- Contributors send BNB until a target is reached. The contribution that reaches the target launches the token in the same transaction.
- The whole raise becomes the pool's quote side, and half of the supply becomes the pool's token side.
- The other half of the supply goes back to the Launcher, and contributors claim it in proportion to what they put in.
- If the deadline passes before the target is reached, contributors take their BNB back.
The same pattern works for a mint (sell an NFT, then launch), a game (in-game purchases fund the pool), or a crowdfund paired with a vault: CrowdLauncher + CrowdVault, where contributors also share the token's tax revenue.
Both examples are in the example repository. Each one has a fork test that runs it against the live Pool Launch Portal on BNB Chain and BNB Chain Testnet, from creating the Launcher through the launch to the last claim. The repository also contains the recommended base contracts for your own Launcher and factory: LauncherBase and LauncherFactoryBase.
Reserve tokens for a mechanism
The creator chooses the total supply and how much of it goes into the pool. Part of the rest can be reserved and handed to a Pool Launch Vault inside the launch transaction. The vault receives a share of the tax revenue and holds the reserve, and its code decides how both are used, for example mining or staking rewards, airdrops, vesting, or releasing tokens as the market cap grows.
A Launcher and a Vault can be used together: the Launcher raises the initial liquidity, and the Vault runs the mechanism on the reserved tokens afterwards. Reserved tokens are held in Flap's Token Dock, a shared, well-known contract that terminals can label as "reserved", so a vault's reserve is not mistaken for one large holder.
Graduation
A Pool Launch token is on the DEX from the first block, so there is nothing to migrate. Instead, the launch is checked once, inside the launch transaction: if the pool's quote side is worth enough for its share of the supply, the token is shown as Graduated; otherwise it stays New. A launch below a lower creation floor is rejected. An audited Launcher Factory (or Vault Factory) can be given a lower floor, agreed during the audit.
The two floors, in USD of the quote put into the pool:
quoteUsd = poolQuote × quote USD price
graduationFloor = $1,500 × multiplier × totalSupply / poolToken
creationFloor = $750 × multiplier × totalSupply / poolToken
graduated ⇔ quoteUsd ≥ graduationFloor
launch allowed ⇔ quoteUsd ≥ creationFloor (otherwise LaunchLiquidityTooLow)
- The floors are for a pool that holds the whole supply. With only part of it in the pool, they scale with
1 / share: at 50% the graduation floor is $3,000, at 20% it is $7,500. multiplieris1(10000 bps) unless the launch's Vault Factory, or else its Launcher Factory, has a lower one.- Example: BNB at $600, 3 BNB in the pool, 50% of the supply in the pool.
quoteUsd = $1,800, the creation floor is $1,500 and the graduation floor $3,000: the launch is allowed but the token stays New. It would need 2 BNB more to graduate. - The quote token's USD price is set on the Portal by Flap (
launchQuoteConfig). To check a planned launch, callgraduationFloorV2.
Getting access (beta)
During the beta, Pool Launch is permissioned, not permissionless:
- A Launcher can only be created through a Launcher Factory that Flap has audited and enabled on the Portal. Calling
newLauncherwith any other factory reverts withLauncherFactoryNotEnabled. - On BNB Chain, token creation is currently paused for everyone else. A Launcher is let through by its own Launcher Factory alone: while that factory is enabled, its Launchers can launch. If Flap disables the factory, it can no longer create Launchers, and its existing Launchers can no longer launch during the pause.
- If your launch also uses a Vault, its Vault Factory must pass the audit too, and Flap enables it for the vault itself (its floor and its UI). A Launcher does not need the Vault Factory to get through the pause.
To launch on Pool Launch:
- Contact the Flap team with your Launcher Factory (and Vault Factory, if any) to start the audit.
- Pass the audit. The floor multiplier for your factory is agreed at this step.
- Flap enables your factory on the Pool Launch Portal, and registers its UI so your Launchers appear on Flap.
- Launch. Your audited factory is then reused: every new launch creates a new Launcher through the same factory, with no new audit as long as the factory does not change.
Learn more
- Build on the Pool Launch Protocol: the launch parameters, the Launcher and its factory, and Pool Launch Vaults.
- Build an Indexer: the events and on-chain reads.
- FlapPoolLaunchVaultExample: example Launchers and Vaults with fork tests, and the base contracts to build on.
- Deployed Contract Addresses → Pool Launch protocol.