Launching a token

The form

What happens, step by step

1. Prepare

When you continue, the page generates the new token’s mint key in your browser and sends the server your details, your wallet address, the mint address and a SHA-256 digest of everything, including the image. The server:

• validates every field again, with the same rules as the form;
• looks each handle up on X, refuses any handle X reports as missing, and shows you the account it found for the rest;
• refuses a handle that has changed hands on X since it was last paid here, because new fees would reach its previous owner rather than the account you mean. When X cannot be asked who owns a handle that was paid here before, it refuses to guess and asks you to try again in a minute. A handle that has never been paid here goes ahead without the lookup, and is looked up again later;
• reserves the next creator index and derives this token’s creator address from it. The index is spent even if you never finish, so no two launches can share a vault;
• fixes the platform share at today’s value (20% by default) for this token, for good;
• returns a message to sign, valid for 15 minutes.

2. Sign the message

Slice: launch a token on pump.fun

Wallet: <your wallet>
Mint: <new token address>
Fee address: <this token's creator address>
Launch digest: <sha256 of the details and images>
Nonce: <random>
Expires: <time>

Signing confirms the token details and fee recipients behind this digest. It is not a transaction and moves no SOL.

A message signature cannot move funds. The server checks it against your wallet, then recomputes the digest from the uploaded image and the stored details. A different picture or a changed recipient produces a different digest and is refused. Only then are the image and the metadata pinned to IPFS. Each wallet can take up to ten launches a day through this step, because each one pins two files.

3. Build, check, simulate

Your browser builds the create transaction with the pump.fun SDK and checks its own work before showing it to you: only the pump.fun, Compute Budget and Associated Token Account programs, the creator address and metadata URI the server issued, at most one buy, and a maximum SOL cost no higher than you entered. It is then simulated on mainnet through our RPC proxy, so a transaction that would fail is caught before your wallet opens.

4. Sign and send

The review shows the total cost, the network fee, the first buy, the creator address and each recipient. You sign with your wallet; the mint key signs in the page. Nothing is sent to our server except the finished signature.

5. Confirm

The page reports the signature, and the server fetches the transaction from the chain and reads its create_v2 instruction: the mint, the creator, the metadata URI, the name and the ticker must all match this launch, the token must be priced in SOL, and none of pump.fun’s other fee modes may be switched on (a creator fee override, mayhem mode, holder rewards or cashback), since each of them would change where the fees go. Only then is the token written to the database and shown on Explore. A handle whose lookup failed at step 1 is looked up once more here, so its fees can be tied to an X account from the first sweep.

If the confirmation is interrupted, the launch stays in the tab’s session and resumes when you return to the launch page. If you never return, a scheduled job does the same check without you: every few minutes it looks for launches between two minutes and seven days old that were never confirmed, asks the chain whether their token exists, and lists every one that does.

Once a signature exists, only the chain can fail a launch: its transaction errored, did not match, or left no trace on chain five minutes after the page reported it (no status for its signature and no token at its mint). How long ago it was prepared never decides it. A launch that was never sent simply expires, and the creator index it reserved stays unused.

What pump.fun will show

On pump.fun the token’s creator is the derived address, not your wallet. That is correct: the creator is where pump.fun pays the creator fee. The derived address never signed anything to create the token, because pump.fun’s create instruction takes the creator as a plain argument. Your wallet appears as the one that signed and paid.

The public record

The terms of every launch are in the metadata JSON that the token points to, under extensions.split, and in our database, which the token page reads. We write that JSON ourselves and pin it before the launch transaction is built, so the URI in the transaction names it. IPFS content is addressed by its hash, so that record cannot be edited after the launch, by us or anyone else.

{
  "name": "Example",
  "symbol": "EXAMPLE",
  "image": "https://ipfs.io/ipfs/Qm…",
  "website": "https://slicepad.fun/token/<mint>",
  "extensions": {
    "split": {
      "recipients": [
        {"handle": "alice", "xUserId": "1234567890", "bps": 6000},
        {"handle": "bob",   "xUserId": null,         "bps": 4000}
      ],
      "platformBps": 2000,
      "creator": "<this token's creator address>"
    }
  }
}

Recipient bps are shares of the recipients’ part and add up to 10000. platformBps is the platform’s part of each sweep, taken first. xUserId is null when X could not be asked at launch time. The rest of the file follows pump.fun’s own metadata fields, so wallets and explorers read it as usual. It is pinned through the operator’s Pinata account when one is configured, and otherwise through pump.fun’s IPFS upload, which stores the file byte for byte. Either way the token’s URI is the ipfs.io address of that exact file.

What is fixed at launch

• The recipients and their shares. There is no feature to change them, for the deployer or for anyone else.
• The platform share. Changing the setting later applies to new launches only.
• The creator address. It is written into the token on chain.

The deployer has no rights over the fees at all. Launching a token and being paid by it are separate: if you want a share, name your own X account as a recipient.

When launches are paused

The operator can pause launches from the console, for example during a pump.fun program change. The prepare step then answers that launches are paused and nothing is reserved. Tokens that already exist are unaffected: their sweeps and payouts run on their own switches.