Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
These codes indicate that the transaction failed and was not included in a ledger, but the transaction could have succeeded in some theoretical ledger. Typically this means that the transaction can no longer succeed in any future ledger. They have numerical values in the range of -199 to -100. The exact code for any given error is subject to change, so don't rely on it.
Caution: Transactions with tef codes are not applied to ledgers and cannot cause any changes to the Xahau state. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see Finality of Results and Reliable Transaction Submission.
tefALREADY
The same exact transaction has already been applied.
tefBAD_ADD_AUTH
DEPRECATED.
tefBAD_AUTH
The key used to sign this account is not authorized to modify this account. (It could be authorized if the account had the same key set as the Regular Key.)
tefBAD_AUTH_MASTER
The single signature provided to authorize this transaction does not match the master key, but no regular key is associated with this address.
tefBAD_LEDGER
tefBAD_QUORUM
The transaction was multi-signed, but the total weights of all included signatures did not meet the quorum.
tefBAD_SIGNATURE
The transaction was multi-signed, but contained a signature for an address not part of a SignerList associated with the sending account.
tefCREATED
DEPRECATED.
tefEXCEPTION
tefFAILURE
Unspecified failure in applying the transaction.
tefINTERNAL
tefINVARIANT_FAILED
tefMASTER_DISABLED
The transaction was signed with the account's master key, but the account has the lsfDisableMaster field set.
tefMAX_LEDGER
The transaction included a LastLedgerSequence parameter, but the current ledger's sequence number is already higher than the specified value.
tefNFTOKEN_IS_NOT_TRANSFERABLE
The transaction attempted to send a non-fungible token to another account, but the NFToken has the lsfTransferable flag disabled and the transfer would not be to or from the issuer. (Added by the [NonFungibleTokensV1_1 amendment][].)
tefNO_AUTH_REQUIRED
The [TrustSet transaction][] tried to mark a trust line as authorized, but the lsfRequireAuth flag is not enabled for the corresponding account, so authorization is not necessary.
tefNO_TICKET
The transaction attempted to use a Ticket, but the specified TicketSequence number does not exist in the ledger, and cannot be created in the future because it is earlier than the sender's current sequence number.
tefNOT_MULTI_SIGNING
The transaction was multi-signed, but the sending account has no SignerList defined.
tefPAST_SEQ
The sequence number of the transaction is lower than the current sequence number of the account sending the transaction.
tefTOO_BIG
The transaction would affect too many objects in the ledger. For example, this was an [AccountDelete transaction][] but the account to be deleted owns over 1000 objects in the ledger.
tefWRONG_PRIOR
The transaction contained an AccountTxnID field (or the deprecated PreviousTxnID field), but the transaction specified there does not match the account's previous transaction.
tefPAST_IMPORT_SEQ
The transaction failed because the import sequence number has already been used.
tefPAST_IMPORT_VL_SEQ
The transaction failed because the import validator list sequence number has already been used.
While processing the transaction, the ledger was discovered in an unexpected state. If you can reproduce this error, please to get it fixed.
While processing the transaction, the server entered an unexpected state. This may be caused by unexpected inputs, for example if the binary data for the transaction is grossly malformed. If you can reproduce this error, please to get it fixed.
When trying to apply the transaction, the server entered an unexpected state. If you can reproduce this error, please to get it fixed.
An invariant check failed when trying to claim the transaction cost. Added by the [EnforceInvariants amendment][]. If you can reproduce this error, please .
The codes tesSUCCESS and tesPARTIAL are the only codes that indicates a transaction succeeded. This does not always mean it accomplished what you expected it to do. (For example, an [OfferCancel][] can "succeed" even if there is no offer for it to cancel.)
The tesPARTIAL code indicates that a transaction has partially succeeded. Specifically, it is used in scenarios where an operation, such as deleting hook state records, exceeds a certain limit (e.g., 512 or 1024 records). In such cases, the transaction deletes up to the limit and then requires you to submit additional transactions with new sequence numbers to continue the deletion process until all records are removed. This ensures that large operations are broken down into manageable parts.
tesSUCCESS
The transaction was applied and forwarded to other servers. If this appears in a validated ledger, then the transaction's success is final.
tesPARTIAL
The transaction partially succeeded and requires additional transactions to complete large operations, such as deleting more than a set limit of records.
These codes indicate that the transaction failed, but it was applied to a ledger to apply the transaction cost. They have numerical values in the range 100 to 199. It is recommended to use the text code, not the numeric value.
Transactions with tec codes destroy the XAH paid as a transaction cost and consume a sequence number. For the most part, the transactions take no other action, but there are some exceptions. For example, a transaction that results in tecOVERSIZE still cleans up some unfunded offers. Always look at the transaction metadata to see precisely what a transaction did.
Caution: A transaction that provisionally failed with a tec code may still succeed or fail with a different code after being reapplied. The result is final when it appears in a validated ledger version. For more information, see Finality of Results and Reliable Transaction Submission.
tecCANT_ACCEPT_OWN_NFTOKEN_OFFER
157
The transaction tried to accept an offer that was placed by the same account to buy or sell a non-fungible token. (Added by the [NonFungibleTokensV1_1 amendment][].)
tecCLAIM
100
Unspecified failure, with transaction cost destroyed.
tecCRYPTOCONDITION_ERROR
146
This [EscrowCreate][] or [EscrowFinish][] transaction contained a malformed or mismatched crypto-condition.
tecDIR_FULL
121
The transaction tried to add an object (such as a trust line, Check, Escrow, or Payment Channel) to an account's owner directory, but that account cannot own any more objects in the ledger.
tecDUPLICATE
149
The transaction tried to create an object (such as a [DepositPreauth][] authorization) that already exists.
tecDST_TAG_NEEDED
143
The [Payment transaction][] omitted a destination tag, but the destination account has the lsfRequireDestTag flag enabled. [New in: rippled 0.28.0][]
tecEXPIRED
148
The transaction tried to create an object (such as an Offer or a Check) whose provided Expiration time has already passed.
tecFAILED_PROCESSING
105
An unspecified error occurred when processing the transaction.
tecFROZEN
137
The [OfferCreate transaction][] failed because one or both of the assets involved are subject to a global freeze.
tecHAS_OBLIGATIONS
151
The [AccountDelete transaction][] failed because the account to be deleted owns objects that cannot be deleted. See Deletion of Accounts for details.
tecINSUF_RESERVE_LINE
122
The transaction failed because the sending account does not have enough XAH to create a new trust line. (See: Reserves) This error occurs when the counterparty already has a trust line in a non-default state to the sending account for the same currency. (See tecNO_LINE_INSUF_RESERVE for the other case.)
tecINSUF_RESERVE_OFFER
123
The transaction failed because the sending account does not have enough XAH to create a new Offer. (See: Reserves)
tecINSUFF_FEE
136
The transaction failed because the sending account does not have enough XAH to pay the transaction cost that it specified. (In this case, the transaction processing destroys all of the sender's XAH even though that amount is lower than the specified transaction cost.) This result only occurs if the account's balance decreases after this transaction has been distributed to enough of the network to be included in a consensus set. Otherwise, the transaction fails with terINSUF_FEE_B before being distributed.
tecINSUFFICIENT_FUNDS
158
One of the accounts involved does not hold enough of a necessary asset. (Added by the [NonFungibleTokensV1_1 amendment][].)
tecINSUFFICIENT_PAYMENT
161
The amount specified is not enough to pay all fees involved in the transaction. For example, when trading a non-fungible token, the buy amount may not be enough to pay both the broker fee and the sell amount. (Added by the [NonFungibleTokensV1_1 amendment][].)
tecINSUFFICIENT_RESERVE
141
The transaction would increase the reserve requirement higher than the sending account's balance. [SignerListSet][], [PaymentChannelCreate][], [PaymentChannelFund][], and [EscrowCreate][] can return this error code. See Signer Lists and Reserves for more information.
tecINTERNAL
144
tecINVARIANT_FAILED
147
tecKILLED
150
The [OfferCreate transaction][] specified the tfFillOrKill flag and could not be filled, so it was killed. (Added by the [fix1578 amendment][].)
tecMAX_SEQUENCE_REACHED
153
A sequence number field is already at its maximum. This includes the MintedNFTokens field. (Added by the [NonFungibleTokensV1_1 amendment][].)
tecNEED_MASTER_KEY
142
This transaction tried to cause changes that require the master key, such as disabling the master key or giving up the ability to freeze balances. [New in: rippled 0.28.0][]
tecNFTOKEN_BUY_SELL_MISMATCH
155
The [NFTokenAcceptOffer transaction][] attempted to match incompatible offers to buy and sell a non-fungible token. (Added by the [NonFungibleTokensV1_1 amendment][].)
tecNFTOKEN_OFFER_TYPE_MISMATCH
156
One or more of the offers specified in the transaction was not the right type of offer. (For example, a buy offer was specified in the NFTokenSellOffer field.) (Added by the [NonFungibleTokensV1_1 amendment][].)
tecNO_ALTERNATIVE_KEY
130
The transaction tried to remove the only available method of authorizing transactions. This could be a [SetRegularKey transaction][] to remove the regular key, a [SignerListSet transaction][] to delete a SignerList, or an [AccountSet transaction][] to disable the master key. (Prior to rippled 0.30.0, this was called tecMASTER_DISABLED.)
tecNO_AUTH
134
The transaction failed because it needs to add a balance on a trust line to an account with the lsfRequireAuth flag enabled, and that trust line has not been authorized. If the trust line does not exist at all, tecNO_LINE occurs instead.
tecNO_DST
124
The account on the receiving end of the transaction does not exist. This includes Payment and TrustSet transaction types. (It could be created if it received enough XAH.)
tecNO_DST_INSUF_NATIVE
125
The account on the receiving end of the transaction does not exist, and the transaction is not sending enough XAH to create it.
tecNO_ENTRY
140
The transaction tried to modify a ledger object, such as a Check, Payment Channel, or Deposit Preauthorization, but the specified object does not exist. It may have already been deleted by a previous transaction or the transaction may have an incorrect value in an ID field such as CheckID, Channel, Unauthorize.
tecNO_ISSUER
133
The account specified in the issuer field of a currency amount does not exist.
tecNO_LINE
135
The TakerPays field of the [OfferCreate transaction][] specifies an asset whose issuer has lsfRequireAuth enabled, and the account making the offer does not have a trust line for that asset. (Normally, making an offer implicitly creates a trust line if necessary, but in this case it does not bother because you cannot hold the asset without authorization.) If the trust line exists, but is not authorized, tecNO_AUTH occurs instead.
tecNO_LINE_INSUF_RESERVE
126
The transaction failed because the sending account does not have enough XAH to create a new trust line. (See: Reserves) This error occurs when the counterparty does not have a trust line to this account for the same currency. (See tecINSUF_RESERVE_LINE for the other case.)
tecNO_LINE_REDUNDANT
127
The transaction failed because it tried to set a trust line to its default state, but the trust line did not exist.
tecNO_PERMISSION
139
The sender does not have permission to do this operation. For example, the [EscrowFinish transaction][] tried to release a held payment before its FinishAfter time, someone tried to use [PaymentChannelFund][] on a channel the sender does not own, or a [Payment][] tried to deliver funds to an account with the "DepositAuth" flag enabled.
tecNO_REGULAR_KEY
131
The [AccountSet transaction][] tried to disable the master key, but the account does not have another way to authorize transactions. If multi-signing is enabled, this code is deprecated and tecNO_ALTERNATIVE_KEY is used instead.
tecNO_SUITABLE_NFTOKEN_PAGE
154
The transaction tried to mint or acquire a non-fungible token but the account receiving the NFToken does not have a directory page that can hold it. This situation is rare. (Added by the [NonFungibleTokensV1_1 amendment][].)
tecNO_TARGET
138
The transaction referenced an Escrow or PayChannel ledger object that doesn't exist, either because it never existed or it has already been deleted. (For example, another [EscrowFinish transaction][] has already executed the held payment.) Alternatively, the destination account has asfDisallowXAH set so it cannot be the destination of this [PaymentChannelCreate][] or [EscrowCreate][] transaction.
tecOBJECT_NOT_FOUND
160
One of the objects specified by this transaction did not exist in the ledger. (Added by the [NonFungibleTokensV1_1 amendment][].)
tecOVERSIZE
145
This transaction could not be processed, because the server created an excessively large amount of metadata when it tried to apply the transaction. [New in: rippled 0.29.0-hf1][]
tecOWNERS
132
The transaction cannot succeed because the sender already owns objects in the ledger. For example, an account cannot enable the lsfRequireAuth flag if it has any trust lines or available offers.
tecPATH_DRY
128
The transaction failed because the provided paths did not have enough liquidity to send anything at all. This could mean that the source and destination accounts are not linked by trust lines.
tecPATH_PARTIAL
101
The transaction failed because the provided paths did not have enough liquidity to send the full amount.
tecTOO_SOON
152
The [AccountDelete transaction][] failed because the account to be deleted had a Sequence number that is too high. The current ledger index must be at least 256 higher than the account's sequence number.
tecUNFUNDED
129
The transaction failed because the account does not hold enough XAH to pay the amount in the transaction and satisfy the additional reserve necessary to execute this transaction.
tecUNFUNDED_ADD
102
DEPRECATED.
tecUNFUNDED_PAYMENT
104
The transaction failed because the sending account is trying to send more XAH than it holds, not counting the reserve.
tecUNFUNDED_OFFER
103
The [OfferCreate transaction][] failed because the account creating the offer does not have any of the TakerGets currency.
tecREQUIRES_FLAG
169
The SetHook transaction][] failed because of an incorrect Flag and Field combination.
tecPRECISION_LOSS
170
The transaction failed because the result would end with significant precision loss.
Unspecified internal error, with transaction cost applied. This error code should not normally be returned. If you can reproduce this error, please .
An invariant check failed when trying to execute this transaction. Added by the [EnforceInvariants amendment][]. If you can reproduce this error, please .
The rippled server summarizes transaction results with result codes, which appear in fields such as engine_result and meta.TransactionResult. These codes are grouped into several categories with different prefixes:
Claimed cost only
tec
The transaction did not achieve its intended purpose, but the transaction cost was destroyed. This result is only final in a validated ledger.
Failure
tef
The transaction cannot be applied to the server's current (in-progress) ledger or any later one. It may have already been applied, or the condition of the ledger makes it impossible to apply in the future.
Local error
tel
The rippled server had an error due to local conditions, such as high load. You may get a different response if you resubmit to a different server or at a different time.
Malformed transaction
tem
The transaction was not valid, due to improper syntax, conflicting options, a bad signature, or something else.
Retry
ter
The transaction could not be applied, but it could apply successfully in a future ledger.
Success
tes
(Not an error) The transaction succeeded. This result only final in a validated ledger.
The rippled server automatically retries failed transactions. It is important not to assume that a transaction has completely failed based on a tentative failure result. A transaction may later succeed unless its success or failure is final.
Warning: Transactions' provisional result codes may differ from their final result. Transactions that provisionally succeeded may eventually fail and transactions that provisionally failed may eventually succeed. Transactions that provisionally failed may also eventually fail with a different code. See the finality of results for how to know when a transaction's result is final.
The distinction between a local error (tel) and a malformed transaction (tem) is a matter of protocol-level rules. For example, the protocol sets no limit on the maximum number of paths that can be included in a transaction. However, a server may define a finite limit of paths it can process. If two different servers are configured differently, then one of them may return a tel error for a transaction with many paths, while the other server could successfully process the transaction. If enough servers are able to process the transaction so that it survives consensus, then it can still be included in a validated ledger.
By contrast, a tem error implies that no server anywhere can apply the transaction, regardless of settings. Either the transaction breaks the rules of the protocol, it is unacceptably ambiguous, or it is completely nonsensical. The only way a malformed transaction could become valid is through changes in the protocol; for example, if a new feature is adopted, then transactions using that feature could be considered malformed by servers that are running older software which predates that feature.
The response from the [submit method][] contains a provisional result from the rippled server indicating what happened during the local processing of the transaction.
The response from submit contains the following fields:
engine_result
String
A code indicating the outcome of the transaction, such as tecPATH_DRY.
engine_result_code
Signed Integer
A number that corresponds to the engine_result. The exact values are subject to change without notice.
engine_result_message
String
A human-readable message explaining what happened. This message is intended for developers to diagnose problems, and is subject to change without notice.
If nothing went wrong when submitting and applying the transaction locally, the response looks like this:
Note: A successful result at this stage does not indicate that the transaction has completely succeeded; only that it was successfully applied to the provisional version of the ledger kept by the local server. Failed results at this stage are also provisional and may change. See Finality of Results for details.
These codes indicate that the transaction was malformed, and cannot succeed according to the Xahau protocol. They have numerical values in the range of -299 to -200. The exact code for any given error is subject to change, so don't rely on it.
Tip: Transactions with tem codes are not applied to ledgers, and cannot cause any changes to the Xahau state. A tem result is final unless the rules for a valid transaction change. (For example, using functionality from an Amendment before that amendment is enabled results in temDISABLED; such a transaction could succeed later if it becomes valid when the amendment is enabled.)
These codes indicate that the transaction failed, but it could apply successfully in the future, usually if some other hypothetical transaction applies first. They have numerical values in the range of -99 to -1. The exact code for any given error is subject to change, so don't rely on it.
Caution: Transactions with ter codes are not applied to the current ledger and cannot cause any changes to the Xahau state. However, a transaction that provisionally failed may still succeed or fail with a different code after being automatically reapplied. For more information, see Finality of Results and Reliable Transaction Submission.
These codes indicate an error in the local server processing the transaction; it is possible that another server with a different configuration or load level could process the transaction successfully. They have numerical values in the range of -399 to -300. The exact code for any given error is subject to change, so don't rely on it.
Caution: Transactions with tel codes are not applied to ledgers and cannot cause any changes to the Xahau state. However, these transactions may be automatically cached and retried later. Transactions that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see Finality of Results and Reliable Transaction Submission.
temBAD_AMOUNT
An amount specified by the transaction (for example the destination Amount or SendMax values of a [Payment][]) was invalid, possibly because it was a negative number.
temBAD_AUTH_MASTER
The key used to sign this transaction does not match the master key for the account sending it, and the account does not have a Regular Key set.
temBAD_CURRENCY
The transaction improperly specified a currency field. See [Specifying Currency Amounts][Currency Amount] for the correct format.
temBAD_EXPIRATION
The transaction improperly specified an expiration value, for example as part of an [OfferCreate transaction][]. Alternatively, the transaction did not specify a required expiration value, for example as part of an [EscrowCreate transaction][].
temBAD_FEE
The transaction improperly specified its Fee value, for example by listing a non-XAH currency or some negative amount of XAH.
temBAD_ISSUER
The transaction improperly specified the issuer field of some currency included in the request.
temBAD_LIMIT
The [TrustSet transaction][] improperly specified the LimitAmount value of a trust line.
temBAD_NFTOKEN_TRANSFER_FEE
The [NFTokenMint transaction][] improperly specified the TransferFee field of the transaction. (Added by the [NonFungibleTokensV1_1 amendment][].)
temBAD_OFFER
The [OfferCreate transaction][] specifies an invalid offer, such as offering to trade XAH for itself, or offering a negative amount.
temBAD_PATH
The [Payment transaction][] specifies one or more Paths improperly, for example including an issuer for XAH, or specifying an account differently.
temBAD_PATH_LOOP
One of the Paths in the [Payment transaction][] was flagged as a loop, so it cannot be processed in a bounded amount of time.
temBAD_SEND_NATIVE_LIMIT
The [Payment transaction][] used the tfLimitQuality flag in a direct XAH-to-XAH payment, even though XAH-to-XAH payments do not involve any conversions.
temBAD_SEND_NATIVE_MAX
The [Payment transaction][] included a SendMax field in a direct XAH-to-XAH payment, even though sending XAH should never require SendMax. (XAH is only valid in SendMax if the destination Amount is not XAH.)
temBAD_SEND_NATIVE_NO_DIRECT
The [Payment transaction][] used the tfNoDirectRipple flag for a direct XAH-to-XAH payment, even though XAH-to-XAH payments are always direct.
temBAD_SEND_NATIVE_PARTIAL
The [Payment transaction][] used the tfPartialPayment flag for a direct XAH-to-XAH payment, even though XAH-to-XAH payments should always deliver the full amount.
temBAD_SEND_NATIVE_PATHS
The [Payment transaction][] included Paths while sending XAH, even though XAH-to-XAH payments should always be direct.
temBAD_SEQUENCE
The transaction is references a sequence number that is higher than its own Sequence number, for example trying to cancel an offer that would have to be placed after the transaction that cancels it.
temBAD_SIGNATURE
The signature to authorize this transaction is either missing, or formed in a way that is not a properly-formed signature. (See tecNO_PERMISSION for the case where the signature is properly formed, but not authorized for this account.)
temBAD_SRC_ACCOUNT
The Account on whose behalf this transaction is being sent (the "source account") is not a properly-formed account address.
temBAD_TRANSFER_RATE
The TransferRate field of an AccountSet transaction is not properly formatted or out of the acceptable range.
temCANNOT_PREAUTH_SELF
The sender of the [DepositPreauth transaction][] was also specified as the account to preauthorize. You cannot preauthorize yourself.
temDST_IS_SRC
The transaction improperly specified a destination address as the Account sending the transaction. This includes trust lines (where the destination address is the issuer field of LimitAmount) and payment channels (where the destination address is the Destination field).
temDST_NEEDED
The transaction improperly omitted a destination. This could be the Destination field of a [Payment transaction][], or the issuer sub-field of the LimitAmount field fo a TrustSet transaction.
temINVALID
The transaction is otherwise invalid. For example, the transaction ID may not be the right format, the signature may not be formed properly, or something else went wrong in understanding the transaction.
temINVALID_COUNT
The transaction includes a TicketCount field, but the number of Tickets specified is invalid.
temINVALID_FLAG
The transaction includes a Flag that does not exist, or includes a contradictory combination of flags.
temMALFORMED
Unspecified problem with the format of the transaction.
temREDUNDANT
The transaction would do nothing; for example, it is sending a payment directly to the sending account, or creating an offer to buy and sell the same currency from the same issuer.
temREDUNDANT_SEND_MAX
[Removed in: rippled 0.28.0][]
temRIPPLE_EMPTY
The [Payment transaction][] includes an empty Paths field, but paths are necessary to complete this payment.
temBAD_WEIGHT
The [SignerListSet transaction][] includes a SignerWeight that is invalid, for example a zero or negative value.
temBAD_SIGNER
The [SignerListSet transaction][] includes a signer who is invalid. For example, there may be duplicate entries, or the owner of the SignerList may also be a member.
temBAD_QUORUM
The [SignerListSet transaction][] has an invalid SignerQuorum value. Either the value is not greater than zero, or it is more than the sum of all signers in the list.
temUNCERTAIN
Used internally only. This code should never be returned.
temUNKNOWN
Used internally only. This code should never be returned.
temDISABLED
The transaction requires logic that is disabled. Typically this means you are trying to use an amendment that is not enabled for the current ledger.
temHOOK_DATA_TOO_LARGE
The transaction CreateCode field contains more than 256 bytes.
terFUNDS_SPENT
DEPRECATED.
terINSUF_FEE_B
The account sending the transaction does not have enough XAH to pay the Fee specified in the transaction.
terLAST
Used internally only. This code should never be returned.
terNO_ACCOUNT
The address sending the transaction is not funded in the ledger (yet).
terNO_AUTH
The transaction would involve adding currency issued by an account with lsfRequireAuth enabled to a trust line that is not authorized. For example, you placed an offer to buy a currency you aren't authorized to hold.
terNO_LINE
Used internally only. This code should never be returned.
terNO_RIPPLE
Used internally only. This code should never be returned.
terOWNERS
The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the lsfRequireAuth flag if it has any trust lines or available offers.
terPRE_SEQ
The Sequence number of the current transaction is higher than the current sequence number of the account sending the transaction.
terPRE_TICKET
The transaction attempted to use a Ticket, but the specified TicketSequence number does not exist in the ledger. However, the Ticket could still be created by another transaction.
terRETRY
Unspecified retriable error.
terQUEUED
The transaction met the load-scaled transaction cost but did not meet the open ledger requirement, so the transaction has been queued for a future ledger.
terNO_HOOK
The transaction attempted to use a HookHash that doesn't exist on the ledger.
telBAD_DOMAIN
The transaction specified a domain value (for example, the Domain field of an [AccountSet transaction][]) that cannot be used, probably because it is too long to store in the ledger.
telBAD_PATH_COUNT
The transaction contains too many paths for the local server to process.
telBAD_PUBLIC_KEY
The transaction specified a public key value (for example, as the MessageKey field of an [AccountSet transaction][]) that cannot be used, probably because it is not the right length.
telCAN_NOT_QUEUE
The transaction did not meet the open ledger cost, but this server did not queue this transaction because it did not meet the queuing restrictions. For example, a transaction returns this code when the sender already has 10 other transactions in the queue. You can try again later or sign and submit a replacement transaction with a higher transaction cost in the Fee field.
telCAN_NOT_QUEUE_BALANCE
The transaction did not meet the open ledger cost and also was not added to the transaction queue because the sum of potential XAH costs of already-queued transactions is greater than the expected balance of the account. You can try again later, or try submitting to a different server. [New in: rippled 0.70.2][]
telCAN_NOT_QUEUE_BLOCKS
The transaction did not meet the open ledger cost and also was not added to the transaction queue. This transaction could not replace an existing transaction in the queue because it would block already-queued transactions from the same sender by changing authorization methods. (This includes all [SetRegularKey][] and [SignerListSet][] transactions, as well as [AccountSet][] transactions that change the RequireAuth/OptionalAuth, DisableMaster, or AccountTxnID flags.) You can try again later, or try submitting to a different server. [New in: rippled 0.70.2][]
telCAN_NOT_QUEUE_BLOCKED
The transaction did not meet the open ledger cost and also was not added to the transaction queue because a transaction queued ahead of it from the same sender blocks it. (This includes all [SetRegularKey][] and [SignerListSet][] transactions, as well as [AccountSet][] transactions that change the RequireAuth/OptionalAuth, DisableMaster, or AccountTxnID flags.) You can try again later, or try submitting to a different server. [New in: rippled 0.70.2][]
telCAN_NOT_QUEUE_FEE
The transaction did not meet the open ledger cost and also was not added to the transaction queue. This code occurs when a transaction with the same sender and sequence number already exists in the queue and the new one does not pay a large enough transaction cost to replace the existing transaction. To replace a transaction in the queue, the new transaction must have a Fee value that is at least 25% more, as measured in fee levels. You can increase the Fee and try again, send this with a higher Sequence number so it doesn't replace an existing transaction, or try sending to another server. [New in: rippled 0.70.2][]
telCAN_NOT_QUEUE_FULL
The transaction did not meet the open ledger cost and the server did not queue this transaction because this server's transaction queue is full. You could increase the Fee and try again, try again later, or try submitting to a different server. The new transaction must have a higher transaction cost, as measured in fee levels, than the transaction in the queue with the smallest transaction cost. [New in: rippled 0.70.2][]
telFAILED_PROCESSING
An unspecified error occurred when processing the transaction.
telINSUF_FEE_P
The Fee from the transaction is not high enough to meet the server's current transaction cost requirement, which is derived from its load level and network-level requirements. If the individual server is too busy to process your transaction right now, it may cache the transaction and automatically retry later.
telLOCAL_ERROR
Unspecified local error.
telNO_DST_PARTIAL
The transaction is an XAH payment that would fund a new account, but the tfPartialPayment flag was enabled. This is disallowed.
telWRONG_NETWORK
The transaction specifies the wrong NetworkID value for the current network. Either specify the correct the NetworkID value for the intended network, or submit the transaction to a server that is connected to the correct network.
tel_REQUIRES_NETWORK_ID
The transaction does not specify a NetworkID field, but the current network requires one. If the transaction was intended for a network that requires NetworkID, add the field and try again. If the transaction was intended for a different network, submit it to a server that is connected to the correct network.
telNETWORK_ID_MAKES_TX_NON_CANONICAL
The transaction specified a NetworkID field, but the current network requires that the NetworkID is not submitted.
telNON_LOCAL_EMITTED_TXN
The emitted transaction cannot be applied because it was not generated locally.
telIMPORT_VL_KEY_NOT_RECOGNISED
The transaction was signed on a different network or the transaction was submitted to the wrong network. For Import transactions the validations must match the vl keys on receiving network.
telCAN_NOT_QUEUE_IMPORT
Import transaction was not able to be directly applied and cannot be queued.