Token Launching

Partners can deploy tokens through two distinct flows: org-level deploys using your partner API key, and wallet-level deploys where provisioned wallets deploy on their own behalf. Both hit the same endpoint (POST /token-launches/deploy) but differ in authentication, signing, and fee routing.

For the full interactive endpoint reference (fields, validation, error codes), see Deploy a token →.

Two Deploy Flows

Org-Level Deploys

Your server calls the deploy endpoint with X-Partner-Key. The org's deployment wallet signs the transaction, and the partner fee split is applied automatically.

curl -X POST https://api.bankr.bot/token-launches/deploy \
  -H "Content-Type: application/json" \
  -H "X-Partner-Key: bk_ptr_YOUR_KEY" \
  -d '{
    "tokenName": "My Token",
    "tokenSymbol": "MTK",
    "feeRecipient": {
      "type": "wallet",
      "value": "0x87be4dA49869fD055d5a60cAc2a6Dc61fdd3052D"
    }
  }'

Auth: X-Partner-Key
Signing wallet: Your org's deployment wallet
feeRecipient: Required — the org wallet signs, so you must specify where the creator's fee share goes
Fee split: Includes your partner share (from org's tokenLaunch config)

Wallet-Level Deploys

A provisioned wallet with tokenLaunchApiEnabled calls the endpoint using its own X-API-Key. The wallet signs the transaction itself.

curl -X POST https://api.bankr.bot/token-launches/deploy \
  -H "Content-Type: application/json" \
  -H "X-API-Key: bk_usr_WALLET_KEY" \
  -d '{
    "tokenName": "User Token",
    "tokenSymbol": "UTKN"
  }'

Auth: X-API-Key (from a provisioned wallet)
Signing wallet: The provisioned wallet itself
feeRecipient: Optional — defaults to the wallet's own address
Fee split: Includes your partner share — the wallet's parent org is resolved automatically via provisioning, so the same fee config applies
Requires: tokenLaunchApiEnabled permission on the wallet's API key + tokenLaunchApi capability on the org

Partner Privileges

Provisioned wallets automatically receive partner-deploy privileges: the 24-hour wallet age check is skipped, gas is sponsored, and partner rate limits apply instead of per-account limits. No extra configuration needed.

Comparison

	Org-Level (`X-Partner-Key`)	Wallet-Level (`X-API-Key`)
Signing wallet	Org deployment wallet	Provisioned wallet
`feeRecipient`	Required	Optional (defaults to wallet)
Partner fee share	Yes — from org config	Yes — resolved from provisioning org
Who controls the deploy	Your server	The provisioned wallet holder
Use case	You deploy on behalf of users	Users deploy their own tokens

Fee Recipient Resolution

The feeRecipient field supports resolving addresses from multiple identifier types:

`type`	`value` example	Resolution
`wallet`	`0x5f8D...E508`	Used directly
`x`	`0xdeployer`	Resolves Twitter/X username to their Bankr wallet
`farcaster`	`dwr.eth`	Resolves Farcaster username to their verified EVM address
`ens`	`vitalik.eth`	Resolves ENS name to underlying address

Response

Both flows return the same response shape:

Response `201`

{
  "success": true,
  "tokenAddress": "0x1234...abcd",
  "poolId": "0xabcd...1234",
  "txHash": "0x9876...fedc",
  "activityId": "665f1a2b3c4d5e6f7a8b9c0d",
  "chain": "base",
  "feeDistribution": {
    "creator": { "address": "0x87be...052D", "bps": 5700 },
    "bankr": { "address": "0xBankr...", "bps": 1805 },
    "partner": { "address": "0xYour...Fee", "bps": 1805 },
    "alt": { "address": "0xAlt...", "bps": 190 },
    "protocol": { "address": "0xAirlock...", "bps": 500 }
  }
}

The feeDistribution object shows exactly how the 1.2% swap fee is split. Values are in basis points (10,000 = 100%). Your partner share appears under the partner key in both deploy flows — for wallet-level deploys, the partner org is resolved automatically from the wallet's provisioning relationship.

Fee Wallet Configuration

Your fee wallet is the address that receives your partner share of trading fees from org-level deploys. It must be configured before deploying tokens with X-Partner-Key.

Set or update your fee wallet from the Token Launch tab in your partner dashboard. The fee wallet must be a valid Ethereum address.

Retroactivity

Changing the fee wallet only affects future launches. The beneficiary for each token is baked into the deploy transaction at launch time and stored on-chain in the Fees Manager contract. Updating the Token Launch tab setting later:

✅ Applies to every token deployed after the change
❌ Does not update beneficiaries on tokens already deployed
❌ Does not redirect fees already accrued in existing pools

This is intentional — it means you can swap to a new fee wallet (e.g. moving from an EOA to a multisig) without worrying about inadvertently affecting launches already in the wild.

To redirect fees on an existing token, the current beneficiary must call updateBeneficiary(poolId, newBeneficiary) on the Fees Manager contract on-chain. See Transferring Fees to a New Wallet for the REST helper, Bankr-wallet flow, and a walkthrough of migrating a partner fee wallet to a multisig.

Fee Split Types

Standard Split

Most partners get a percentage of Bankr's portion of fees. The feeSplitPercentage field (0–100) determines what fraction of Bankr's share goes to you.

For example, with feeSplitPercentage: 50:

Creator: 57% (5,700 bps)
Partner: ~18% (1,805 bps) — half of Bankr's share
Bankr: ~18% (1,805 bps) — remaining half
Ecosystem (alt): 1.9% (190 bps)
Protocol: 5% (500 bps)

Custom Split

Partners with custom arrangements have a customFeeSplitBps object with exact basis-point allocations for each beneficiary. This overrides the standard percentage calculation.

Both split types are visible in your organization's tokenLaunch config and in every deploy response's feeDistribution.

Claiming Fees

Fees accumulate on-chain in the Uniswap V4 pool and must be claimed by the wallet holder. The Bankr CLI's claim-wallet command scans all launches where your wallet is a beneficiary and claims in bulk:

# Install the CLI
npm install -g @bankr/cli

# Set your partner wallet private key
echo "BANKR_PRIVATE_KEY=0xYourPartnerWalletKey" > .env

# Scan all launches and claim fees
bankr fees claim-wallet --all --yes

This works across all beneficiary roles (partner, creator, etc.). See Claiming Fees for the full guide including the interactive fee dashboard (bankr fees).

Simulate Before Deploying

Test your integration without broadcasting a transaction by setting simulateOnly: true. Works with both deploy flows:

curl -X POST https://api.bankr.bot/token-launches/deploy \
  -H "Content-Type: application/json" \
  -H "X-Partner-Key: bk_ptr_YOUR_KEY" \
  -d '{
    "tokenName": "Test Token",
    "tokenSymbol": "TEST",
    "feeRecipient": { "type": "wallet", "value": "0x..." },
    "simulateOnly": true
  }'

Returns the predicted tokenAddress and feeDistribution with status 200 instead of 201. No transaction is broadcast and no gas is consumed.

Rate Limits

Scope	Limit
Per fee recipient (burst)	1 deploy per minute
Per fee recipient (daily)	20 deploys per 24 hours
Per fee recipient (in-flight)	1 concurrent deploy

Rate limits are applied per fee recipient address, not per partner key — each unique end-user address has its own quota. The 50/day (100 for Bankr Club) wallet cap that applies to direct X-API-Key deploys does not apply to partner-key deploys.

See Deploy a token → for the interactive endpoint reference.

Two Deploy Flows​

Org-Level Deploys​

Wallet-Level Deploys​

Comparison​

Fee Recipient Resolution​

Response​

Response 201​

Fee Wallet Configuration​

Retroactivity​

Fee Split Types​

Standard Split​

Custom Split​

Claiming Fees​

Simulate Before Deploying​

Rate Limits​