Trading

Search…
Trading
Trading instructions, like other transactions, must be executed deterministically on all nodes in order for decentralization to work. This is required, in order to ensure that all participants receive the exact same results for matching, risk management, and settlement of all orders and positions. Furthermore, each node must assess the state of each market to select the most optimal trading mode based on market attributes, liquidity, and recent price history. As a result of this requirement for absolute determinism, each market action, including standard order processing. As well as margin-related closeouts, and responses to risky price or liquidity conditions, must be fully automated from start to finish, with no manual intervention or exceptions process. This is unlike centralized markets, and it is not without issues.
This fully automated trading and settlement logic works within the market framework. It also interprets data structures and transactions in order to determine the state of the market at any given time. The protocol's internal state includes the price history of order completion, transactions, order book status, open positions, and margin requirements for each participant. All of this is transparent and made publicly visible.
The protocol's trading core is a modular application with functional separation between components, which enables maximum configurability. This includes selective use of a subset of components, in permissioned deployments that do not require the protocol's full capability. The elements for Trading are described in the bullets below. 
Matching Engine: A limit order book for open markets that operates in continuous trading or auction mode. Trading on over-the-counter (OTC) marketplaces will also allow requests for quotation (RFQ) and matching trades.
Risk Engine: Calculates margin requirements for each participant's net open position by evaluating the risk model for each market. The risk engine then makes sure that each net position has enough margin, this is achieved by sending allocation requests to the collateral management, and if it doesn't, it executes closeout trades.
Collateral Engine: Processes deposit notifications from collateral blockchains and settlement instructions from the settlement engine, to keep track of each participant's balance regarding each crypto asset they've placed. It's also in charge of allocating collateral to margin markets.
Settlement Engine: Generates settlement instructions for the collateral engine, and when markets mature, products create interim cash flows, and at any time a position is wholly or partially closed. If there is a shortfall at settlement, the position resolution algorithm is utilized.
Governance Engine: Manages the creation and closure of network markets and parameter modifications. Actions are taken in response to voting that occurs, after one or more participants approve a proposed transaction.
Properties of fxdx Protocol
Eliminates liquidity providers as tokens are not kept in VAMMs
Since one trader's profit cancels out another trader's loss, the vault always has enough collateral to pay back every trader
One trader's profit is offset by another trader's loss. This is akin to peer-to-peer futures trading
Example trade
Price of ETH =100$
Initial State of vAMM : vETH(x) * vUSDC(y) = constant(k) {10 * 1000 =10000} 
Bob goes long on ETH with 20 USDC as collateral with 10x leverage
       20 USDC * 10 = 200vUSDC
       vAMM =  8.33 * 1200 =10000
       Price of ETH = 1200/8.33 = 144$
Alice goes short on ETH with 15 USDC's collateral and 5x leverage
     15 USDC * 5 = -75vUSDC
      vAMM = 8.88 *1125 =10000
      Price of ETH = 1125/8.88 = 126$
As there are more long positions than short positions Bob has to pay the funding rate to Alice.
fxdx Protocol Characteristics
Liquidations
Last modified 6mo ago
Copy link
Contents
Properties of fxdx Protocol