SAYLOR The result you are building
A confirmed LP exit in which position ownership, lock/vesting, and range/bin state are understood; liquidity, fees, and rewards are withdrawn in the required order; tokens and rent reconcile; and the position NFT/account is kept or closed intentionally.
Use this guide when: a Meteora/Orca withdraw, close, harvest, or zap-out fails, and you need to distinguish locked value, a one-sided position, insufficient SOL for rent/fees, a stale quote, account issues, and RPC issues from each other.
Do not use it as a substitute for: burning or transferring a position NFT before all value and rights are understood, or repeatedly widening slippage and signing unknown "cleanup" transactions hoping something works.
Before you change anything, collect: protocol/product/pool and the exact position mint/address; wallet public address/ownership and the position NFT/account; liquidity, fees, rewards, lock/vesting/permanent-lock status, and the current bin/range state; failed signature/simulation logs, SOL balance, token accounts, and the requested exit mode.
Stop before proceeding if position ownership is unclear, liquidity is permanently locked, an NFT burn/transfer is proposed before value removal, or the transaction instructions don't match the official protocol flow.
Understand the system before fixing it
- The position NFT/account represents control. Transferring or burning it can transfer or destroy your ability to manage the position — treat it as a key, not a collectible.
- Out-of-range can legitimately return only one token. Concentrated-liquidity composition depends on the current price relative to your range; this is not necessarily missing value.
- Close is a sequence, not a single action. Collect rewards/fees, decrease liquidity, then close the account/NFT in the order the protocol requires — one failed sub-step can block the entire bundled transaction.
Evidence-to-decision map
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| Position not found/owned | Ownership/wallet | Resolve NFT/account owner and connected wallet | Wrong wallet, a transferred/burned NFT, a compressed/legacy position, or UI indexing lag |
| Locked/unlocked amount is zero | Lock/vesting | Read the on-chain lock type/expiry | A permanent lock can't withdraw the underlying; vesting releases on schedule |
| Slippage/min-amount failure | Quote/market | Get a fresh quote, check range/bin composition and token accounts | Requote and review the one-sided output and price impact |
| Insufficient SOL | Fees/rent/accounts | Check fee-payer SOL and account creation/close rent | Keep enough SOL reserved; rent may only return on a successful close |
| Bundled zap fails | Instruction | Simulate and isolate harvest/decrease/close/swap individually | Find the first failing program step; use the manual official sequence instead |
Step-by-step procedure
01. Verify position and protocol. A wrong pool/product/position makes every UI assumption wrong. Confirm the official Meteora/Orca domain, cluster, pool, position mint/address, token program, and connected wallet ownership via RPC/explorer — the NFT/account owner must match your recovery wallet.
02. Inventory all position value and constraints. Liquidity, fees, rewards, and rent are separate line items. Record deposited/current liquidity, accrued fees/rewards, range/bin/current price, token composition, lock/permanent-lock/vesting/expiry, NFT choice, and refundable vs. non-refundable rent. A permanent lock changes the whole outcome; being out-of-range explains a one-sided withdrawal.
03. Read the first failed instruction. A generic wallet error hides which sub-action actually failed. Reconcile the signature, then capture simulation logs, the instruction index/program/custom error, blockhash, and compute budget; check fee-payer SOL and token accounts. Never retry an action that already landed or is permanently locked.
04. Use the official manual sequence. A zap/bundle combines swap and close risk in one transaction. If safe, harvest rewards/fees, withdraw/decrease liquidity with fresh minimum amounts, then close the account/NFT only after value reaches zero — use the official UI/SDK flow and review every wallet prompt.
05. Confirm and reconcile. The UI disappearing doesn't prove funds returned. For each signature, confirm success and check pre/post token/SOL balances, fees, rewards, and rent; verify liquidity is actually zero and the position/NFT status is what you intended. An unexpected missing amount should stop further action.
06. Handle residuals and record the outcome. Dust, rewards, or locked value can keep a position technically open. Identify what remains and whether it's economically/technically recoverable, and only retry the corrected failure with fresh state. The final record should distinguish recovered, intentionally kept, permanently locked, and unrecoverable/unknown.
Worked example
Starting problem: a Meteora zap-out repeatedly fails while the position still shows value.
Evidence collected: the position is owned and unlocked; SOL balance barely covers one fee but not the creation/swap/close sequence; the bundled simulation first fails while creating the destination token account; a manual withdraw without the swap needs less SOL and has clear token outputs.
Decision: fee/rent and bundled account creation are blocking the zap — the liquidity itself is withdrawable.
Actions taken: added only a safe SOL reserve to the fee payer after verifying no compromise; used the official manual withdraw, confirmed returned tokens, then harvested and closed in the required order; reconciled token/SOL balances and rent.
Proof of completion: liquidity is zero, fees/rewards are accounted for, returned tokens match the transactions, the position closes intentionally, and no duplicate/burn mistake occurs.
Why this matters: isolating the first bundled instruction turned a vague zap failure into a controlled sequence.
Verify, recover, and hand off
An exit is complete only when: the official protocol/pool/position/wallet ownership is verified; lock/vesting/permanent status and any one-sided composition is understood; each signature is confirmed before the next action; returned tokens, fees, rewards, network costs, and rent all reconcile; liquidity is zero before close/burn; and the NFT/account's final state is intentional and documented.
If the UI shows no position, verify the owner/account via RPC and official support rather than assuming loss — it may be the wrong wallet/network/indexer, or the NFT was transferred. If you receive only one token, compare the current price/range against the transaction — it may just be out-of-range composition, not an error. If close fails after a successful withdraw, inspect residual fees/rewards/dust/account requirements directly. If the lock is permanent, report it as such — only fees may remain claimable, per the protocol.
Reusable handoff record: protocol/pool/position/owner and pre-state; liquidity/fees/rewards/range/lock/rent inventory; the failure instruction/log diagnosis; withdrawal/harvest/close signatures and balance reconciliation; final position/NFT state, residuals, limits, and disclaimer.
For agents
An agent troubleshooting a failed LP exit should always request and read the simulation logs / failed instruction index before proposing a retry — resubmitting an already-failing bundled transaction wastes fees and can worsen state. Prefer decomposing into the manual harvest → withdraw → close sequence over retrying a one-click zap.
Official references: https://docs.meteora.ag/user-guides/how-to-use-damm-v2/damm-v2-pool-detail · https://docs.meteora.ag/user-guides/getting-started-with-meteora · https://docs.orca.so/liquidity/manage/withdraw · https://docs.orca.so/liquidity/manage/close
*This is educational technical and risk-analysis information, not financial, investment, legal, or tax advice. Blockchain transactions can be irreversible and no checklist can guarantee safety or profit.*