Events
This page is also Markdown, for agents: /intear-dex/reference/events.md, and /llms.txt lists every page.
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: truebefore the operations ofexecute_operations, andFully authorized: falsebefore operations in a deposit,Executing operation <n>before each operation, counting from 0,Skipping swap option on <dex id>: <error>for each option of aSwapAdvancedthat failed or, withFallbackQueue, didn’t meet the constraint,After withdraw: Ok(())in the receipt after each withdrawal, or anErrif the transfer failed, thenRefunding 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.
balance_updates
Section titled “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.
user_deposit
Section titled “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.
{ "account_id": "alice.near", "asset_id": "near", "amount": "1000000000000000000000000" }withdraw
Section titled “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. For a Withdraw in a deposit message, it’s the sender if they have the asset registered, otherwise rescue_address.
dex_events_borsh
Section titled “dex_events_borsh”Events that DEXs logged during the call, all in one event to save space. data is a string:
- Decode it from base64.
- 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_prependedin Rust). - 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.
dex_event
Section titled “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 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_deployed
Section titled “dex_deployed”{ "dex_id": "slimedragon.near/xyk", "code_hash": "<base58 SHA-256 of the code>" }