Build on the launchpad
The bonding curve is blast_fun in sui/launchpad. Venue adapters and post-migration custody are blast_fun_migrators in sui/migrators. These are separate from blast_presale: do not reuse presale states, fee policies, capabilities, vaults, cancellation rules, or reward deadlines.
Use the generated launchpad reference for every signature, type, event, and abort code. Use the Blast SDK for reads, transaction construction, and exact previews, matched to the intended contract revision. Amounts are atomic units, time values are milliseconds, and BPS have denominator 10,000.
Packages and activation
Section titled “Packages and activation”LaunchConfig and RuntimeConfig are shared singletons. LaunchConfig initially admits decimals 6 and 9, but no quote types or migration witnesses; rates, protocol allocations, and creation fee initialize at zero. Admission and operational policy must be configured before use. These initialization values are not live rates.
Publication sends a non-transferable Bootstrap to the deployer. package_admin::wrap consumes it with the matching never-upgraded native UpgradeCap, seals the capabilities in PackageAdmin, and creates the launchpad PackageVersion. Without this activation, protected creation calls cannot run. Migrators has its own package custody and version object.
After an upgrade, call the current package ID and pass that package’s PackageVersion. An old generation aborts. Types and event filters retain original package identity. The two packages advance independently.
Create in three transactions
Section titled “Create in three transactions”1. Publish the generated coin
Section titled “1. Publish the generated coin”Compile and patch launch_ticket_template: metadata, decimals, supply mode, SELL_BURN_BPS, and the creator recipient. Address requires a non-zero address; Account carries a 32-byte Blast account commitment.
Publication mints 1_000_000_000 * 10^decimals atoms into LaunchTicket<Meme>, transfers the ticket to the publisher, and sends the pending Currency<Meme> to the Coin Registry. The ticket holds supply, treasury capability, metadata capability, and creator information; only launch finalization releases these into their intended custody. Decimal values above 10 overflow the u64 supply, regardless of listing policy.
Use the exact coin type from publish effects or LaunchTicketCreated; tooling can rename the module and witness. Supply every transitive dependency required by the published bytecode. Consume the UpgradeCap returned by the publish command; it grants no minting authority over the finalized coin.
2. Finalize currency registration
Section titled “2. Finalize currency registration”Call Sui Coin Registry’s coin_registry::finalize_registration<Meme> using the pending currency as a receiving object. It creates the shared Currency<Meme> used in the next transaction. Do not pass the pre-registration object to launch finalization.
3. Configure, finalize, and share
Section titled “3. Configure, finalize, and share”In one programmable transaction block (PTB), with type arguments <Meme, Quote>:
- Start through
blast_fun_migrators::cetus::neworbluefin::new, consuming the ticket. Pass both package versions andLaunchConfig. Cetus also needsVenueConfigand venue objects to reserve the pair at a registered tick spacing. Bluefin takes spacing 1–400 and fee rate 1–20,000 in its venue units. - Set
launch::set_virtual_quote(positive),set_graduation_target,set_allocation_plan, andset_lp_fee_split. All are required. - Optionally call
set_opening_roundwith 0 or 60,000–300,000 ms, andset_partnerwith a currently admitted partner andClock. - Pass exactly
LaunchConfig.creation_feein aCoin<SUI>tolaunch::finalize, together with the sharedCurrency<Meme>. Even a zero fee requires a zero coin. Finalization fixes supply as burn-only or fixed, consumes the treasury capability, and retains the native metadata capability inside the launch. - Optionally buy before public sharing without an opening round, or join its pot with a round. Consume all returned coins.
- Finish with
launch::share, which recordspublic_start_ms. The launch must not be used again in this PTB. Claim creator capabilities in a later transaction.
LaunchInitializer has no abilities and must be finalized in its creation PTB. Launch has only key and must be shared there. Construct Bps, recipients, allocation plans, routes, and fee splits with their Move constructors inside the PTB, rather than passing them as pure struct arguments.
Allocation rules
Section titled “Allocation rules”Token supply: curve + pool + Blast + project recipients = 10,000 BPS. Quote reserve: pool + Blast + project recipients = 10,000 BPS. Curve and pool token shares must be positive; the target’s pool quote allocation must be at least one atom. Leave space for the protocol allocations that finalize copies from LaunchConfig.
There may be at most 16 project-recipient entries with non-zero destination addresses; entries may have zero shares, and migration allocation entries can repeat an address. The LP split separately permits at most 16 non-zero, distinct recipient addresses; creator, auto-LP, rewards, burn, and recipients sum to 10,000 BPS.
Supply/quote apportionment uses u128 products: Blast rounds up, other parts round down, then remaining atoms go by largest remainder, earlier entries first on ties. Token order is curve, pool, Blast, recipients; quote order is pool, Blast, recipients. Every atom is accounted for. Unsold curve tokens do not become a recipient allocation.
Creator capabilities
Section titled “Creator capabilities”After sharing, launch::claim_creator_caps issues CurveFeeCap<Meme> and BlastMetadataCap<Meme> once. An address recipient submits the transaction itself with no attestation. A Blast-account recipient supplies an expiring Ed25519 attestation binding that account commitment, coin type, and claiming sender; use the exact domain and BCS format in creator_authority.move.
The live cap ID is checked, not merely its type. Curve fees are claimed through launch::claim_creator_fees; LP fees through vault::claim_creator_fees. Both return two coins that the PTB must consume. Metadata setters change name, description, or icon through the shared currency. Symbol and decimals are fixed.
CreatorAdmin can reassign either cap, invalidating the old cap and cancelling the unclaimed initial recipient. Reassigning only one before initial claiming leaves the other unissued until it is separately reassigned. Deleting a live cap does not remove admin reassignment power.
Continue with curve arithmetic, migration and rewards, and state and events. The authority guide explains which runtime policies and upgrade powers remain live.