How SLICE works

SLICE is a launchpad on top of pump.fun. When you launch a token, you name one to 6 X (Twitter) accounts and the percentage each of them gets. The token's creator fees are permanently routed to the SLICE treasury, claimed on-chain every 15 minutes, and credited to those accounts.

Recipients don't need to do anything up front — they don't even need to know the token exists. Whenever they want, they sign in with X on /claim, connect a Solana wallet and withdraw their balance in SOL. No fiat, no KYC off-ramp, no custody of the token itself.

trade → creator vault → SLICE treasury → 80% to recipients · 20% $SLICE buyback & burn

Pump (live). Tokens launched on pump.fun on Solana, both on the bonding curve and after migration to PumpSwap. Fees from both phases are claimed.

Pons (coming soon). Pons runs on Robinhood Chain, an EVM chain — not Solana. The architecture already supports multiple venues and chains (the ledger is kept in each chain's native currency), but Pons support ships after the Solana launch. Recipients will withdraw in ETH to an EVM address.

pump.fun lets a token's creator set up a fee sharing config: a list of shareholders and their share of creator fees in basis points. A SLICE launch creates this config in the same transaction as the token and sets exactly one shareholder: the SLICE treasury, at 100% (10,000 bps). The config's admin authority is then revoked, which locks the route forever — nobody, including the deployer and SLICE, can point the fees somewhere else afterwards.

1  create_v2                 name, ticker, metadata URI (creator = your wallet)
2  buy                       optional initial buy
3  create_fee_sharing_config admin = your wallet
4  update_fee_shares         [{ SLICE_TREASURY, 10000 bps }]
5  revoke                    admin locked → route is permanent

The split between recipients is not stored in the pump.fun config — it lives in the SLICE database, which is the source of truth. To make it publicly verifiable, the token description ends with a fee line that anyone can read on pump.fun:

Fees to @alice 50% @bob 30% @carol 20% via SLICE

Fees to @alice via SLICE

The parser is tolerant of spacing and letter case. Every token page shows this line under Fee proof and whether it matches the recorded split.

Registering an existing token

Already launched on pump.fun? Use the Register tab. If your wallet is still the admin of the token's fee sharing config, you sign update_fee_shares (treasury 100%) and revoke, then enter the split. The backend checks the config on-chain — a single shareholder, the treasury, 10,000 bps, admin revoked — before registering the token. You also sign the split itself (ed25519 over a JSON message); that signature is shown on the token page as proof that the deployer chose the recipients.

Detection

The indexer subscribes to the Pump Fees program and filters for configs that include the treasury, so new tokens are detected within seconds, without polling. A reconciliation pass re-scans the same accounts every 10 minutes as a backup.

DETECTED     config found, not yet verified
PAYABLE      100% to treasury + admin revoked + split on record → fees are claimed
MIGRATED     bonding curve completed; fees now come from PumpSwap (still payable)
NOT_PAYABLE  something is off — see "Token not registering"

A recipient can be any of four kinds. Type it the way you'd naturally write it — the launch form recognises all of these:

X account

@alice · enter as @alice · x.com/alice. Signs in with X to claim.

GitHub user

gh:octocat · enter as github.com/octocat · gh:octocat. Signs in with GitHub to claim.

Solana wallet

sol:<address> · enter as a base58 address. Paid automatically above ◎0.10.

Verified charity

charity:<slug> · enter as picked from the list. Paid automatically above ◎0.10.

Each kind appears in the fee line in the same form, so the split stays readable and verifiable on pump.fun:

Fees to @alice 40% gh:octocat 30% sol:7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU 20% charity:give-well 10% via SLICE

• One to 6 recipients per token, each at least 1%, in whole or half percent steps. Shares must add up to exactly 100%.
• Recipients must be unique within a token and can't be on the opt-out list.
• Percentages are shares of the recipient pool (80% of creator fees). A recipient at 50% therefore receives 40% of all creator fees.
• When a token is registered, each X handle is resolved to its permanent X user ID. Credits follow the user ID, so renaming an account keeps the balance, and someone who later grabs an abandoned username doesn't get it. If the lookup fails, the ID is attached the first time the matching username signs in.
• Only charities verified by the SLICE team can be named; their payout address is on record and shown on their profile.
• The split can't be edited after launch — the fee line in the description is public and permanent.

Every claim is divided in integer lamports — no floating point anywhere. 20% goes to the $SLICE buyback bucket, the rest is split between recipients by their basis points. Rounding dust goes to the last recipient, so the parts always add up to the claim, to the lamport.

protocolCut   = floor(amount × 2000 / 10000)       → buyback bucket
recipientPool = amount − protocolCut
share[i]      = floor(recipientPool × bps[i] / 10000)
share[last]  += recipientPool − Σ share                 (dust)

protocol cut        0.200000000 SOL   → $SLICE buyback & burn
@alice  50%         0.400000000 SOL
@bob    30%         0.240000000 SOL
@carol  20%         0.160000000 SOL

Being named as a recipient doesn't mean you asked for the token. That's why recipients can endorse a token that pays them: sign in on /claim and press Endorse next to the token. Endorsements can be withdrawn at any time.

• An endorsed token shows a badge on its page and cards, with the endorsing recipients listed.
• Endorsed tokens rank higher in Explore and can be filtered on.
• Only X and GitHub recipients can endorse — wallets and charities have no sign-in.

• Every 15 minutes a job checks the creator vault of each payable token. If it holds at least ◎0.01, it calls distribute_creator_fees and the SOL lands in the treasury. Migrated tokens are claimed through PumpSwap.
• Several tokens are batched into one transaction where possible.
• The amount credited is the actual increase of the treasury balance in that transaction (pre/post balances from the transaction meta), not an estimate.
• Each claim is recorded once, keyed by its transaction signature. Re-running the job can't double-count. Failed claims write nothing and retry with exponential backoff.
• Credits are appended to a ledger. A balance is always Σ credits − Σ debits — it's never stored as a number that could be edited.

1. Go to /claim and Sign in with X. We only read your user ID and username.
2. See your balance per token. Connect a Solana wallet (Phantom, Solflare, Backpack).
3. Sign a message proving you control the destination address:

SLICE withdraw to <address> for @handle, nonce <n>

• Minimum withdrawal is ◎0.01. One pending withdrawal per account at a time.
• SOL is sent from a dedicated payout wallet, separate from the treasury, which holds only a daily budget. The debit and the withdrawal are written in the same database transaction, and the transaction signature is shown in your history and on Payments.
• Signing costs nothing — you don't pay network fees to withdraw.

Don't want to come back to withdraw? X and GitHub recipients can opt in to automatic payouts once: sign in on /claim, pick a destination wallet and a threshold, and sign one message with that wallet. From then on, whenever your balance reaches the threshold, it is sent automatically.

SLICE auto-payout to <address> for @handle above <threshold> SOL, nonce <n>

• Default threshold ◎0.10, minimum ◎0.05. You can change or turn it off at any time.
• Wallet and charity recipients can't sign in, so they are always paid automatically once they hold at least ◎0.10.
• Automatic payouts use the same path as manual withdrawals — the same locks, daily cap and kill switch apply, and every payout shows up on Payments.

Balances never expire. If an account never signs in, its credits stay on the ledger and remain withdrawable at any time. Every public profile shows earned, withdrawn and available amounts, so recipients can find out they're owed.

20% of every claim accumulates in the buyback bucket. Once an hour, if the bucket holds at least ◎0.50, it is swapped SOL → $SLICE through Jupiter, and the purchased tokens are burned with an SPL burn instruction. Both the swap and the burn signatures are recorded.

Until $SLICE is live, the bucket simply accumulates. The full history is public on Burns, and the totals on Analytics.

Bring launches to SLICE and earn from them. Share your link — the ref is your X handle:

https://getslice.fun/launch?ref=<your X handle>

• You earn 25% of the protocol share of every token you refer — 5% of all its creator fees — for the lifetime of the token. It comes out of the 20% protocol cut; recipients' 80% is never touched.
• The referral is stored in a cookie for 30 days. First touch wins: a later link from someone else doesn't replace it.
• You can't refer yourself as a recipient — if the referrer is also named in the split, no referral is recorded. Opted-out handles don't earn referrals either.
• Referral earnings are credited to your X account and withdrawn on /claim like any other balance.

Tokens that cross $20K market cap are queued to be featured on our main X account, @getslicedotfun. Every candidate is reviewed by the team before it's posted, so a feature isn't guaranteed — tokens that look like spam, impersonation or a rug are skipped. Only payable tokens qualify.

Don't want fees from tokens you didn't ask for? Sign in with X on /claim and press Stop payments to me (or ask us to do it for you). Your handle goes on the do-not-pay list and:

• it is hidden across the site and can't be named in new launches;
• your share of future claims is redirected — 50% to the protocol treasury, 50% to the $SLICE buyback;
• you can still withdraw the balance you already have for 30 days. After that, the remainder is redirected the same way.

A token only earns once it's PAYABLE. Tokens marked “Not payable” show the reason on their page. Common causes:

• Config is not 100% to the treasury — another shareholder exists, or the treasury has fewer than 10,000 bps.
• Admin not locked — revoke wasn't signed, so the route could still change.
• Split missing — the config points to us, but there is no split on record (e.g. the Register flow wasn't completed).
• More than 6 recipients, shares that don't add up to 100%, or an invalid handle.
• Handle opted out — a recipient is on the do-not-pay list.
• Not detected yet — detection is near-instant, with a full reconciliation every 10 minutes. Give it a moment.

Still stuck? Reach us on X at @getslicedotfun with the mint address.

bps

Basis points. 10,000 bps = 100%.

Creator vault

The account where pump.fun accumulates a token's creator fees until they are claimed.

Fee sharing config

pump.fun account listing who receives a token's creator fees. Ours: treasury at 10,000 bps, admin revoked.

Recipient key

How a recipient is written: @alice, gh:octocat, sol:<address> or charity:<slug>.

Fee line

The "Fees to @… via SLICE" line in the token description — the public copy of the split.

Treasury

The SLICE wallet that receives claimed fees.

Payout wallet

A separate hot wallet that sends withdrawals, topped up from the treasury within a daily cap.

Recipient pool

The 80% of each claim shared by the recipients.

Ledger

Append-only list of credits and debits per recipient. Balance = credits − debits.

Referrer

The X account whose link brought a launch; earns 25% of the protocol share.

Buyback bucket

The 20% of each claim waiting to be swapped into $SLICE and burned.

Dust

Lamports left over from integer rounding; always credited to the last recipient.

Lamport

The smallest unit of SOL. 1 SOL = 1,000,000,000 lamports.

Migration

When a token completes its bonding curve and moves to PumpSwap.