Reading events from the Quantova chain
Every state change on the Quantova Virtual Machine emits a structured event. This guide explains how applications, indexers and oversight systems subscribe to those events, decode them and reconcile them against deterministic state, so off chain records match the protocol exactly.
Events are recorded as part of execution and committed under SHA3 256 state roots. Because verification is deterministic, any party can replay a block and confirm that the events it observed are the events the protocol produced, with no reliance on a trusted node operator.
What a Quantova event is
An event is a typed record emitted by the QVM when a transaction changes state. Each event names the module that raised it, the action it represents and the values that action produced.
Events are not application data written by a contract for convenience. They are produced by the execution layer as a faithful account of what occurred during a block. A transfer, a staking bond, a governance vote and a bridge settlement each emit their own event with their own fields, so an external system can follow protocol activity without parsing raw storage.
Every event is tied to the transaction that caused it and to the block that included it. Because block linkage and state roots use SHA3 256, the position and content of an event are fixed once the block reaches finality. An indexer that records events therefore holds the same view of history as the protocol itself.
| Field | Meaning |
|---|---|
| Module | The pallet or runtime module that raised the event |
| Event name | The action that occurred, such as Transfer |
| Attributes | The decoded values the action produced |
| Phase | Whether it came from a transaction, finalisation or initialisation |
| Block | Height and hash of the including block |
| Index | Ordered position within the block |
Events you will read most often
Balance and transfer events
Account credits, debits and transfers, each carrying the sender, recipient and amount. These reconcile account balances against state without scanning storage.
Staking events
Bond, unbond, reward and slash events on the NPoS system. They report validator activity, the 30 day unbonding queue and any penalty applied for an offence.
Governance events
Referenda raised, votes cast with conviction and runtime upgrades enacted. These track forkless upgrades and the path to the 80 percent runtime approval threshold.
Bridge events
Lock, mint, burn and release events across 36 blockchains and 78 assets on the QVM. They settle cross chain movement and carry the proof reference for each leg.
Contract events
Events emitted by smart contracts running in the QVM. They are decoded against the contract definition and ordered alongside protocol events in the same block. Every deployment on the Quantova Virtual Machine inherits post quantum security by default, not by choice, so every emitted event is bound to post quantum verified state.
System events
Execution success and failure, fee deduction and block lifecycle markers. They confirm whether a transaction applied and what the fee, typically about five cents, came to.
From a block to a decoded record
Open a node connection
Connect to a Quantova node or provider through the SDK. The client subscribes to new blocks and to finalised heads as they are produced.
Watch for new events
Subscribe to the system events for each block. The node returns the full event set with its module, name, attributes and phase.
Decode against metadata
Decode each event using runtime metadata so attributes resolve to named, typed values rather than raw bytes.
Link to the transaction
Map each event to the transaction that raised it through its phase, so you know which call produced which record.
Wait for finality
Treat an event as authoritative once its block reaches deterministic finality, which the protocol delivers in about 3 seconds.
Reconcile against state
Replay the block and confirm the decoded events match the SHA3 256 state root, so your record agrees with the protocol.
Subscribe with the Quantova SDKs
The same event interface is available across the SDK family, so you can read events from JavaScript, Python or Rust services with one model.
import { Quantova } from 'qweb3.js'
const api = await Quantova.connect('wss://rpc.quantova.org')
await api.query.system.events((records) => {
records.forEach(({ event, phase }) => {
console.log(phase.toString(), event.section, event.method)
console.log(event.data.toHuman())
})
})
| SDK | Use |
|---|---|
| qweb3.js | Event streams for web and Node services |
| qweb3.py | Indexing and analytics in Python |
| qweb3.rs | High throughput Rust services and indexers |
| @quantova/api | Typed access for application back ends |
Records you can hold institutions to
- ✓Events are emitted by the execution layer as part of state transition, not written by application code, so they report what the protocol actually did.
- ✓Once a block reaches deterministic finality, the order and content of its events are fixed and cannot be revised by any node operator.
- ✓Any party can replay a finalised block and confirm that observed events match the SHA3 256 state root, with no privileged access required.
- ✓Events provide a complete reconciliation trail for balances, staking, governance and bridge settlement that auditors and oversight bodies can verify independently.
A verifiable record of every state change
Quantova events give applications, indexers and regulators a typed, ordered account of protocol activity. Connect through the SDKs, decode against runtime metadata, wait for finality and reconcile against deterministic SHA3 256 state. The result is an off chain record that agrees with the protocol exactly and that any party can verify on its own.
Owned by Quantova Inc. Released under the Business Source License 1.1.
