ZMQ architecture

ZMQ is the simplest integration path for most domain applications.

Use it to wake your application when Char sees relevant work. Treat the notification as a prompt to read current state from your local node, not as the roll itself.

Define

• which notifications matter to your app,
• how notifications map to domain and ballot work,
• where the app stores its next ballot cursor,
• how pending leader work is retried,
• how observed rolls are applied idempotently,
• which polling backfill runs after reconnect.

Flow

1. Subscribe to Char notifications from your node.
2. On a leader notification, refresh domain info and confirm the selected leader is controlled by the loaded wallet.
3. If the app should submit, produce the ballot payload and send it through the node.
4. On a roll notification, fetch the roll from the node.
5. Apply only verified outcomes, then advance the app cursor.
6. Periodically poll from the persisted cursor to catch missed notifications.

Reconnects

ZMQ delivery is advisory. A dropped notification should not corrupt app state.

After reconnect, poll from the stored next_ballot cursor until the app catches up. If the app detects a ballot gap, stop applying new rolls and reconcile in order before advancing.