Event types
Once a subscription is established, the server sends event messages (notifications) matching the selectedtypes and min_finality. Each message is a JSON object representing a single event.
The type field in each notification identifies the notification schema:
"transactions"— subscribe to transactions and their finality levels."actions"— subscribe to certain actions by settingaction_types."trace"— subscribe to a transaction trace."account_state_change"— emitted for each matching confirmed or finalized account transaction."jettons_change"— emitted for each matching confirmed or finalized jetton wallet transaction."trace_invalidated"— emitted when earlier trace data becomes invalid.
Notification schemas
Trace-related notifications, such as"transactions", "actions", and "trace" are grouped by the trace. They use the same trace_external_hash_norm value across all events generated from one external message.
Transactions and actions in the same trace are ordered by logical time (LT) in descending order. The "trace" event includes the full trace tree and a map of all transactions in that trace.
"transactions"
Subscriptions that include "transactions" can receive multiple notifications for the same trace as finality increases.
Trace is determined by its trace_external_hash_norm.
Notification example
"actions"
Subscriptions that include "actions" can receive multiple notifications for the same trace as finality increases.
Trace is determined by its trace_external_hash_norm.
Notification example
"trace"
Subscriptions that include "trace" receive trace-wide payloads. These payloads are not filtered by account address and include all transactions and actions in the trace.
Trace is determined by its trace_external_hash_norm.
Notification example
"account_state_change"
Subscriptions that include "account_state_change" receive notifications for each transaction executed on a subscribed account address.
This event is emitted only for "confirmed" and "finalized" finality levels.
Notification example
"jettons_change"
Subscriptions that include "jettons_change" receive notifications for each transaction on a jetton wallet contract when the subscribed address is its own address or its owner’s TON wallet address.
This event is emitted only for "confirmed" and "finalized" finality levels.
Notification example
"trace_invalidated"
The "trace_invalidated" notification signals that previously emitted speculative or intermediate trace data is no longer valid.
Typical causes include:
- external message was not accepted by the blockchain;
- later state change invalidated previous emulation result;
- confirmed shard block was replaced by another block, and the trace did not end up in the finalized block.
trace_external_hash_norm.
Notification example
"trace", "transactions", and "actions" data for the affected trace_external_hash_norm.
The "trace_invalidated" notification cannot be sent for the "finalized" finality level of the trace.
Delivery semantics
min_finality behavior
For trace-based events:
min_finality = "pending"returns"pending","confirmed", and"finalized"snapshots.min_finality = "confirmed"skips pure emulation and starts at"confirmed"or later.min_finality = "finalized"returns only finalized trace-based events.
"account_state_change"and"jettons_change"are emitted only with"confirmed"and"finalized"finality levels.
Event invalidation
Subscriptions that allow speculative states can later receive"trace_invalidated". If the finality level reaches "finalized", the server is guaranteed not to emit "trace_invalidated" for the trace.