> For the complete documentation index, see [llms.txt](https://stonkfun.gitbook.io/stonkfun-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stonkfun.gitbook.io/stonkfun-docs/earning/creator-fees.md).

# Creator fees

On a standard launch, the creator holds one of the two locked positions' Fee Key NFTs and claims its accrued trading fees whenever they like.

## What accrues

| Tier | Your liquidity share | Roughly, per unit of swap volume |
| ---- | -------------------- | -------------------------------- |
| 1%   | 50%                  | 0.42%                            |
| 2%   | 75%                  | 1.26%                            |

Fees arrive in both tokens of the pair, or in the quote token alone depending on how your pool collects them.

There is no deadline and no expiry. Unclaimed fees sit safely on the position on-chain.

## Claiming from the token page

Connect the wallet holding the Fee Key. The token page shows what has accrued in both tokens and a button to claim it. You sign one transaction, and the fees land directly in your own token accounts.

## Claiming over the API

Three calls, in the same shape as launching: read, prepare, sign locally, submit.

### 1. What is waiting

```bash
curl 'https://www.stonkfun.xyz/api/public/v1/tokens/<mint>/fees'
```

This needs no wallet at all, so a dashboard can show what is waiting before anyone connects.

Reward coins return `claimable: null` with a reason rather than an error, since they have no creator position.

### 2. Prepare

```bash
POST /api/public/v1/tokens/{mint}/fees/claim/prepare
{ "creatorWallet": "<your wallet>" }
```

Returns an unsigned transaction, the amounts it will collect, and an `intentId`.

### 3. Sign and submit

```bash
POST /api/public/v1/tokens/{mint}/fees/claim/submit
{
  "creatorWallet": "<your wallet>",
  "intentId": "<from prepare>",
  "signedTransaction": "<base64>"
}
```

Relays the signed claim, waits for confirmation, and answers with the transaction signature.

### Full example

```js
import { Keypair, Transaction } from '@solana/web3.js';
import fs from 'node:fs';

const API = 'https://www.stonkfun.xyz/api/public/v1';
const mint = 'YOUR_TOKEN_MINT';
const creator = Keypair.fromSecretKey(            // the wallet holding the Fee Key NFT
  Uint8Array.from(JSON.parse(fs.readFileSync('creator.json', 'utf8')))
);

const headers = { 'Content-Type': 'application/json' };
const call = async (path, init) => {
  const response = await fetch(API + path, init);
  const body = await response.json();
  if (!response.ok) throw new Error(`${body.error.code}: ${body.error.message}`);
  return body.data;
};

// 1. What is waiting? A plain read, no wallet involved.
const { claimable } = await call(`/tokens/${mint}/fees`);
if (!claimable) throw new Error('Nothing claimable on this launch');
console.log('Waiting:', claimable.quote.amountTokens, claimable.quote.symbol);

// 2. Prepare. Returns an UNSIGNED claim transaction, valid for 90 seconds.
const wallet = creator.publicKey.toBase58();
const prepared = await call(`/tokens/${mint}/fees/claim/prepare`, {
  method: 'POST',
  headers,
  body: JSON.stringify({ creatorWallet: wallet }),
});

// 3. Sign locally. Your key never leaves this process, and this transaction can only ever
//    pay you: sign it as-is, since altering the instructions invalidates the claim.
const tx = Transaction.from(Buffer.from(prepared.transaction, 'base64'));
tx.sign(creator);

// 4. Submit. The fees land straight in your own token accounts.
const claimed = await call(`/tokens/${mint}/fees/claim/submit`, {
  method: 'POST',
  headers,
  body: JSON.stringify({
    creatorWallet: wallet,
    intentId: prepared.intentId,
    signedTransaction: tx.serialize().toString('base64'),
  }),
});

console.log('Claimed:', claimed.signature);
```

This is how you claim across a portfolio on a schedule instead of clicking through tokens one at a time.

## Only your signature can claim your fees

The claim transaction is only valid when signed by the wallet holding that launch's Fee Key NFT, and it pays that wallet's own accounts.

That is why preparing a claim needs no credential. For a token you do not own, it returns a transaction you cannot make valid, which would pay someone else if you could. No platform key signs any part of it, and submit relays only the exact transaction prepare issued.

The `creatorWallet` you pass has to be the fee payer of the transaction you sign.

## Expiry and retries

A prepared claim expires after **90 seconds**, because the transaction carries a live blockhash. Expiring costs you nothing, so prepare again. The fees are still on the position.

Retrying a submit that timed out is safe too. An `intentId` that already went through returns its original signature with `alreadySubmitted: true` rather than claiming a second time.

## Errors

| Code           | HTTP | Meaning                                                                                   |
| -------------- | ---- | ----------------------------------------------------------------------------------------- |
| `forbidden`    | 403  | A reward coin, or a wallet that does not hold the Fee Key. No credential would change it. |
| `conflict`     | 409  | Nothing is claimable yet, or the prepared claim expired. Prepare again.                   |
| `rate_limited` | 429  | Over the claim-prepare budget. Honour `Retry-After`.                                      |

## Rate limits

| Endpoint                                           | Limit                  |
| -------------------------------------------------- | ---------------------- |
| `POST /tokens/{mint}/fees/claim/prepare`           | 20 per minute, per IP  |
| Everything else, including the read and the submit | 300 per minute, per IP |

The prepare has its own counter rather than a share of the launch budget, so claiming across a portfolio is never throttled by someone else's launch burst from the same address.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://stonkfun.gitbook.io/stonkfun-docs/earning/creator-fees.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.