Events

The engine logs NEP-297 events with the standard inteardex:

EVENT_JSON:{"standard":"inteardex","version":"1.0.0","event":"swap","data":{...}}

Event	Version	Logged when
swap	1.0.0	A swap happened
balance_updates	2.0.0	Inner balances changed during a call
user_deposit	1.0.0	Assets were deposited to an inner balance
withdraw	1.0.0	Assets left the engine
dex_events_borsh	1.0.0	DEXs logged events during a call
dex_event	1.0.0	A DEX logged a JSON event
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. withdraw is logged in the receipt after the transfer, once its result is known.

Besides events, the engine logs plain text: Executing operation <n> before each operation, and the logs of DEXs prefixed with [<dex id>].

swap

{
  "dex_id": "slimedragon.near/xyk",
  "request": {
    "message": "<base64>",
    "asset_in": "near",
    "asset_out": "nep141:usdt.tether-token.near",
    "amount": { "ExactIn": "1000000000000000000000000" },
    "referrer": "myapp.near"
  },
  "amount_in": "1000000000000000000000000",
  "amount_out": "4880007",
  "trader": "alice.near",
  "referrer": "myapp.near"
}

trader is the account the swap is for. For swaps in a deposit message, it’s the sender the token contract reported.

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:

[
  { "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 (empty msg). Deposits with operations don’t log it.

{ "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.

{
  "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.

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<DexEventData>:

Field	Borsh type	Description
dex_id	DexId	The DEX that logged it
event	Vec<u8>	The event, in the DEX’s own Borsh format
referrer	Option<AccountId>	The referrer of the call
user	Option<AccountId>	The caller, or the alleged trader of a swap (see What a DEX sees)

In Rust, DexEventData is in intear-dex-types.

dex_event

A DEX logged a JSON event (a log starting with EVENT_JSON:). Same fields as DexEventData, but event is the JSON event as logged by the DEX:

{
  "dex_id": "slimedragon.near/xyk",
  "event": { "standard": "xyk", "version": "1.0.0", "event": "...", "data": { ... } },
  "referrer": null,
  "user": "alice.near"
}

dex_deployed

{ "dex_id": "slimedragon.near/xyk", "code_hash": "<base58 SHA-256 of the code>" }