| source_account | VARCHAR(16777216) | The account that submitted the operation |
| source_account_muxed | VARCHAR(16777216) | The muxed account address (if applicable) |
| source_account_muxed_id | VARCHAR(16777216) | The muxed ID of the source account |
| operation_id | VARCHAR(16777216) | The unique identifier for this operation |
| type | VARCHAR(16777216) | The type of operation (e.g., payment, create_account, etc.) |
| type_id | NUMBER(38,0) | The numeric ID of the operation type |
| ledger_sequence | NUMBER(38,0) | The sequence number of the ledger containing this operation |
| ledger_close_time | TIMESTAMP_NTZ(9) | The close time of the ledger containing this operation |
| ledger_hash | VARCHAR(16777216) | The hash of the ledger containing this operation |
| transaction_hash | VARCHAR(16777216) | The hash of the transaction containing this operation |
| transaction_index | NUMBER(38,0) | The index of the transaction within the ledger |
| transaction_result | VARCHAR(16777216) | The result code of the transaction containing this operation |
| transaction_successful | BOOLEAN | Whether the transaction containing this operation was successful |
| operation_index | NUMBER(38,0) | The index of this operation within the transaction |
| operation_details | VARIANT | Detailed information about the operation in JSON format |
| _created_at | TIMESTAMP_NTZ(9) | Timestamp when this record was created |
| _updated_at | TIMESTAMP_NTZ(9) | Timestamp when this record was last updated |
| transaction_events | VARIANT | Array of token-transfer and SEP-41 events emitted in the transaction |
| operation_result | VARIANT | JSON object with the result of this Stellar operation, decoded from the transaction result XDR. Where operation_details describes the operation as submitted, operation_result describes what it actually did — so it is the only place executed (rather than requested) values are available. The shape is an OperationResult union: the op_inner arm is keyed by the RESULT union case, which is not always the operation type (create_passive_sell_offer reports under manage_sell_offer). Notable paths: - operation_result:op_inner:manage_sell_offer:success:offers_claimed — SDEX orderbook and AMM fills (“claim atoms”) for manage_sell_offer, manage_buy_offer and create_passive_sell_offer. Each entry carries the counterparty, the offer id (or liquidity pool id), and the amounts and assets actually exchanged. These are what Horizon’s v1 effects flattened into trade / liquidity_pool_trade rows. An empty array means the offer crossed nothing and simply rested on the book — no trade occurred. - operation_result:op_inner:path_payment_strict_send:success:offers — the same claim atoms for each hop of a path payment (also path_payment_strict_receive). - operation_result:op_inner:manage_sell_offer:success:offer — the resulting offer entry state, either "deleted" or a created / updated object carrying the assigned offer_id. Each claim atom is itself a union by venue: order_book (with seller_id and offer_id), v0 (pre-protocol-18 SDEX, carrying seller_ed25519 — a raw ed25519 key that must be strkey-encoded to match a G... account id), and liquidity_pool (with liquidity_pool_id and no offer id). A failed operation inside an otherwise-successful transaction carries its failure in the same position, e.g. {"op_inner": {"payment": "underfunded"}}. Null when the transaction produced no operation results at all, i.e. it failed at the transaction level (tx_bad_seq, tx_too_late, …) rather than at an operation. |
