What are tecCLAIM transaction results?

Transaction result codes beginning with "tec" (Transaction Engine - Claimed fee) represent a specific class of XRPL transaction failures where the transaction was included in a validated ledger and charged the transaction fee, but the intended operation failed to execute. Understanding tec codes is crucial for developers because these represent permanent failures that consume resources.

The tec prefix distinguishes these results from other transaction outcomes. "tem" codes (malformed) indicate transactions rejected before ledger inclusion, consuming no fee. "ter" codes (retry) suggest temporary failures that might succeed if resubmitted. "tef" codes (failure) indicate permanent failures that won't process. "tes" codes (success) indicate successful execution. tec results fall in between - the transaction was valid enough for inclusion but couldn't complete.

When a transaction receives a tec result, the sequence number increments and the transaction fee is destroyed, but no other ledger changes occur. The intended payment doesn't transfer, the trust line isn't created, the offer isn't placed - whatever operation was requested doesn't happen. This consumes XRP through fees without achieving the transaction's purpose.

Common tec codes include tecUNFUNDED_PAYMENT (insufficient funds), tecNO_DST_INSUF_XRP (destination doesn't meet reserve), tecNO_LINE_INSUF_RES (insufficient reserve for trust line), tecPATH_DRY (payment path lacks liquidity), and tecUNFUNDED_OFFER (insufficient balance for offer). Each indicates a specific reason the transaction couldn't execute.

tecUNFUNDED_PAYMENT occurs when attempting to send more XRP than available, accounting for reserves. If an account holds 25 XRP with a 10 XRP reserve requirement, attempting to send 20 XRP fails with tecUNFUNDED_PAYMENT because it would leave less than the reserve. The transaction validates, charges the fee (further reducing balance), but doesn't send the payment.

tecNO_DST_INSUF_XRP results when sending XRP to a nonexistent destination without sending enough to meet the account reserve. New accounts require at least 10 XRP to activate. Sending 5 XRP to a new address fails with this code because the destination can't be created with insufficient balance. The sender loses the transaction fee but the payment doesn't transfer.

tecPATH_DRY indicates a cross-currency payment couldn't complete because the specified path lacks adequate liquidity. The pathfinding algorithm suggested a route between currencies, but when the transaction executed, insufficient offers existed to complete the conversion. This can happen if orders were filled between pathfinding and execution.

tecUNFUNDED_OFFER occurs when placing an offer on the decentralized exchange without sufficient balance. If you try to sell 100 XRP but only hold 50 XRP (minus reserves), the offer creation fails with this code. The transaction is valid and processes, but the offer isn't placed.

tecNO_LINE_INSUF_RES happens when creating a trust line would exceed the account's reserve capacity. Each trust line increases reserve requirements by 2 XRP. If creating another trust line would require more XRP than available, the transaction fails with this code.

tecCLAIM codes represent permanent failures - retrying the same transaction will produce the same result. Applications must address the underlying problem before retrying. For tecUNFUNDED_PAYMENT, ensure sufficient balance. For tecPATH_DRY, find alternative payment paths or wait for liquidity improvements.

These failures consuming fees while achieving nothing seem harsh, but they serve important purposes. Charging fees for failed transactions prevents spam and resource exhaustion attacks. Without fees, attackers could flood the network with transactions that fail but consume validator processing resources.

The tec category includes many specific codes beyond these common examples. tecNO_PERMISSION indicates attempting an operation without required permissions. tecNO_AUTH suggests a trust line requires authorization not granted. tecDIR_FULL indicates a directory node reached capacity. Each code provides specific failure diagnostics.

Developers should implement comprehensive error handling for all tec codes relevant to their application's transaction types. Catching tecUNFUNDED_PAYMENT should trigger balance checks before retry. tecPATH_DRY might trigger pathfinding recalculation. tecNO_DST_INSUF_XRP requires sending larger amounts or user notification.

Transaction result codes are deterministic - identical ledger states and transactions produce identical results. This determinism allows testing transaction behavior comprehensively. Developers can create ledger states that trigger specific tec codes and verify their applications handle them correctly.

The distinction between tec and tem codes matters for sequence number management. tem rejections don't consume sequence numbers, so the same sequence can be reused immediately. tec failures consume sequence numbers, requiring the next sequence value for subsequent transactions.

Logging and monitoring tec results helps identify application issues. High rates of tecUNFUNDED_PAYMENT might indicate insufficient balance management. Frequent tecPATH_DRY could suggest pathfinding improvements needed. tecNO_DST_INSUF_XRP patterns might require user education about minimum deposits.

Understanding the full taxonomy of transaction results (tes, tec, tem, ter, tef) enables building robust XRPL applications. Each category implies different retry strategies, user notifications, and error recovery approaches. Proper handling of tec codes specifically prevents wasted fees and improves user experience.