| id | A unique identifier for a this transaction | integer | | Yes | Yes | | Yes | |
| transaction_hash | A hex-encoded SHA-256 hash of this transaction's XDR-encoded form | string | | | | | Yes | |
| ledger_sequence | The sequence number of the ledger that this transaction was included in | integer | | | | cluster | Yes | |
| application_order | Each transaction within the transaction set for a ledger is executed and applied sequentially to the network. The validator nodes randomly shuffle submitted transactions and assign them an application order number, which corresponds to the order in which they are applied | integer | | | | | Yes | |
| account | The account address that originates the transaction | string | | | | cluster | Yes | |
| account_sequence | The source account's sequence number that this transaction consumed. Sequence numbers can only be used once and help maintain atomicity and idempotency on the network. | integer | | | | | Yes | |
| max_fee | The maximum fee (in stroops) that the source account is willing to pay for the transaction to be included in a ledger. When the network enters surge pricing, this helps determine if a transaction is included in the set | integer | | | | | Yes | The stroop is the fractional representation of a lumen (XLM). 1 stroop is 0.0000001 XLM. |
| operation_count | The number of operations contained within this transaction | integer | | | | | Yes | A transaction is permitted to have up to 100 operations |
| created_at | The date the transaction was created | timestamp | | | | | No | |
| memo_type | The type of memo | string | MemoTypeMemoHash MemoTypeMemoId MemoTypeMemoNone MemoTypeMemoReturn MemoTypeMemoText | | | | Yes | Defaults to `MemoTypeMemoNone` |
| memo | An optional freeform field that attaches a memo to a transaction | string | | | | | No | Memos are heavily used by centralized exchanges to help with account management. |
| time_bounds | A transaction precondition that can be set to determine when a transaction is valid. The user can set a lower and upper timebound, defined as a UNIX timestamp when the transaction can be executed. If the transaction attempts to execute outside of the time range, the transaction will fail | string | | | | | No | |
| successful | Indicates if this transaction was successful or not | boolean | | | | cluster | No | A transaction's success does not indicate whether it was included and written to a ledger. It only indicates whether the operations in the transaction were successfully applied to mutate the ledger state. |
| fee_charged | The fee (in stroops) paid by the source account to apply this transaction to the ledger. At minimum, a transaction is charged # of operations * base fee. The minimum base fee is 100 stroops | integer | | | | | No | The stroop is the fractional representation of a lumen (XLM). 1 stroop is 0.0000001 XLM. |
| inner_transaction_hash | A transaction hash of a transaction wrapped with its signatures for fee-bump transactions | string | | | | | No | |
| fee_account | An account that is not the originating source account for a transaction is allowed to pay transaction fees on behalf of the source account. These accounts are called fee accounts and incur all transaction costs for the source account. | string | | | | | No | |
| new_max_fee | If an account has a fee account, the fee account can specify a maximum fee (in stroops) that it is willing to pay for this account's fees. When the network is in surge pricing, the validators will consider the new_max_fee instead of the max_fee when determining if the transaction will be included in the transaction set | integer | | | | | No | |
| account_muxed | If the user has defined multiplexed (muxed) accounts, the account exists "virtually" under a traditional Stellar account address. This address distinguishes between the virtual accounts | string | | | | | No | |
| fee_account_muxed | If the fee account that sponsors fee is a multiplexed account, the virtual address will be listed here | string | | | | | No | |
| ledger_bounds | A transaction precondition that can be set to determine valid conditions for a transaction to be submitted to the network. Ledger bounds allow the user to specify a minimum and maxiumum ledger sequence number in which the transaction can successfully execute | string | | | | | No | |
| min_account_sequence | A transaction precondition that can be set to determine valid conditions for a transaction to be submitted to the network. This condition contains an integer representation of the lowest source account sequence number for which the transaction is valid | integer | | | | | No | |
| min_account_sequence_age | A transaction precondition that can be set to determine valid conditions for a transaction to be submitted to the network. This condition contains a minimum duration of time that must have passed since the source account's sequence number changed for the transaction to be valid | integer | | | | | No | |
| min_account_sequence_ledger_gap | A transaction precondition that can be set to determine valid conditions for a transaction to be submitted to the network. This condition contains an integer representation of the minimum number of ledgers that must have closed since the source account's sequence number change for the transaction to be valid | integer | | | | | No | |
| extra_signers | An array of up to two additional signers that must have corresponding signatures for this transaction to be valid | array[string] | | | | | No | |
| tx_envelope | base-64 encoded XDR blob | string | | | | | No | |
| tx_result | base-64 encoded XDR blob | string | | | | | No | |
| tx_meta | base-64 encoded XDR blob | string | | | | | No | |
| tx_fee_meta | base-64 encoded XDR blob | string | | | | | No | |
| batch_id | String representation of the run id for a given DAG in Airflow. Takes the form of "scheduled__<batch_end_date>-<dag_alias>". Batch ids are unique to the batch and help with monitoring and rerun capabilities | string | | | | | Yes | |
| batch_run_date | The start date for the batch interval. When taken with the date in the batch_id, the date represents the interval of ledgers processed. The batch run date can be seen as a proxy of closed_at for a ledger. | datetime | | | | MONTH partition | Yes | The table is partitioned on batch_run_date. It is recommended to always include the batch_run_date in the filter if possible to help reduce query cost. |
| batch_insert_ts | The timestamp in UTC when a batch of records was inserted into the database. This field can help identify if a batch executed in real time or as part of a backfill | timestamp | | | | | Yes | |
| resource_fee | The fee charged less the inclusion fee for the Soroban transaction. This is calculated by the read/write operations and how process intensive the Soroban transaction is | integer | | | | | No | |
| soroban resources_instructions | Number of CPU instructions the Soroban transaction uses | integer | | | | | No | |
| soroban resources_read_bytes | Number of bytes read by the Soroban transaction | integer | | | | | No | |
| soroban_resources_write_bytes | Number of bytes written by the Soroban transaction | integer | | | | | No | |
| closed_at | Timestamp in UTC when this ledger closed and committed to the network. Ledgers are expected to close ~every 5 seconds | timestamp | | | | | Yes | We aim to repartition the table by closed_at |
| transaction_result_code | The detailed result code that outlines why a transaction failed. This code is only useful for failed transactions. The full list of domain values can be found here | string | TransactionResultCodeTxFeeBumpInnerSuccess TransactionResultCodeTxSuccess TransactionResultCodeTxFailed TransactionResultCodeTxTooEarly TransactionResultCodeTxTooLate TransactionResultCodeTxMissingOperation TransactionResultCodeTxBadSeq TransactionResultCodeTxBadAuth TransactionResultCodeTxInsufficientBalance TransactionResultCodeTxNoAccount TransactionResultCodeTxInsufficientFee TransactionResultCodeTxBadAuthExtra TransactionResultCodeTxInternalError TransactionResultCodeTxNotSupported TransactionResultCodeTxFeeBumpInnerFailed TransactionResultCodeTxBadSponsorship TransactionResultCodeTxBadMinSeqAgeOrGap TransactionResultCodeTxMalformed TransactionResultCodeTxSorobanInvalid | | | | Yes | |
| inclusion_fee_bid | The maximum bid the submitter is willing to pay for inclusion of the transaction. This fee is used to prioritize transactions that are included in the ledger. | integer | | | | | No | |
| inclusion_fee_charged | The fee charged for the transaction to be included in the ledger. This is a fixed fee for the entire ledger and starts at a minimum of 100 stroops. The fee increases based on demand | integer | | | | | No | |
| resource_fee_refund | The amount of the resource fee refunded to the transaction submitter. The refundable fees are calculated from rent, events and return value. Refundable fees are charged from the source account before the transaction is executed and then refunded based on the actual usage. | integer | | | | | No | |
| non_refundable_resource_fee_charged | The amount charged for the transaction that is not refundable | integer | | | | | | |
| refundable_resource_fee_charged | The amount charged for the transaction from the refundable_fee | integer | | | | | | |
| rent_fee_charged | The rent fee charged to persist the contract or contract code | integer | | | | | | |
| refundable_fee | The amount of resource fees that are refundable based on the actual usage of resources in the transaction | integer | | | | | | |