The Current/Future Status of ZMQ in Monero
ZMQ_SUB sockets must "subscribe" to topics before it receives any data.
This allows filtering on the server side, so network traffic is reduced. Monero
allows for filtering on: (1) format, (2) context, and (3) event.
format refers to the wire format (i.e. JSON) used to send event information.
context allows for a reduction in fields for the event, so the daemon doesn't waste cycles serializing fields that get ignored.
event refers to status changes occurring within the daemon (i.e. new block to main chain).
full- the entire block or transaction is transmitted (the hash can be computed remotely).
minimal- the bare minimum for a remote client to react to an event is sent.
chain_main- changes to the primary/main blockchain.
txpool_add- new publicly visible transactions in the mempool. Includes previously unseen transactions in a block but not the
miner_tx. Does not "re-publish" after a reorg. Includes
The subscription topics are formatted as
format-context-event, with prefix
matching supported by both Monero and ZMQ. The
will never have hyphens or colons in their name. For example, subscribing to
json-minimal-chain_main will send minimal information in JSON when changes
to the main/primary blockchain occur. Whereas, subscribing to
will send minimal information in JSON on all available events supported by the
The Monero daemon will ensure that events prefixed by
chain will be sent in
"chain-order" - the
prev_id (hash) field will always refer to a previous
block. On rollbacks/reorgs, the event will reference an earlier block in the
chain instead of the last block. The Monero daemon also ensures that
txpool_add events are sent before
chain_* events - the
will only serialize miner transactions since the other transactions were
previously published via
txpool_add. This prevents transactions from being
serialized twice, even when the transaction was first observed in a block.
ZMQ Pub/Sub will drop messages if the network is congested, so the above rules
for send order are used for detecting lost messages. A missing gap in
chain_* events indicates a lost pub message. Missing
txpool_add messages can only be detected at the next
Since blockchain events can be dropped, clients will likely want to have a
chain_main events. The
GetLastBlockHeader RPC is useful
for checking the current chain state. Dropped messages should be rare in most
The Monero daemon will send a
txpool_add pub exactly once for each
transaction, even after a reorg or restarts. Clients should use the
GetTransactionPool after a reorg to get all transactions that have been put
back into the tx pool or been invalidated due to a double-spend.