Skip to main content
Obligation orders are user-set, price-triggered instructions that automatically deleverage a position when a condition is met. They’re the on-chain equivalent of a stop-loss: a borrower creates an order saying “if my LTV crosses 75%, repay 30% of my debt by liquidating part of my collateral.” Permissionless executors can then submit transactions that trigger the order when the condition becomes true. This is a tool for sophisticated borrowers (institutions, leveraged vault strategies) who want guaranteed self-deleverage rules separate from the protocol’s standard liquidation flow.

Market-level enablement

Reserve-level fee

Enable obligation orders via SDK

Curator-side: flip the market flags. User-side: build a price-based order via SDK helpers and submit setObligationOrder.

Curator: enable on the market

Curator: set the per-reserve execution fee

Update protocolOrderExecutionFeePct in the reserve config (range 0–100):

Borrower: set a stop-loss order

The SDK provides high-level helpers createPriceBasedOrder and readPriceBasedOrder, plus KaminoAction.buildSetObligationOrderIxn to wrap the on-chain instruction.
A complete working example is at klend-sdk/examples/klend-examples/example_obligation_order.ts.

Order conditions

An order specifies a ConditionType and a threshold: The most useful conditions for self-deleverage are UserLtvAbove and LiquidationLtvCloserThan. The price-ratio conditions are useful for protecting against specific pair movements.

Order opportunities (the action)

DeleverageSingleDebtAmount is the granular case — pay down a chunk of debt, leave the rest. DeleverageAllDebt is the full unwind.

The execution flow

The borrower calls set-obligation-order from their wallet, supplying a condition type, threshold, opportunity type, amount, and any reserve references the order needs. The order is stored on the obligation account and is now visible to executors. Execution is permissionless. Anyone can run a monitor that watches the program for orders whose condition is currently met; the standard pattern is an executor bot that scans active orders and submits fill-obligation-order against any that are fillable, referencing the obligation, the collateral reserve, the debt reserve, and the amount. When the bot’s call lands, the program performs the deleverage in a single instruction: it liquidates the specified amount of collateral, repays the corresponding debt, pays the standard liquidation bonus to the executor, and routes protocol_order_execution_fee_pct of the proceeds to the protocol fee account. The order is cleared (or partially filled, if the action was specified as an amount and the bot only filled a portion).

Why a curator enables this

Standard liquidation only fires when a borrower’s LTV crosses the per-reserve liquidationThresholdPct. That’s the safety floor. Obligation orders let a borrower set a softer trigger above that floor — a stop-loss that fires before the position becomes liquidatable, on terms the borrower controls. An institutional borrower running a 10× yield loop on SOL/mSOL might set:
  • Order 1: UserLtvAbove 70%DeleverageSingleDebtAmount 20% of position (gradual deleveraging as risk rises)
  • Order 2: UserLtvAbove 78%DeleverageAllDebt (full exit before liquidation threshold at 80%)
When SOL price drops, Order 1 fires first, paring the position back. If that’s not enough and prices keep falling, Order 2 fires before the protocol’s liquidation kicks in — saving the borrower the wider liquidation bonus.

Common conditions for self-deleverage

Pausing during an incident

The market-level kill switch is price_triggered_liquidation_disabled. Setting it to 1 blocks all price-triggered actions, including obligation order fills, while leaving non-price flows (manual repay, manual deposit, etc.) operational. Useful for: oracle outage, suspicious price movement, before a planned migration. Reset to 0 once the incident is resolved.

Reference