Overview

The Kumbaya launchpad uses Uniswap V3 concentrated liquidity positions to simulate a bonding curve, so a freshly-launched token can be traded immediately on the same DEX infrastructure as everything else - no separate AMM, no migration step, no surprises post-launch.

🔥 A note on naming. The launchpad's smart contracts are prefixed Fire (FireLaunch, FireToken, FireGraduator, FireRegistry, FireStream, FuelVault) - a campfire metaphor that fits the "Kumbaya" theme of people gathering around a fire. The contracts are part of Kumbaya, not a separate protocol; throughout these docs "the launchpad" and the Fire* contract names refer to the same thing.

🛡 Audited. Every launchpad contract - including FireToken - is covered by a signed BlockSec audit. No critical or high findings remain open. See Audit & security for the full breakdown and the bundled report.

How a launch works at a high level

┌─────────┐   ignite()    ┌──────────────┐   creates V3 pool,    ┌──────────────┐
│ Creator │──────────────▶│  FireLaunch  │──────────────────────▶│ Stacked seed │
└─────────┘               └──────┬───────┘  seed + tail positions │ + tail pos   │
                                 │                                └──────────────┘
                                 │ if creatorAllocationBps > 0:
                                 │   capture portion → FuelVault (creator liquid)
                                 │   remainder       → FireToken (creator vesting)
                                 ▼
                          ┌──────────────┐
                          │  FuelVault   │ ◀── on each buy: skimBps of token amount
                          │              │     credits the BUYER (not creator)
                          │              │ ◀── giftWithSig moves credits buyer→creator
                          └──────┬───────┘
                                 │ withdraw (creator)
                                 ▼
                              creator wallet

        trades happen ──▶ V3 Pool (bonding curve)  ──▶  pre-grad fees:
                                                       • protocol (100%)

   When price reaches graduation tick:
        ────────────────────────────────────────────────────────────
        recordGraduationCondition()  →  grace period (registry-set)
        ────────────────────────────────────────────────────────────
                       │
                       ▼
                 graduate()  ──▶  setGraduated() (skim off, vesting starts)
                                  burn all seed + tail positions
                                  distribute pre-grad fees
                                  mint full-range NFT to FireStream
                                  FuelVault.onGraduated() (burn countdown)

   After graduation:
        Trades go through the now-ordinary V3 pool
        FireStream.claimFees() splits NFT fees: registry recipients + creator
        FireToken.releaseVested() unlocks linearly (no-op if creatorAllocationBps=0)
        FuelVault.executeBurn() can permanently destroy ungifted user credits

The contracts

Contract	What it does
FireRegistry	Stores protocol-level config: fee splits, defaults, guardian, accepted numeraires/fee tiers
FireLaunch	Token factory. Entry point for creators (ignite)
FireToken	ERC-20 with EIP-2612 permit() and infinite Permit2 allowance. Has a skim hook on buys (pre-graduation only) and a linear creator vesting schedule
FireGraduator	Position lifecycle: builds the bonding curve, collects pre-grad fees, graduates the pool
FireStream	Custodies the graduated NFT and distributes its fees to beneficiaries
FuelVault	Tip-credit ledger (deposit, gift, withdraw, vest, burn-after-grace). User-facing this is the Tip Jar on kumbaya.xyz; on-chain functions still carry the gift / Gifted / FuelVault names

For mainnet/testnet addresses see Contract Addresses.

Production defaults (frontend launches)

These are the values the Kumbaya frontend (kumbaya.xyz/launchpad/create) plugs into every standard launch on mainnet:

Parameter	Value	Note
defaultTotalSupply	1,000,000,000 (1B, 18 decimals)	Fixed supply per launch
feeTier	10000 (1%)	V3 pool fee tier
tickSpacing	200	Derived from fee tier
tickLower	-219400	Bonding curve start (token0 perspective)
tickUpper	-174800	Graduation tick
numPositions	50	Stacked seed positions
skimBps	300 (3%)	Skim on buys → FuelVault
creatorAllocationBps	0	No on-token creator allocation in default flow
maxShareToBeSoldBps	7200 (72%)	To bonding curve
Tail liquidity	2800 (28%)	Remainder, full-range tail position
vestingDuration	90 days	Linear, starts at graduation

Because creatorAllocationBps = 0 in the production frontend, default launches don't have a creator vesting schedule to claim. Creators earn from post-graduation FireStream fees and from FuelVault skim/gift inflows. See Fees and credits.

A custom integration calling FireLaunch.ignite() directly can set a non-zero creatorAllocationBps, up to the registry's MAX_CREATOR_ALLOCATION_BPS = 2000 (20%).

Lifecycle states

A launchpad token has three distinct on-chain lifecycle states:

State	What's true
Bonding	graduationConditionMetAt == 0. Trades go through stacked seed positions. Skim hook active on transfers (taking skimBps to FuelVault). Creator vesting hasn't started.
Grace	graduationConditionMetAt != 0 and graduated == false. Price hit the graduation tick. Anyone can graduate() after the grace period elapses; the guardian can graduate immediately.
Graduated	graduated == true. Seed positions are burned. A full-range NFT lives in FireStream. Skim hook disabled. Creator vesting clock started. FuelVault burn countdown started.

Design notes for integrators

• The bonding curve is just V3 positions. All your existing Uniswap V3 tooling (QuoterV2, SwapRouter, indexer queries) works for launchpad tokens - pre-graduation and post-graduation. Buyers don't call the launchpad contracts directly; they swap on the V3 pool the way they would for any other token.

• ignite() doesn't accept ETH. The frontend's "buy at launch" feature is implemented as a 2-tx batch: ignite() plus an immediate swap on the freshly-created pool. See Launching a token.

• Allocation is parameterized at launch time, capped by FireRegistry. Don't hardcode the 80/10/10 split - read it back from IgniteParams or the on-chain LaunchState.

• Pre- and post-graduation fee splits are different. Pre-grad fees go to the protocol. Post-grad fees stream through FireStream, with the creator getting whatever remains after registry beneficiaries. Fees and credits has the full breakdown.

Pages in this section

• Contracts at a glance - file-level summary

• Launching a token (ignite) - full IgniteParams reference + how to do init-buy in the same batch

• Bonding curve and graduation - recordGraduationCondition, grace period, graduate(), force-graduate

• Fees and credits - pre/post-grad fee splits, FireStream, FuelVault