Logx Network Architecture
The biggest issues that DeFi currently faces are the issue of liquidity fragmentation and subpar consumer experience on-chain. This is one of the major reasons why CEXs continue to thrive.
Current Derivatives Trading Architecture:
Perp DEXs historically followed either Orderbook , AMM or V-AMM based architecture.
-
On-Chain Order books
Orderbooks are the most widely used method for crypto exchange as they enable peer-to-peer (P2P) trading with granular control of liquidity. They offer market transparency, high efficiency from a fee and liquidity perspective, and a great degree of internal price discovery. However, they have significant disadvantages like:
- Limited Throughput (speed): Because order books require high-frequency updates of orders, they are highly reliant on throughput to operate. Every millisecond counts, as evidenced by traditional finance market makers optimising for speed at the cost of billions of dollars annually.
- Centralisation: Firstly, because of the limits of the blockchain throughput, on-chain order books typically have off-chain matching engines. This is a centralisation risk because the economic incentive to front-run order flow is exceptional. The payment for order flow (PFOF) market size in traditional finance is over $4B annually.
- Market-Making and Liquidity: On-chain order book exchanges have struggled to build deep liquidity with the on-chain markets being so fragmented (many competing blockchains and exchanges). Every new orderbook exchange must necessarily fragment or capture liquidity from existing ones. This is simply because maker orders in an order book are committed capital; this contrasts to how LogX approaches market-making with just-in-time liquidity.
The result of this fragmentation is a liquidity crunch, with trading volume typically gravitating towards exchanges with the highest liquidity.
-
Automatic Market Maker (AMM) Models:
While AMMs are not directly perpetual futures contracts, they can allow traders to have Delta = 1 exposure to underlying assets with leverage via borrowing funds (the price move in the underlying asset is reflected identically in the price of the derivative).
These exchanges operate primarily by offering traders leverage via borrowing and utilise spot-AMM liquidity and markets to match buy and sell orders, which allow for internal price discovery.
However, there are reasons this model has not found product market fit:
- Leverage is limited by lender capital, which has to be heavily incentivised. This means leverage is largely limited (2–5x) and extremely expensive for traders and the protocol.
- Lenders face credit risks because traders are at risk of insolvency.
There is no easy way to work around the capital-intensive liquidity challenges of this model, and because of the capital inefficiencies presented, this model has not found widespread adoption.
-
Oracle Based Virtual Automatic Market Maker (vAMM) Models:
The vAMM model, popularised by platforms like GMX, has been an innovative market response to current challenges in on-chain order book shortcomings. This model has gained traction with considerable daily volume and now many iterations of forks.
vAMM exchanges allow for guaranteed order execution, high leverage, and predictable trade slippage.
This model hinges on a counterparty liquidity pool (LP), which serves as the de facto counterparty for trader positions. However, this approach is fraught with inefficiencies:
- Capital Inefficiency: Liquidity remains idle and underutilised, with the LP counter-trading all positions, requiring restricted open interest (OI) due to lack of price discovery, especially on volatile assets, to protect LP depositors.
- High Costs: Without price discovery mechanisms, the protocol can’t adequately price risks, leading to higher fees for execution, borrowing, and funding, with most platform revenues (up to 70%) going to LPs to offset the risk of losses from counter-trading all positions.
- Limited Asset Range: Listing long-tail and volatile assets is risky for LPs, leading to severely restricted open interest (OI) and high fees plus slippage to offset the risk.
- Fragmented Liquidity: VAMMS suffer from fragmented liquidity as large pools are needed for trades, with new forks pulling liquidity from existing protocols, worsening overall conditions, limiting multi-chain deployments, and making incentivising liquidity costly through inflationary rewards at the expense of stakeholder value.
Currently, centralized exchanges offer the most liquid markets. Traders who experience lower liquidity, higher slippage, and higher fees on-chain will naturally prefer centralized exchanges until these conditions improve. As long as traders remain on centralized exchanges, they will continue to be the most efficient venues for liquidity.
Our approach allows traders to enjoy the best aspects of CEX trading:
- Deep Liquidity
- Seamless Execution
- Tight Spreads
- Low Fees
At the same time, executing trades on-chain provides the benefits of DEX trading:
- Trustless Environment
- Immutable Positions
- Reduced Risk of Counterparty Insolvency
- Permissionless Access
By combining these strengths, LogX Network delivers both liquidity and security without compromise.
Constant BID ASK streaming and Order Flow
The conventional Request for Quote (RFQ) procedure starts when a trader indicates their desire to buy or sell a specific derivative contract at a designated price and volume. Market makers then provide customised bids that cater to the trader’s requirements. Once the trader places the request, our off-chain matching engine will match the trader’s request with the best possible quote.
This method proactively streams quotations, consistently presenting the optimal available quote at any moment. Consequently, users are instantly shown the most favourable price quotation available, facilitating more informed decision-making. This approach bypasses the lengthy and intricate steps found in traditional RFQ systems, providing a streamlined and effective trading experience.
This is a new kind of automatic market for quotations” (AMFQ) method for perp trading.
- Trader arrives at logX and selects the token market on which they want to trade by entering all the details.
- The
solver
(market maker) provides an offer through LogX on conditions for the trade (price, slippage, fees, funding rates, collateral, etc.). This step happens automatically and in real time. No capital is committed by the solver at this time. - The trader then has all the pre-agreed conditions needed to open a trade streamed to them as an “quote” and can then choose to execute the trade. This solves a necessary and complex step in an RFQ process to receive and evaluate bids to select the best one.
Note: Steps 1-3 happen off-chain
through the LogX exchange.
- After reviewing the trade conditions, the trader places the trade, locking in the required collateral as the initial margin.
- The AMM (Automated Market Maker) then evaluates the trade request and, if accepted, deposits the necessary initial margin into the contract.
- This creates a direct, isolated contract between the trader and the AMM. The contract is perfectly balanced, with each party responsible for covering the other’s potential gains or losses based on the position’s price movement. The contract remains active until the trader closes the position or one party is liquidated, which is automatically managed by a neutral third party based on the margin health.
Note: Steps 4-6 happen on-chain
where the quotation and bilateral
agreement live.
- The AMM can then manage its risk by “hedging” its position (e.g., being long 1 BTC) using various methods, such as trading on centralised exchanges (CEX), decentralised exchanges (DEX), over-the-counter (OTC) desks, options, or even holding the asset directly. Additionally, the AMM can offset its risk by balancing this position with other positions or with other AMMs in the network (in future implementations).
Note: Step 7 takes place off-chain, and the solver is solely
responsible for managing their hedging strategy.
Because collateral is locked into the bilateral agreement and
completely isolated from external factors, users do not have to make any
trust assumptions regarding the solvency of the solver on-chain.