Transaction Format

Transaction Format

You are here:
Estimated reading time: 40 min

Transactions Overview

Transaction is the only way to modify the CSC Ledger. Transactions are only valid if signed, submitted, and accepted into a validated ledger version following the consensus process. Some ledger rules also generate pseudo-transactions, which aren’t signed or submitted, but still must be accepted by consensus. Transactions that fail are also included in ledgers because they modify balances of CSC to pay for the anti-spam transaction cost.

Authorizing Transactions

In the decentralized CSC Ledger, a digital signature proves that a transaction is authorized to do a specific set of actions. Only signed transactions can be submitted to the network and included in a validated ledger. A signed transaction is immutable: its contents cannot change, and the signature is not valid for any other transaction.

A transaction can be authorized by any of the following types of signatures:

  • A single signature from the master secret key that is mathematically associated with the sending address. You can disable or enable the master key using an AccountSet transaction.
  • A single signature that matches a regular key associated with the address. You can add, remove, or replace a regular key using a SetRegularKey transaction.
  • multi-signature that matches a list of signers owned by the address. You can add, remove, or replace a list of signers using a SignerListSet transaction.

Any signature type can authorize any type of transaction, with the following exceptions:

Signing and Submitting Transactions

Sending a transaction to the CSC Ledger involves several steps:

  1. Create an unsigned transaction in JSON format.
  2. Use one or more signatures to authorize the transaction.
  3. Submit a transaction to a casinocoind server. If the transaction is properly formed, the server provisionally applies the transaction to its current version of the ledger and relays the transaction to other members of the peer-to-peer network.
  4. The consensus process determines which provisional transactions get included in the next validated ledger.
  5. The casinocoind servers apply those transactions to the previous ledger in a canonical order and share their results.
  6. If enough trusted validators created the exact same ledger, that ledger is declared validated and the results of the transactions in that ledger are immutable.

Unsigned Transaction Format

Here is an example of an unsigned Payment transaction in JSON

  "TransactionType" : "Payment",
  "Account" : "cDarPNJEpCnpBZSfmcquydockkePkjPGA2",
  "Destination" : "ca5nK24KXen9AHvsdFTKHSANinZseWnPcX",
  "Amount" : {
     "currency" : "USD",
     "value" : "1",
     "issuer" : "cDarPNJEpCnpBZSfmcquydockkePkjPGA2"
  "Fee": "12",
  "Flags": 2147483648,
  "Sequence": 2,

The CSC Ledger only relays and executes a transaction if the transaction object has been authorized by the sending address (in the Account) field. For transactions authorized by only a single signature, you have two options:

  1. Convert it to a binary blob and sign it offline. This is preferable, since it means that the account secret used for signing the transaction is never transmitted over any network connection.
  2. Have a casinocoind server sign the transaction for you. The sign command takes a JSON-format transaction and secret and returns the signed binary transaction format ready for submission. (Transmitting your account secret is dangerous, so you should only do this from within a trusted and encrypted connection, or through a local connection, and only to a server you control.)
    • As a shortcut, you can use the submit command with a tx_json object to sign and submit a transaction all at once. This is only recommended for testing and development purposes.

In either case, signing a transaction generates a binary blob that can be submitted to the network. This means using casinocoind‘s submit command. Here is an example of the same transaction, as a signed blob, being submitted with the WebSocket API:

  "id": 2,
  "command": "submit",
  "tx_blob" : "120000240000000461D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000F732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB74483046022100982064CDD3F052D22788DB30B52EEA8956A32A51375E72274E417328EBA31E480221008F522C9DB4B0F31E695AA013843958A10DE8F6BA7D6759BEE645F71A7EB240BE81144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754"

After a transaction has been submitted, you can check its status using the API, for example using the tx command.

The success of a transaction is not final unless the transaction appears in a validated ledger with the result code tesSUCCESS. See also: Finality of Results.

Example response from the tx command:

  "id": 6,
  "status": "success",
  "type": "response",
  "result": {
    "Account": "cDarPNJEpCnpBZSfmcquydockkePkjPGA2",
    "Amount": {
      "currency": "USD",
      "issuer": "cDarPNJEpCnpBZSfmcquydockkePkjPGA2",
      "value": "1"
    "Destination": "ca5nK24KXen9AHvsdFTKHSANinZseWnPcX",
    "Fee": "10",
    "Flags": 2147483648,
    "Sequence": 2,
    "SigningPubKey": "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB",
    "TransactionType": "Payment",
    "TxnSignature": "3045022100D64A32A506B86E880480CCB846EFA3F9665C9B11FDCA35D7124F53C486CC1D0402206EC8663308D91C928D1FDA498C3A2F8DD105211B9D90F4ECFD75172BAE733340",
    "date": 455224610,
    "hash": "33EA42FC7A06F062A7B843AF4DC7C0AB00D6644DFDF4C5D354A87C035813D321",
    "inLedger": 7013674,
    "ledger_index": 7013674,
    "meta": {
      "AffectedNodes": [
          "ModifiedNode": {
            "FinalFields": {
              "Account": "cDarPNJEpCnpBZSfmcquydockkePkjPGA2",
              "Balance": "99999980",
              "Flags": 0,
              "OwnerCount": 0,
              "Sequence": 3
            "LedgerEntryType": "AccountRoot",
            "LedgerIndex": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8",
            "PreviousFields": {
              "Balance": "99999990",
              "Sequence": 2
            "PreviousTxnID": "7BF105CFE4EFE78ADB63FE4E03A851440551FE189FD4B51CAAD9279C9F534F0E",
            "PreviousTxnLgrSeq": 6979192
          "ModifiedNode": {
            "FinalFields": {
              "Balance": {
                "currency": "USD",
                "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
                "value": "2"
              "Flags": 65536,
              "HighLimit": {
                "currency": "USD",
                "issuer": "cDarPNJEpCnpBZSfmcquydockkePkjPGA2",
                "value": "0"
              "HighNode": "0000000000000000",
              "LowLimit": {
                "currency": "USD",
                "issuer": "ca5nK24KXen9AHvsdFTKHSANinZseWnPcX",
                "value": "100"
              "LowNode": "0000000000000000"
            "LedgerEntryType": "CasinocoinState",
            "LedgerIndex": "96D2F43BA7AE7193EC59E5E7DDB26A9D786AB1F7C580E030E7D2FF5233DA01E9",
            "PreviousFields": {
              "Balance": {
                "currency": "USD",
                "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
                "value": "1"
            "PreviousTxnID": "7BF105CFE4EFE78ADB63FE4E03A851440551FE189FD4B51CAAD9279C9F534F0E",
            "PreviousTxnLgrSeq": 6979192
      "TransactionIndex": 0,
      "TransactionResult": "tesSUCCESS"
    "validated": true



Multi-signing in the CSC Ledger is the act of authorizing transactions for the CSC Ledger by using a combination of multiple secret keys. You can have any combination of authorization methods enabled for your address, including multi-signing, a master key, and a regular key. (The only requirement is that at least one method must be enabled.)

The SignerListSet transaction defines which addresses can authorize transactions from your address. You can include up to 8 addresses in a SignerList. You can control how many signatures are needed, in which combinations, by using the quorum and weight values of the SignerList.

To successfully submit a multi-signed transaction, you must do all of the following:

  • The address sending the transaction (specified in the Account field) must own a SignerList in the ledger.
  • The transaction must include the SigningPubKey field as an empty string.
  • The transaction must include a Signers field containing an array of signatures.
  • The signatures present in the Signers array must match signers defined in the SignerList.
  • For the provided signatures, the total weight associated with those signers must be equal or greater than the quorum for the SignerList.
  • The transaction cost (specified in the Fee field) must be at least (N+1) times the normal transaction cost, where N is the number of signatures provided.
  • All fields of the transaction must be defined before collecting signatures. You cannot auto-fill any fields.
  • If presented in binary form, the Signers array must be sorted based on the numeric value of the signer addresses, with the lowest value first. (If submitted as JSON, the submit_multisigned command handles this automatically.)

For more information, see How to Multi-Sign.

Reliable Transaction Submission

Reliably submitting transactions is the process of achieving both of the following:

  • Idempotency – A transaction should be processed once and only once, or not at all.
  • Verifiability – Applications can determine the final result of a transaction.

To have both qualities when submitting a transaction, an application should:

  1. Construct and sign the transaction first, including a LastLedgerSequence parameter that gives the transaction a limited lifespan.
  2. Persist details of the transaction before submitting.
  3. Submit the transaction.
  4. Confirm that the transaction was either included in a validated ledger, or that it has expired due to LastLedgerSequence.
  5. If a transaction fails or expires, you can modify and resubmit it.

Main article: Reliable Transaction Submission

Identifying Transactions

The "hash" is the unique value that identifies a particular transaction. The server provides the hash in the response when you submit the transaction; you can also look up a transaction in an account’s transaction history with the account_tx command.

The transaction hash can be used as a “proof of payment” since anyone can look up the transaction by its hash to verify its final status.

Common Fields

Every transaction type has the same set of fundamental fields. Field names are case-sensitive. The common fields for all transactions are:

Field JSON Type Internal Type Description
Account String Account The unique address of the account that initiated the transaction.
AccountTxnID String Hash256 (Optional) Hash value identifying another transaction. This transaction is only valid if the sending account’s previously-sent transaction matches the provided hash.
Fee String Amount (Required, but auto-fillable) Integer amount of CSC, in drops, to be destroyed as a cost for distributing this transaction to the network.
Flags Unsigned Integer UInt32 (Optional) Set of bit-flags for this transaction.
LastLedgerSequence Number UInt32 (Optional, but strongly recommended) Highest ledger sequence number that a transaction can appear in.
Memos Array of Objects Array (Optional) Additional arbitrary information used to identify this transaction.
PreviousTxnID String Hash256 Use AccountTxnID instead.
Sequence Unsigned Integer UInt32 (Required, but auto-fillable) The sequence number, relative to the initiating account, of this transaction. A transaction is only valid if the Sequence number is exactly 1 greater than the last-valided transaction from the same account.
SigningPubKey String PubKey (Automatically added when signing) Hex representation of the public key that corresponds to the private key used to sign this transaction. If an empty string, indicates a multi-signature is present in the Signers field instead.
Signers Array Array (Optional) Array of objects that represent a multi-signature which authorizes this transaction.
SourceTag Unsigned Integer UInt32 (Optional) Arbitrary integer used to identify the reason for this payment, or a sender on whose behalf this transaction is made. Conventionally, a refund should specify the initial payment’s SourceTag as the refund payment’s DestinationTag.
TransactionType String UInt16 The type of transaction. Valid types include: PaymentAccountSetSetRegularKey, and SignerListSet.
TxnSignature String VariableLength (Automatically added when signing) The signature that verifies this transaction as originating from the account it says it is from.

Auto-fillable Fields

Some fields can be automatically filled in before the transaction is signed, either by a casinocoind server or by the library used for offline signing. Both casinocoin-libjs and casinocoind can automatically provide the following values:

  • Fee – Automatically fill in the transaction cost based on the network. (Note: casinocoind‘s sign command supports limits on how high the filled-in-value is, using the fee_mult_max parameter.)
  • Sequence – Automatically use the next sequence number for the account sending the transaction.

For a production system, we recommend not leaving these fields to be filled by the server. For example, if transaction costs become high due to a temporary spike in network load, you may want to wait for the cost to decrease before sending some transactions, instead of paying the temporarily-high cost.

The Paths field of the Payment transaction type can also be automatically filled in.

Transaction Cost

To protect the CSC Ledger from being disrupted by spam and denial-of-service attacks, each transaction must destroy a small amount of CSC. This transaction cost is designed to increase along with the load on the network, making it very expensive to deliberately or inadvertently overload the network.

The Fee field specifies an amount, in drops of CSC, to destroy as the cost for relaying this transaction. If the transaction is included in a validated ledger (whether or not it achieves its intended purpose), then the amount of CSC specified in the Fee parameter is destroyed forever. You can look up the transaction cost in advance, or let casinocoind set it automatically when you sign a transaction.

Note:Multi-signed transactions require additional fees to relay to the network.

Canceling or Skipping a Transaction

An important and intentional feature of the CSC Ledger is that a transaction is final as soon as it has been incorporated in a validated ledger.

However, if a transaction has not yet been included in a validated ledger, you can effectively cancel it by rendering it invalid. Typically, this means sending another transaction with the same Sequence value from the same account. If you do not want the replacement transaction to do anything, send an AccountSet transaction with no options.

For example, if you try to submit 3 transactions with sequence numbers 11, 12, and 13, but transaction 11 gets lost somehow or does not have a high enough transaction cost to be propagated to the network, then you can cancel transaction 11 by submitting an AccountSet transaction with no options and sequence number 11. This does nothing (except destroying the transaction cost for the new transaction 11), but it allows transactions 12 and 13 to become valid.

This approach is preferable to renumbering and resubmitting transactions 12 and 13, because it prevents transactions from being effectively duplicated under different sequence numbers.

In this way, an AccountSet transaction with no options is the canonical “no-op” transaction.


We strongly recommend that you specify the LastLedgerSequence parameter on every transaction. Provide a value of about 3 higher than the most recent ledger index to ensure that your transaction is either validated or rejected within a matter of seconds.

Without the LastLedgerSequence parameter, a transaction can become stuck in an undesirable state where it is neither validated nor rejected for a long time. Specifically, if the load-based transaction cost of the network increases after you send a transaction, your transaction may not get propagated enough to be included in a validated ledger, but you would have to pay the (increased) transaction cost to send another transaction canceling it. Later, if the transaction cost decreases again, the transaction can become included in a future ledger. The LastLedgerSequence places a hard upper limit on how long the transaction can wait to be validated or rejected.


The AccountTxnID field lets you chain your transactions together, so that a current transaction is not valid unless the previous one (by Sequence Number) is also valid and matches the transaction you expected.

One situation in which this is useful is if you have a primary system for submitting transactions and a passive backup system. If the passive backup system becomes disconnected from the primary, but the primary is not fully dead, and they both begin operating at the same time, you could potentially have serious problems like some transactions sending twice and others not at all. Chaining your transactions together with AccountTxnID ensures that, even if both systems are active, only one of them can submit valid transactions at a time.

To use AccountTxnID, you must first set the asfAccountTxnID flag, so that the ledger keeps track of the ID for the account’s previous transaction.


The Memos field includes arbitrary messaging data with the transaction. It is presented as an array of objects. Each object has only one field, Memo, which in turn contains another object with one or more of the following fields:

Field Type Internal Type Description
MemoData String VariableLength Arbitrary hex value, conventionally containing the content of the memo.
MemoFormat String VariableLength Hex value representing characters allowed in URLs. Conventionally containing information on how the memo is encoded, for example as a MIME type.
MemoType String VariableLength Hex value representing characters allowed in URLs. Conventionally, a unique relation (according to RFC 5988) that defines the format of this memo.

The MemoType and MemoFormat fields should only consist of the following characters: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=%

The Memos field is limited to no more than 1KB in size (when serialized in binary format).

Example of a transaction with a Memos field:

    "TransactionType": "Payment",
    "Account": "cMmTCjGFRWPz8S2zAUUoNVSQHxtRQD4eCx",
    "Destination": "c3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
    "Memos": [
            "Memo": {
                "MemoType": "687474703a2f2f6578616d706c652e636f6d2f6d656d6f2f67656e65726963",
                "MemoData": "72656e74"
    "Amount": "1"

Signers Field

The Signers field contains a multi-signature, which has signatures from up to 8 key pairs, that together should authorize the transaction. The Signers list is an array of objects, each with one field, Signer. The Signer field has the following nested fields:

Field Type Internal Type Description
Account String AccountID The address associated with this signature, as it appears in the SignerList.
TxnSignature String Blob A signature for this transaction, verifiable using the SigningPubKey.
SigningPubKey String PubKey The public key used to create this signature.

The SigningPubKey must be a key that is associated with the Account address. If the referenced Account is a funded account in the ledger, then the SigningPubKey can be that account’s current Regular Key if one is set. It could also be that account’s Master Key, unless the lsfDisableMaster flag is enabled. If the referenced Account address is not a funded account in the ledger, then the SigningPubKey must be the master key associated with that address.

Because signature verification is a compute-intensive task, multi-signed transactions cost additional CSC to relay to the network. Each signature included in the multi-signature increases the transaction cost required for the transaction. For example, if the current minimum transaction cost to relay a transaction to the network is 10000 drops, then a multi-signed transaction with 3 entries in the Signers array would need a Fee value of at least 40000 drops to relay.


The Flags field can contain various options that affect how a transaction should behave. The options are represented as binary values that can be combined with bitwise-or operations to set multiple flags at once.

Most flags only have meaning for a specific transaction type. The same bitwise value may be reused for flags on different transaction types, so it is important to pay attention to the TransactionType field when setting and reading flags.

The only flag that applies globally to all transactions is as follows:

Flag Name Hex Value Decimal Value Description
tfFullyCanonicalSig 0x80000000 2147483648 Require a fully-canonical signature, to protect a transaction from [transaction malleability] exploits.

Transaction Types

The type of a transaction (TransactionType field) is the most fundamental information about a transaction. This indicates what type of operation the transaction is supposed to do.

All transactions have certain fields in common:

Each transaction type has additional fields relevant to the type of action it causes:

Pseudo-Transactions that are not created and submitted in the usual way, but may be added to open ledgers according to ledger rules. They still must be approved by consensus to be included in a validated ledger. Pseudo-transactions have their own unique transaction types:


An AccountSet transaction modifies the properties of an account in the CSC Ledger. [Source]

Example AccountSet:

    "TransactionType": "AccountSet",
    "Account" : "cDarPNJEpCnpBZSfmcquydockkePkjPGA2",
    "Fee": "12",
    "Sequence": 5,
    "Domain": "6578616D706C652E636F6D",
    "SetFlag": 5,
    "MessageKey": "cQD4SqHJtDxn5DDL7xNnojNa3vxS1Jx5gv"
Field JSON Type Internal Type Description
ClearFlag Unsigned Integer UInt32 (Optional) Unique identifier of a flag to disable for this account.
Domain String VariableLength (Optional) The domain that owns this account, as a string of hex representing the ASCII for the domain in lowercase.
EmailHash String Hash128 (Optional) Hash of an email address to be used for generating an avatar image. Conventionally, clients use Gravatar to display this image.
MessageKey String PubKey (Optional) Public key for sending encrypted messages to this account.
SetFlag Unsigned Integer UInt32 (Optional) Integer flag to enable for this account.
TransferRate Unsigned Integer UInt32 (Optional) The fee to charge when users transfer this account’s issued currencies, represented as billionths of a unit. Cannot be more than 2000000000 or less than 1000000000, except for the special case 0 meaning no fee.
TickSize Unsigned Integer UInt8 (Optional) Tick size to use for offers involving a currency issued by this address. The exchange rates of those offers is rounded to this many significant digits. Valid values are 3 to 15 inclusive, or 0 to disable. (Requires the TickSize amendment.)
WalletLocator String Hash256 (Optional) Not used.
WalletSize Unsigned Integer UInt32 (Optional) Not used.

If none of these options are provided, then the AccountSet transaction has no effect (beyond destroying the transaction cost). See Canceling or Skipping a Transaction for more details.


The Domain field is represented as the hex string of the lowercase ASCII of the domain. For example, the domain would be represented as "6578616D706C652E636F6D".

To remove the Domain field from an account, send an AccountSet with the Domain set to an empty string.

Client applications can use the casinocoin.txt file hosted by the domain to confirm that the account is actually operated by that domain.

AccountSet Flags

There are several options which can be either enabled or disabled for an account. Account options are represented by different types of flags depending on the situation:

  • The AccountSet transaction type has several “AccountSet Flags” (prefixed asf) that can enable an option when passed as the SetFlag parameter, or disable an option when passed as the ClearFlag parameter.
  • The AccountSet transaction type has several transaction flags (prefixed tf) that can be used to enable or disable specific account options when passed in the Flags parameter. This style is discouraged. New account options do not have corresponding transaction (tf) flags.
  • The AccountRoot ledger object type has several ledger-specific-flags (prefixed lsf) which represent the state of particular account options within a particular ledger. Naturally, the values apply until a later ledger version changes them.

The preferred way to enable and disable Account Flags is using the SetFlag and ClearFlag parameters of an AccountSet transaction. AccountSet flags have names that begin with asf.

All flags are off by default.

The available AccountSet flags are:

Flag Name Decimal Value Corresponding Ledger Flag Description
asfRequireDest 1 lsfRequireDestTag Require a destination tag to send transactions to this account.
asfRequireAuth 2 lsfRequireAuth Require authorization for users to hold balances issued by this address. Can only be enabled if the address has no trust lines connected to it.
asfDisallowCSC 3 lsfDisallowCSC CSC should not be sent to this account. (Enforced by client applications, not by casinocoind)
asfDisableMaster 4 lsfDisableMaster Disallow use of the master key. Can only be enabled if the account has configured another way to sign transactions, such as a Regular Key or a Signer List.
asfAccountTxnID 5 (None) Track the ID of this account’s most recent transaction. Required for AccountTxnID
asfNoFreeze 6 lsfNoFreeze Permanently give up the ability to freeze individual trust lines or disable Global Freeze. This flag can never be disabled after being enabled.
asfGlobalFreeze 7 lsfGlobalFreeze Freeze all assets issued by this account.
asfDefaultCasinocoin 8 lsfDefaultCasinocoin Enable rippling on this account’s trust lines by default.

To enable the asfDisableMaster or asfNoFreeze flags, you must authorize the transaction by signing it with the master key. You cannot use a regular key or a multi-signature.

The following Transaction flags, specific to the AccountSet transaction type, serve the same purpose, but are discouraged:

Flag Name Hex Value Decimal Value Replaced by AccountSet Flag
tfRequireDestTag 0x00010000 65536 asfRequireDest (SetFlag)
tfOptionalDestTag 0x00020000 131072 asfRequireDest (ClearFlag)
tfRequireAuth 0x00040000 262144 asfRequireAuth (SetFlag)
tfOptionalAuth 0x00080000 524288 asfRequireAuth (ClearFlag)
tfDisallowCSC 0x00100000 1048576 asfDisallowCSC (SetFlag)
tfAllowCSC 0x00200000 2097152 asfDisallowCSC (ClearFlag)

Blocking Incoming Transactions

Incoming transactions with unclear purposes may be an inconvenience for financial institutions, who would have to recognize when a customer made a mistake, and then potentially refund accounts or adjust balances depending on the mistake. The asfRequireDest and asfDisallowCSC flags are intended to protect users from accidentally sending funds in a way that is unclear about the reason the funds were sent.

For example, a destination tag is typically used to identify which hosted balance should be credited when a financial institution receives a payment. If the destination tag is omitted, it may be unclear which account should be credited, creating a need for refunds, among other problems. By using the asfRequireDest tag, you can ensure that every incoming payment has a destination tag, which makes it harder for others to send you an ambiguous payment by accident.

You can protect against unwanted incoming payments for non-CSC currencies by not creating trust lines in those currencies. Since CSC does not require trust, the asfDisallowCSC flag is used to discourage users from sending CSC to an account. However, this flag is not enforced in casinocoind because it could potentially cause accounts to become unusable. (If an account did not have enough CSC to send a transaction that disabled the flag, the account would be completely unusable.) Instead, client applications should disallow or discourage CSC payments to accounts with the asfDisallowCSC flag enabled.


The TransferRate field specifies a fee to charge whenever counterparties transfer the currency you issue. See Transfer Fees for more information.

In casinocoind‘s WebSocket and JSON-RPC APIs, the TransferRate is represented as an integer, the amount that must be sent for 1 billion units to arrive. For example, a 20% transfer fee is represented as the value 1200000000. The value cannot be less than 1000000000. (Less than that would indicate giving away money for sending transactions, which is exploitable.) You can specify 0 as a shortcut for 1000000000, meaning no fee.


A Payment transaction represents a transfer of value from one account to another. (Depending on the path taken, this can involve additional exchanges of value, which occur atomically.) [Source]

Payments are also the only way to create accounts.

Example payment:

  "TransactionType" : "Payment",
  "Account" : "cDarPNJEpCnpBZSfmcquydockkePkjPGA2",
  "Destination" : "ca5nK24KXen9AHvsdFTKHSANinZseWnPcX",
  "Amount" : {
     "currency" : "USD",
     "value" : "1",
     "issuer" : "cDarPNJEpCnpBZSfmcquydockkePkjPGA2"
  "Fee": "12",
  "Flags": 2147483648,
  "Sequence": 2,
Field JSON Type Internal Type Description
Amount Currency Amount Amount The amount of currency to deliver. For non-CSC amounts, the nested field names MUST be lower-case. If the tfPartialPayment flag is set, deliver up to this amount instead.
Destination String Account The unique address of the account receiving the payment.
DestinationTag Unsigned Integer UInt32 (Optional) Arbitrary tag that identifies the reason for the payment to the destination, or a hosted recipient to pay.
InvoiceID String Hash256 (Optional) Arbitrary 256-bit hash representing a specific reason or identifier for this payment.
Paths Array of path arrays PathSet (Optional, auto-fillable) Array of payment paths to be used for this transaction. Must be omitted for CSC-to-CSC transactions.
SendMax Currency Amount Amount (Optional) Highest amount of source currency this transaction is allowed to cost, including transfer fees, exchange rates, and slippage. Does not include the CSC destroyed as a cost for submitting the transaction. For non-CSC amounts, the nested field names MUST be lower-case. Must be supplied for cross-currency/cross-issue payments. Must be omitted for CSC-to-CSC payments.
DeliverMin Currency Amount Amount (Optional) Minimum amount of destination currency this transaction should deliver. Only valid if this is a partial payment. For non-CSC amounts, the nested field names are lower-case.

Special issuer Values for SendMax and Amount

Most of the time, the issuer field of a non-CSC Currency Amount indicates a financial institution’s issuing address. However, when describing payments, there are special rules for the issuer field in the Amount and SendMax fields of a payment.

  • There is only ever one balance for the same currency between two addresses. This means that, sometimes, the issuer field of an amount actually refers to a counterparty that is redeeming issuances, instead of the address that created the issuances.
  • When the issuer field of the destination Amount field matches the Destination address, it is treated as a special case meaning “any issuer that the destination accepts.” This includes all addresses to which the destination has extended trust lines, as well as issuances created by the destination which are held on other trust lines.
  • When the issuer field of the SendMax field matches the source account’s address, it is treated as a special case meaning “any issuer that the source can use.” This includes creating new issuances on trust lines that other accounts have extended to the source account, and sending issuances the source account holds from other issuers.

Creating Accounts

The Payment transaction type is the only way to create new accounts in the CSC Ledger. To do so, send an amount of CSC that is equal or greater than the account reserve to a mathematically-valid account address that does not exist yet. When the Payment is processed, a new AccountRoot object is added to the ledger.

If you send an insufficient amount of CSC, or any other currency, the Payment fails.


If present, the Paths field must contain a path set – an array of path arrays. Each individual path represents one way value can flow from the sender to receiver through various intermediary accounts and order books. A single transaction can potentially use multiple paths, for example if the transaction exchanges currency using several different order books to achieve the best rate.

You must omit the Paths field for direct payments, including:

  • An CSC-to-CSC transfer.
  • A direct transfer on a trust line that connects the sender and receiver.

If the Paths field is provided, the server decides at transaction processing time which paths to use, from the provided set plus a default path (the most direct way possible to connect the specified accounts). This decision is deterministic and attempts to minimize costs, but it is not guaranteed to be perfect.

The Paths field must not be an empty array, nor an array whose members are all empty arrays.

For more information, see Paths.

Payment Flags

Transactions of the Payment type support additional values in the Flags field, as follows:

Flag Name Hex Value Decimal Value Description
tfNoDirectCasinocoin 0x00010000 65536 Do not use the default path; only use paths included in the Paths field. This is intended to force the transaction to take arbitrage opportunities. Most clients do not need this.
tfPartialPayment 0x00020000 131072 If the specified Amount cannot be sent without spending more than SendMax, reduce the received amount instead of failing outright. See Partial Payments for more details.
tfLimitQuality 0x00040000 262144 Only take paths where all the conversions have an input:output ratio that is equal or better than the ratio of Amount:SendMax. See Limit Quality for details.

Partial Payments

A partial payment allows a payment to succeed by reducing the amount received. Partial payments are useful for returning payments without incurring additional costs to oneself. However, partial payments can also be used to exploit integrations that naively assume the Amount field of a successful transaction always describes the exact amount delivered.

A partial payment is any Payment transaction with the tfPartialPayment flag enabled. A partial payment can be successful if it delivers any positive amount greater than or equal to its DeliverMin field (or any positive amount at all if DeliverMin is not specified) without sending more than the SendMax value.

The delivered_amount field of a payment’s metadata indicates the amount of currency actually received by the destination account.

For more information, see the full article on Partial Payments.

Limit Quality

The CSC Ledger defines the “quality” of a currency exchange as the ratio of the numeric amount in to the numeric amount out. For example, if you spend $2 USD to receive £1 GBP, then the “quality” of that exchange is 0.5.

The tfLimitQuality flag allows you to set a minimum quality of conversions that you are willing to take. This limit quality is defined as the destination Amount divided by the SendMax amount (the numeric amounts only, regardless of currency). When set, the payment processing engine avoids using any paths whose quality (conversion rate) is worse (numerically lower) than the limit quality.

By itself, the tfLimitQuality flag reduces the number of situations in which a transaction can succeed. Specifically, it rejects payments where some part of the payment uses an unfavorable conversion, even if the overall average average quality of conversions in the payment is equal or better than the limit quality. If a payment is rejected in this way, the transaction result is tecPATH_DRY.

Consider the following example. If I am trying to send you 100 Chinese Yuan (Amount = 100 CNY) for 20 United States dollars (SendMax = 20 USD) or less, then the limit quality is 5. Imagine one trader is offering ¥95 for $15 (a ratio of about 6.3 CNY per USD), but the next best offer in the market is ¥5 for $2 (a ratio of 2.5 CNY per USD). If I were to take both offers to send you 100 CNY, then it would cost me 17 USD, for an average quality of about 5.9.

Without the tfLimitQuality flag set, this transaction would succeed, because the $17 it costs me is within my specified SendMax. However, with the tfLimitQuality flag enabled, the transaction would fail instead, because the path to take the second offer has a quality of 2.5, which is worse than the limit quality of 5.

The tfLimitQuality flag is most useful when combined with partial payments. When both tfPartialPayment and tfLimitQuality are set on a transaction, then the transaction delivers as much of the destination Amount as it can, without using any conversions that are worse than the limit quality.

In the above example with a ¥95/$15 offer and a ¥5/$2 offer, the situation is different if my transaction has both tfPartialPayment and tfLimitQuality enabled. If we keep my SendMax of 20 USD and a destination Amount of 100 CNY, then the limit quality is still 5. However, because I am doing a partial payment, the transaction sends as much as it can instead of failing if the full destination amount cannot be sent. This means that my transaction consumes the ¥95/$15 offer, whose quality is about 6.3, but it rejects the ¥5/$2 offer because that offer’s quality of 2.5 is worse than the quality limit of 5. In the end, my transaction only delivers ¥95 instead of the full ¥100, but it avoids wasting money on poor exchange rates.


A SetRegularKey transaction changes the regular key associated with an address. [Source]

    "Flags": 0,
    "TransactionType": "SetRegularKey",
    "Account": "cDarPNJEpCnpBZSfmcquydockkePkjPGA2",
    "Fee": "12",
    "RegularKey": "cAR8rR8sUkBoCZFawhkWzY4Y5YoyuznwD"
Field JSON Type Internal Type Description
RegularKey String AccountID (Optional) A base-58-encoded CasinoCoin address to use as the regular key. If omitted, removes the existing regular key.

In addition to the master key, which is mathematically-related to an address, you can associate at most 1 additional key pair with an address using this type of transaction. The additional key pair is called a regular key. If your address has a regular key pair defined, you can use the secret key of the regular key pair to authorize transactions.

A regular key pair is generated in the same way as any other CasinoCoin keys (for example, with wallet_propose), but it can be changed. A master key pair is an intrinsic part of an address’s identity (the address is derived from the master public key). You can disable a master key but you cannot change it.

You can protect your master secret by using a regular key instead of the master key to sign transactions whenever possible. If your regular key is compromised, but the master key is not, you can use a SetRegularKey transaction to regain control of your address. In some cases, you can even send a key reset transaction without paying the transaction cost.

For even greater security, you can use multi-signing, but multi-signing requires additional CSC for the transaction cost and reserve.


The SignerListSet transaction creates, replaces, or removes a list of signers that can be used to multi-sign a transaction. This transaction type was introduced by the MultiSign amendment. [Source]

Example SignerListSet:

    "Flags": 0,
    "TransactionType": "SignerListSet",
    "Account": "cDarPNJEpCnpBZSfmcquydockkePkjPGA2",
    "Fee": "12",
    "SignerQuorum": 3,
    "SignerEntries": [
            "SignerEntry": {
                "Account": "csA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
                "SignerWeight": 2
            "SignerEntry": {
                "Account": "cUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
                "SignerWeight": 1
            "SignerEntry": {
                "Account": "caKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
                "SignerWeight": 1
Field JSON Type Internal Type Description
SignerQuorum Number UInt32 A target number for the signer weights. A multi-signature from this list is valid only if the sum weights of the signatures provided is greater than or equal to this value. To delete a SignerList, use the value 0.
SignerEntries Array Array (Omitted when deleting) Array of SignerEntry objects, indicating the addresses and weights of signers in this list. A SignerList must have at least 1 member and no more than 8 members. No address may appear more than once in the list, nor may the Account submitting the transaction appear in the list.

An account may not have more than one SignerList. A successful SignerListSet transaction replaces the existing SignerList, if one exists. To delete a SignerList, you must set SignerQuorum to 0 and omit the SignerEntries field. Otherwise, the transaction fails with the error temMALFORMED. A transaction to delete a SignerList is considered successful even if there was no SignerList to delete.

You cannot create a SignerList such that the SignerQuorum could never be met. The SignerQuorum must be greater than 0 but less than or equal to the sum of the SignerWeight values in the list. Otherwise, the transaction fails with the error temMALFORMED.

You can create, update, or remove a SignerList using the master key, regular key, or the current SignerList, if those methods of signing transactions are available.

You cannot remove the last method of signing transactions from an account. If an account’s master key is disabled (it has the lsfDisableMaster flag enabled) and the account does not have a Regular Key configured, then you cannot delete the SignerList from the account. Instead, the transaction fails with the error tecNO_ALTERNATIVE_KEY.


Pseudo-Transactions are never submitted by users, nor propagated through the network. Instead, a server may choose to inject them in a proposed ledger directly. If enough servers inject an equivalent pseudo-transaction for it to pass consensus, then it becomes included in the ledger, and appears in ledger data thereafter.

Some of the fields that are mandatory for normal transactions do not make sense for pseudo-transactions. In those cases, the pseudo-transaction has the following default values:

Field Default Value
Sequence 0
Fee 0
SigningPubKey “”
Signature “”


Tracks the progress of the amendment process for changes in transaction processing. This can indicate that a proposed amendment gained or lost majority approval, or that an amendment has been enabled.

Note:You cannot send a pseudo-transaction, but you may find one when processing ledgers.
Field JSON Type Internal Type Description
Amendment String Hash256 A unique identifier for the amendment. This is not intended to be a human-readable name. See Amendments for a list of known amendments.
LedgerSequence Number UInt32 The index of the ledger version where this amendment appears. This distinguishes the pseudo-transaction from other occurrences of the same change.

EnableAmendment Flags

The Flags value of the EnableAmendment pseudo-transaction indicates the status of the amendment at the time of the ledger including the pseudo-transaction.

Flags value of 0 (no flags) indicates that the amendment has been enabled, and applies to all ledgers afterward. Other Flags values are as follows:

Flag Name Hex Value Decimal Value Description
tfGotMajority 0x00010000 65536 Support for this amendment increased to at least 80% of trusted validators starting with this ledger version.
tfLostMajority 0x00020000 131072 Support for this amendment decreased to less than 80% of trusted validators starting with this ledger version.


A change in transaction cost or account reserve requirements as a result of Fee Voting.

You cannot send a pseudo-transaction, but you may find one when processing ledgers.
    "Account": "rrrrrrrrrrrrrrrrrrrrrhoLvTp",
    "BaseFee": "000000000000000A",
    "Fee": "0",
    "ReferenceFeeUnits": 10,
    "ReserveBase": 20000000,
    "ReserveIncrement": 5000000,
    "Sequence": 0,
    "SigningPubKey": "",
    "TransactionType": "SetFee",
    "date": 439578860,
    "hash": "1C15FEA3E1D50F96B6598607FC773FF1F6E0125F30160144BE0C5CBC52F5151B",
    "ledger_index": 3721729,
Field JSON Type Internal Type Description
BaseFee String UInt64 The charge, in drops of CSC, for the reference transaction, as hex. (This is the transaction cost before scaling for load.)
ReferenceFeeUnits Unsigned Integer UInt32 The cost, in fee units, of the reference transaction
ReserveBase Unsigned Integer UInt32 The base reserve, in drops
ReserveIncrement Unsigned Integer UInt32 The incremental reserve, in drops
LedgerSequence Number UInt32 The index of the ledger version where this pseudo-transaction appears. This distinguishes the pseudo-transaction from other occurrences of the same change.

Transaction Results

Immediate Response

The response from the submit command contains a provisional result from the casinocoind server indicating what happened during local processing of the transaction.

The response from submit contains the following fields:

Field Value Description
engine_result String A code that categorizes the result, such as tecPATH_DRY
engine_result_code Signed Integer A number that corresponds to the engine_result, although exact values are subject to change.
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:

 "engine_result": "tesSUCCESS",
    "engine_result_code": 0,
    "engine_result_message": "The transaction was applied. Only final in a validated ledger."

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.

Looking up Transaction Results

To see the final result of a transaction, use the tx commandaccount_tx command, or other response from casinocoind. Look for "validated": true to indicate that this response uses a ledger version that has been validated by consensus.

Field Value Description
meta.TransactionResult String A code that categorizes the result, such as tecPATH_DRY
validated Boolean Whether or not this result comes from a validated ledger. If false, then the result is provisional. If true, then the result is final.
  "hash": "E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7",
    "meta": {
      "TransactionResult": "tesSUCCESS"
    "validated": true

Result Categories

Both the engine_result and the meta.TransactionResult use standard codes to identify the results of transactions, as follows:

Category Prefix Description
Local error tel The casinocoind 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.
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.
Retry ter The transaction could not be applied, but it might be possible to apply later.
Success tes (Not an error) The transaction succeeded. This result only final in a validated ledger.
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.

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 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.

Claimed Cost Justification

Although it may seem unfair to charge a transaction cost for a failed transaction, the tec class of errors exists for good reasons:

  • Transactions submitted after the failed one do not have to have their Sequence values renumbered. Incorporating the failed transaction into a ledger uses up the transaction’s sequence number, preserving the expected sequence.
  • Distributing the transaction throughout the network increases network load. Enforcing a cost makes it harder for attackers to abuse the network with failed transactions.
  • The transaction cost is generally very small in real-world value, so it should not harm users unless they are sending large quantities of transactions.

Finality of Results

The order in which transactions apply to the consensus ledger is not final until a ledger is closed and the exact transaction set is approved by the consensus process. A transaction that succeeded initially could still fail, and a transaction that failed initially could still succeed. Additionally, a transaction that was rejected by the consensus process in one round could achieve consensus in a later round.

A validated ledger can include successful transactions (tes result codes) as well as failed transactions (tec result codes). No transaction with any other result is included in a ledger.

For any other result code, it can be difficult to determine if the result is final. The following table summarizes when a transaction’s outcome is final, based on the result code from submitting the transaction:

Error Code Finality
tesSUCCESS Final when included in a validated ledger
Any tec code Final when included in a validated ledger
Any tem code Final unless the protocol changes to make the transaction valid
tefPAST_SEQ Final when another transaction with the same sequence number is included in a validated ledger
tefMAX_LEDGER Final when a validated ledger has a sequence number higher than the transaction’s LastLedgerSequence field, and no validated ledger includes the transaction

Any other transaction result is potentially not final. In that case, the transaction could still succeed or fail later, especially if conditions change such that the transaction is no longer prevented from applying. For example, trying to send a non-CSC currency to an account that does not exist yet would fail, but it could succeed if another transaction sends enough CSC to create the destination account. A server might even store a temporarily-failed, signed transaction and then successfully apply it later without asking first.

Understanding Transaction Metadata

The metadata section of a transaction includes detailed information about all the changes to the shared CSC Ledger that the transaction caused. This is true of any transaction that gets included in a ledger, whether or not it is successful. Naturally, the changes are only final if the transaction is validated.

Some fields that may appear in transaction metadata include:

Field Value Description
AffectedNodes Array List of ledger objects that were created, deleted, or modified by this transaction, and specific changes to each.
DeliveredAmount Currency Amount DEPRECATED. Replaced by delivered_amount. Omitted if not a partial payment.
TransactionIndex Unsigned Integer The transaction’s position within the ledger that included it. (For example, the value 2 means it was the 2nd transaction in that ledger.)
TransactionResult String result code indicating whether the transaction succeeded or how it failed.
delivered_amount Currency Amount The Currency Amount actually received by the Destination account. Use this field to determine how much was delivered, regardless of whether the transaction is a partial payment.


The Amount of a Payment transaction indicates the amount to deliver to the Destination, so if the transaction was successful, then the destination received that much — except if the transaction was a partial payment. (In that case, any positive amount up to Amount might have arrived.) Rather than choosing whether or not to trust the Amount field, you should use the delivered_amount field of the metadata to see how much actually reached its destination.

The delivered_amount field of transaction metadata is included in all successful Payment transactions, and is formatted like a normal currency amount. However, the delivered amount is not available for transactions that meet both of the following criteria:

  • Is a partial payment, and
  • Included in a validated ledger before 2014-01-20

If both conditions are true, then delivered_amount contains the string value unavailable instead of an actual amount. If this happens, you can only figure out the actual delivered amount by reading the AffectedNodes in the transaction’s metadata.

See also: Partial Payments

Full Transaction Response List

tel Codes


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 -399 to -300. The exact code for any given error is subject to change, so don’t rely on it.

Code Explanation
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 too long.
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 CSC 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.
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.
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.
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.
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.
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.
telLOCAL_ERROR Unspecified local error.
telNO_DST_PARTIAL The transaction is an CSC payment that would fund a new account, but the tfPartialPayment flag was enabled. This is disallowed.

tem Codes

These codes indicate that the transaction was malformed, and cannot succeed according to the CSC Ledger protocol. They have numerical values in the range -299 to -200. The exact code for any given error is subject to change, so don’t rely on it.

Code Explanation
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 for the correct format.
temBAD_EXPIRATION The transaction improperly specified an expiration value. Alternatively, the transaction did not specify a required expiration value.
temBAD_FEE The transaction improperly specified its Fee value, for example by listing a non-CSC currency or some negative amount of CSC.
temBAD_ISSUER The transaction improperly specified the issuer field of some currency included in the request.
temBAD_PATH The Payment transaction specifies one or more Paths improperly, for example including an issuer for CSC, 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_CSC_LIMIT The Payment transaction used the tfLimitQuality flag in a direct CSC-to-CSC payment, even though CSC-to-CSC payments do not involve any conversions.
temBAD_SEND_CSC_MAX The Payment transaction included a SendMax field in a direct CSC-to-CSC payment, even though sending CSC should never require SendMax. (CSC is only valid in SendMax if the destination Amount is not CSC.)
temBAD_SEND_CSC_NO_DIRECT The Payment transaction used the tfNoDirectCasinocoin flag for a direct CSC-to-CSC payment, even though CSC-to-CSC payments are always direct.
temBAD_SEND_CSC_PARTIAL The Payment transaction used the tfPartialPayment flag for a direct CSC-to-CSC payment, even though CSC-to-CSC payments should always deliver the full amount.
temBAD_SEND_CSC_PATHS The Payment transaction included Paths while sending CSC, even though CSC-to-CSC 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.
temDST_NEEDED The transaction improperly omitted a destination. This could be the Destination field of a Payment 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_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.
temCASINOCOIN_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.

tef Codes

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 -199 to -100. The exact code for any given error is subject to change, so don’t rely on it.

Code Explanation
tefALREADY The same exact transaction has already been applied.
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 While processing the transaction, the ledger was discovered in an unexpected state. If you can reproduce this error, please report an issue to get it fixed.
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.
tefEXCEPTION 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 report an issue to get it fixed.
tefFAILURE Unspecified failure in applying the transaction.
tefINTERNAL When trying to apply the transaction, the server entered an unexpected state. If you can reproduce this error, please report an issue to get it fixed.
tefINVARIANT_FAILED An invariant check failed when trying to claim the transaction cost. Requires the EnforceInvariants amendment. If you can reproduce this error, please report an issue.
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.
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.
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.

ter Codes

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 -99 to -1. The exact code for any given error is subject to change, so don’t rely on it.

Code Explanation
terINSUF_FEE_B The account sending the transaction does not have enough CSC 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_casinocoin 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.
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.

tes Success

The code tesSUCCESS is the only code that indicates a transaction succeeded. This does not always mean it did what it was supposed to do. Success uses the numerical value 0.

Code Explanation
tesSUCCESS The transaction was applied and forwarded to other servers. If this appears in a validated ledger, then the transaction’s success is final.

tec Codes

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. The exact codes sometimes appear in ledger data, so they do not change, but we recommend not relying on the numeric value regardless.

Code Value Explanation
tecCLAIM 100 Unspecified failure, with transaction cost destroyed.
tecDIR_FULL 121 The address sending the transaction cannot own any more objects in the ledger.
tecDST_TAG_NEEDED 143 The Payment transaction omitted a destination tag, but the destination account has the lsfRequireDestTag flag enabled.
tecFAILED_PROCESSING 105 An unspecified error occurred when processing the transaction.
tecINSUF_RESERVE_LINE 122 The transaction failed because the sending account does not have enough CSC 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 CSC to create a new Offer. (See: Reserves)
tecINSUFFICIENT_RESERVE 141 The transaction would increase the reserve requirement higher than the sending account’s balance. SignerListSet can return this error code. See SignerLists and Reserves for more information.
tecINTERNAL 144 Unspecified internal error, with transaction cost applied. This error code should not normally be returned. If you can reproduce this error, please report an issue.
tecINVARIANT_FAILED 147 An invariant check failed when trying to execute this transaction. Requires the EnforceInvariants amendment. If you can reproduce this error, please report an issue.
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.
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 casinocoind 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 CSC.)
tecNO_DST_INSUF_CSC 125 The account on the receiving end of the transaction does not exist, and the transaction is not sending enough CSC to create it.
tecNO_ENTRY 140 Reserved for future use.
tecNO_ISSUER 133 The account specified in the issuer field of a currency amount does not exist.
tecNO_LINE_INSUF_RESERVE 126 The transaction failed because the sending account does not have enough CSC 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.
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_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. Alternatively, the destination account has asfDisallowCSC set.
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.
tecOWNERS 132 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.
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.
tecUNFUNDED 129 The transaction failed because the account does not hold enough CSC to pay the amount in the transaction and satisfy the additional reserve necessary to execute this transaction. (See: Reserves)
tecUNFUNDED_PAYMENT 104 The transaction failed because the sending account is trying to send more CSC than it holds, not counting the reserve. (See: Reserves)