Events & Meta-transactions
Last updated
Last updated
The Events format is a standard interface for tracking contract activity.
Events use the standard logs capability of NEAR. Events are log entries that start with the EVENT_JSON: prefix followed by a single valid JSON string.
JSON string should have the following interface:
// Interface to capture data about an event
// Arguments
// * `standard`: name of standard, e.g. nep171
// * `version`: e.g. 1.0.0
// * `event`: type of the event, e.g. nft_mint
// * `data`: associate event data. Strictly typed for each set {standard, version, event} inside corresponding NEP
interface EventLogData {
standard: string,
version: string,
event: string,
data?: unknown,
}Thus, to emit an event, you only need to log a string following the rules above. Here is a barebones example using Rust SDK near_sdk::log! macro (security note: prefer using serde_json or alternatives to serialize the JSON string to avoid potential injections and corrupted events):
use near_sdk::log;
// ...
log!(
r#"EVENT_JSON:{"standard": "nepXXX", "version": "1.0.0", "event": "YYY", "data": {"token_id": "{}"}}"#,
token_id
);
// ...Valid event logs
EVENT_JSON:{
"standard": "nepXXX",
"version": "1.0.0",
"event": "xyz_is_triggered",
"data": {
"triggered_by": "foundation.near"
}
}Invalid event logs
Two events in a single log entry (instead, call log for each individual event)
Invalid JSON data
Missing required fields standard, version or event
Drawbacks
There is a known limitation of 16kb strings when capturing logs. This impacts the amount of events that can be processed.
In-protocol meta transactions allowing for third-party account to initiate and pay transaction fees on behalf of the account.
Changes to protocol are required:
New Action kind: DelegateAction(receiver_id, Action, signer_pk, signature)
On conversion to Receipt, such action is sent as DelegateAction to the receiver_id.
On processing Receipt, it verifies the signature over the given account and signer_pk. Unwraps into receiver_id: AccountId, action: Action inside into new Receipt with given receiver_id and action. This means that predeccessor_id of such action has been overriden.
Increases complexity of the NEAR's transactional model.
Meta transactions take an extra block to execute, as they first need to be included by the originating account, then routed to the delegate account and only after that to the real destination.
Delegate actions are not programmable as they require having signatures. Original proposal contained a new AccessKey kind that would support programmable delegated actions. On the other hand, that would be limiting without progamability of smart contracts, hence that idea evolved into Account Extensions.