| history_operation_id | The operation id associated with the executed trade. The total amount traded in an operation can be broken up into multiple smaller trades spread across multiple orders by multiple parties | integer | | Yes | There is a many-to-one relationship for history_operation_id with the history_operations table. |
| order | The sequential number assigned to the portion of a trade that is executed within an operation. The history_operation_id and order number together represent a unique trade segment | integer | | Yes | |
| ledger_closed_at | The timestamp in UTC when the ledger with this trade was closed | timestamp | | Yes | |
| selling_account_address | The account address of the selling party | string | | No | |
| selling_asset_code | The 4 or 12 character code of the sold asset within a trade | string | | No | Asset codes have no guarantees of uniqueness. The combination of asset code, issuer, and type represents a distinct asset |
| selling_asset_issuer | The account address of the original asset issuer for the sold asset within a trade | string | | No | |
| selling_asset_type | The identifier for type of asset code used for the sold asset within the trade | string | - credit_alphanum4
- credit_alphanum12
- native
| Yes | XLM is the native asset to the network. XLM has no asset code or issuer representation and will instead be displayed with an asset type of 'native' |
| selling_amount | The amount of sold asset that was moved from the seller account to the buyer account, reported in terms of the sold amount | float | | Yes | |
| buying_account_address | The account address of the buying party | string | | No | |
| buying_asset_code | The 4 or 12 character code of the bought asset within a trade | string | | No | Asset codes have no guarantees of uniqueness. The combination of asset code, issuer, and type represents a distinct asset |
| buying_asset_issuer | The account address of the original asset issuer for the bought asset within a trade | string | | No | |
| buying_asset_type | The identifier for type of asset code used for the bought asset within the trade | string | - credit_alphanum4
- credit_alphanum12
- native
| Yes | XLM is the native asset to the network. XLM has no asset code or issuer representation and will instead be displayed with an asset type of 'native' |
| buying_amount | The amount of purchased asset that was moved from the seller account into the buying account, reported in terms of the bought asset | float | | Yes | |
| price_n | The price ratio of the sold asset: bought asset. When taken with price_d, the price can be calculated by price_n/price_d | integer | | No | |
| price_d | The price ratio of the sold asset: bought asset. When taken with price_n, the price can be calculated by price_n/price_d | integer | | No | |
| selling_offer_id | The offer ID in the orderbook of the selling offer. If this offer was immediately and fully consumed, this will be a synthetic ID. | integer | | No | |
| buying_offer_id | The offer ID in the orderbook of the buying offer. If this offer was immediately and fully consumed, this will be a synthetic ID. | integer | | 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 | | No | |
| 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 | | No | 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 | | No | |
| selling_liquidity_pool_id | The unique identifier for a liquidity pool if the trade was executed against a liquidity pool instead of the orderbook | string | | No | |
| liquidity_pool_fee | The percentage fee (in basis points) of the total fee collected by the liquidity pool for executing the trade. The fee is pooled and distributed back to liquidity pool shareholders to incentivize users to stake money in the pool. | integer | 30 | No | Liquidity pool fees can only change with protocol changes to the network itself |
| trade_type | Indicates whether the trade was executed against the orderbook (decentralized exchange) or liquidity pool | integer | - 1 - Decentralized Exchange Trade
- 2 - Liquidity Pool Trade
| No | |
| rounding_slippage | Applies to liquidity pool trades only. With fractional amounts of an asset traded, the network must round a fraction to the nearest whole number. This can cause the trade to "slip" price by a percentage compared with the original offer. Rounding slippage reports the percentage that dust trades slip before executing. | integer | | No | Defaults to 1. Rounding Slippage is always unprofitable for the trader and is not a valid way to try and extract more value from the network. |
| seller_is_exact | Indicates whether the buying or selling party trade was impacted by rounding slippage. If true, the buyer was impacted. If false, the seller was impacted | boolean | | No | |
| selling_asset_id | Unique identifier for selling_asset_code, selling_asset_issuer | integer | | No | |
| buying_asset_id | Unique identifier for buying_asset_code, buying_asset_issuer | integer | | No | |