GTX (Great Trading Xperience)

🌎 Overview

GTX is a decentralized finance (DeFi) protocol designed to enable permissionless spot trading, with plans to expand into perpetual markets in the future. Addressing inefficiencies in Automated Market Makers (AMMs) and centralized exchanges, GTX provides an order book-based, permissionless trading experience that is fair, efficient, and scalable.

❌ Problems with Traditional AMMs

• 🔄 Inefficient Capital Utilization – AMMs require deep liquidity to minimize slippage, leading to inefficient capital allocation.

• 💰 High Impermanent Loss – Liquidity providers often suffer from impermanent loss due to volatile price movements.

• 📉 Price Manipulation – AMMs are vulnerable to front-running and sandwich attacks, harming traders.

• 🚧 Restricted Market Listings – Centralized exchanges limit listings, making it difficult for emerging assets to gain liquidity.

✅ GTX Solution for Spot Trading

GTX introduces a Central Limit Order Book (CLOB)-based DEX with:

1. 🌐 Decentralized Market Creation – Anyone can list a spot trading pair without permission.

2. 📊 Efficient Order Book Trading – CLOB enables traders to set limit orders and achieve fair price execution.

3. 🤖 AMM-Free Model – Eliminates impermanent loss risks by relying on direct peer-to-peer trading.

4. 📡 Oracle-Free Spot Trading – Uses an order book mechanism to ensure transparent and decentralized price discovery.

🔥 Key Features

• 💱 Spot Trading – Fully decentralized CLOB-based exchange.

• 🚀 Permissionless Market Creation – No gatekeepers—anyone can list a new market.

• 🔍 Fair and Transparent Pricing – No reliance on external oracles for spot trades.

• 📈 Optimized Liquidity Utilization – Capital-efficient trading mechanism compared to AMMs.

• ⚡ High-Frequency Trading Ready – Supports traders placing orders with minimal delay.

• 🛑 No Liquidity Providers (LPs) Needed – Orders are matched peer-to-peer, removing LP dependency.

• 🔃 Cross-chain Swaps - Liquidity can be accessed from other chains (swap only for now)

• 💹 Permissionless Market Making – Everyon can participate to be market maker to earn incentives from trading (Coming Soon)

🏗️ Architectures

System Architecture

The CLOB DEX system consists of four main components:

• GTXRouter: Entry point for all user interactions

• PoolManager: Manages trading pairs and pool deployments

• OrderBook: Handles order placement and matching using RB-Tree

• BalanceManager: Manages token deposits, withdrawals, and locks

Cross-Chain Architecture

• Multichains - All chains supported to connect with our apps

• Solver - Using Open Intents Framework (OIF) and Hyperlane intergrations for connecting other chains to GTX

• GTX - Source of liquidity, on-chain trading deployed on Pharos

🔄 How WETH to WBTC Swap Operates in Pharos

1. Initiating an Open Intent (User Action)

• The user creates an open intent to swap WETH for WBTC on the parent chain, such as Ethereum.

• This intent is signed and transmitted through the Open Intents Framework (OIF).

2. Transmitting Intent to Pharos

• Hyperlane facilitates the relay of the signed swap intent from the parent chain to Pharos.

• Upon arrival, the OIF Router on Pharos authenticates the intent and initiates processing.

3. Matching Orders & Executing Trades

• Pharos examines its CLOB order book for a direct WETH/WBTC market order.

• If a direct market order is available, the trade is executed immediately.

• In the absence of a direct match, Pharos employs routing strategies:

  • Initially, WETH is sold for USDC (Market Order 1).

  • Subsequently, the obtained USDC is used to purchase WBTC (Market Order 2).

• These orders are executed sequentially by Pharos using its CLOB liquidity to ensure optimal execution.

4. Bridging Assets Back to the Parent Chain

• Once the trade is completed, the acquired WBTC is transferred to the user via the Hyperlane Bridge.

• The user receives WBTC on the parent chain, such as Ethereum.

🔗 Links

• Github:

  • Clob

  • Indexer

  • Open Intents

  • Frontend

• Website

• Presentation
  

📡 Indexer Integration

We use Goldsky for indexing, which allows the frontend to easily query key data such as candlestick charts, pool balances, and listed markets. Goldsky is chosen due to its simple setup, customizability, and compatibility with EVM chains. It is also self-hostable, ensuring greater control over the infrastructure.

🔄 How It Works

1. 👨‍💻 Traders place buy/sell orders on the decentralized order book.

2. 📊 Order Matching occurs through a fair and efficient matching engine.

3. 💰 Protocol earns trading fees when orders are matched in the order book.

4. 🔄 Settlement happens directly on-chain, ensuring security and transparency.

📖 More Details

💎 Core Features

🔄 Advanced Order Types

• 📊 Limit Orders – Set precise pricing for trades.

• ⚡ Market Orders – Instant execution at the best available price.

• 🎯 Smart Order Routing – Optimized execution for best trade outcomes.

⚙️ High-Performance Engine

• 🏃‍♂️ O(log n) Matching Algorithm – Efficient trade matching.

• 📈 Price-Time Priority Execution – Ensures fair order processing.

• 🔍 Real-Time Order Book Updates – Continuous visibility into market movements.

• 🔒 Atomic Settlements – Ensures consistency and security in trades.

🏗️ Architecture Highlights

🌳 Red-Black Tree Price Levels

• O(log n) Operations – Efficient price level insertions and removals.

• Quick Best Bid/Ask Access – Fast retrieval of top market prices.

• Ordered Iteration – Enables seamless market data traversal.

📜 Order Queues

• Double-Linked List Structure – Efficiently manages orders at each price level.

• FIFO Execution – Ensures fair trade processing within the same price level.

• Efficient Order Updates – Minimizes processing overhead.

🗃️ Optimized Storage Access

• Packed struct layouts reduce storage operations

• Minimized SSTOREs through strategic updates

• Efficient order data retrieval patterns

👀 View Functions

• Retrieve best bid/ask prices.

• Check order queue status at any price level.

• View user’s active orders.

• Fetch next best price levels with trading volumes.

🔒 Security Features

1. Balance Protection

   • Order amount locking before placement

   • Atomicity in balance operations

   • Authorization checks for operators

2. Order Integrity

   • Order ownership validation

   • Expiration handling

   • Time-in-force constraints enforcement

3. Access Control

   • Router authorization for order operations

   • Owner-only configuration changes

   • Operator-limited permissions

📜 Contract Addresses

The contract addresses are stored in JSON files under the deployments/<chain_id>.json (Source). Example folder:

• 🔗 Local Development: deployments/31337.json (Anvil network)

• 🌐 GTX Dev Network: deployments/31338.json (GTX Development)

• 🚀 Rise Network: deployments/11155931.json (Rise Sepolia)

• 🌟 Pharos Network: deployments/50002.json (Pharos Devnet)

To access contract addresses for a specific network:

1. Locate the appropriate JSON file for your target network

2. Parse the JSON to find the contract you need (e.g., GTXRouter, PoolManager)

3. Use the address in your frontend or for contract interactions

📜 Contract ABIs

The contract ABIs are stored in the deployed-contracts/deployedContracts.ts (Source) file.

Note: This file is automatically generated using the generate-abi target in the Makefile. Ensure you run the appropriate Makefile command to update or regenerate the ABIs when needed.