This is an enterprise-only feature. Please contact us to enable.
- Distributed on-chain at swap time — the fee is sent straight to the wallet address you specified in the fee configs when creating the flow, as part of the settlement transaction. Nothing to claim; it arrives with the swap.
- Accrued as a claimable balance — the fee accumulates off-chain (typically as USDC) and you sweep it later with the claim flow below.
Fee collection is available for EVM and SVM, and applies to transactions that require conversion. See Supported chains for fees.
Add a fee config
feeConfig is an optional field on the create flow body (Step 1 of any mode — payment, deposit, or withdrawal). It is fixed at creation and cannot be changed later.
Validation. The create call returns
422 if:
- there are no recipients, or more than 1 recipient in the same chain (EVM or Solana),
- any
percentageis not strictly between0and1, - the recipients’ combined
percentageis1or greater (that would consume the entire swap), or - any
walletAddressis not a valid EVM or Solana address (see Supported chains for fees).
percentage × sourceAmount, split independently — so [{ 0.01 }, { 0.005 }] collects 1.5% total and delivers each recipient their own cut.
Supported chains for fees
A recipient can be an EVM address (0x…) or a Solana address (base58), and you can mix both in one fee config. Any other address is rejected with 422.
Add both an EVM and a Solana fee config item so you get paid on every swap. The fee is not always paid out on the chain the payer swapped from: a swap that started on Solana can deliver your fee to an EVM address.
percentage on both addresses: a swap only ever pays one of the two, so your fee rate stays the same. You can add 1 recipient per chain, for a maximum of 2 in one fee config.
The token a payer swaps from can be on any supported chain. Fees to a Solana recipient arrive on-chain at swap time; anything that accrues to an EVM recipient is collected with the claim flow below.
Check claimable balances
Check whether a recipient has any fees waiting to be claimed. Returns a per-token, per-chain breakdown plus ahasClaimableFees convenience flag.
Response (200):
An empty
balances list (hasClaimableFees: false) means there is nothing to claim right now — either no fees have accrued, or every fee was distributed directly on-chain at swap time.recipientAddress is not a valid EVM address.
Claim accrued fees
Claiming is a two-step, sign-in-the-middle flow: initiate to get the payload(s) the recipient must sign, then submit the signatures. The recipient wallet authorizes the release — no provider details are ever exposed. 1. Initiate the claim.
Response (200):
An empty
steps array means there was nothing to claim — no signing or submit needed.
Error (400): recipientAddress is not a valid EVM address.
2. Sign each step with the recipient wallet, then submit the signatures.
Response (200):
After a successful submit, re-check balances — the claimed balance should now be empty.
Example: claim in TypeScript
claim-fees.ts
Sign
data.message exactly as returned — don’t reconstruct or modify it. data.signatureKind (eip191) tells you how to sign: it’s a standard personal-sign message, so most libraries’ signMessage (for example viem’s) produce the right signature directly.