> ## Documentation Index > Fetch the complete documentation index at: https://docs.arcus.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Settle loan results > > **Endpoint:** `wss://api.arcus.xyz/v1/ws` — one socket multiplexes every channel and RPC request. Click **Connect**, then send the example subscribe message below to start receiving data. Per-account settleLoan request outcomes — the engine's ack for every `POST /v1/settleLoan`, `APPLIED` and `REJECTED` alike, one frame per request. The WS twin of the REST response body (same fields and display units), correlatable with the REST 202 ACK by `requestId`. This is the only WebSocket surface for settleLoan rejections: a reject moves no cash and produces no fill or state frame. An `APPLIED` settlement is additionally visible on `spotFills` as a `LOAN_SETTLE` fill, but only this channel carries the `requestId` correlation and the loan math (`repaidAmount` / `newLoanBalance`). Stream-only: no snapshot on subscribe (the `trades` precedent) — the subscribe ack carries empty contents (`{}`) and frames flow from the moment of subscription. ## AsyncAPI ````yaml api-reference/asyncapi.yaml settleLoanResults id: settleLoanResults title: Settle loan results description: > > **Endpoint:** `wss://api.arcus.xyz/v1/ws` — one socket multiplexes every channel and RPC request. Click **Connect**, then send the example subscribe message below to start receiving data. Per-account settleLoan request outcomes — the engine's ack for every `POST /v1/settleLoan`, `APPLIED` and `REJECTED` alike, one frame per request. The WS twin of the REST response body (same fields and display units), correlatable with the REST 202 ACK by `requestId`. This is the only WebSocket surface for settleLoan rejections: a reject moves no cash and produces no fill or state frame. An `APPLIED` settlement is additionally visible on `spotFills` as a `LOAN_SETTLE` fill, but only this channel carries the `requestId` correlation and the loan math (`repaidAmount` / `newLoanBalance`). Stream-only: no snapshot on subscribe (the `trades` precedent) — the subscribe ack carries empty contents (`{}`) and frames flow from the moment of subscription. servers: - id: mainnet protocol: wss host: api.arcus.xyz bindings: [] variables: [] - id: testnet protocol: wss host: api.testnet.arcus.xyz bindings: [] variables: [] address: /v1/ws?channel=settleLoanResults parameters: [] bindings: [] operations: - &ref_1 id: subscribeSettleLoanResults title: Subscribe settle loan results type: receive messages: - &ref_3 id: subscribe contentType: application/json payload: - name: Subscribe to an account channel type: object properties: - name: type type: string description: subscribe required: true - name: channel type: string enumValues: - account - positions - userFills - orders - funding - accountAttributeUpdates required: true - name: id type: string description: > Master Ethereum address (0x-prefixed) or an encoded internal account id. When an encoded id is used it already carries its own subaccount index; supplying `accountIndex` as well is allowed only if the two agree. Whichever spelling is sent, every response frame echoes the lowercase master address. required: true - name: accountIndex type: integer description: > Subaccount of the address in `id` to subscribe to. Honored on the account-scoped channels — `account`, `positions`, `spotPositions`, `orders`, `userFills`, `spotFills`, `funding`, `accountTransferUpdates`, `accountAttributeUpdates`, `settleLoanResults`. Omit for subaccount 0, which is what every client written before this field existed gets. It is part of subscription identity: each subaccount is a separate subscription with its own snapshot and stream, so one connection may hold several, and `unsubscribe` must repeat the same `accountIndex` — omitting it drops only subaccount 0. Supplying it on a channel that is not account-scoped (e.g. `l2Orderbook`, `trades`, `markets`) is an error, NOT a silently ignored field, for the same reason `market` is: a client that believed its stream was scoped to one subaccount would mis-handle the rest. A value outside 0-9 is likewise an error rather than a clamp — an out-of-range subaccount can never carry traffic, so accepting one returns a permanently silent subscription. required: false - name: snapshot type: boolean description: >- When false, suppress the initial state snapshot on subscribe and stream only live updates (e.g. userFills, orders). Defaults to true. required: false - name: nFills type: integer description: > Optional userFills-only snapshot size (default 500, max 500). Honored only on the userFills channel; ignored elsewhere. Live channel_data frames are unaffected. required: false - name: market type: string description: > Restrict this subscription to a single market. Honored only on `positions`, `orders`, and `userFills` — the account-scoped channels whose every frame is about exactly one market. Supplying it on any other channel (e.g. `account`, `accountTransferUpdates`) is an error, NOT a silently ignored field: a client that believed its stream was scoped to one market would mishandle every other market's data. Accepts the display ticker ("BTC-USD", case-insensitive) or the numeric market id ("1"), the same spellings as the REST `?market=` query param. Omit for every market; an unresolvable value is an error rather than an unfiltered stream. The filter applies to the subscribe snapshot, the live `channel_data` frames, and the post-snapshot catch-up alike, so the baseline and the diffs always describe the same markets. It is part of subscription identity: one connection may hold several market-filtered views of the same channel + id, and `unsubscribe` must repeat the market it subscribed with (an `unsubscribe` with no `market` matches only the unfiltered view). The `subscribed` / `unsubscribed` acks echo the resolved ticker. required: false headers: [] jsonPayloadSchema: type: object required: - type - channel - id properties: type: type: string const: subscribe x-parser-schema-id: channel: type: string enum: - account - positions - userFills - orders - funding - accountAttributeUpdates x-parser-schema-id: id: type: string description: > Master Ethereum address (0x-prefixed) or an encoded internal account id. When an encoded id is used it already carries its own subaccount index; supplying `accountIndex` as well is allowed only if the two agree. Whichever spelling is sent, every response frame echoes the lowercase master address. example: 0xAbCd...1234 x-parser-schema-id: accountIndex: type: integer description: > Subaccount of the address in `id` to subscribe to. Honored on the account-scoped channels — `account`, `positions`, `spotPositions`, `orders`, `userFills`, `spotFills`, `funding`, `accountTransferUpdates`, `accountAttributeUpdates`, `settleLoanResults`. Omit for subaccount 0, which is what every client written before this field existed gets. It is part of subscription identity: each subaccount is a separate subscription with its own snapshot and stream, so one connection may hold several, and `unsubscribe` must repeat the same `accountIndex` — omitting it drops only subaccount 0. Supplying it on a channel that is not account-scoped (e.g. `l2Orderbook`, `trades`, `markets`) is an error, NOT a silently ignored field, for the same reason `market` is: a client that believed its stream was scoped to one subaccount would mis-handle the rest. A value outside 0-9 is likewise an error rather than a clamp — an out-of-range subaccount can never carry traffic, so accepting one returns a permanently silent subscription. minimum: 0 maximum: 9 default: 0 example: 3 x-parser-schema-id: snapshot: type: boolean description: >- When false, suppress the initial state snapshot on subscribe and stream only live updates (e.g. userFills, orders). Defaults to true. default: true x-parser-schema-id: nFills: type: integer description: > Optional userFills-only snapshot size (default 500, max 500). Honored only on the userFills channel; ignored elsewhere. Live channel_data frames are unaffected. default: 500 maximum: 500 minimum: 1 x-parser-schema-id: market: type: string example: BTC-USD description: > Restrict this subscription to a single market. Honored only on `positions`, `orders`, and `userFills` — the account-scoped channels whose every frame is about exactly one market. Supplying it on any other channel (e.g. `account`, `accountTransferUpdates`) is an error, NOT a silently ignored field: a client that believed its stream was scoped to one market would mishandle every other market's data. Accepts the display ticker ("BTC-USD", case-insensitive) or the numeric market id ("1"), the same spellings as the REST `?market=` query param. Omit for every market; an unresolvable value is an error rather than an unfiltered stream. The filter applies to the subscribe snapshot, the live `channel_data` frames, and the post-snapshot catch-up alike, so the baseline and the diffs always describe the same markets. It is part of subscription identity: one connection may hold several market-filtered views of the same channel + id, and `unsubscribe` must repeat the market it subscribed with (an `unsubscribe` with no `market` matches only the unfiltered view). The `subscribed` / `unsubscribed` acks echo the resolved ticker. x-parser-schema-id: x-parser-schema-id: SubscribeByAddressPayload title: Subscribe to an account channel example: |- { "type": "subscribe", "channel": "account", "id": "0xAbCd...1234" } bindings: [] extensions: - id: x-parser-unique-object-id value: subscribe bindings: [] extensions: &ref_0 - id: x-parser-unique-object-id value: settleLoanResults - &ref_2 id: receiveSettleLoanResults title: Receive settle loan results type: send messages: - &ref_4 id: update contentType: application/json payload: - name: Settle Loan Result Update description: > One engine-confirmed settleLoan outcome per frame (`APPLIED` or `REJECTED`), mirroring the `POST /v1/settleLoan` response body. See the openapi `SettleLoanResultMessage` schema. type: object properties: - name: type type: string description: >- `subscribed` for the initial snapshot; `channel_data` for updates. enumValues: - subscribed - channel_data required: true - name: channel type: string description: Channel name. required: true - name: id type: string description: > Channel id (market, or the lowercase master Ethereum address on account-scoped channels). Absent for global channels. Always lowercase for addresses regardless of the spelling used to subscribe, so compare it case-insensitively. required: false - name: accountIndex type: integer description: > Subaccount this frame belongs to. Present on EVERY frame of an account-scoped channel — `subscribed`, `unsubscribed`, `degraded`, and `channel_data` alike — including when it is 0, so a frame names its subaccount outright and no client needs a "missing means 0" rule. Omitted on every other channel. This is what makes several subaccounts of one address demuxable on a single connection: `id` alone is the master address and is identical across all of them. required: false - name: sigFigs type: integer description: > Echo of the l2Orderbook aggregation this frame belongs to. Omitted on full-precision views and on every other channel. Lets a client holding several aggregations of the same market demux snapshots. enumValues: - 2 - 3 - 4 - 5 required: false - name: roundStep type: integer description: >- Echo of the l2Orderbook roundStep for this view. Omitted unless sigFigs is 5 and roundStep was 2 or 5. enumValues: - 1 - 2 - 5 required: false - name: throttleMs type: integer description: > Echo of the throttleMs cadence requested on subscribe. Present on the `subscribed` ack for `bbo` and `oraclePrices` when throttling was requested; absent otherwise and absent on `channel_data` frames (it is not part of subscription identity, so there is nothing to demux). enumValues: - 100 - 250 - 500 - 1000 - 2000 required: false - name: market type: string description: > Display ticker of the market this frame belongs to, always the resolved ticker even when the client subscribed by numeric id. Present only on `positions` / `orders` / `userFills`; omitted on every other channel. Its meaning differs slightly by frame type. On `subscribed` / `unsubscribed` it echoes the market filter the subscription was created with, and is omitted for an unfiltered subscription. On `channel_data` it is the market of the frame itself, so an UNFILTERED subscriber sees it too — those channels emit one frame per market, so every frame has one. This is what lets a client demux, exactly as `sigFigs` / `roundStep` do for l2Orderbook: a connection holding several market-filtered views of one account matches each frame to the right view by this field. Clients that hold a single unfiltered view can ignore it. required: false - name: contents type: object description: Channel-specific payload. Schema varies by channel. required: false properties: [] headers: [] jsonPayloadSchema: type: object description: Common envelope for all server-pushed channel messages. required: - type - channel properties: type: type: string enum: - subscribed - channel_data description: >- `subscribed` for the initial snapshot; `channel_data` for updates. x-parser-schema-id: channel: type: string description: Channel name. x-parser-schema-id: id: type: string description: > Channel id (market, or the lowercase master Ethereum address on account-scoped channels). Absent for global channels. Always lowercase for addresses regardless of the spelling used to subscribe, so compare it case-insensitively. x-parser-schema-id: accountIndex: type: integer description: > Subaccount this frame belongs to. Present on EVERY frame of an account-scoped channel — `subscribed`, `unsubscribed`, `degraded`, and `channel_data` alike — including when it is 0, so a frame names its subaccount outright and no client needs a "missing means 0" rule. Omitted on every other channel. This is what makes several subaccounts of one address demuxable on a single connection: `id` alone is the master address and is identical across all of them. minimum: 0 maximum: 9 example: 3 x-parser-schema-id: sigFigs: type: integer description: > Echo of the l2Orderbook aggregation this frame belongs to. Omitted on full-precision views and on every other channel. Lets a client holding several aggregations of the same market demux snapshots. enum: - 2 - 3 - 4 - 5 x-parser-schema-id: roundStep: type: integer description: >- Echo of the l2Orderbook roundStep for this view. Omitted unless sigFigs is 5 and roundStep was 2 or 5. enum: - 1 - 2 - 5 x-parser-schema-id: throttleMs: type: integer enum: - 100 - 250 - 500 - 1000 - 2000 description: > Echo of the throttleMs cadence requested on subscribe. Present on the `subscribed` ack for `bbo` and `oraclePrices` when throttling was requested; absent otherwise and absent on `channel_data` frames (it is not part of subscription identity, so there is nothing to demux). x-parser-schema-id: market: type: string example: BTC-USD description: > Display ticker of the market this frame belongs to, always the resolved ticker even when the client subscribed by numeric id. Present only on `positions` / `orders` / `userFills`; omitted on every other channel. Its meaning differs slightly by frame type. On `subscribed` / `unsubscribed` it echoes the market filter the subscription was created with, and is omitted for an unfiltered subscription. On `channel_data` it is the market of the frame itself, so an UNFILTERED subscriber sees it too — those channels emit one frame per market, so every frame has one. This is what lets a client demux, exactly as `sigFigs` / `roundStep` do for l2Orderbook: a connection holding several market-filtered views of one account matches each frame to the right view by this field. Clients that hold a single unfiltered view can ignore it. x-parser-schema-id: contents: type: object additionalProperties: true description: Channel-specific payload. Schema varies by channel. properties: {} x-parser-schema-id: x-parser-schema-id: ChannelDataEnvelope title: Settle Loan Result Update description: > One engine-confirmed settleLoan outcome per frame (`APPLIED` or `REJECTED`), mirroring the `POST /v1/settleLoan` response body. See the openapi `SettleLoanResultMessage` schema. example: |- { "type": "", "channel": "", "id": "", "accountIndex": 123, "sigFigs": 123, "roundStep": 123, "throttleMs": 123, "market": "", "contents": {} } bindings: [] extensions: - id: x-parser-unique-object-id value: update bindings: [] extensions: *ref_0 sendOperations: - *ref_1 receiveOperations: - *ref_2 sendMessages: - *ref_3 receiveMessages: - *ref_4 extensions: - id: x-parser-unique-object-id value: settleLoanResults securitySchemes: [] ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.