tecPATH_DRY means the provided XRPL payment paths did not have enough usable liquidity to deliver anything. Check the real source and destination assets, issuer context and receiving trust line before retrying. Adding XRP or changing a fee does not automatically create a valid token-payment route.
Confirm the payment type before changing the wallet
An app can label a payment XRPL or XRP while the actual request sends an issued token or converts between assets. The Payment reference distinguishes direct XRP payments from token and cross-currency flows. A normal XRP-to-XRP payment must omit Paths and SendMax, so an unexpected path error is a reason to inspect what the app actually constructed.
This guide focuses on classic trust-line tokens and route-based payments. It does not treat every newer XRPL token format as a trust-line asset. Preserve the complete transaction or wallet error, network and intended recipient. A vague message saying failed cannot establish the same cause.
| Evidence | What it tells you | Next check |
|---|---|---|
| tecPATH_DRY | The provided paths could not deliver anything | Asset identity, trust-line connectivity and usable route |
| tecPATH_PARTIAL | The paths could not deliver the full amount | Available liquidity and the payment's actual constraints |
| tecUNFUNDED_PAYMENT | An XRP payment exceeds spendable XRP after reserve | Source funding and the exact intended XRP amount |
| tecNO_AUTH | A required token authorization is missing | Issuer authorization in the relevant trust-line context |
| A provisional result only | The ledger outcome is not yet final | The result in a validated ledger |
A currency code does not identify every token
For the trust-line token case, check the currency and issuer or counterparty context together. The Payment documentation also defines special issuer values in some fields, so read the actual amount object rather than treating every label as a universal ticker. Two tokens displayed as USD can involve different issuers and different paths.
In a fictional example, a wallet holds USD from issuer Cedar, but the recipient expects USD from issuer Maple. Matching the three-letter display does not create a route between those positions. If conversion is needed, the request must have usable liquidity and appropriate trust-line relationships. The example does not name real issuers or recommend a substitute token.
Ask the recipient which exact asset it accepts. Do not create a trust line to an unfamiliar issuer merely to make an error disappear. A successful transfer of another asset would not necessarily settle the recipient's order or create a supported exchange deposit.
Check the trust line and route as separate conditions
The official tec-code reference lists missing trust-line connectivity and issuer rippling settings among possible explanations for tecPATH_DRY. These are possibilities to investigate, not a diagnosis that every occurrence requires one particular trust-line change.
The Paths explanation describes routes through trust-line relationships, order books and automated market makers. A route can depend on offers and state that change before execution. A computed possibility is not a permanent commitment that the desired amount can still be delivered later.
Receiver authorization, usable limits and token restrictions can matter too. The freeze documentation distinguishes issuer controls on trust-line tokens from native XRP. If a restriction applies, ask the issuer or service through its official process. Changing the network fee does not remove that token's authorization or freeze condition.
Read source limits without turning them into an unlimited spend
For a cross-currency request, SendMax limits the source amount under the transaction's rules. If the permitted source cannot obtain the required destination asset, the presence of a route diagram does not make the payment affordable. Compare the source asset, intended delivered asset and constraints rather than only the wallet's total value estimate.
Do not respond by approving an arbitrarily higher source limit. A changed maximum changes what you authorize. Likewise, partial-payment settings can change the meaning of success by allowing less than the headline amount to arrive. Do not enable partial delivery merely to force an order through unless that outcome is intended and accepted by the recipient.
A route lookup also has limits. The ripple_path_find reference says results can become outdated and do not guarantee the best route. An empty alternatives list is relevant to that query's source, destination and asset conditions; it does not prove that every conceivable transfer is permanently impossible.
A diagnostic sequence before the next signature
- Confirm the network, source account and intended recipient. Save the exact result code and transaction hash if available.
- Identify whether the request is direct XRP, a trust-line token payment or a conversion. Read the actual asset fields.
- Match the destination currency and issuer context with the recipient's instructions. Check whether the source actually holds the asset it is trying to send.
- Inspect relevant trust-line existence, usable capacity, authorization and restrictions through trusted records.
- Refresh the route through the wallet's supported process if the payment needs conversion. Review source limits and delivered amount again.
- Before retrying, establish the earlier attempt's final result so a provisional display is not mistaken for permission to pay twice.
A path error does not prove that your whole wallet is locked. Equally, a visible token balance does not prove it is spendable along the requested route. If the wallet cannot explain its constructed payment, contact its verified support with the public request details instead of submitting your seed to a supposed route-repair website.
Check the validated result and the receiver's credit
The tec reference warns that a provisional result can change when reapplied; finality comes from a validated ledger. A recorded failure can still involve the network transaction cost. Do not infer from payment failed that the source balance must be unchanged, or confuse that cost with a successful delivery of the intended amount.
After a successful corrected payment, inspect the actual delivered asset and amount. A custodial receiver's internal credit is a later, separate check. Provide the transaction hash, network, intended asset and receiving order reference if it needs investigation. An address-book label or screenshot of a green send button does not replace that evidence.
For the native asset, see the XRP page. For destination routing, use the existing XRP destination-tag guide. If you later use a no-account swap, follow the order's actual accepted asset and receiving instructions. This diagnosis does not establish that KOT.CASH accepts every issued token or conversion path on the XRP Ledger.
FAQ
What does tecPATH_DRY mean on XRP Ledger?
The provided payment paths could not deliver anything under the request's conditions. Investigate asset identity, trust-line connectivity and route liquidity rather than assuming it is always a gas shortage.
Does an XRP trust line fix every tecPATH_DRY error?
No, a correct trust line is only one possible condition. The payment can still lack conversion liquidity or have the wrong asset, authorization or constraints.
Should I add XRP after a tecPATH_DRY payment?
First establish whether the problem is actually source XRP funding, a token route or another condition. Extra XRP does not automatically create liquidity or authorize a token payment.
Related on KOT.CASH
Sources
- xrpl.org/docs/references/protocol/transactions/transaction-results/tec-codes
- xrpl.org/docs/references/protocol/transactions/types/payment
- xrpl.org/docs/concepts/tokens/fungible-tokens/paths
- xrpl.org/docs/concepts/tokens/fungible-tokens/freezes
- xrpl.org/docs/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/ripple_path_find