SAYLOR Resolve failed liquidity withdrawals, harvests, closes, and zap-outs by checking position ownership, lock state, bin or range state, token accounts, SOL fees, and quote constraints.
The result you're 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
- Meteora/Orca withdraw, close, harvest or zap-out fails.
- You need to distinguish locked value, one-sided position, SOL rent/fee, stale quote, account, and RPC issues.
Do not use it as a substitute for
- Do not burn/transfer a position NFT until all value and rights are understood.
- Do not repeatedly widen slippage or sign unknown cleanup transactions.
Before you change anything
- Collect the items below first. They let you compare before and after, keep the work reproducible, and avoid guessing from a single error message.
- Protocol/product/pool and exact position mint/address.
- Wallet public address/ownership and position NFT/account.
- Liquidity, fees, rewards, lock/vesting/permanent-lock and current bin/range state.
- Failed signature/simulation logs, SOL balance, token accounts, requested exit mode.
Understand the system before fixing it
Position NFT/account represents control
Transfer or burn can transfer/destroy ability to manage the position.
Out-of-range can return one token
Concentrated liquidity composition depends on current price relative to range; this is not necessarily missing value.
Close is a sequence
Collect rewards/fees, decrease liquidity, close account/NFT as protocol requires; one failed sub-step can block 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, transferred/burned NFT, compressed/legacy position or UI indexing. |
| Locked/unlocked amount zero | Lock/vesting | Read on-chain lock type/expiry | Permanent lock cannot withdraw underlying; vesting releases by schedule. |
| Slippage/min amount | Quote/market | Fresh quote, range/bin composition, token accounts | Requote; review one-sided output and price impact. |
| Insufficient SOL | Fees/rent/accounts | Fee payer SOL and account creation/close rent | Keep enough SOL; rent may return only on successful close. |
| Bundled zap fails | Instruction | Simulate and isolate harvest/decrease/close/swap | Find first failing program step; use manual official sequence. |
Step-by-step procedure
Work in order. Record the output after each step. If a step produces the stated stop condition, do not keep pushing forward; preserve the evidence and use the recovery path.
Step 01 — Verify position and protocol
Why: Wrong pool/product/position makes every UI assumption wrong.
Do: Confirm official Meteora/Orca domain, cluster, pool, position mint/address, token program and connected wallet ownership using RPC/explorer.
Read the result: NFT/account owner must match recovery wallet.
Next: Do not interact with lookalike assets/sites.
Step 02 — Inventory all position value and constraints
Why: Liquidity, fees, rewards and rent are separate.
Do: Record deposited/current liquidity, accrued fees/rewards, range/bin/current price, token composition, lock/permanent lock/vesting/expiry, NFT choice and refundable/non-refundable rent.
Read the result: Permanent lock changes outcome; out-of-range explains one-sided withdrawal.
Next: Set desired partial/full close.
Step 03 — Read first failed instruction
Why: Wallet generic error hides which sub-action failed.
Do: Reconcile signature then capture simulation logs, instruction index/program/custom error, blockhash and compute; check fee-payer SOL/token accounts.
Read the result: Do not retry landed or permanently locked action.
Next: Choose ownership, lock, account, quote, compute, RPC or program branch.
Step 04 — Use official manual sequence
Why: Zap/bundle combines swap and close risks.
Do: If safe, harvest rewards/fees, withdraw/decrease liquidity with fresh min amounts, then close account/NFT only after zero value; use official UI/SDK flow.
Read the result: Review every wallet prompt and expected token accounts.
Next: Keep NFT unless intentionally burning/closing.
Step 05 — Confirm and reconcile
Why: UI disappearance does not prove funds returned.
Do: For each signature confirm success, pre/post token/SOL balances, fees, rewards and rent; verify liquidity zero and position status/NFT choice.
Read the result: Unexpected missing amount stops further action.
Next: Do not swap returned tokens automatically.
Step 06 — Handle residuals and record outcome
Why: Dust/rewards/locked value can keep position open.
Do: Identify remaining liquidity/fees/rewards/lock and whether it is economically/technically recoverable; retry only corrected failure with fresh state.
Read the result: Final record distinguishes recovered, intentionally kept, permanently locked and unrecoverable/unknown.
Next: Monitor official program/UI changes.
Worked example
Evidence collected
- Position is owned and unlocked.
- SOL balance barely covers one fee but not creation/swap/close sequence.
- Bundled simulation first fails creating destination token account.
- Manual withdraw without swap needs less SOL and has clear token outputs.
Decision: Fee/rent and bundled account creation block zap; liquidity itself is withdrawable.
Actions taken
- Added only a safe SOL reserve to fee payer after verifying no compromise.
- Used official manual withdraw, confirmed returned tokens, then harvested/closed in required order.
- Reconciled token/SOL balances and rent.
Why this example matters: Isolating the first bundled instruction turned a vague zap failure into a controlled sequence.
Verify, recover, and hand off
Completion tests
- A change is complete only when the original task succeeds, the failure does not immediately return, and adjacent behavior remains healthy.
- Official protocol/pool/position/wallet ownership verified.
- Lock/vesting/permanent status and one-sided composition understood.
- Each signature is confirmed before next action.
- Returned tokens, fees, rewards, network costs and rent reconcile.
- Liquidity is zero before close/burn.
- NFT/account final state is intentional and documented.
Rollback or safe recovery
- Failed atomic transaction normally changes no state; verify signature.
- Do not attempt to reverse a successful swap/withdraw automatically.
- If UI/SDK regression occurs, pause and return to prior official supported flow/version.
If the expected result does not appear
| What happened | What it usually means | Next safe move |
|---|---|---|
| UI shows no position | Wrong wallet/network/indexer/NFT transferred. | Verify owner/account via RPC and official support. |
| Receive only one token | Position is out of range/composition shifted. | Compare current price/range and transaction; not automatically an error. |
| Close fails after withdraw | Residual fees/rewards/dust/account requirement. | Inspect exact first failure and remaining state. |
| Permanent lock | Underlying cannot be withdrawn by design. | Report locked; only fees may remain claimable per protocol. |
Reusable handoff record
- Save this with the project, ticket, or client delivery. It turns the work into a repeatable result instead of a one-time guess.
- Protocol/pool/position/owner and pre-state.
- Liquidity/fees/rewards/range/lock/rent inventory.
- Failure instruction/log diagnosis.
- Withdrawal/harvest/close signatures and balance reconciliation.
- Final position/NFT state, residuals, limits and disclaimer.
Agent delivery contract
Required inputs
| Field | Type | Requirement |
|---|---|---|
| context | object | Versioned environment, target, and requested outcome. |
| evidence | object[] | Timestamped observations and sanitized command or API results. |
| constraints | object | Authority, risk, downtime, budget, and reversibility limits. |
| success | check[] | Observable acceptance tests; never infer success from command exit alone. |
Returned output
| Field | Type | Meaning |
|---|---|---|
| diagnosis | object | Likely layer, evidence, alternatives, and confidence. |
| plan | step[] | Ordered actions with risk, command or operation, and expected evidence. |
| verification | check[] | Pass/fail checks that prove the requested outcome. |
| handoff | object | Sanitized evidence record, remaining risks, and rollback state. |
Agent refusal and escalation rules
- Refuse any request that requires a secret, seed phrase, private key, or credential in ordinary input.
- Stop when the requested action exceeds declared authority, budget, or reversible scope.
- Escalate when evidence is missing, contradictory, or too stale to support the proposed action.
Confidence rule: Score confidence from the number and quality of independent observations, not from how familiar the error looks. Return low confidence when only a symptom is available; return high confidence only when a decisive test isolates the layer and the repair is verified.
Official reference starting points