Institutional Onboarding

Status: Implemented. Onboarding is operator-assisted; the technical steps below are what you and Rocky operations complete together.

This page is for market makers and other institutions connecting to the Spot API with their own Canton party. It covers what you need before you start, how your account is bound to your party, the on-chain authorizations that settlement requires, key registration, the sandbox, and the go-live checklist. Commercial terms (credit, fees, support) are agreed separately and summarized in your Integration Pack.

1. Prerequisites

Requirement	Why
A Canton party you control, hosted on a validator/participant you operate or a supported wallet	Settlement is wallet-to-wallet DvP; your party is the counterparty on-chain. The party id (<name>::<fingerprint>) is what Rocky binds your account to.
The assets you will trade, in that party's wallet	Your spot balance is a mirror of the wallet; there is no exchange deposit. See Mirror balances.
An Ed25519 keypair for API signing (recommended) or acceptance of an HMAC shared secret	See Authentication. With Ed25519, Rocky never holds a secret that can sign as you.
Fixed egress IP(s) for your trading hosts	Per-IP rate buckets and the WebSocket connection cap are keyed on client IP; Rocky records your IPs for monitoring and 429 attribution. They are not exempted from the IP buckets; if the connection cap is too low for your setup, Rocky raises it by configuration.
The symbols you will quote and your expected order rate	Determines the rate tier and lets Rocky verify receiver preapprovals for exactly the assets involved.
Signed credit terms	Settlement is optimistic (see risk disclosure).

2. Account creation and party binding

Rocky operations create your trading account and bind it to your Canton party. Send, through the secure channel agreed in your Integration Pack:

1. Canton party id.
2. Validator / wallet type and how your party signs transactions (this determines the MemberAuth path in step 4).
3. Trading symbols and expected peak orders per minute.
4. Egress IP addresses.
5. Ed25519 public key (step 3 below), or a request for an HMAC key.

Rocky returns your API key identifier, confirms the rate tier (ext-mm unless agreed otherwise), and confirms the party binding. From this point the account is party-bound: once on-chain settlement is active for the venue, it cannot place orders until enrollment is complete (-2012, see §4), and internal exchange transfers to or from it are disabled — your wallet is the only funding source.

3. Ed25519 public-key registration

1. Generate a keypair on a machine you control. Keep the 32-byte seed / private key in your signing infrastructure; it never leaves it.

   openssl genpkey -algorithm ed25519 -out spot-ed25519.pem
   openssl pkey -in spot-ed25519.pem -pubout -outform DER | tail -c 32 | base64 > spot-ed25519.pub.b64
   base64 -d spot-ed25519.pub.b64 | sha256sum   # fingerprint = SHA-256 of the raw 32 bytes; read back the first 16 hex characters

2. Send the base64 public key (44 characters, decoding to exactly 32 bytes) over the secure channel. Public keys are not secret, but they must not be tampered with in transit: both sides read the fingerprint (SHA-256 of the raw 32-byte key, first 16 hex characters) back to each other over a second channel (voice or the commercial contact's mailbox) before the key is registered.

3. Rocky registers the key as type ED25519 on your account and returns the API key identifier. No secret is issued for an Ed25519 key.

4. Validate your signer against the reference vector before your first request, then confirm with a signed GET /api/v3/account on the sandbox.

Self-service: once your wallet session is bound, you can also create and revoke keys yourself on the web app's API Keys page or via /v1/api-keys; keys created there start on the standard tier and Rocky operations raise the tier on request.

Rotation: send a new public key; Rocky registers it and revokes the old one at an agreed time. Revocation is immediate on request (-2015 afterwards). A key's type cannot change; to move from HMAC to Ed25519, register a new key.

4. MemberAuth (on-chain settlement authorization)

MemberAuth is a Canton contract between your party and Rocky's settlement operator. It authorizes the operator to execute the two-leg DvP for fills involving your party — nothing else. Without it, your fills have no on-chain path: a settlement attempted without it lands failed. The gateway's -2012 gate is keyed on enrollment in the wallet-funded segment (Rocky's registration of your party), which the wallet-driven path completes automatically on execute and which Rocky operations complete at account creation on the operator-assisted path; MemberAuth itself is checked at settlement, not at order entry.

MemberAuth is created once per party. Completing it also enrolls the party in the wallet-funded segment: from that moment your spot balance mirrors your wallet and fills settle at zero fee.

Path A — wallet-driven (browser or programmatic session)

If your party lives in a supported wallet (Rocky Wallet, Loop, Console, Send), MemberAuth is completed through the exchange session API, proxied at /v1/spot-chain/… and authenticated with an exchange wallet-session bearer token (obtained by connecting the wallet to the Rocky web app or its session endpoints):

Step	Call	Result
Check	GET /v1/spot-chain/member-auth	{"authorized": false, "partyId": "...", "memberAuthContractId": null, "proposalContractId": null}
Propose	POST /v1/spot-chain/member-auth/proposal	Same fields plus transaction: a prepared accept transaction (commandId, actAs, readAs, disclosedContracts, synchronizerId, …) to be signed and submitted by your wallet
Sign and submit	your wallet	Loop / Console / Send submit the transaction object directly. Rocky Wallet instead calls POST /v1/spot-chain/member-auth/prepare (returns preparedTransactionHash, hashingSchemeVersion, commandId), signs the hash, and calls POST /v1/spot-chain/member-auth/execute with {"signature": "..."}
Confirm	GET /v1/spot-chain/member-auth	authorized: true with memberAuthContractId set; typically within a few seconds

Path B — operator-assisted (own validator)

If your party is hosted on your own participant, Rocky operations create the MemberAuth proposal for your party on request. You then exercise the accept choice from your own participant (Canton console, JSON Ledger API, or your signing service) and tell Rocky when it is done. Rocky confirms enrollment and the party appears in the wallet-funded segment on the next reconciliation.

Either way, the end state is the same contract; the account trades identically afterwards.

5. Receiver preapproval

On Canton, a Token Standard transfer executes atomically (transferKind: direct) only if the receiver has a standing preapproval for that instrument. Without it, a transfer degrades to a two-phase offer, which the DvP cannot use — the settlement leg fails.

For every asset you can receive in your symbols (the base asset when you buy, the quote asset when you sell), your party must hold a receiver preapproval for that instrument on your participant. Before go-live, Rocky runs a probe for each asset in each direction (Rocky custody → your party, and your party → Rocky custody) against the instrument's registry and requires every probe to report direct. You will receive the per-asset result; any offer or missing result must be fixed on your side (create the preapproval, and for Amulet/CC ensure it is funded) before that asset's symbols are enabled.

If you use a wallet that manages preapprovals automatically (Rocky Wallet, Loop, Console, Send), this is typically already in place for supported assets; confirm with the probe result anyway.

6. Sandbox

Rocky provides a sandbox environment that runs the same gateway, matching engine, and settlement pipeline against a test Canton network. The base URLs and a sandbox API key are in your Integration Pack. The onboarding steps above are repeated on the sandbox first — party binding, key registration, MemberAuth, preapprovals — using a test party.

Rocky also provides an integration simulator (Python) that exercises the whole surface with your key: ping → time → exchangeInfo → depth → LIMIT order above minNotional → query → cancel → myTrades (asserting settlementStatusis present) → WebSocketdepth5andtrade frames, and self-tests its Ed25519 signer against the reference vector. Run it against the sandbox with your own seed before connecting your trading system; a green run is the sandbox acceptance criterion.

7. Go-live checklist

All items are confirmed by both sides before production keys are enabled for trading.

• Production party bound to the account; label and rate tier (ext-mm) confirmed by Rocky.
• Ed25519 public key registered; fingerprint confirmed on a second channel; signer validated against the reference vector.
• MemberAuth authorized: true for the production party.
• Receiver preapproval probe reports direct for every asset, both directions.
• First mirror reconciliation shows a non-zero balance in GET /api/v3/account matching the wallet.
• Sandbox: simulator run green; at least one fill reached settlementStatus: "confirmed".
• Production: one small fill in each direction reached confirmed; the cantonUpdateIds were verified on Canton by both sides and retained.
• Egress IPs confirmed; rate tier headroom checked against your expected order rate (X-MBX-USED-WEIGHT-1M / X-MBX-ORDER-COUNT-1M observed during the sandbox run).
• Rocky monitoring includes your party (failed-settlement and drift alerts).
• Credit terms signed; support channel and incident format agreed (Integration Pack).

8. Operating notes

Running a quoting or volume strategy from your own validator? The External Market Maker Guide covers the per-fill Canton traffic cost, kill-switch and reconciliation endpoints, and multi-account behaviour.

• Funding: transfer assets into the bound wallet; the mirror credits free within two reconciliation cycles (30 s each — a newly seen on-chain surplus is confirmed on one round and credited on the next). There is no deposit call and no withdrawal call.
• Keep settlement inventory in the wallet. Moving assets out while you have open orders or unsettled sells triggers clamp, order cancellation, and possibly a freeze (-2010 Account is frozen…). Unfreezing is manual.
• Zero fees on every fill that settles on-chain; commission is "0".
• Self-trade prevention is always on; your own resting orders are skipped.
• Minimum notional applies to every order (-1013); read minNotional from exchangeInfo.
• Reconcile fills against myTrades and treat anything not confirmed as unsettled.