Skip to main content

External Market Maker Guide

Scope. For market makers and volume providers that trade Spot from their own Canton party, hosted on a validator they operate or a supported wallet. It builds on Institutional Onboarding (how the account is created) and On-chain Settlement (how a fill is delivered) and covers what is different about running a quoting or volume strategy on Rocky: every fill is an on-chain transaction that your validator pays for.

1. What makes Rocky different​

On a custodial exchange your inventory sits in the exchange's wallet and fills are ledger entries. On Rocky's wallet-funded segment:

Custodial exchangeRocky wallet-funded segment
InventoryDeposited with the exchangeStays in your Canton party; the spot balance is a mirror of it
A fillA database rowOne Canton transaction: a two-leg DvP between your party and the counterparty's party (or Rocky's custody party when the counterparty is a house account)
Who signsThe exchangeRocky's settlement operator, under the MemberAuth you granted; your participant confirms
FeesMaker/taker bpsMaker/taker bps (4 / 10), withheld from the on-chain leg
Cost per fillFee onlyCanton traffic, paid in CC by your validator
WithdrawalA request and a waitNone: settled assets are already in your wallet

The last two rows are the economics of market making here. You pay the maker fee on every fill, and there is a real, per-fill network cost on top that Rocky does not reimburse.

2. Canton traffic: the cost you carry​

Every message a participant sends to the Global Synchronizer consumes sequencer traffic, which validators buy with CC. Your validator pays for:

  • Confirmation responses on every fill. Your party is a stakeholder on its own leg of each DvP, so your participant must confirm each settlement transaction. This is the recurring cost and it scales with fill count, not fill size.
  • Transactions you submit yourself: moving assets into or out of the bound wallet, creating receiver preapprovals, accepting the MemberAuth proposal (operator-assisted path), and any Offer you accept for assets without a direct preapproval.
  • Background protocol traffic (ACS commitments, topology) that a participant produces regardless of trading.

Rocky's settlement operator pays for the submission itself; you pay for your side. What a single confirmation costs in CC depends on the transaction size and the Synchronizer's current traffic price. Read the number from your validator, not from this page: the validator UI and the Scan API show traffic purchased and consumed per round. For sizing, Rocky measured its own side of a two-leg DvP in September 2026 at roughly 32 KB of sequencer traffic on the allocate-and-execute path and 14 KB on the direct-transfer path it now uses by default (about $1.9 and $0.8 at the then-current $60/MB governance price); your confirmation is a fraction of that, and Rocky publishes its own lane-by-lane consumption at GET /v1/traffic. The direct path needs a direct receiver preapproval on every asset you trade — one more reason §2.4 matters.

Practical consequences

  1. Cost is per fill, not per notional. Ten fills of 0.001 CBTC cost ten times the traffic of one fill of 0.01 CBTC. Quote sizes at or above the level where the spread captured covers the traffic per fill, and treat minNotional in exchangeInfo as a floor, not a target.
  2. Volume programs pay on both legs. If you run two of your own parties against each other to generate prints, both validators confirm every fill; self-trade prevention only stops a single account from matching itself (see §5). Budget CC per print before choosing a cadence.
  3. Keep the validator funded. A validator that runs out of traffic stops confirming; the settler then sees timeouts, the fill sits in retry, and after the attempt cap it is failed while the internal balances already reflect the fill. Monitor your traffic balance the way you monitor inventory.
  4. Prefer direct preapprovals. An Offer costs an extra accept transaction on your side per fill and, for DvP, does not work at all: the leg fails. Rocky's pre-go-live probe must report direct for every asset in both directions.

3. Account model and limits​

  • Segment: GET /api/v3/account reports settlement.segment (wallet once enrolled and settlement is active for the venue, internal otherwise), settlement.frozen, and the bound party. canTrade is false while frozen. See Account Information.
  • Funding: transfer into the bound wallet; the mirror credits free after two 30-second reconciliation rounds. /v1/spot/transfer and /v1/withdrawals are rejected for enrolled accounts.
  • Inventory discipline: moving assets out of the wallet while you have open orders or unsettled sells is negative drift. The reconciler reduces free, then cancels orders on that asset, then freezes the account if the shortfall is still uncovered. Unfreezing is a manual operations action. See Mirror balances.
  • Rate tier: ext-mm (2400 weight/min, 100 orders/10 s, 600 orders/min), assigned at onboarding. Cancels never consume order quota. See Rate limits.
  • Order types: LIMIT (GTC) and MARKET (IOC) only. There is no post-only flag; a limit that crosses will take. There is no batch order, cancel-replace, or user-data stream today (§8).

4. Quoting workflow​

Reference implementation: Rocky-DEX/Rocky-API-Maker-Bot (Python and TypeScript clients, quoter and reconciliation examples); snippets on the Quickstart page.

  1. Bootstrap: GET /api/v3/exchangeInfo for tickSize, stepSize, minNotional; GET /api/v3/account to confirm settlement.segment: "wallet" and read the mirror balance.
  2. Place: POST /api/v3/order per level. Send a newClientOrderId per quote for 15-minute idempotency on retries.
  3. Track fills by order: GET /api/v3/myTrades returns orderId on every fill and accepts orderId= as a filter, so a fill maps back to the quote it hit without price/time correlation. See Account Trade List.
  4. Pull a ladder: DELETE /api/v3/openOrders?symbol= cancels every resting order on the symbol in one weight-1 call that is not charged to the order buckets. Use it as the kill switch on disconnect, price-feed loss, or validator alerts. See Cancel All Orders.
  5. Query a finished order: GET /api/v3/order returns FILLED / CANCELED orders from history as well as open ones.

5. Self-trade prevention and multi-account programs​

STP is always on and cannot be configured: an incoming order skips resting orders of the same account rather than matching them. It does not apply across accounts. Two API keys on two different parties will match each other, and each such fill is a real DvP on both validators. Fills between two wallet parties settle wallet-to-wallet; fills against a Rocky house account settle against Rocky's custody party.

6. Settlement reconciliation​

Every fill on the wallet segment has a settlement row: pending → processing → confirmed, with retry on transient errors and failed as the terminal error state (see the status machine). Reconcile against it, not against the order acknowledgement.

  • GET /api/v3/settlements lists your settlement rows with attempts, lastError, nextAttemptTime and the cantonUpdateId once confirmed; filter by symbol and status.
  • GET /api/v3/settlements/summary returns counts per status per symbol and unsettledQuoteQty, the quote notional still waiting on chain. Watch it as queue depth: settlement is serialized per venue, so sustained fill rates above what the chain absorbs show up here first as growing pending.
  • A failed row means Rocky operations are already alerted. Your internal balance reflects the fill; the on-chain delivery is resolved manually. Do not re-quote the inventory twice.

See Settlement Ledger.

7. Operational checklist​

Before enabling a strategy in production:

  • Validator traffic balance monitored with an alert threshold that covers at least one day of expected fills.
  • Receiver preapproval probe direct for every asset in both directions; no Offer path in use.
  • GET /api/v3/account shows settlement.segment: "wallet", frozen: false, and a mirror balance matching the wallet.
  • Kill switch wired to DELETE /api/v3/openOrders per symbol, triggered on feed loss, API errors, and validator alerts.
  • Reconciliation job polls settlements/summary and alarms on failed > 0 or unsettledQuoteQty above your tolerance.
  • Quote size chosen so spread capture per fill exceeds traffic cost per fill.

8. Not available today​

Documented so you do not design around them: user-data WebSocket stream, batch order placement, cancel-replace, post-only / IOC / FOK time-in-force, configurable STP modes, API-key IP allowlists and scopes, volume-based fee tiers. Poll openOrders (weight 1) and myTrades / settlements (weight 10) at a cadence that fits your tier.