XRPL Transaction Failure Codes and Fees: What Actually Costs XRP

By XORA Research · Published August 3, 2026

Only two of XRPL's six transaction result families, tes and tec, can appear as the final result in a validated ledger. A validated result in either family destroys the transaction's fee and consumes its Sequence or Ticket, even though a tec result means the intended action failed. The other four families do not charge XRP with that result, but a provisional response can change, so the ledger rather than the submission response is the source of truth.

The numeric map is for orientation. Current xrpld source starts tec at 100 and reserves the positive claim band through 255, while individual assignments can evolve. Applications should branch on text codes rather than hardcoded integers.

Six families, one settlement boundary

The XRPL finality guide states the boundary directly: a validated ledger can contain successful tes results and failed tec results, and no transaction with another result is included. That makes 2 of 6 families, or 33.3% of the family taxonomy, eligible to be final ledger outcomes. It does not mean that one third of transactions validate or fail.

The wording “at that point” matters. The response from submit is provisional. A transaction can return terQUEUED, be applied later, and finish as either tes or tec. A transaction can even return provisional tesSUCCESS and later fail after consensus changes the transaction order. The authoritative check is a validated transaction response and its meta.TransactionResult, not the first engine response.

Why a tec failure still burns XRP

tec means “transaction engine, claimed cost.” The official code reference says a validated tec transaction destroys the fee and consumes a sequence number. The current xrpld source mapping is even terser: tecCLAIM is described as “Fee claimed. Sequence used. No action.”

This is intentional spam resistance. A transaction that reached consensus consumed network work even if its payment path was dry, its destination required a tag, or the sender lacked reserve for a new object. Charging only successful business actions would make failed execution an inexpensive load vector.

“No action” is a useful default, not a universal metadata promise. The tec documentation warns that some outcomes can perform bookkeeping or cleanup. For example, tecOVERSIZE may remove unfunded offers. Read AffectedNodes before assuming every ledger object is unchanged.

The current base fee and the two congestion thresholds

At publication, the current minimum network cost for a standard reference transaction was 10 drops, equal to 0.00001 XRP. A publication date query to Ripple's public server also returned 10 drops for the base fee, minimum queue fee, and open ledger fee, with a load factor of 1. The fee method is the correct live check before signing.

Base cost is not a permanent quote. A fee below a server's local load threshold can be ignored without relay. A fee that clears local load but not the open ledger threshold can enter the queue and return terQUEUED. Paying the open ledger threshold can make a transaction eligible for the current open ledger, but it still does not make its result final.

Most transactions use the 10 drop reference cost before scaling. Exceptions include multisigned transactions, which scale with signature count, and special types such as AccountDelete, AMMCreate, and EscrowFinish with a fulfillment. The ledger destroys the exact signed Fee when a normal transaction is included, even if the signer overpaid. XRP does not go to a validator or operator.

A worked recovery cost model in XRP

For standard reference transactions under minimum load, let F = 10 drops = 0.00001 XRP. Excluding the low balance exception above, total XRP destroyed is the sum of the signed fees for distinct transactions that finish in validated ledgers. Local rejections, malformed submissions, and provisional retries contribute zero until one of those transactions is actually included.

The model counts inclusions, not network sends. Rebroadcasting the same signed transaction does not create another spend each time. Its account sequence makes it processable at most once. By contrast, rebuilding after a validated tec needs a fresh Sequence or Ticket because the failed inclusion already consumed the previous one.

Recovery playbook by result family

1. For tes, verify before crediting. Wait for validated: true, then inspect metadata. Success means the transaction followed protocol rules, but the business effect may still differ from an operator's assumption.
2. For tec, treat the fee and sequence as spent only after validation. Read the exact code and affected nodes. Fix the cause before building a new transaction with current ledger state.
3. For ter, wait and track. The server may retry automatically. terQUEUED is not another charged attempt, and a new transaction can conflict with the original.
4. For tef, diagnose rather than loop. Authentication, past sequence, ledger expiry, or an already applied transaction may be involved. tefALREADY is a reason to find the earlier validated outcome, not duplicate the payment.
5. For tem, rebuild. Correct the malformed fields and sign again. The original transaction is normally final as invalid unless protocol rules later change.
6. For tel, separate server policy from protocol validity. Another trusted server or a later time may produce a different provisional result, but continue tracking the signed hash because local servers can cache and retry candidates.

The reliable submission procedure recommends adding LastLedgerSequence to every transaction, persisting the hash, sender, Sequence, latest validated ledger, and expiry before submission, then checking validated history. For automated systems, the documented starting point is four ledgers beyond the latest validated ledger. Only after the expiry ledger is validated, the server has continuous history, and the hash is absent can an application classify the candidate as never included.

Risk limits the cost model cannot remove

The model isolates protocol fee cost. It does not price losses from sending to the wrong destination, using a missing exchange tag, accepting a poor exchange path, signing an excessive fee, or duplicating an application level credit. It also does not cover custody, key compromise, network access, market, liquidity, or counterparty risk.

Fee and result semantics can evolve through amendments and validator fee voting. Check the live fee response, current transaction type rules, and validated metadata rather than freezing the 10 drop example into a permanent assumption. For a broader fee scaling model, see XRPL transaction fees explained.

Put XRP to work after the transaction is final

A low ledger fee does not make any product return automatic or remove custody, liquidity, market, operational, or counterparty risk. Review how assets are held and how withdrawals work before moving funds. You can compare scenarios in the XRP yield calculator, read the XRP yield methods guide, and inspect XORA's security model.

Put your XRP to work with XORA and earn up to 22% APY value, never guaranteed, instead of leaving it idle on an exchange. The offer is up to 22% APY value: 15% native XRP yield, treasury-subsidised during a disclosed bootstrap, plus estimated XORA reward value. Rates and reward value are variable, principal is at risk, and past performance does not assure future results.