Дослідження з перевіркою джерел: FIX DROP COPY Sequence
Текст статті показано у перевіреному англійському оригіналі. Переклад буде додано після перегляду джерел.
Verified Fact Boundary
1. Coinbase Exchange FIX Drop Copy documentation says drop copy receives execution reports for orders placed through FIX sessions or REST API associated with an API key. 2. Coinbase Exchange Drop Copy documentation describes a single-connection limit per API key and a weekly FIX5 reset schedule. 3. Coinbase International Exchange FIX overview says every connection establishes a new session and new sequence numbers, and resend requests are not supported. 4. Coinbase Exchange upcoming-changes documentation shows execution-report fields can change through scheduled documentation updates. 5. Coinbase REST order lookup documentation allows order queries using exchange-assigned or client-assigned identifiers with required permissions. 6. The safe radar separates drop-copy coverage, reset calendar, change notices, REST lookup fallback, client-order-ID lineage and local gap recovery.
Показати менше
Decision Matrix
Таблиця статті: прокрутіть горизонтально або сфокусуйте область таблиці й використовуйте клавіші зі стрілками.
| Check | What it means | Practical action | Unknown to keep explicit |
|---|---|---|---|
| Session scope | drop copy coverage depends on the API key and session relationship described by the venue | record which keys, sessions and products are included before using the feed | whether a sub-account or separate key is outside the drop-copy stream |
| Reset calendar | scheduled resets and logon resets can break naive sequence assumptions | write the reset calendar into the reconciliation runbook | how the desk proves no execution report was missed around reset |
| Connection limit | single-connection limits create failover design constraints | assign ownership for the active drop-copy connection | what happens if monitoring and production compete for the same key |
| Execution-report coverage | drop copy is useful only if the desk understands which order routes it covers | compare FIX, REST and application routes against the documented coverage | whether manual actions or other portfolios appear in the same stream |
| Change notice | execution-report fields can change through documented venue updates | subscribe the parser owner to venue change notices and schema tests | which optional fields are safe to ignore after a change |
| Fallback lookup | REST order lookup can support reconciliation but is not the same as a live feed | define when to query by order ID or client order ID after a gap | how permission scope or outages limit the fallback |
Source Map
- Coinbase Developer Documentation: Exchange FIX Drop Copy 5.0 (coinbase-exchange-drop-copy)
- Coinbase Developer Documentation: INTX FIX API Overview (coinbase-intx-fix-overview)
- Coinbase Developer Documentation: Exchange Upcoming Changes (coinbase-exchange-upcoming-changes)
- Coinbase Developer Documentation: Get single order (coinbase-get-single-order)
Control Notes
1. Session scope
Session scope is the decision point where public documentation must become an operating rule. In this package, it means drop copy coverage depends on the API key and session relationship described by the venue. The practical action is to record which keys, sessions and products are included before using the feed. The unresolved edge is whether a sub-account or separate key is outside the drop-copy stream, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, recovery guarantee, price implication, settlement guarantee or platform ranking.
2. Reset calendar
Reset calendar is the decision point where public documentation must become an operating rule. In this package, it means scheduled resets and logon resets can break naive sequence assumptions. The practical action is to write the reset calendar into the reconciliation runbook. The unresolved edge is how the desk proves no execution report was missed around reset, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, recovery guarantee, price implication, settlement guarantee or platform ranking.
The operating test is also narrow. A public page can prove public wording.
3. Connection limit
Connection limit is the decision point where public documentation must become an operating rule. In this package, it means single-connection limits create failover design constraints. The practical action is to assign ownership for the active drop-copy connection. The unresolved edge is what happens if monitoring and production compete for the same key, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, recovery guarantee, price implication, settlement guarantee or platform ranking.
The operating test is also narrow. A public page can prove public wording.
4. Execution-report coverage
Execution-report coverage is the decision point where public documentation must become an operating rule. In this package, it means drop copy is useful only if the desk understands which order routes it covers. The practical action is to compare FIX, REST and application routes against the documented coverage. The unresolved edge is whether manual actions or other portfolios appear in the same stream, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, recovery guarantee, price implication, settlement guarantee or platform ranking.
The operating test is also narrow. A public page can prove public wording.
5. Change notice
Change notice is the decision point where public documentation must become an operating rule. In this package, it means execution-report fields can change through documented venue updates. The practical action is to subscribe the parser owner to venue change notices and schema tests. The unresolved edge is which optional fields are safe to ignore after a change, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, recovery guarantee, price implication, settlement guarantee or platform ranking.
The operating test is also narrow. A public page can prove public wording.
6. Fallback lookup
Fallback lookup is the decision point where public documentation must become an operating rule. In this package, it means REST order lookup can support reconciliation but is not the same as a live feed. The practical action is to define when to query by order ID or client order ID after a gap. The unresolved edge is how permission scope or outages limit the fallback, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, recovery guarantee, price implication, settlement guarantee or platform ranking.
The operating test is also narrow. A public page can prove public wording.
Known Unknowns
- whether a sub-account or separate key is outside the drop-copy stream
- how the desk proves no execution report was missed around reset
- what happens if monitoring and production compete for the same key
- whether manual actions or other portfolios appear in the same stream
- which optional fields are safe to ignore after a change
- how permission scope or outages limit the fallback
Practical Takeaway
FIX drop copy and sequence-reset documentation is a reconciliation-control signal, not a guarantee that a trading desk has complete books. Coinbase Exchange says FIX Drop Copy provides execution reports for orders placed through associated FIX sessions or REST API keys, while Coinbase International Exchange says each connection establishes a new session and sequence-number set, with weekly resets and optional reset on logon. The radar outcome is to map session scope, reset calendar, single-connection limit, execution-report coverage, client-order-ID handling, REST order lookup and gap recovery before relying on drop copy as the sole audit trail. The article stops at the evidence boundary. It helps the reader decide what to inspect next without converting public documentation into a promise that a private account, wallet, callback, policy framework, settlement route or liquidity position will work under every future condition.