Polling architecture

Polling is useful when ZMQ is not available, or when a service wants a periodic backfill path.

Your app keeps a next_ballot pointer and asks its local Char node for current domain and roll state. If a roll exists, the app verifies, applies, stores, and advances.

Define

• domain preimage,
• starting ballot,
• payload meaning,
• when this process is allowed to submit payloads,
• database writes per accepted outcome,
• reorg window,
• retry interval.

Loop

1. Read domain info from the local node.
2. Check whether the loaded wallet controls the selected leader.
3. If this process is the leader, produce and submit the ballot payload.
4. Query getreferendumresolution for next_ballot.
5. If a decision exists, call the app roll handler.
6. Apply the roll transactionally and advance next_ballot.
7. If no result exists, wait and retry.

Store

• last applied ballot,
• roll hash,
• data hash,
• applied payload,
• Bitcoin block context if your app needs auditability.

Backfill

Polling is also the recovery path for missed ZMQ notifications. Start from the stored cursor, fetch one ballot at a time, and do not advance past a gap until the missing ballot is resolved or explicitly skipped by your app rules.

During the reorg window, re-check recent ballots before treating application state as final.