Wallet subscription

This scenario follows order-owner participations and their outcomes. The owner must be allowed for your account. It does not select every transaction sent by the address or filter by signer.

Use the complete quickstart subscription template, replacing its synthetic address with an allowed owner and selecting permitted stages. Keep consumer and subscription IDs stable across reconnects.

Expected flow

1. Receive subscribed and its source-quality snapshot.
2. Process matching intent and/or receipt events; pending need not arrive first.
3. Apply canonicality and corrections for known occurrences.
4. Save effects and checkpoint atomically, then ACK.
5. After disconnect, resume the same subscription.

A quiet wallet can produce no trades and still advance checkpoints. A relevant source-quality gap can arrive without trade matches. The scenario does not promise activity within a fixed time.

Maintain provisional intents separately from actual executions and their canonicality. Receipt-only execution remains a valid observed result; its intent correlation can be unavailable.

Consumer acceptance check

For a deterministic synthetic scenario, accept one execution at revision 1, replay the identical event, then apply a correction changing its occurrence assessment. Expected results: one execution entity, no duplicate effect on replay, and the changed canonical assessment without adding another trade. An unknown correction target must not fabricate a fill.

This is an acceptance scenario, not a runnable SDK or a claim that this synthetic owner has real activity. Use durable consumer pseudocode for persistence and recovery for failures.