The three-step flow
The current owner kicks off the transfer by callinginitiate-obligation-ownership-transfer with the new owner’s pubkey. The obligation enters a “pending transfer” state; the position keeps accruing interest and is still repayable, but ownership stays with the current owner until the flow completes.
The klend program’s global admin then calls approve-obligation-ownership-transfer. This middle step exists for protocol-level oversight: it gives the curator a safeguard against transfers that would compromise the market (sanctioned addresses, accounts that wouldn’t satisfy the market’s compliance posture, etc.).
Finally, the new owner calls accept-obligation-ownership-transfer. The obligation’s owner field updates and the transfer is complete. If at any point either party wants to back out, abort-obligation-ownership-transfer cancels the pending state.
Why three steps
| Step | Concern addressed |
|---|---|
| Initiate | Current owner must explicitly opt in. No surprise transfers |
| Approve | Protocol-level oversight. Prevents transfers to addresses that would create regulatory or operational issues |
| Accept | New owner must explicitly opt in. No transfers to addresses that don’t want the obligation |
- SDK
- API
- Kamino CLI
Surface the transfer flow via SDK
The four obligation ownership transfer instructions (initiate, approve, accept, abort) are part of the on-chain klend program. The current public klend-sdk does not yet expose dedicated TypeScript helpers for these.End-user apps integrate the transfer via:- The Kamino webapp’s obligation transfer UI for whitelisted markets
- Building the instructions manually from the program IDL
- Wrapping the transfer endpoints in your own SDK layer
initiate-obligation-ownership-transfer(currentOwner, obligation, newOwnerPubkey)— signed by current ownerapprove-obligation-ownership-transfer(globalAdmin, obligation)— signed by Kamino’s global adminaccept-obligation-ownership-transfer(newOwner, obligation)— signed by new ownerabort-obligation-ownership-transfer(signer, obligation)— signed by current owner before approval, or by either party
Interaction with open borrow orders
If the obligation has an open borrow order when accept is called, the order becomes unfillable. The order’s debt destination is tied to the original owner’s authority; once ownership changes, the order can no longer execute. Recommended flow before transfer:Cancel any open borrow orders
The current owner cancels via the appropriate instruction or SDK call.
Interaction with obligation orders
Obligation orders (price-triggered self-deleverage) survive the transfer. The new owner inherits the orders as configured. They can update or cancel them after acceptance viaset-obligation-order.
If the orders rely on assumptions about the previous owner’s risk model, the new owner should review and adjust them after acceptance.
Interaction with farms
Pending farm rewards on the obligation are tied to the obligation’s farm-state position, which moves with the obligation. After acceptance, the new owner can claim accumulated rewards normally. If the previous owner wants to claim rewards before transfer, they should do so before initiating; otherwise, those rewards belong to the new owner from the moment of accept.Curator’s role in the transfer
For most curators, the global-admin approval step is handled by Kamino’s program-level admin. The market curator’s role is:- Surfacing the feature to users who need it (institutional holders, managed accounts, custodial flows)
- Guidance on cleanup before transfer (cancel borrow orders, claim rewards if desired, communicate position state to the new owner)
- Documentation of any market-specific implications (e.g., a permissioned market where the new owner needs separate approval)
When users actually use this
Common scenarios:| Scenario | What’s happening |
|---|---|
| Custody rotation | An institution moves their position from a hot-wallet custody setup to a multisig custody setup, or vice versa |
| Managed account migration | A fund manager hands an account back to its beneficial owner, or the beneficial owner reassigns to a new manager |
| Address compromise | A user’s wallet is compromised; they want to migrate their healthy position to a fresh address before liquidation pressure builds |
| Settlement | One leg of an off-chain trade is settled by transferring ownership of an existing on-chain position |
Common errors
| Error | Cause |
|---|---|
ObligationOwnershipTransferNotInitiated | Accept called before initiate. The flow must be in order |
ObligationOwnershipTransferNotApproved | Accept called before approve. The global admin step must complete first |
OwnershipTransferAlreadyInitiated | A new initiate call was made while one is already pending. Abort the existing one first |
Unauthorized | The signer doesn’t match the role expected at this step (current owner, global admin, or new owner) |
| Transfer succeeded but new owner can’t operate | The obligation may hold an asset whose transfer hook rejects the new owner. Verify hook compatibility |
Reference
- Borrow orders — the open-order interaction at acceptance
- Obligation orders — orders carry through the transfer
- Farms & rewards — reward accounting around the transfer