needsCreation: false retain their existing terms. Legacy configs, v1-to-v2 migrations, Robinhood Chain launches, and non-SOL direct launches have separate behavior.
Choose the config payer deliberately
Thepayer supplied to POST /fee-share/config becomes the deployer. There is no public request field to select a different deployer or change its fee rate. A different wallet used later to launch the token does not replace the config’s deployer.
The claimersArray and basisPointsArray still define the normal recipient allocation, and basis points must sum to 10,000. Those percentages divide the claimers pool remaining after the deployer deduction. Do not reduce the array total to 7,500 to reserve the deployer share.
The payer can also appear in claimersArray. In that case, it earns both its separate deployer cut and its normal recipient allocation. Config creation also funds the required deployer accounts, so its SOL cost can differ from a legacy config.
Calculate the split
The deployer rate is 2,500 basis points of the gross claimers pool, not 25% of total trading fees. First account for any fee compounding and the applicable platform split. The deployer then takes 25% of the gross claimers pool, and the configured recipients divide the remaining 75%. A partner share, when present, is deducted from the platform pool — it does not reduce the deployer or recipient amounts. For a protocol claim of 1 SOL, assuming a 50% platform split and a partner taking 25% of the platform pool:
If there is no partner, the partner share stays with the platform, which then receives the full 0.5 SOL. The deployer share (0.125 SOL) and the recipient pool (0.375 SOL) are the same either way; do not deduct the partner share from the claimers pool.
If the deployer has a 50% normal allocation and another recipient has the other 50%, the example above pays the deployer 0.3125 SOL in total and the other recipient 0.1875 SOL. Allocating 100% of the normal recipient pool to another wallet still leaves the separate deployer share in place.
Actual calculations use integer lamports and round each percentage down. Platform overrides and compounding can change the amounts; see Customize Token Fees for the gross fee pools.
Read deployer balances
Use Get Deployer Claimable Positions, authenticated with yourx-api-key:
wallet is the config payer. It can claim its separate deployer share even if every normal recipient allocation belongs to other wallets. Pending pool discovery uses indexed config-creator and launch metadata, then verifies the deployer on-chain. Configs created outside the Bags API need matching indexed metadata to appear before their first protocol claim.
The response separates fees still pending in each token’s pools from fees already credited to the deployer’s shared WSOL vault. The accrued portion is attributed using indexed events and reconciled with finalized on-chain state. Pool calculations use fresh finalized config rates, including current deployer terms. Successful GET results can be cached for 5 seconds with a 2-second stale window.
BigInt for arithmetic:
pendingDbcLamports + pendingDammLamports + accruedLamports. The wallet total adds those position totals and unattributedVaultLamports once. Do not add vaultClaimableLamports again: its attributed portion is already included in the positions, and its residual is the separate unattributed field.
The unattributed field covers vault funds without recorded token fee accrual, such as direct deposits. It is never assigned to an arbitrary token. Only positions with positive totals are returned, ordered by tokenMint. A wallet can have an empty positions array and a positive unattributed vault balance.
If indexed attribution is incomplete or cannot be reconciled, the endpoint returns
503 with Retry-After: 5 and { "success": false, "response": "..." }. Treat the balance as temporarily unavailable; do not display it as zero. Discovery and accounting limits also reject incomplete results rather than return partial totals.Request a deployer claim batch
Call Create Deployer Claim Transactions:wallet is required and must sign the returned transactions. An API key authorizes the HTTP request; it does not authorize moving the wallet’s funds. These endpoints are REST calls; this guide does not require a new SDK method.
Optional parameters:
A request attempts at most 20 pool claim candidates, independently of
maxTransactions. Claims beyond either limit are deferred with batch_limit. Optional request fields must be omitted when unused; null is not accepted.
Each pool claim collects the token’s deployer cut and withdraws the shared deployer vault. A vault-only withdrawal is also supported when fees are already accrued. Withdrawals unwrap WSOL into native SOL for the deployer. They do not withdraw the wallet’s normal recipient ledger or user fee vault.
The gas sponsor partially signs and fronts funds for execution. The transaction repays sponsorship and execution costs from claim proceeds; existing wallet SOL must cover a shortfall. The planner reserves wallet funds conservatively and does not assume that profits from an earlier transaction will fund a later one, or count the same aggregate vault balance twice.
The response is a plan:
transaction field and the shared TransactionWithBlockhash shape. These are version-0 transactions; the legacy creator claim response’s tx field is a different contract.
A successful HTTP response does not mean every claim fits into this batch. Inspect deferredClaims, including when transactions is empty:
remainingTokenMints lists selected tokens whose pending pool claims were deferred. Tokens omitted by a tokenMints filter are not listed. A vault-only deferral has tokenMint: null, protocol: "vault", and may leave remainingTokenMints empty.