# Events > Events that the Intear DEX engine logs in the inteardex standard: swaps, deposits, withdrawals, balance updates, DEX deployments, and the compressed events of DEXs. This page is part of the Intear DEX docs. Intear DEX is the `dex.intear.near` contract. https://docs.intear.tech/intear-dex/llms-full.txt has all of its pages in one file, and https://docs.intear.tech/llms.txt lists every page of the Intear docs. The engine logs [NEP-297](https://github.com/near/NEPs/blob/master/neps/nep-0297.md) events with the standard `inteardex`: ``` EVENT_JSON:{"standard":"inteardex","version":"1.0.0","event":"swap","data":{...}} ``` | Event | Version | Logged when | | --- | --- | --- | | [`swap`](#swap) | `1.0.0` | A swap happened | | [`balance_updates`](#balance_updates) | `2.0.0` | Inner balances changed during a call | | [`user_deposit`](#user_deposit) | `1.0.0` | Assets were deposited to an inner balance | | [`withdraw`](#withdraw) | `1.0.0` | Assets left the engine | | [`dex_events_borsh`](#dex_events_borsh) | `1.0.0` | DEXs logged events during a call | | [`dex_event`](#dex_event) | `1.0.0` | A DEX logged a JSON event. Only in old transactions | | [`dex_deployed`](#dex_deployed) | `1.0.0` | DEX code was deployed | `swap`, `user_deposit`, `dex_event` and `dex_deployed` are logged when they happen. `dex_events_borsh` and `balance_updates` are logged once, at the end of the call, in this order. A receipt keeps its logs even when it fails, so a `swap`, `dex_event` or `dex_deployed` logged before a later operation failed was reverted: only count events of successful receipts. `dex_events_borsh` and `balance_updates` are only logged when the call succeeds. `withdraw` is logged in the receipt after the transfer, once its result is known. Besides events, the engine logs plain text: - `Fully authorized: true` before the operations of `execute_operations`, and `Fully authorized: false` before [operations in a deposit](https://docs.intear.tech/intear-dex/guides/operations.md#operations-in-a-deposit), - `Executing operation ` before each [operation](https://docs.intear.tech/intear-dex/guides/operations.md), counting from 0, - `Skipping swap option on : ` for each option of a [`SwapAdvanced`](https://docs.intear.tech/intear-dex/guides/operations.md#best-of-several-dexs) that failed or, with `FallbackQueue`, didn't meet the constraint, - `After withdraw: Ok(())` in the receipt after each withdrawal, or an `Err` if the transfer failed, then `Refunding to ...` when the assets are refunded. DEXs can't log text. ## `swap` ```json { "dex_id": "slimedragon.near/xyk", "request": { "message": "", "asset_in": "near", "asset_out": "nep141:usdt.tether-token.near", "amount": { "ExactIn": "995000000000000000000000" }, "referrer": "myapp.near" }, "amount_in": "995000000000000000000000", "amount_out": "4855607", "trader": "alice.near", "referrer": "myapp.near", "referral_fees_paid": [["myapp.near", "5000000000000000000000"]] } ``` `trader` is the account the swap is for. For swaps in a [deposit message](https://docs.intear.tech/intear-dex/guides/operations.md#operations-in-a-deposit), it's the sender the token contract reported. `referral_fees_paid` has the [referral fees](https://docs.intear.tech/intear-dex/guides/referral-fees.md) each account got, in `asset_in`, and is empty without them. The `request` and `amount_in` are the DEX's, without the fees, so the trader paid `amount_in` and the fees together: 1 NEAR in this example, with a fee of 0.5%. Old `swap` events don't have `referral_fees_paid`. ## `balance_updates` The final balance of every owner and asset whose balance changed in the call, in the order they first changed. `data` is an array: ```json [ { "owner": { "Account": "alice.near" }, "asset_id": "near", "balance": "0" }, { "owner": { "Dex": "slimedragon.near/xyk" }, "asset_id": "near", "balance": "52000000000000000000000000000" }, { "owner": { "Dex": "slimedragon.near/xyk" }, "asset_id": "nep141:usdt.tether-token.near", "balance": "253000000000" }, { "owner": { "Account": "alice.near" }, "asset_id": "nep141:usdt.tether-token.near", "balance": "4880007" } ] ``` This is the easiest way to keep track of inner balances: apply the last `balance` of each owner and asset, no math needed. :::note Older versions of the engine logged `user_balance_update` and `dex_balance_update` (`1.0.0`), one per change, instead. They are no longer logged, but you'll find them in old transactions. ::: ## `user_deposit` Assets were added to an inner balance with a plain deposit: an empty `msg`, or `deposit_near` without `operations`. Deposits with operations don't log it, and neither does NEAR attached to `execute_operations`, which only shows up in `balance_updates`. ```json { "account_id": "alice.near", "asset_id": "near", "amount": "1000000000000000000000000" } ``` ## `withdraw` A withdrawal's transfer succeeded. Not logged for failed transfers: those are refunded and show up in `balance_updates`. ```json { "from": { "Account": "alice.near" }, "to": "bob.near", "asset_id": "nep141:usdt.tether-token.near", "amount": "4880007" } ``` `from` is the inner balance the assets came from, or a DEX for withdrawals a DEX requested. For a `Withdraw` in a [deposit message](https://docs.intear.tech/intear-dex/guides/operations.md#withdrawing-from-a-deposit), it's the sender if they have the asset registered, otherwise `rescue_address`. ## `dex_events_borsh` Events that DEXs logged during the call, all in one event to save space. `data` is a string: 1. Decode it from base64. 2. Decompress it as an LZ4 block. The first 4 bytes are the uncompressed length, as a little-endian u32 (the format of `lz4_flex::decompress_size_prepended` in Rust). 3. Decode the result as Borsh `Vec`: | Field | Borsh type | Description | | --- | --- | --- | | `dex_id` | `DexId` | The DEX that logged it | | `event` | `Vec` | The event, in the DEX's own format | | `referrer` | `Option` | The referrer of the call | | `user` | `Option` | The account of the [`caller`](https://docs.intear.tech/intear-dex/guides/dexes.md#what-a-dex-sees): the caller, or the alleged sender of a deposit | In Rust, `DexEventData` is in [`intear-dex-types`](https://docs.intear.tech/intear-dex/reference/types.md#borsh). ## `dex_event` A DEX logged a JSON event: a log that starts with `EVENT_JSON:` and is valid JSON after it. Same fields as `DexEventData`, but `event` is the JSON event as logged by the DEX. DEXs can't log anymore, and log Borsh events in [`dex_events_borsh`](#dex_events_borsh) instead, so `dex_event`s, like this one, are only in old transactions: ```json { "dex_id": "slimedragon.near/xyk", "event": { "standard": "xyk", "version": "1.0.0", "event": "...", "data": { ... } }, "referrer": null, "user": "alice.near" } ``` ## `dex_deployed` ```json { "dex_id": "slimedragon.near/xyk", "code_hash": "" } ```