Attach referrer addresses to a quote and a share of it accrues to you. Fees are recorded per fulfilled order, claimed in bulk as a signed voucher, and redeemed on chain by whoever holds the voucher’s referrer address.

​
Setting a referrer

referrers is a list of address and basis-point pairs on GetQuote and PreviewQuote.
The fee is priced into the quote like every other component: it appears in fee_breakdown as referrer_fee, and amount_out is already net of it. Preview and quote agree, so the number you show the user is the number they get.
Request every quote that carries referrers with your API key. Referral fees are claimable only from the partner session of the partner that owns the key the quote was requested with (any of its keys, including revoked ones). A quote requested without a key carries no referrer fee: the referrer list is still validated, then dropped, so fee_breakdown has no referrer_fee and nothing accrues. The SDK omits the header when apiKey is empty, so an unset BLINK_API_KEY silently makes every quote keyless and drops your fee.
Referrer addresses must be valid for the chain the fee accrues on. An unusable list fails the quote with invalid referrer list.
Your basis points come out of the user’s output, not out of the operator spread. Setting a high value makes your route quote worse against competitors.

​
How it accrues

Accrual happens off chain, in the operator’s records. Each fulfilled order carries its referrer list in the stored order parameters, and the amount owed is computed from the deposit. The accrual is written once both the deposit and the fulfillment have settled past the per-chain deep-reorg depth, so a freshly fulfilled order becomes claimable after a short settlement delay rather than instantly. A cross-chain order also waits for its deposit to be released from the escrow, because that release is what moves the referrer share into the vault vouchers are paid from (the fee manager contract on EVM chains, the voucher vault on Solana and Sui); until then the balance is listed but not yet claimable. Nothing is transferred per order: there is no per-swap payout transaction, which is what keeps the fee cheap to offer. Same-chain swaps participate too. Their fee is withheld from the swap output on chain and sent straight to the fee manager, so it is claimable without waiting for a release. Balances are grouped by referrer address, chain, and token. A partner earning on USDC across two chains has two balances, and each is claimed separately.

​
Claiming

Claiming is self-served from the partner panel at https://panel.hular.dev, or programmatically through PartnerApi. Both require a partner session; referral earnings are not publicly queryable.
1

List what is claimable

GetPartnerReferrals returns balances grouped by referrer, chain, and token, with the order count behind each.
2

Claim a balance

ClaimPartnerReferrer takes a referrer, chain, and token. It marks the selected orders claimed, totals them, and returns a voucher.
3

Redeem on chain

Send the voucher to the contract in its router_address: the fee manager on EVM chains, the program on Solana, the package on Sui. The response includes ready-to-send calldata on EVM.

​
Vouchers

A voucher is a signed instruction to pay an exact amount of one token to one referrer address. On EVM it is an EIP-712 payload (id, token, referrer, amount) signed by the operator’s voucher key and redeemed against the BlinkFeeManager contract, which pays only out of the referrer fees it holds and never touches the operator float. On Solana it is the same shape signed with ed25519 and verified through the instructions sysvar.
BuildVoucherRedemption returns a prepared transaction for a given voucher and payer, which is the simpler path on Solana where the redemption needs an accompanying ed25519 instruction. ListPartnerVouchers returns every voucher with its redemption status, kept current from on-chain VoucherRedeemed events. Use it to reconcile: a voucher that is issued but not redeemed is money sitting unclaimed, and it does not expire. See Partner panel for the session flow behind these calls.