The AMM LP Token Trust Line Limit Problem

An AMMDeposit transaction has no field for a trust-line limit. When you deposit into a pool you do not already hold LP tokens for, the ledger auto-creates the LP token trust line for you — issuer set to the AMM account, currency set to the pool's LP token — and it sets the limit to 0.

Your LP balance still grows normally, because AMMDeposit mints LP tokens and AMMWithdraw burns them directly, bypassing the trust limit entirely. That is why you routinely see LP holders with a real positive balance sitting on a 0-limit line — a state that is impossible for a normal token, where your limit caps your balance.

If the limit is irrelevant to how AMM pools work, why does the ledger set it to 0 rather than something generous? The most likely reason is cleanup. A trust line only auto-deletes when it is back in its default state — balance 0 and limit 0 — and joining then fully leaving a pool is meant to be a clean round-trip.

Because the limit starts at 0, a full AMMWithdraw empties your balance to 0 and the line is instantly in its default state again, so the ledger removes it and refunds the 0.2 XRP reserve in the same transaction — no leftover object, no stranded reserve. Starting the line at 0 appears to be a deliberate choice to preserve that automatic removal. The catch, as the next sections show, is that the moment you raise the limit to make the position transferable, you opt out of that clean exit.

A regular Payment respects the destination's trust limit. Since the auto-created LP line has a limit of 0, it has no headroom to accept anything — so sending LP tokens to that account fails with tecPATH_DRY.

The counter-intuitive part: this happens even when the recipient already holds the same LP token. Two people who both provided liquidity to the same pool still cannot move LP tokens between them, because each of their AMM-created lines is capped at 0. To receive LP tokens, the recipient must first raise their trust-line limit (a TrustSet) to at least the amount being sent.

So you raise the limit to make your position transferable. Now the second edge appears. The XRP Ledger only auto-deletes a trust line when it is back in its default state: balance 0 and limit 0. Normally, when you withdraw all your liquidity (AMMWithdraw with the withdraw-all flag), your LP balance hits 0 and the ledger removes the line and returns its 0.2 XRP owner reserve in the same transaction.

But once you have edited the limit to a non-zero value, the line is no longer "default." AMMWithdraw empties it to a 0 balance — yet the line lingers, still holding 0.2 XRP of reserve. To actually close it, you have to send one more transaction: a TrustSet resetting the limit to 0, which finally lets the ledger delete the line and refund the reserve.

Neither column is strictly better — the 0-limit default optimizes for a clean exit, a raised limit optimizes for transferability.

This is not rare. Because the 0 limit is the ledger's default and most tools never change it, the majority of LP holders sit at limit 0. In a live snapshot of the XRP/RLUSD AMM pool, 244 of 398 LP holders (about 61%) had a trust-line limit of exactly 0 — each one unable to receive LP tokens via a Payment without a TrustSet first. The holders with non-zero limits are the ones whose wallet or tooling explicitly raised it.

• To receive LP tokens: set up (or raise) your LP trust line first — issuer = the AMM account, currency = the pool's LP token — with a limit at least as large as the amount you will receive. A sensible ceiling is the pool's total LP supply.
• To send LP tokens: confirm the recipient has done the above. A pre-send simulation that returns tecPATH_DRY almost always means their limit is too low.
• When you fully exit: if you ever raised the limit, remember the line will not auto-delete. Reset the limit to 0 to remove it and reclaim the 0.2 XRP reserve.
• Redeeming, not "burning": LP tokens cannot be sent to the AMM issuer to burn them (that returns tecNO_PERMISSION). The only way to destroy LP tokens is AMMWithdraw, which redeems them for your share of the pool.

The whole problem traces to one check in rippled. When a Payment delivers an issued token, withdrawToDestExceedsLimit() in View.cpp compares the amount against the recipient's trust-line limit and rejects the transfer if there is no headroom. It makes no exception for AMM LP tokens — even though for LP tokens the limit is meaningless (the AMM mints and burns them past the limit anyway).

The fix is small: skip (or relax) that limit check when the token's issuer is an AMM account — rippled can tell, because an AMM's issuing AccountRoot carries the AMMID field. That one change fixes both halves of the problem at once: if a 0-limit line can receive LP tokens, nobody ever needs to raise the limit — so every LP line stays in its default state and the clean auto-delete (line removed, 0.2 XRP refunded on full exit) is preserved for everyone. An equally small alternative: make emptied AMM trust lines auto-delete regardless of limit.

The catch is deployment, not code. Changing a transaction outcome (a Payment that failed with tecPATH_DRY would now succeed) is consensus-critical, so it cannot ship as a patch — it has to go through the XRPL amendment process: a named amendment with 80%+ validator support held for two weeks. A few lines of C++, but weeks of governance. Until something like it lands, the workarounds above are the practical path.

The XRPL.to pool page manages this whole trade-off automatically so you never hit the surprise:

• After a deposit, it raises your LP trust-line limit to the pool's total supply — so your position is immediately transferable and can receive more LP tokens. The line already exists, so this adds no reserve, only the fee.
• It shows a one-click "set up trust line to receive LP tokens" prompt for anyone who wants to receive LP tokens without depositing, and a "raise limit" prompt if an existing line is too low.
• On a full withdrawal, it resets the limit to 0 so the ledger deletes the line and returns the 0.2 XRP reserve — restoring the clean-exit behavior you would expect by default.

Related guides on AMM pools, trust lines, and reserves.