Transferring Fees to a New Wallet

Change who receives trading fees on an already-launched token — useful when moving from an EOA to a multisig, handing ownership to someone else, or rotating keys.

Which path applies depends on how the token launched: GET /token-launches/:tokenAddress reports it as launch.launchType. Everything up to Bankr Launch v3 Tokens describes a doppler launch; a bankr_v3 launch (every Arc launch, and any Arbitrum launch whose provider was bankr_v3) transfers through its own contracts and endpoints, so skip to that section.

Who Can Transfer

Only the current fee beneficiary can transfer their share. If you're already the deployer, that's you. If fees were transferred to you previously, you're the current beneficiary.

On-chain the transfer is a call to updateBeneficiary(poolId, newBeneficiary) on the Fees Manager contract — only the current beneficiary's signature is valid.

What Happens to Already-Accrued Fees

The beneficiary transfer is forward-only on the pool's share pointer. Fees already in the pool go to whoever is the beneficiary at claim time, not whoever was the beneficiary when they accumulated.

If you want to collect pre-transfer fees at the old wallet, claim them first, then transfer.

Paths

Bankr wallet (gas sponsored)

If the current beneficiary is a Bankr-managed wallet, execute server-side — no ETH needed in the wallet.

• Web: Transfer fee recipient on the token's Trade page (bankr.bot/trade/<tokenAddress>), or Edit fee recipient in its Manage drawer under Your Tokens
• Chat: "transfer fees for 0xTokenAddress to 0xNewWallet"
• Authenticated API: POST /user/doppler/execute-transfer-beneficiary with your Privy JWT

External wallet (self-sign)

If you hold the private key yourself (EOA, Ledger, etc.), use the public helper to build an unsigned transaction and sign locally. No authentication required — your signature is the authorization.

Request

curl -X POST https://api.bankr.bot/public/doppler/build-transfer-beneficiary \
  -H "Content-Type: application/json" \
  -d '{
    "tokenAddress": "0xTokenAddress",
    "currentBeneficiary": "0xOldWallet",
    "newBeneficiary": "0xNewMultisig"
  }'

Response

{
  "to": "0xFeesManagerAddress...",
  "data": "0xabcdef...",
  "chainId": 8453,
  "description": "Transfer fee beneficiary for MyToken"
}

Sign and broadcast with the current beneficiary's private key on the chain named by chainId; the signing wallet needs a little native gas there.

If currentBeneficiary isn't actually a beneficiary on this pool, the endpoint returns 403.

Direct on-chain

If you'd rather skip the API and encode the call yourself, the ABI is:

function updateBeneficiary(bytes32 poolId, address newBeneficiary);

Call it on the pool's Fees Manager (the initializer address returned by GET /token-launches/:tokenAddress/fees). See Reading Creator Fees → On-chain reads for resolving initializer and poolId.

For quote-only fees launches on the 1.75% schedule, the creator's fee entry lives on the hook contract instead — its fees manager sits at the hook address, not the initializer. Call updateBeneficiary there. Default launches keep the creator's entry on the initializer as before. The API paths above resolve the correct contract for you either way.

Bankr Launch v3 Tokens

Launch v3 tokens don't have a Doppler Fees Manager, so updateBeneficiary and the /public/doppler/*-transfer-beneficiary endpoints don't apply to them. The creator position lives on one of two contracts, and the API resolves which for you:

Creator fee mode	Contract	Call
quote (the default) or token	Creator Fee Vault	setBeneficiary(token, newRecipient)
both — fees paid in kind	Fee Locker	setFeeRecipient(token, newRecipient)

So a default Arc launch transfers through the vault; a vault launch whose creator fee beneficiary was never set falls back to the locker. The API resolves this for you, so you don't need to know the launch's mode to transfer.

Only the current recipient (or vault beneficiary) can hand the position on — the contract re-checks the signer.

Web

Open the token's Trade page (bankr.bot/trade/<tokenAddress>) and use Transfer fee recipient in the Fees section. The v3 Fees section shows the launch's fee recipient and their claimable balance to every viewer — you no longer have to be signed in as the recipient to see what's waiting — while the transfer and claim actions still require the recipient's signature.

Bankr wallet (server-signed)

curl -X POST https://api.bankr.bot/launch-v3/0xTokenAddress/recipient/transfer \
  -H "Content-Type: application/json" \
  -H "x-access-token: <your Privy access token>" \
  -d '{ "newRecipient": "0xNewMultisig" }'
# → { "txHash": "0x..." }

Signed server-side with your Bankr wallet. Returns 403 when the signed-in wallet isn't the current recipient or, with Permitted recipients on in Security settings, when newRecipient isn't on that list; 400 when newRecipient already receives the token's fees, and 404 when the token isn't a Launch v3 token on a chain where v3 is deployed. Arc is not gas-sponsored, so an Arc transfer spends native USDC from the signing wallet — keep a little there.

External wallet (self-sign)

curl -X POST https://api.bankr.bot/launch-v3/0xTokenAddress/recipient/build \
  -H "Content-Type: application/json" \
  -d '{ "account": "0xCurrentRecipient", "newRecipient": "0xNewMultisig" }'
# → { "transaction": { "to": "0x...", "data": "0x...", "value": "0x0", "chainId": 5042, "description": "..." } }

No authentication — your signature is the authorization. Sign and broadcast the returned transaction with the current recipient's key on the chain named by chainId.

What happens to already-accrued fees

On the locker path, changing the recipient first settles the fees accrued so far to the outgoing recipient (best effort). On the vault path the change is forward-only, as on Doppler: fees already in the vault go to whoever is the beneficiary at claim time, so claim from the token page's Fees section first if you want them at the old wallet.

Multisig Migration (common partner flow)

Moving a partner fee wallet (or a personal EOA) to a multisig typically means running the transfer once per launched token. Workflow:

1. Pull the list of tokens where the old wallet is a beneficiary:

   curl "https://api.bankr.bot/public/doppler/creator-fees/0xOldWallet"

2. For each tokens[].tokenAddress, build a transfer transaction (see above)
3. Sign and broadcast each with the old wallet's key
4. Optionally update your Fee Wallet configuration so future launches route to the multisig automatically

Changing the Fee Wallet setting in the Token Launch tab is forward-only — it does not touch existing tokens. See Fee Wallet Retroactivity.

Gas

Path	Who pays gas	Gas needed
Bankr wallet via web UI, chat, or execute-transfer-beneficiary	Bankr (sponsored, up to 10 tx or $3 of gas/day)	None
External wallet via build-transfer-beneficiary + self-sign	You	A little on the token's chain
Direct on-chain updateBeneficiary call	You	A little on the token's chain

Troubleshooting

"Address is not a beneficiary for this pool" — the currentBeneficiary you passed doesn't hold shares in the pool. Double-check it matches the creator / current beneficiary. Query GET /public/doppler/claimable-fees/:tokenAddress?beneficiary=0x... to verify.

Transaction reverts — the signing wallet must be the current beneficiary. If you recently transferred the beneficiary away, your old wallet no longer has permission.

Accrued fees disappeared after transfer — they didn't disappear. They're now claimable by the new beneficiary (see What Happens to Already-Accrued Fees above).