Skip to main content
Fund your cash with crypto on Solana
  • submit_crypto_funding on Solana. A USDC deposit sent on Solana is credited like one on an EVM chain: send its base58 signature as txHash, as it is (signatures are case-sensitive), with chainId 101 (or 901 in sandbox). get_crypto_funding lists Solana in depositTo where it is offered, with the USDC mint as tokenAddress, and your Solana wallets in fromWallets with namespace: "solana". Nothing changes for EVM deposits. See Fund your cash with crypto.
ISIN and CUSIP in get_symbols
  • get_symbols names each chain’s isin and cusip (2026-11-04): the identifiers of the security behind that chain’s CET, beside its tokenAddress. They are per chain, since each chain is its own CET. A chain without one leaves the field out rather than sending null. Nothing else in get_symbols changes.
A reference the broker refused
  • Correction: a reference the broker refused cannot be used again the same day (2026-11-04). These pages said the reference of an order the broker rejected could be reused. The broker keeps it for the rest of the day, so resending answers INVALID_ORDER as a duplicate: send the order under a new externalRef. A reference refused by Securitize before the order reached the broker (your own cash, the symbol, the order’s shape) is still usable. An order the broker refused as it was placed was never created, so get_order answers ORDER_NOT_FOUND for it.
Time in force and tick size
  • Only DAY is supported as timeInForce (2026-11-04). The contract listed GTC, IOC and FOK, but the broker does not offer them through its API: IOC and FOK answer INVALID_ORDER, and a GTC order is refused by the broker after its ack. Nothing changes for an order that sends DAY or leaves timeInForce out.
  • Tick size for limitPrice. A price of 1.00 or more must be in whole cents, at most 2 decimal places; the broker refuses a finer one as sub-penny. Only a price under 1.00 may use 4. See Limits on an order.
Fund your cash with crypto
  • New read: get_crypto_funding (2026-11-03). Where to send USDC to fund your own cash: depositTo, Securitize’s wallets, one per chain and token with the token’s contract and the confirmations a deposit needs, and fromWallets, your own wallets a deposit must come from. When crypto funding is not enabled for you, enabled is false and depositTo is empty. Like every read, it is not signed and a read-only key may send it, and it is served over HTTP too, as GET /v1/market-maker/crypto-funding.
  • New: submit_crypto_funding. Send the chainId and txHash of a USDC deposit you sent to one of depositTo, and it is credited to your own cash in USD, one for one, once the transaction succeeded and is final. EVM chains only. Signed like place_order; a read-only key answers NOT_PERMITTED. A transaction is credited once, whoever sends it, and sending it again answers the same credit. The credit shows in get_cash_movements and get_cash_balance_v2; it is not pushed as cash_movement. Two new error codes: DEPOSIT_PENDING, not on chain yet or not final, and DEPOSIT_REFUSED, not credited as sent. See Fund your cash with crypto.
Every redemption balance at once
  • New read: get_redemption_balances (2026-10-28). Your redemption balance in every CET you can trade, in one read: the ack carries balances, one entry per symbol and chain with the same deposited, burned, reserved and available as get_redemption_balance, sorted by symbol and then chain. symbol and chainId are optional and narrow the list; nothing matching is an empty list, not an error. Like every read, it is not signed and a read-only key may send it, and it is served over HTTP too, as GET /v1/market-maker/redemption-balances. get_redemption_balance is unchanged. See Reads over HTTP.
Reads over HTTP
  • New: the reads as signed GET requests. Your redemption balance, an order, mints, burns, your cash and its movements answer over HTTP too, with no session: the query parameters are the message’s payload fields, and the body is the ack’s payload. Every request carries your public key, a timestamp and an Ed25519 signature over timestamp.GET.path-and-query, with the same key you sign hello with; a read-only key is enough. Failures answer the socket’s codes with an HTTP status. See Reads over HTTP.
Fund your cash in sandbox
  • New in sandbox: sandbox_deposit and sandbox_withdraw (2026-10-26). They move USD into and out of your own cash, so you can fund yourself and test the cash flow end to end. Signed like place_order, with an amount and your own clientRef, which never moves money twice. Each is booked about a minute later and pushed as cash_movement. Sandbox only: in production they answer MALFORMED. See Sandbox funding.
Contract and guides aligned
  • quantity, notional and limitPrice patterns now reject zero and leading zeros in the contract too, as the server always has.
  • Reconnect on any close, not only 1001; a session that cannot be opened for a moment (UPSTREAM_UNAVAILABLE) or a clock off by more than 30 seconds keeps the socket: send a new hello.
  • A symbol your account does not trade answers INVALID_ORDER, mistyped or not; INVALID_SYMBOL is left for a symbol the broker no longer recognises.
get_positions retired
  • get_positions is retired. It reported the broker account as a whole, which other clients trade through too, rather than what is yours. Your shares are the CETs in your wallet; get_mints and get_burns say how they got there, and get_cash_balance_v2 what your orders cost and brought in.
Your own cash
  • New read: get_cash_balance_v2. Your own cash, per currency: what you deposited and withdrew, the fees charged to you, what your orders bought and sold, your balance after all of it (netBalance), what your working buys hold (committed), and available, what a new buy can spend. See Your own cash.
  • New read: get_cash_movements, the deposits, withdrawals and fees behind your balance, newest first, and a new push, cash_movement, when one is recorded or cancelled.
  • A buy is paid from your own cash. It must be a LIMIT order by quantity, and quantity × limitPrice plus its fees is held against your available before it reaches the broker. A buy that cash does not cover, a MARKET buy and an order by notional, buy or sell, answer INVALID_ORDER. With orders in money gone, so is their 100,000 USD ceiling.
Redemption balance
  • New read: get_redemption_balance. Send a symbol and a chainId, as get_symbols lists them, and the ack carries your own balance in that CET’s redemption wallet: deposited, burned, reserved and available. Like every read, it is not signed and a read-only key may send it.
  • A sell is checked against your redemption balance. The redemption wallet is shared by every account that sells the CET, so each transfer to it is credited to the account whose wallet sent it, and a sell may only draw on what was credited to it and not already held by its other sells. A sell for more answers INVALID_ORDER with your figures. Read get_redemption_balance after a transfer to know when it has been credited. See Sell shares and redeem CETs.
Redemption wallet
  • New read: get_redemption_address. Send a symbol and a chainId, as get_symbols lists them, and the ack carries the CET’s tokenAddress and its redemptionAddress: the wallet to send the CETs to before you sell. Like every read, it is not signed and a read-only key may send it. A symbol and chain you cannot trade answers INVALID_SYMBOL. See Sell shares and redeem CETs.
Fees on orders
  • get_order carries fees and feeTotal: the fees charged on the order’s trades, one per trade with its status, and their sum. Fees are charged after the fill, when each trade reaches the broker’s ledger, so the list can grow after the order has filled. Fees charged before this change are not listed. See Fees.
Generating a keypair
  • Sandbox and authentication shows how to generate the Ed25519 keypair with OpenSSL, print both keys in base58, and what to send Securitize to register it. Any Ed25519 keypair works, whatever chain your CETs are minted on.
Burn transaction hash
  • Burns carry txHash, the hash of their transaction on its chain, already on the first burn_updated, and get_burns takes it as a filter. Burns from before this change have none. See The transaction hash.
  • A burn’s memo is written on chain on Solana, as a mint’s is. The docs said it was not: a burn can be found from its transaction, by txHash, or on Solana by the traceId at the end of its memo.
Mint transaction hash
  • Mints carry txHash, the hash of their transaction on its chain, and get_mints takes it as a filter. Mints from before this change have none. On an EVM chain the mint transaction carries no memo, so this is the way from a transaction to its mint there. See The transaction hash.
  • A mint is usually pushed up to three times. mint_updated usually comes again within a minute of a mint landing, carrying its txHash, and the same snapshot can occasionally arrive twice. Overwrite the mint you hold by traceId, as before.
Selling after a transfer
  • Sell shares and redeem CETs says when the CETs count. A transfer to the redemption wallet counts once it is confirmed on chain and recorded by Securitize; a sell placed before then answers INVALID_ORDER and can be sent again a few seconds later.
Symbols and chains
  • New read: get_symbols. It lists the symbols you can trade and, for each one, the chains its CETs can be minted on, with the token address on each chain. Like every read, it is not signed and a read-only key may send it.
  • place_order takes an optional chainId. Send it when get_symbols lists the symbol on more than one chain; without it such an order answers INVALID_ORDER. A symbol on a single chain needs no chainId.
  • Responses carry chainId. The place_order ack, get_order, get_mints, get_burns and every push carry chainId beside tokenAddress: the chain of the CET, as get_symbols lists it.
  • externalRef is at most 39 characters on place_order (previously 47). get_order still finds orders placed with a longer reference.
Developer portal
The CET Underlying API documentation is published on this portal: the API reference for every message, the guides to buying and selling shares and reconciling the CETs minted and burned, and the material coding agents read.