# How does ICDex work The ICDex project comprises three main components: ICDexRouter, ICDexPair, and ICDexMaker.

Governed and controlled by the SNS, ICDexRouter acts as a Factory, responsible for creating and managing both ICDexPair and ICDexMaker.

## Accounts and Roles Traders are identified by `AccountId` within the pair and support subaccounts. ## Each account may fulfill one or more of the following roles: • Trader (User): An ordinary trader, requiring no authorization. • Maker: A trader who places an order into the order book leaving it open for another trader to fill thereby increasing liquidity and assuming the Maker role for that order. • Taker: A trader who places an order that immediately matches with existing orders, thereby removing liquidity, and is designated the Taker role for that order. • Vip-Maker: Granted by ICDexRouter, this role allows a trader to receive a trading fee re-bate, specified as a percentage, when acting as a Maker. • Trading Ambassador (Referrer): A trader with a trade volume greater than 0 can become a Trading Ambassador without specific authorization. They can refer new users to the trading pair, with their referrals and the total trade volume of these referrals being tracked. • Broker: Other dApps can integrate with ICDex as a `Broker`, By specifying the broker parameter when using the trading API, they can earn commissions paid by the Taker. No authorization is required for the Broker role. • Pro-Trader: A Trader utilizing the Strategy Orders feature is called a `Pro-Trader`. This role also requires no authorization. ## Dedicated accounts within the trading pair include: • TxAccount: Specifically allocated for each order in tunnel mode, this account temporarily holds funds for the order. It remains in a locked state until the order is either filled or canceled, preventing the transfer of funds to the recipient beforehand. Every order maintains a distinct TxAccount, identified by the address { owner = pair\_canister\_id; subaccount = ?txid }. In exceptional cases, funds remaining in a TxAccount can be reclaimed through a fallback operation. • PoolAccount: This central account for trading pairs is utilized to hold temporary funds for all orders collectively. Its ownership and status are regulated by the records in the TraderAccount ledger, for example, { owner = pair\_canister\_id; subaccount = null }. • TraderAccount: Functioning as the local ledger within a trading pair, it tracks the balances traders maintain in the PoolAccount. Balances in the TraderAccount are categorized into locked and available sections. Traders can adjust their available balance by depositing or withdrawing funds. The TraderAccount does not directly hold tokens; instead, balances are accessible through the accountBalance() and safeAccountBalance() methods of the trading pair. • DepositAccount: This is a temporary account used by traders to deposit funds into the available balance of their TraderAccount. Each trader possesses an individual DepositAccount, specified by { owner = pair\_canister\_id; subaccount = ?accountId }. In case of anomalies, funds left in the DepositAccount can also be recovered through a fallback operation. ## On-Chain Orderbook Matching Engine
The matching engine differentiates between incoming orders and book orders. An incoming order is currently being entered, while a book order is already placed in the order book.
To conceptualize a matching engine, think of it as a specialized function operating in a sequential manner. Firstly, it accepts two key inputs: an order (1) and an "order book" (2). Upon processing these inputs, the engine outputs two critical components: a list of completed trades (3) and a collection of all resting orders (4). These resting orders are then assimilated into the "order book," serving as the basis for processing the next incoming order by the matching engine. This cyclical process ensures continuous and efficient order matching in the trading environment. ### Matching principles ICDex Orderbook employs the First-In-First-Out (FIFO) algorithm for its matching engine. This price-time algorithm prioritizes buy orders by price and then time. Buy orders with the same maximum price are further prioritized based on the time of bid, with the earliest bid receiving precedence. ### Order Types ICDex Orderbook supports various order types including Limit (LMT), Market (MKT), Fill-And-Kill (FAK), and Fill-Or-Kill (FOK) orders. **LMT:** A Limit Order lets you set a specific price for buying or selling an asset. You can place a Limit Buy Order to buy at a price below the current market value or a Limit Sell Order to sell above the current market value. **MKT:** A Market Order facilitates immediate buying or selling at the current market price. This order type ensures execution but may be partially canceled if insufficient matching orders exist. **FAK:** A Fill and Kill Order is ideal for bulk orders at a set limit price, with any unfilled portion being canceled post-execution. **FOK:** A Fill or Kill Order must be executed in full immediately or not at all. It can match with multiple existing orders, resulting in several trades, but is never displayed in the order book. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://iclighthouse.gitbook.io/iclighthouse/products/icdex/how-does-icdex-work.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.