CoinJar Exchange operates a 24/7 digital currency market powered by a proprietary, ultra-low latency matching engine called CoreMatch. This page outlines the mechanics of CoreMatch and the operational specifications of CoinJar Exchange.
CoinJar reserves the right to update this page at any time without notice so it’s your responsibility to be aware of the latest Trading Rules. These Trading Rules complement CoinJar’s Terms of Service which you must accept if you use or continue to use any CoinJar services, including via APIs.
CoinJar Exchange runs 3 discrete trading sessions every UTC day. During each trading session, the market sequentially enters into each of
|Start Time (inc.)||End Time (exc.)||Session||State||Duration|
|00:00:00||07:50:00||First Session||Continuous||7 hours 50 minutes|
|07:50:00||07:58:00||First Session||Auction||8 minutes|
|07:58:00||07:59:55||First Session||Auction, No Cancel||1 minute 55 seconds|
|07:59:55||08:00:00||First Session||Closing Padding||5 seconds|
|08:00:00||15:50:00||Second Session||Continuous||7 hours 50 minutes|
|15:50:00||15:58:00||Second Session||Auction||8 minutes|
|15:58:00||15:59:55||Second Session||Auction, No Cancel||1 minute 55 seconds|
|15:59:55||16:00:00||Second Session||Closing Padding||5 seconds|
|16:00:00||23:50:00||Third Session||Continuous||7 hours 50 minutes|
|23:50:00||23:58:00||Third Session||Auction||8 minutes|
|23:58:00||23:59:55||Third Session||Auction, No Cancel||1 minute 55 seconds|
|23:59:55||00:00:00 +1||Third Session||Closing Padding||5 seconds|
All times referenced are in UTC.
- Continuous: Continuous orders (GTC/IOC/MOC) are matched on a price-time priority basis. Auction orders (AO) are accepted but not processed.
- Auction: Continuous orders are matched as normal. Auction data is regularly disseminated by the exchange.
- Auction No Cancel: Continuous orders are matched as normal. Auction orders are accepted but cannot be cancelled.
- Closing: Gap time in between sessions. Orders are not accepted or matched.
- Trading Halt: Orders are not accepted or matched.
Orders submitted with an
AO time-in-force setting participate in auctions, along with any unfilled native orders on the central limit order book at the end of auctions. Auctions take place concurrently with continuous trading. All auction orders are ‘dark’ and only the following information is regularly published to the market:
- Indicative price: The single price all matched orders would receive if auction ends immediately.
- Auction volume: The volume matched if auction ends immediately.
- Imbalance: A
buyimbalance indicates that there will be surplus bids resting at the indicative price if the auction concludes immediately. A
sellimbalance indicates that there will be surplus asks resting at the indicative price if the auction concludes immediately.
The best bid must be greater than or equal to the best ask to result in any match, and all matched orders are filled at the final auction price, resulting in price improvement for most orders. The final auction price is determined using the following order:
- The single price that maximises the volume matched using the merged order book (unfilled continuous orders and all auction orders)
- If there are multiple prices that satisfy the above, the “minimum surplus” principle is applied to select potential auction prices, i.e. the auction must result in the least total outstanding size in the order book.
- If imbalance is to the buy side (i.e. there are unmatched buy orders at any potential auction price), the final auction price is the highest potential auction price. If imbalance is to the sell side (i.e. there are unmatched sell orders at any potential auction price), the final auction price is the lowest potential auction price.
- If there is no imbalance at any potential auction price, the final auction price is the median of all potential auction prices.
Where a surplus exists at the final auction price, orders are matched on a price-auction-time priority basis (
AO orders receive priority at the same price during auctions). Final auction prices may not be in whole multiples of a tick. Implied orders are not considered for auctions.
AO time-in-force setting expires after the first auction with a non-zero trade volume. If the auction ends and the order is unfilled or partially filled, the remainder is converted into a GTC order.
Due to the non-continuous nature of auctions, it is important to be aware that the indicative price has the potential to deviate significantly from the market prices immediately before or after the auction. While indicative prices are announced throughout the auction period, they are only indicative of the state of the auction order book at any given time and they may change quickly and significantly when large orders are placed or cancelled.
CoinJar Exchange guarantees that all orders that receive a fill during the auction are filled at the same fill price regardless of limit order prices, and that this fill price is not worse than the limit order price of each order.
CoinJar Exchange operates a central limit order book in each trading product. During continuous trading, orders are crossed as they are received by the trading engine, therefore the bid-ask spread between native orders is never zero or negative. If an incoming order can be matched against an existing resting order or implied order, the incoming order is immediately filled at the price of the resting native order or implied order, and price improvement is possible. Resting orders are matched on a price-time priority basis.
Order book data are disseminated in 4 different formats:
|Order Book Type||Dissemination Mode||Price Levels||Coalescing||Implied Price Levels|
|Level 1 aggregated order book||REST and WebSocket (
||Best Bid/Ask||Not coalesced*||Best Bid/Ask|
|Level 2 aggregated order book (Recommended)||REST and WebSocket (
||Top 40||Every 100ms||Top 40|
|Level 3 aggregated order book||REST only||All||Every 100ms||Top 40|
|Full native order book||WebSocket only (
ticker: channels only, new trades are not coalesced but best bid/ask data are refreshed every 100ms.
Orders at the same price levels are aggregated with only the total size displayed.
CoinJar Exchange supports first-generation implied matching for incoming orders. Implied matching allows an incoming order to be matched against a combination of resting orders in other related order books where this yields a more favourable overall price. This functionality bridges the available liquidity in different trading products and offers more trading opportunities to participants.
As illustrated in the example below, within the BTC/AUD order book, a bid and an ask can be implied from BTC/USDC and USDC/AUD order books.
|BTC/USDC Order Book||and||USDC/AUD Order Book||imply||BTC/AUD Order Book|
When a BTC/AUD buy order with a price of at least 15500 is received, the matching engine will execute against the implied order, triggering a fill against the 11310 BTC/USDC ask and the 1.370 USDC/AUD ask.
CoreMatch supports three directions of implication, covering all possible first-order links between order books on CoinJar Exchange:
|Implication Direction||Example (A implied from B & C)||Price Formula (P)||Size Formula (Q)|
|From two pairs of same base currency||BTC/GBP implied from
ETH/BTC & ETH/GBP
|PA = PC / PB||QA = min(QB × PB, QC × PB)|
|From two pairs chained||ETH/GBP implied from
ETH/BTC & BTC/GBP
|PA = PB × PC||QA = min(QB, QC / PB)|
|From two pairs of same counter currency||ETH/BTC implied from
ETH/GBP & BTC/GBP
|PA= PB / PC||QA = min(QB, QC × PC / PB)|
A first-generation implied match (between an incoming native order and an implied order) always results in three fills in three different trading pairs. The two legs associated with the implied order are considered maker trades and the incoming order is considered a taker. An order book may contain implied orders from multiple implications. For example, BTC/GBP order book may contain implied orders from ETH/BTC & ETH/GBP, XRP/BTC & XRP/GBP, BTC/USDC & USDC/GBP, etc.
If the incoming order has a size greater than the top resting order or implied order (whichever has a better price), the remainder will be matched against the next best resting order or implied order, until there is no more order to be matched at the order price. When the price is equal, native orders have priority over implied orders.
Second-generation implied matching is not supported. As a result, while it is not possible for an order book to ‘cross’ with one native and one implied order, it is possible for the order book to remain in a crossed state with two implied orders at the top of the order book. When this happens, both the implied bid and the implied ask can be traded against at the overlapped prices.
When a valid order is received by CoinJar Exchange, an initial state is returned immediately with no waiting period. The initial state can be one of the following:
booked: Order is received and being worked on. If order received partial fills, the order stays as
bookedwith a non-zero
filledvalue. If order has a time-in-force of
AO, the order stays as
bookeduntil the end of the auction.
filled: Order is completely filled. A marketable order immediately transitions to this state.
cancelled: Order is cancelled. An initial status of
cancelledindicates that the order no longer satisfies the time-in-force setting (e.g. non-marketable IOC order). If order received partial fills before being cancelled, the order status is
cancelledwith a non-zero
cancelled states are permanent. Orders in the
booked will transition to
filled when it is completely filled, or
cancelled if it is cancelled by the account holder.
Prices and Sizes
All prices and sizes on CoinJar Exchange have finite precisions, and CoinJar Exchange has a systematic way of determining the tick sizes and trade sizes.
All order prices can only have 4 significant figures, and the unit of the 4th significant figure is the tick size (or minimum price increment). For example, if a product is traded at between 1000 and 9999, the tick size is 1.
Minimum trade size (or size increment) is determined by the tick size such that trade size multiplied by tick size has 2 decimal places (AUD-denominated pairs) or 6 decimal places (BTC-denominated pairs). For example, if BTC/AUD is between 1000 and 9999, the tick size is $1 and minimum trade size is 0.01 BTC.
To maintain an orderly market, prices of new orders cannot deviate too significantly from the market price. Currently, CoinJar Exchange requires the price of new orders to be within 80% and 125% of the last tick. For example, if the last price is $500, the minimum order price is $400 and the maximum order price is $625, regardless of buying or selling.
The only native order type supported by CoreMatch is limit (
LMT). CoinJar Exchange also provides simulated market (
MKT) orders by generating a series of
IOC orders, but these generated orders are not blocking or atomic.
LMT) orders can have the following time-in-force options:
- Good Till Cancelled (
GTC): Default option. Orders are active until cancellation.
- Immediate Or Cancel (
IOC): Order is filled immediately and the remaining portion is cancelled. If partially filled, the remaining size is not revealed to the market.
- Maker Or Cancel (
MOC): Order is cancelled immediately if any part of the order would fill immediately. If cancelled, no order information is revealed to the market.
- Auction Only (
AO): Order participates in the upcoming auction. If partially filled or unfilled at the upcoming auction, it will be converted to GTC at which point the remaining size is revealed to the market.
In the future, CoinJar Exchange may introduce additional order types, such as Stop-Limit (
STL) or algo order types.
Self-Trade Prevention (STP)
CoinJar Exchange does not permit self-trading. If a trader trades against his/her own order, both orders will be cancelled out. If one order is larger than the other, the larger order will have the size difference remaining.
For example, a trader places a 2 BTC sell order and then a 1.5 BTC buy order at the same price, the buy order will be cancelled immediately and the sell order will have 0.5 BTC remaining.
No fees are charged for STP cancellations, and the crossed volume is not reported as a fill (although in the Orders API it will be counted as “filled size”). No settlement occurs for STP crosses.
All trades on CoinJar Exchange are final, unless we are required by law to reverse certain trades or where a significant technical error has occured to cause trades that are not consistent with our Terms of Service or Trading Rules.
Settlement involves the simultaneous transfer of the base currency from seller’s account to buyer’s account, and the counter currency from buyer’s account to seller’s account. The amount in base currency is equal to the size of the trade, whereas the amount in counter currency is equal to the value of the trade (price multiplied by size). When the amount in counter currency is not whole multiples of a subunit of the currency (e.g. 0.01 AUD or 0.00000001 BTC), it will be rounded to the nearest subunit. CoinJar has the discretion to select a suitable rounding method but the same amount applies to both the buyer and the seller.
The settlement of any trades takes place after the trade has occurred. While in most cases CoinJar Exchange ensures that settlement takes place within 10 seconds of the trade, during periods with extremely high trading volume, settlement may be delayed by up to an hour.
Before the trades are settled, you can place new orders with unsettled funds, but you won’t be allowed to withdraw unsettled funds. For example, if you sell 2 BTC @ $10,000, you will receive $20,000 in unsettled funds immediately after the trade which you can use to place a new order, but you will have to wait for the settlement to occur to withdraw this $20,000 from CoinJar Exchange.
CoinJar Exchange performs fee billing post-settlement and trading fees are charged daily in arrears. Generally, fees are charged everyday after 02:00 UTC for trades matched during the previous UTC day. Fee invoices are automatically charged to CoinJar Exchange accounts. If an account has a negative balance after fee invoices are paid, withdrawals from CoinJar Exchange will be restricted until the account deficits are covered by deposits or trades.
If you plan to implement automated trading strategies or run your trading algorithms against CoinJar Exchange, you may want to consider the topics in this section.
CoreMatch is capable of processing tens of thousands of requests per second with extremely low latencies. However, not all actions on CoinJar Exchange happen instantly. This table outlines the expected latencies for various actions in the trading lifecycle.
|#||Stage||Description||Expected latency (excluding network)|
|1||Order Placement||REST API returns initial order status. Order information is available in orders API.||<10ms|
|2||Trade Match||WebSocket API sends order update, new fill, new trade, account balance updates, ticker update and orderbook updates.||<10ms|
|3||Trade Record||Trade information is archived and available in trades API and candles API.||<1s|
|4||Order Record||Order information is archived and available in historical orders API.||<1s|
|5||Fill Record||Fill information is archived and available in fills API.||<60s|
|6||Settlement||Settlement occurs with buyer’s and seller’s settled account balance adjusted. Funds become withdrawable.||<60s|
To minimise network latency, you may choose to co-locate with the CoinJar Exchange servers in AWS Sydney (
Some (but not all) CoinJar Exchange API endpoints have rate limits. Generally, most API calls are rate limited to 600 requests every 10 minutes. For example, if you make 40 API calls between 12:40:00 and 12:41:00, you will only have 560 API calls left until the rate limit resets at 12:50:00.
API calls for order placements, order cancellation and market data are not rate limited. However, CoinJar reserves the right to restrict your API access if we determine (in our sole discretion) that your usage of non-rate-limited APIs is excessive compared to your settled trading activities.
Requests from all sources are counted towards the API rate limits per user, including API calls made on the CoinJar Exchange web interface. Therefore, if you develop and use multiple trading applications to access the same CoinJar Exchange account, you may need to consider the combined API call volume from all of these applications.
Each API key generated on CoinJar Exchange has full control of your CoinJar Exchange account, including transfers to and from CoinJar. All activities performed with your API key are considered irrevocably authorised by you. CoinJar Exchange API keys cannot be used to control your non-Exchange CoinJar accounts.
You are solely responsible for keeping API keys secure and confidential. You may revoke API keys at any time using the CoinJar Exchange web interface.