Skip to main content

BSL Byte Encoding

BSL has two byte-oriented order-entry surfaces:

SurfaceTransportUse
BSL Direct TCPPersistent TCP/TLS with 48-byte handshake and 8-byte frame headersLatency-sensitive market making.
BSL compact HTTPHTTP POST body containing SDK JSON bytesCompatibility, onboarding, and admin-friendly bots.

Older docs and code may call these binary or MM; those are compatibility names. BSL is the product name.

Native Direct TCP​

Use GET /api/v1/bsl/connectivity and read bslTcp:

protocol: senticore-bsl-tcp-v2
transport: tcp_tls
handshake: 48 bytes
message header: u32_le kind + u32_le payload_len
compact action frame: 192 bytes

See BSL Direct TCP for the full session flow.

HTTP Compatibility Bundle​

Current private-beta tested submit path:

POST /api/order-entry/binary
Content-Type: application/x-senticore-order-entry-batch
X-BSL-Result-Mode: ack
X-Senticore-Response-Mode: detailed

Direct trading-plane compatibility path:

POST /api/v1/mm/orders/batch.bin

Canonical BSL path after edge rollout:

POST /api/v1/bsl/orders/compact

Payload Shape​

{"version":1,"actions":[...],"idempotencyKey":"client-batch-1"}

Each actions[] item is the same signed action envelope used by normal sequencer ingress. There is no separate matching, risk, lifecycle, or settlement semantics for compact order entry.

Access​

Every mutating action needs a valid account or delegated signature. A provisioned order-entry lane key may be assigned for dedicated limits:

X-Senticore-Order-Entry-Key: <order-entry-api-key>

That key is not a public session token and is not generated by the SDK. It authorizes a lane and rate tier; it does not replace the signed action.

ACK and Reconciliation​

The beta detailed response confirms acceptance at the configured boundary and returns derived order ids where available. It does not guarantee final fill or final book state. Reconcile through account/order reads, private streams, or FIX drop-copy where provisioned.

Next​