Skip to content
Tenzro
Documentation menu
Consensus and ledger

Events

Follow the chain's committed events from a cursor, query their history, and prove any event against a certified checkpoint.

Every block's execution emits events, the chain commits them, and every node keeps them in a durable log that readers follow from a cursor. Any event can be proven against a certified checkpoint, so an index built from events, and any answer computed from one, can be checked rather than trusted.

What is committed

For each executed transaction a block emits, in order, its outcome (transaction_included: success, gas used, any deployed contract) and then each log it emitted (log: contract address, topics, data). An event's position is its cursor, height:tx_index:event_index, and cursors are totally ordered.

The block header carries event_root, the Merkle root of the block's events in cursor order, and the checkpoint certificate covers the header. A node importing a certified block refuses it when its own execution emits different events.

Subscribe from the CLI

bash
# Follow new logs from one contract
tenzro events subscribe --types log --address 0xCONTRACT --rpc https://rpc.tenzro.com

# Only logs with a given event signature, stop after 10
tenzro events subscribe --types log --topic 0xTOPIC0 --limit 10

# Resume exactly where a previous reader stopped
tenzro events subscribe --from-cursor 120394:3:1

Query history

bash
# Events from a height, 100 at a time
tenzro events history --from-height 1000 --limit 100

# A cursor range
tenzro events history --from-cursor 1000:0:0 --to-cursor 2000:0:0 --types transaction_included

# EVM logs, eth_getLogs compatible
tenzro events logs --address 0xCONTRACT --from-block 1000

JSON-RPC

MethodWhat it does
tenzro_subscribeThe next events after a cursor (the current tip when no start is given), waiting up to wait_ms (at most 30 seconds) for new blocks. Pass the returned cursor back as from_cursor, so a reader that restarts resumes with no gap and no repeat.
tenzro_queryEventsA page of a range, every event with its proof.
tenzro_getEventProofOne event's proof; with certified, a proof from genesis that its anchor is certified.
tenzro_verifyEventProofChecks a proof against the certification this node holds for its anchor.
tenzro_eventStatusHow far this node has indexed and what it retains.
bash
curl -s https://rpc.tenzro.com -H 'content-type: application/json' -d '{
  "jsonrpc": "2.0", "id": 1, "method": "tenzro_subscribe",
  "params": {"filter": {"event_types": ["log"], "addresses": ["0xCONTRACT"]}, "wait_ms": 10000}
}'

The filter takes event_types (log, transaction_included), addresses, topics (positional: null, one topic, or a list), from_block and to_block. An unknown field or a malformed value is refused. Standard EVM tooling can use eth_getLogs as usual.

Server-sent events

GET /events?filter=<json>&from_cursor=<cursor> streams the same events as server-sent events. Each event's id is its cursor, so a reconnecting client resumes from Last-Event-ID. A node's own live events, such as inference streams, are at GET /events/node, and reach a reader only as the resource's visibility allows.

Verify an event

bash
tenzro events verify --chain-id <CHAIN_ID> --genesis-hash <HASH> --genesis-committee-root <ROOT> <CURSOR>

The CLI follows the chain's certificates from genesis and checks the event's proof against them, so the answer does not depend on trusting the node you asked. The Rust and TypeScript SDKs check proofs the same way.

Agents

A delegated agent reads the event stream only when its terms list the subscribe_events operation, and when its terms name counterparties its filter must name those addresses and no others. The check runs on every read, over JSON-RPC, server-sent events, MCP and A2A. The MCP tools are subscribe_events, query_events and verify_event_proof.

Status

bash
tenzro events info

tenzro_eventStatus returns the same information over JSON-RPC.