Create a Token
Metadata, cost review and a separately signed launch.
Code exists; Stayers production behavior is not yet verified.
A creator launches through the existing Create Token page. The platform configuration must already exist, match the approved policy and pass the relevant mainnet checks.
Enter the token's identity
Provide a name, ticker, description and supported image/metadata information. The creator cannot choose another supply, decimal count, fee schedule or mint authority through this form.
| Parameter | Intended value |
|---|---|
| Supply | 1,000,000,000 |
| Decimals | 6 |
| Quote asset | SOL |
| Stayers / DBC creation fee | 0 SOL |
| Bonding curve | Meteora DBC |
| Graduation | Meteora DAMM v2 |
Optional creator first buy
Enter a creator buy amount in SOL, or leave it at 0 SOL to create without purchasing. For a positive amount, Meteora's SDK places pool initialization and the creator's exact-input buy in one atomic transaction. The connected creator wallet pays and receives the purchased tokens in its associated token account. There is no separate buy transaction or fallback: either creation and the buy both succeed, or neither succeeds.
Another transaction cannot trade between initialization and this buy. Choosing 0 SOL does not reserve the first subsequent trade. Supply remains exactly one billion tokens; this purchase does not mint additional tokens.
The review displays buy amount, slippage, estimated tokens, minimum tokens received, network fee and account rent. Buying is optional, but a positive purchase adds its SOL amount to launch costs. The full transaction must simulate successfully before wallet approval. Receipt verification checks initialization order, creator/recipient, approved input and minimum output, and the actual token balance increase.
This path is implemented and tested with isolated SDK fixtures. The first real launch and creator buy remain unverified until their on-chain receipt is checked.
Review the prepared transaction
The server constructs the launch with the installed Meteora SDK, verifies the selected configuration and simulates the transaction. The review shows network fees, estimated account rent and the conservative SOL cost bound before the wallet signs.
A newly generated mint-account signer is an ephemeral account signer, not a treasury private key. No treasury key should be uploaded to the service.
Approve and verify
Only an explicit wallet approval can authorize a launch. Submission also depends on server approval switches. After execution, verification checks the pool/mint relationship, supply, decimals and absence of mint/freeze authority.
An account creation signature alone is not proof that all launch policy checks passed. The interface must show a verified result from the actual chain rather than simulated success.
Current availability
Construction and confirmation paths are implemented, and the finalized configuration transaction ↗ is verified. The first real token launch still needs its own on-chain verification. Image/metadata storage must be configured, and each launch requires an actual cost review and explicit wallet approval. Creating the configuration does not automatically select its address in a deployment or launch a token.
stayers.fun