Look Up Transaction Results

To use the XRP Ledger effectively, you need to be able to understand transaction outcomes: did the transaction succeed? What did it do? If it failed, why?

The XRP Ledger is a shared system, with all data recorded publicly and carefully, securely updated with each new ledger version. Anyone can look up the exact outcome of any transaction and read the transaction metadata to see what it did.

This document describes, at a low level, how to know why a transaction reached the outcome it did. For an end-user, it is easier to look at a processed view of a transaction. For example, you can use XRP Charts to get an English-language description of any recorded transaction.

Prerequisites

To understand the outcome of a transaction as described in these instructions, you must:

Know which transaction you want to understand. If you know the transaction's identifying hash, you can look it up that way. You can also look at transactions that executed in a recent ledger or the transactions that most recently affected a given account.
Have access to a rippled server that provides reliable information and has the necessary history for when the transaction was submitted.
- For looking up the outcomes of transactions you've recently submitted, the server you submitted through should be enough, as long as it maintains sync with the network during that time.
- For outcomes of older transactions, you may want to use a full-history server.

Tip

There are other ways of querying for data on transactions from the XRP Ledger, including the Data API and other exported databases, but those interfaces are non-authoritative. This document describes how to look up data using the rippled API directly, for the most direct and authoritative results possible.

1. Get Transaction Status

Knowing whether a transaction succeeded or failed is a two-part question:

Was the transaction included in a validated ledger?
If so, what changes to the ledger state occurred as a result?

To know whether a transaction was included in a validated ledger, you usually need access to all the ledgers it could possibly be in. The simplest, most foolproof way to do this is to look up the transaction on a full history server. Use the tx method, account_tx method, or other response from rippled. Look for "validated": true to indicate that this response uses a ledger version that has been validated by consensus.

If the result does not have "validated": true, then the result may be tentative and you must wait for the ledger to be validated to know if the transaction's outcome is final.
If the result does not contain the transaction in question, or returns the error txnNotFound, then the transaction is not in any ledger that the server has in its available history. This may or may not mean that the transaction failed, depending on whether the transaction could be in a validated ledger version that the server does not have and whether it could be included in a future validated ledger. You can constrain the range of ledgers a transaction can be in by knowing:
- The earliest ledger the transaction could be in, which is the first ledger to be validated after the transaction was first submitted.
- The last ledger the transaction could be in, which is defined by the transaction's LastLedgerSequence field.

The following example shows a successful transaction, as returned by the tx method, which is in a validated ledger version. The order of the fields in the JSON response has been rearranged, with some parts omitted, to make it easier to understand:

{
  "TransactionType": "AccountSet",
  "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
  "Sequence": 376,
  "hash": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567",

  ... (omitted) ...

  "meta": {
    "AffectedNodes": [
      ... (omitted) ...
    ],
    "TransactionResult": "tesSUCCESS"
  },
  "ledger_index": 46447423,
  "validated": true
}

This example shows an AccountSet transaction sent by the account with address rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn, using Sequence number 376. The transaction's identifying hash is 017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567 and its result is tesSUCCESS. The transaction was included in ledger version 46447423, which has been validated, so these results are final.

Case: Not Included in a Validated Ledger

If a transaction is not included in a validated ledger, it cannot possibly have had any effect on the shared XRP Ledger state. If the transaction's failure to be included in a ledger is final, then it cannot have any future effect, either.

If the transaction's failure is not final, it may still become included in a future validated ledger. You can use the provisional results of applying the transaction to the current open ledger as a preview of the likely effects the transaction may have in a final ledger, but those results can change due to many factors.

Case: Included in a Validated Ledger

If the transaction is included in a validated ledger, then the transaction metadata contains a full report of all changes that were made to the ledger state as a result of processing the transaction. The metadata's TransactionResult field contains a transaction result code that summarizes the outcome:

The code tesSUCCESS indicates that the transaction was, more or less, successful.
A tec-class code indicates that the transaction failed, and its only effects on the ledger state are to destroy the XRP transaction cost and possibly perform some bookkeeping like removing expired Offers and closed payment channels.
No other code can appear in any ledger.

The result code is only a summary of the transaction's outcome. To understand in more detail what the transaction did, you must read the rest of the metadata in context of the transaction's instructions and the ledger state before the transaction executed.

2. Interpret Metadata

Transaction metadata describes exactly how the transaction was applied to the ledger, including the following fields:

Field	Value	Description
`AffectedNodes`	Array	List of ledger entries that were created, deleted, or modified by this transaction, and specific changes to each.
`DeliveredAmount`	Currency Amount	(May be omitted) For a partial payment, this field records the amount of currency actually delivered to the destination. To avoid errors when reading transactions, instead use the `delivered_amount` field, which is provided for all Payment transactions, partial or not.
`TransactionIndex`	Unsigned Integer	The transaction's position within the ledger that included it. This is zero-indexed. (For example, the value `2` means it was the 3rd transaction in that ledger.)
`TransactionResult`	String	A result code indicating whether the transaction succeeded or how it failed.
`delivered_amount`	Currency Amount	(Omitted for non-Payment transactions) The amount of currency actually received by the `Destination` account. Use this field to determine how much was delivered, regardless of whether the transaction is a partial payment. See this description for details.

Most of the metadata is contained in the AffectedNodes array. What to look for in this array depends on the type of transaction. Almost every transaction modifies the sender's AccountRoot object to destroy the XRP transaction cost and increase the account's Sequence number.

Info: One exception to this rule is for pseudo-transactions, which aren't sent from a real account and thus do not modify an AccountRoot object. There are other exceptions that modify an AccountRoot object without changing its Balance field: free key reset transactions do not change the sender's XRP balance; and in the unlikely scenario that a transaction causes an account to receive exactly as much XRP as it destroys, the account's Balance shows no net change. (The net decrease in XRP occurs elsewhere in the metadata, debited from wherever the account sent the XRP.)

This example shows the full response from step 1 above. See if you can figure out what changes it made to the ledger:

{
  "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
  "Fee": "12",
  "Flags": 2147483648,
  "LastLedgerSequence": 46447424,
  "Sequence": 376,
  "SigningPubKey": "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB",
  "TransactionType": "AccountSet",
  "TxnSignature": "30450221009B2910D34527F4EA1A02C375D5C38CF768386ACDE0D17CDB04C564EC819D6A2C022064F419272003AA151BB32424F42FC3DBE060C8835031A4B79B69B0275247D5F4",
  "date": 608257201,
  "hash": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567",
  "inLedger": 46447423,
  "ledger_index": 46447423,
  "meta": {
    "AffectedNodes": [
      {
        "ModifiedNode": {
          "LedgerEntryType": "AccountRoot",
          "LedgerIndex": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8",
          "FinalFields": {
            "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
            "AccountTxnID": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567",
            "Balance": "396015164",
            "Domain": "6D64756F31332E636F6D",
            "EmailHash": "98B4375E1D753E5B91627516F6D70977",
            "Flags": 8519680,
            "MessageKey": "0000000000000000000000070000000300",
            "OwnerCount": 9,
            "Sequence": 377,
            "TransferRate": 4294967295
          },
          "PreviousFields": {
            "AccountTxnID": "E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF",
            "Balance": "396015176",
            "Sequence": 376
          },
          "PreviousTxnID": "E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF",
          "PreviousTxnLgrSeq": 46447387
        }
      }
    ],
    "TransactionIndex": 13,
    "TransactionResult": "tesSUCCESS"
  },
  "validated": true
}

The only changes made by this no-op transaction are to update the AccountRoot object representing the sender's account in the following ways:

The Sequence value increases from 376 to 377.
The XRP Balance in this account changes from 396015176 to 396015164 drops of XRP. This decrease of exactly 12 drops represents the transaction cost, as specified in the Fee field of the transaction.
The AccountTxnID changes to show that this transaction is now the one most recently sent from this address.
The previous transaction to affect this account was the transaction E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF, which executed in ledger version 46447387, as specified in the PreviousTxnID and PreviousTxnLgrSeq fields. (This may be useful if you want to walk backwards through the account's transaction history.)
Note
Although the metadata does not explicitly show it, any time a transaction modifies a ledger object, it updates that object's PreviousTxnID and PreviousTxnLgrSeq fields with the current transaction's information. If the same sender has multiple transactions in a single ledger version, each one after the first provides a PreviousTxnLgrSeq whose value is the ledger index of the ledger version that included all those transactions.

Since the ModifiedNode entry for rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn's account is the only object in the AffectedNodes array, no other changes were made to the ledger as a result of this transaction.

Tip

If the transaction sends or receives XRP, the sender's balance changes are combined with the transaction cost, resulting in a single change to the Balance field in the net amount. For example, if you sent 1 XRP (1,000,000 drops) and destroyed 10 drops for the transaction cost, the metadata shows your Balance decreasing by 1,000,010 drops of XRP.

General-Purpose Bookkeeping

Almost any transaction can result in the following types of changes:

Sequence and Transaction Cost changes: As mentioned, every transaction (excluding pseudo-transactions) modifies the sender's AccountRoot object to increase the sender's sequence number and destroy the XRP used to pay the transaction cost.
Account Threading: Some transactions that create objects also modify the AccountRoot object of an intended recipient or destination account to indicate that something relating to that account changed. This technique of "tagging" an account changes only that object's PreviousTxnID and PreviousTxnLgrSeq fields. This makes it more efficient to look up an account's transaction history by following the "thread" of transactions mentioned in these fields.
Directory Updates: Transactions that create or remove ledger objects often make changes to DirectoryNode objects to track which objects exist. Also, when a transaction adds an object that counts towards an account's owner reserve, it increases the OwnerCount of the owner's AccountRoot object. Removing an object decreases the OwnerCount. This is how the XRP Ledger tracks how much owner reserve each account owes at any point in time.

Example of increasing an Account's OwnerCount:

{
  "ModifiedNode": {
    "FinalFields": {
      "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
      "Balance": "9999999990",
      "Flags": 0,
      "OwnerCount": 1,
      "Sequence": 2
    },
    "LedgerEntryType": "AccountRoot",
    "LedgerIndex": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05",
    "PreviousFields": {
      "Balance": "10000000000",
      "OwnerCount": 0,
      "Sequence": 1
    },
    "PreviousTxnID": "B24159F8552C355D35E43623F0E5AD965ADBF034D482421529E2703904E1EC09",
    "PreviousTxnLgrSeq": 16154
  }
}

Many transaction types create or modify DirectoryNode objects. These objects are for bookkeeping: tracking all objects attached to an account, or all exchange Offers at the same exchange rate. If the transaction created new objects in the ledger, it may need to add entries to an existing DirectoryNode object, or add another DirectoryNode object to represent another page of the directory. If the transaction removed objects from the ledger, it may delete one or more DirectoryNode objects that are no longer needed.

Example of a CreatedNode representing a new Offer Directory:

{
  "CreatedNode": {
    "LedgerEntryType": "DirectoryNode",
    "LedgerIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
    "NewFields": {
      "ExchangeRate": "4E11C37937E08000",
      "RootIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
      "TakerPaysCurrency": "0000000000000000000000004254430000000000",
      "TakerPaysIssuer": "5E7B112523F68D2F5E879DB4EAC51C6698A69304"
    }
  }
},

Other things to look for when processing transaction metadata depend on the transaction type.

Payments

A Payment transaction can represent a direct XRP-to-XRP transaction, a cross-currency payment, or a direct transaction of a fungible token. Anything other than a direct XRP-to-XRP transaction can be a partial payment, including token-to-XRP or XRP-to-token transactions.

XRP amounts are tracked in the Balance field of AccountRoot objects. (XRP can also exist in Escrow objects and PayChannel objects, but Payment transactions cannot affect those.)

You should always use the delivered_amount field to see how much a payment delivered.

If the payment contains a CreatedNode with "LedgerEntryType": "AccountRoot", that means the payment funded a new account in the ledger.

Token Payments

Payments involving tokens are a bit more complicated.

All changes in token balances are reflected in RippleState objects, which represent trust lines. An increase to one party's balance on a trust line is considered to decrease the counterparty's balance by equal amount; in the metadata, this is only recorded as a single change to the shared Balance for the RippleState object. Whether this change is recorded as an "increase" or "decrease" depends on which account has the numerically higher address.

A single payment may go across a long path consisting of several trust lines and order books. The process of changing the balances on several trust lines to connect parties indirectly is called rippling. Depending on the issuer specified in the transaction's Amount field, it is also possible that the amount delivered may be split between several trust lines (RippleState accounts) connected to the destination account.

Tip

The order that modified objects are presented in the metadata does not necessarily match the order those objects were visited while processing a payment. To better understand payment execution, it may help to reorder AffectedNodes members to reconstruct the paths the funds took through the ledger.

Cross-currency payments consume Offers in part or entirely to change between different currency codes and issuers. If a transaction shows DeletedNode objects for Offer types, that can indicate an Offer that was fully consumed, or an Offer that was found to be expired or unfunded at the time of processing. If a transaction shows a ModifiedNode of type Offer, that indicates an Offer that was partially consumed.

The QualityIn and QualityOut settings of trust lines can affect how one side of a trust line values the token, so that the numeric change in balances is different from how the sender values that token. The delivered_amount shows how much was delivered as valued by the recipient.

If the amount to be sent or received is outside of the token precision, it is possible that one side may be debited for an amount that is rounded to nothing on the other side of the transaction. As a result, when two parties transact while their balances are different by a factor of 10¹⁶, it is possible that rounding may effectively "create" or "destroy" small amounts of the token. (XRP is never rounded, so this is not possible with XRP.)

Depending on the length of the paths, the metadata for cross-currency payments can be long. For example, transaction 8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B delivered 2.788 GCB issued by rHaaans..., spending XRP but passing through USD from 2 issuers, paying XRP to 2 accounts, removing an unfunded offer from r9ZoLsJ... to trade EUR for ETH, plus bookkeeping for a total of 17 different ledger objects modified.

Offers

An OfferCreate transaction may or may not create an object in the ledger, depending on how much was matched and whether the transaction used flags such as tfImmediateOrCancel. Look for a CreatedNode entry with "LedgerEntryType": "Offer" to see if the transaction added a new Offer to the ledger's order books. For example:

{
  "CreatedNode": {
    "LedgerEntryType": "Offer",
    "LedgerIndex": "F39B13FA15AD2A345A9613934AB3B5D94828D6457CCBB51E3135B6C44AE4BC83",
    "NewFields": {
      "Account": "rETSmijMPXT9fnDbLADZnecxgkoJJ6iKUA",
      "BookDirectory": "CA462483C85A90DB76D8903681442394D8A5E2D0FFAC259C5B0C59269BFDDB2E",
      "Expiration": 608427156,
      "Sequence": 1082535,
      "TakerGets": {
        "currency": "EUR",
        "issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq",
        "value": "2157.825"
      },
      "TakerPays": "7500000000"
    }
  }
}

A ModifiedNode of type Offer indicates an Offer that was matched and partially consumed. A single transaction can consume a large number of Offers. An Offer to trade two tokens might also consume Offers to trade XRP because of auto-bridging. All or part of an exchange can be auto-bridged.

A DeletedNode of type Offer can indicate a matching Offer that was fully consumed, an Offer that was found to be expired or unfunded at the time of processing, or an Offer that was canceled as part of placing a new Offer. You can recognize a canceled Offer because the Account that placed it is the sender of the transaction that deleted it.

Example of a deleted Offer:

{
  "DeletedNode": {
    "FinalFields": {
      "Account": "rETSmijMPXT9fnDbLADZnecxgkoJJ6iKUA",
      "BookDirectory": "CA462483C85A90DB76D8903681442394D8A5E2D0FFAC259C5B0C595EDE3E1EE9",
      "BookNode": "0000000000000000",
      "Expiration": 608427144,
      "Flags": 0,
      "OwnerNode": "0000000000000000",
      "PreviousTxnID": "0CA50181C1C2A4D45E9745F69B33FA0D34E60D4636562B9D9CDA1D4E2EFD1823",
      "PreviousTxnLgrSeq": 46493676,
      "Sequence": 1082533,
      "TakerGets": {
        "currency": "EUR",
        "issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq",
        "value": "2157.675"
      },
      "TakerPays": "7500000000"
    },
    "LedgerEntryType": "Offer",
    "LedgerIndex": "9DC99BF87F22FB957C86EE6D48407201C87FBE623B2F1BC4B950F83752B55E27"
  }
}

Offers can create, delete, and modify both types of DirectoryNode objects, to keep track of who placed which Offers and which Offers are available at which exchange rates. Generally, users don't need to pay close attention to this bookkeeping.

An OfferCancel transaction may have the code tesSUCCESS even if there was no Offer to delete. Look for a DeletedNode of type Offer to confirm that the transaction actually deleted an Offer. If not, the Offer may already have been removed by a previous transaction, or the OfferCancel transaction may have used the wrong sequence number in the OfferSequence field.

If an OfferCreate transaction shows a CreatedNode of type RippleState, that indicates that the Offer created a trust line to hold a token received in the trade.

Escrows

A successful EscrowCreate transaction creates an Escrow object in the ledger. Look for a CreatedNode entry of type Escrow. The NewFields should show an Amount equal to the amount of XRP escrowed, and other properties as specified.

A successful EscrowCreate transaction also debits the same amount of XRP from the sender. Look for a ModifiedNode of type AccountRoot, where the Account in the final fields matches the address from the Account in the transaction instructions. The Balance should show the decrease in XRP due to the escrowed XRP (and the XRP destroyed to pay the transaction cost).

A successful EscrowFinish transaction modifies the AccountRoot of the recipient to increase their XRP balance (in the Balance field), deletes the Escrow object, and reduces the owner count of the escrow creator. Since the escrow's creator, recipient, and finisher may all be different accounts or the same, this can result in one to three ModifiedNode objects of type AccountRoot. A successful EscrowCancel transaction is very similar, except it sends the XRP back to the original creator of the escrow.

Of course, an EscrowFinish can only be successful if it meets the conditions of the escrow, and an EscrowCancel can only be successful if the expiration of the Escrow object is before the close time of the previous ledger.

Escrow transactions also do normal bookkeeping for adjusting the sender's owner reserve and the directories of the accounts involved.

In the following excerpt, we see that r9UUEX...'s balance increases by 1 billion XRP and its owner count decreases by 1 because an escrow from that account to itself finished successfully. The Sequence number does not change because a third party completed the escrow:

{
  "ModifiedNode": {
    "FinalFields": {
      "Account": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp",
      "Balance": "1650000199898000",
      "Flags": 1048576,
      "OwnerCount": 11,
      "Sequence": 23
    },
    "LedgerEntryType": "AccountRoot",
    "LedgerIndex": "13FDBC39E87D9B02F50940F9FDDDBFF825050B05BE7BE09C98FB05E49DD53FCA",
    "PreviousFields": {
      "Balance": "650000199898000",
      "OwnerCount": 12
    },
    "PreviousTxnID": "D853342BC27D8F548CE4D7CB688A8FECE3229177790453BA80BC79DE9AAC3316",
    "PreviousTxnLgrSeq": 41005507
  }
},
{
  "DeletedNode": {
    "FinalFields": {
      "Account": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp",
      "Amount": "1000000000000000",
      "Destination": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp",
      "FinishAfter": 589075200,
      "Flags": 0,
      "OwnerNode": "0000000000000000",
      "PreviousTxnID": "D5FB1C7D18F931A4FBFA468606220560C17ADF6DE230DA549F4BD11A81F19DFC",
      "PreviousTxnLgrSeq": 35059548
    },
    "LedgerEntryType": "Escrow",
    "LedgerIndex": "62F0ABB58C874A443F01CDCCA18B12E6DA69C254D3FB17A8B71CD8C6C68DB74D"
  }
},

Payment Channels

Look for a CreatedNode of type PayChannel when creating a payment channel. You should also find a ModifiedNode of type AccountRoot showing the decrease in the sender's balance. Look for an Account field in the FinalFields to confirm that the address matches the sender, and look at the difference in the Balance fields to see the change in XRP balance.

The metadata also lists the newly-created payment channel in the destination's owner directory. This prevents an account from being deleted if it is the destination of an open payment channel. (This behavior was added by the fixPayChanRecipientOwnerDir amendment.)

There are several ways to request to close a payment channel, aside from the immutable CancelAfter time of the channel (which is only set on creation). If a transaction schedules a channel to close, there is a ModifiedNode entry of type PayChannel for the channel, with the newly-added close time in the Expiration field of the FinalFields. The following example shows the changes to a PayChannel in a case where the sender requested to close the channel without redeeming a claim:

{
  "ModifiedNode": {
    "FinalFields": {
      "Account": "rNn78XpaTXpgLPGNcLwAmrcS8FifRWMWB6",
      "Amount": "1000000",
      "Balance": "0",
      "Destination": "rwWfYsWiKRhYSkLtm3Aad48MMqotjPkU1F",
      "Expiration": 608432060,
      "Flags": 0,
      "OwnerNode": "0000000000000002",
      "PublicKey": "EDEACA57575C6824FC844B1DB4BF4AF2B01F3602F6A9AD9CFB8A3E47E2FD23683B",
      "SettleDelay": 3600,
      "SourceTag": 1613739140
    },
    "LedgerEntryType": "PayChannel",
    "LedgerIndex": "DC99821FAF6345A4A6C41D5BEE402A7EA9198550F08D59512A69BFC069DC9778",
    "PreviousFields": {},
    "PreviousTxnID": "A9D6469F3CB233795B330CC8A73D08C44B4723EFEE11426FEE8E7CECC611E18E",
    "PreviousTxnLgrSeq": 41889092
  }
}

TrustSet Transactions

TrustSet transactions create, modify, or delete trust lines, which are represented as RippleState objects. A single RippleState object contains settings for both parties involved, including their limits, rippling settings, and more. Creating and modifying trust lines can also adjust the sender's owner reserve and owner directory.

The following example shows a new trust line, where rf1BiG... is willing to hold up to 110 USD issued by rsA2Lp...:

 {
  "CreatedNode": {
    "LedgerEntryType": "RippleState",
    "LedgerIndex": "9CA88CDEDFF9252B3DE183CE35B038F57282BC9503CDFA1923EF9A95DF0D6F7B",
    "NewFields": {
      "Balance": {
        "currency": "USD",
        "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
        "value": "0"
      },
      "Flags": 131072,
      "HighLimit": {
        "currency": "USD",
        "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
        "value": "110"
      },
      "LowLimit": {
        "currency": "USD",
        "issuer": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
        "value": "0"
      }
    }
  }
}

Other Transactions

Most other transactions create a specific type of ledger entry and adjust the sender's owner reserve and owner directory:

AccountSet transactions modify the sender's existing AccountRoot object, changing the settings and flags as specified.
DepositPreauth transactions add or remove a DepositPreauth object for a specific sender.
SetRegularKey transactions modify the AccountRoot object of the sender, changing the RegularKey field as specified.
SignerListSet transactions add, remove, or replace a SignerList object.

Pseudo-Transactions

Pseudo-transactions also have metadata, but they do not follow all the rules of normal transactions. They are not tied to a real account (the Account value is the base58-encoded form of the number 0), so they do not modify an AccountRoot object in the ledger to increase the Sequence number or destroy XRP. Pseudo-transactions only make specific changes to special ledger objects:

EnableAmendment pseudo-transactions modify the Amendments ledger object to track which amendments are enabled, and which ones are pending with majority support and for how long.
SetFee pseudo-transactions modify the FeeSettings ledger object to change the base levels for the transaction cost and reserve requirements.