Skip to content

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. Only in old transactions
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,
  • Executing operation <n> before each operation, counting from 0,
  • Skipping swap option on <dex id>: <error> for each option of a SwapAdvanced 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.

{
"dex_id": "slimedragon.near/xyk",
"request": {
"message": "<base64>",
"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, it’s the sender the token contract reported.

referral_fees_paid has the referral fees 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.

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.

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.

{ "account_id": "alice.near", "asset_id": "near", "amount": "1000000000000000000000000" }

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. For a Withdraw in a deposit message, it’s the sender if they have the asset registered, otherwise rescue_address.

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 format
referrer Option<AccountId> The referrer of the call
user Option<AccountId> The account of the caller: the caller, or the alleged sender of a deposit

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

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 instead, so dex_events, like this one, are only in old transactions:

{
"dex_id": "slimedragon.near/xyk",
"event": { "standard": "xyk", "version": "1.0.0", "event": "...", "data": { ... } },
"referrer": null,
"user": "alice.near"
}
{ "dex_id": "slimedragon.near/xyk", "code_hash": "<base58 SHA-256 of the code>" }