Skip to main content

Documentation Index

Fetch the complete documentation index at: https://kamino.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

A market accumulates protocol fees over time from several sources. The curator (or a designated fee recipient) periodically withdraws these to a destination account.

Sources of protocol fees

Each reserve generates fees independently based on its config. The fees are stored on-chain in the reserve’s liquidity substructure as accumulated_protocol_fees_sf (scaled fraction).
SourceConfigured byAccrues from
Interest take rateprotocolTakeRatePct (reserve, 0–100)Each interest accrual: this percentage of accrued interest is routed to protocol fees; depositors receive the remainder
Origination feefees.borrowFee (reserve, decimal string)Each new borrow: the configured fraction of the principal is added to debt and paid to protocol fees
Flash loan feefees.flashLoanFee (reserve)Each flash loan: the configured fraction of the borrowed amount
Liquidation feeprotocolLiquidationFeePct (reserve, 0–100)Each liquidation: this percentage of liquidation proceeds
Order execution feeprotocolOrderExecutionFeePct (reserve, 0–100)Each obligation order fill: this percentage of execution proceeds
Referral feesreferral_fee_bps (market)Borrows referred by registered referrers: the configured bps is shared with the referrer
All fees accumulate in the reserve’s fee vault on the same liquidity mint as the reserve. A USDC reserve’s fees are accumulated in USDC.

Two withdrawal handlers

InstructionUsed for
redeemFeesThe standard curator fee withdrawal. Drains accumulated_protocol_fees_sf from the reserve to the configured fee recipient
withdrawProtocolFeeA more general withdrawal handler for specific fee accounting buckets
For routine curator operations, redeemFees is the relevant instruction.

Withdraw fees via SDK

The SDK exposes the raw redeemFees and withdrawProtocolFee instructions via the codegen module. Build the instructions with the relevant accounts and submit from the curator’s wallet (or multisig).
import { redeemFees } from '@kamino-finance/klend-sdk/dist/@codegen/klend/instructions';
import { PROGRAM_ID } from '@kamino-finance/klend-sdk';

// Build args and accounts per the instruction's signature, then:
const ix = redeemFees(args, accounts, PROGRAM_ID);
// Sign with the curator's wallet (or build as a multisig proposal) and submit
For full args / accounts shapes, see the auto-generated source at klend-sdk/src/@codegen/klend/instructions/redeemFees.ts and withdrawProtocolFee.ts.

Fee recipient

The fee recipient is configured at the program level. For most curator markets, this is the lending_market_owner (or its multisig). In specialized configurations, it can be a separate dedicated address — useful when the curator wants ops to flow to one signer set and fee revenue to flow to another. Confirm the recipient by inspecting the market’s accounts via get-market-or-vault-admin-info.

When to withdraw

Fees accrue continuously but withdrawing them is a discrete event. A common cadence:
CadenceReasoning
QuarterlyStandard for established markets. Reduces operational overhead
MonthlyHigher-volume markets where fee accumulation is meaningful
Event-drivenMarkets that receive a one-off fee event (large flash loan, large liquidation) may withdraw immediately
Pre-migrationBefore transferring market ownership or going immutable, drain pending fees so the new state starts clean

Operational considerations

ConsiderationWhat to watch
Reserve liquidityWithdrawals require the reserve to have enough available liquidity. If the reserve is at high utilization, a large withdrawal may need to wait until liquidity is freed by repayments or new deposits
Multisig timelockFor multisig-owned markets, the withdrawal goes through the standard proposal flow with the configured timelock
ReportingFee withdrawals are visible on-chain. Keep records that align on-chain transfers with the curator’s accounting

Reference