Tracking settlement

The event sequence after an accept

No event marks the accept itself — your quote just shows settling: true in a snapshot. Then:

trade.step {step: "allocated"}           every allocation of the trade is committed
  └► quote.status {status: "won"}        + rfq.closed
  └► trade.settled {TradeDto}            atomic settle executed — the proof
        — or —
     quote.status {status: "revoked"}    + trade.failed {tradeId, rfqId, reason}

trade.step.refs carries the contract ids each phase created. These events are ephemeral — they exist only on the stream. The durable record is the TradeDto.

The proof

trade.settled (and later GET /maker/trades) carries:

{
  "tradeId": "…", "price": "97300.0", "fee": "121.625",
  "settledAt": "2026-07-19T10:00:02Z",
  "ledger": {
    "updateId": "1220ab…",
    "receiptCids": ["00c1…", "00d2…"]
  }
}

The ledger block is the on-ledger proof of the trade — what updateId and receiptCids are, and what they prove, is in Atomic settlement.

Reconciling after downtime

The stream does not replay missed trade events (the snapshot covers RFQs and quotes only). After downtime, reconcile via:

curl -H "X-API-Key: $API_KEY" "$API_URL/maker/trades?limit=100"

Newest first, limit 1–500 (default 100). Only settled trades are recorded: one still in flight appears here once it settles. Each carries the ledger block — absent only on trades recorded before the field existed, or on a settle the desk recorded after losing its response (the receipts alone, no update id).

After a trade.settled, GET /wallet/holdings shows your new balance.