Binary Framing
Binary order-entry messages use length-prefix framing over TLS.
Frame layout
| Offset | Width | Field | Notes |
|---|---|---|---|
| 0 | 4 bytes | Length | Payload length plus fixed binary header |
| 4 | 2 bytes | Message type | Unsigned integer enum |
| 6 | 2 bytes | Flags | Reserved for negotiated features |
| 8 | 8 bytes | Sequence | Monotonic per session |
| 16 | 8 bytes | Timestamp | Client send time |
| 24 | Variable | Payload | Message-specific binary payload |
All multi-byte integers are little-endian. Decimal fields use fixed-scale integer representation to avoid floating-point ambiguity.
Session sequence
Clients must increment the sequence number by one for every application message. The gateway rejects duplicates and stale sequences. Gap recovery is handled by session-level resend and state reconciliation through private streams or HTTP.
Compatibility
The flags field is reserved for negotiated feature bits. Clients must ignore unknown server feature announcements and must not send unsupported flags.
Checksums
Order-entry frames are protected by TLS transport integrity. Optional payload checksums can be negotiated for high-throughput market-maker sessions.