Layer 1: Trading
Last updated
Last updated
XIO Trading integrates with major execution venues, providing access to liquidity and market connectivity. The platform is built for both centralized and decentralized exchanges, ensuring scalability and flexibility for future expansion. Our ability to connect to execution endpoints in a flexible manner be that for market data, venue onboarding or execution venues is key to building high-speed and adaptable trading architecture. Below we will out line the steps and schematic to achieve this.
XIO targets being highly performant, operating our ecosystem permissionless first with a verified credential approach second. Every alert, order, cancel or trade happens sub 100msecs using the minimal amount of hops within the XIO Tech stack. Our internal measures will be publish and measures to achieve our target latency will be presented out loud on our roadmap and discussed on our upcoming AMAs
XIO’s first phase focuses on Binance integration and user onboarding. Exchange link enables relatively quick access to our the Binance liquidity and execution framework. XIO will build a pluggable venue service where venues like Binance will connect via our API will be connect. The model will wrap a websockets and REST API model with a connection facade diagram below in a XIO Asynchronous Connection (XAC)
Phase 1 paves the way for the following venues to be connected, allowing XIO platform to spread orders and collect market data via the 'spun-up' XIO processors
Bybit
Orderly
Key Functionalities are added with the follow architectural model which modifies the Model View View Model [MVVM] paradigm where XIO UI user is the Actor
User Action:
XIO user initiates an action in the View (e.g., user wants to retrieve fetch token balance).
View to ViewModel:
XIO View sends a request to the our ViewModel to fetch the token balance. Our view Model is an XIO processor handling this request
ViewModel to Model:
Our ViewModel makes a call to the Model to retrieve the token balance from the decentralised component, sometimes a smart contract or querying a secured or optimised data set
Model to Blockchain:
Our Model interacts with the blockchain, sending a request to the smart contract to retrieve the balance using our 'transaction-id'
Blockchain to Model:
The blockchain processes the request and returns the balance data to the Model.
Model to ViewModel:
The Model sends the retrieved balance back to the ViewModel.
ViewModel to View:
Our UI Component will contain a standardised pattern to ensure we can achieve
Professional and fluid experience on mobile-first thereafter desktop outcome
Professional use of the available real-estate with intuitive navigation
Upgradeable component set where low-interference-upgrades can be applied Below if the model we are proposing for the UI which achieves the target outcome
Using a standard MVVM model amongst other model and patterns creates a medium of understanding where engineering and product will communicate in a standard language
The above appraoch will be applied for the following components in Phase 1
Onboarding UI
Dashboard
Watchlist
Interactive Chart
Position Management
Emergency Controls
Venue Management
Phase 2 focuses on expanding execution venues and data onboarding with addition of multi-chain assets store in Wallet combined with additional venues onboardings. Whilst Phase 1 focused on Ethereum this phase will look to onboard more venues and EVM-compatibles. Venues are normalised to either data which provide stream data sets or execution venues such as DEXs, CEXs or indeed AMMs. We will provide connection via our 'Assured Vendor Connectors' and 'Assured Vendor Connectors; these connections using a Rust based micro framework with built-in hot-hot resilience
Anticipated Tick Data venues shortlist likely to include:
Coingecko
CoinMarketCap
Messari
CryptoCompare
From a Venue viewpoint the shortlist likely to include:
Orderly - spot and perpetual futures orderbooks on Arbitrum, Optimism, Polygon, Base and Near
Talos - FX, spot, futures, perpetuals and options
Wintermute - liquid staking tokens, fiat-2-crypto, options and forwards
GSR - offering both liquidity, smort order execution and DeFi
B2C2 - liquid crypto and fiat currency pairs and synthetic exposure
Equally we will seek to leverage CEX (Binance, Coinbase, Kraken) with stretch outcomes to broaden inclusion in Phase 2 else Phase 3 to DEXs (Uniswap, PancakeSwap)
Key Components below include
Venue Fleet Monitor - this central composer ensure all venues are connected and status is managed via and Venue Processor, ability to utilise a hot-hot failover model is planned
Venue Processor Monitor LB1 - this is a load balanced component with abiltiy to refresh and reconnect based on measures monitor during the process lifetime. LB2 mirrors LB1 as hot-hot.
Assured Venue Process set - these contain prioritised processors build in Rust using low latency XIO libraries to create state channels with priority elevation under required market conditions
Additional Phase 2 deliverables are indicated below to include Venue, Market and Value transfer
XIO expands beyond Ethereum to other chains with focus on Security, Fees, Compatibility and Timings
Security: XIO seeks bridges with good KPIs and focus on security, as bridges can be hack targets
Fees: with goal of low transaction fees, network congestion can be a result of a low-fee network
Compatibility: all tokens wont be supported across all bridges. pre-vet the specifics before committing to bridging agreements which can be very engineering intensive and costly.
Transaction Timings across bridges can be notorious with consensus times being excessive
EVM-compatible
Eth compatible L2 to bridge assets to XIO
Enable roll-up type solution. Use of Smart Contract in Solidity, Vyper, Ethers.js, Web3.js, Rust
Arbituum
Trustless transfer of Tokens alongside
Compile Ethereum smart contracts for Arbituum using Hop Protocol
Intra-layer bridge using Cairo
Write token-compatible bridge in Rust to bridge/transfer assets
StarkNet
L2 network using zk-STARKS for scalabliity and v.low fees
Rust - XIO processor hot-hot, Solidity based Smart Contracts
Polygon network
Interrogability between Ethereum/ Dot/
PoS Bridge to bridge Eth <-> Polygon. Polydon Plasma Bridge allows ERC-20 and NFT bridging
BEP-20 and ERC-20 bridging to BSC using AnySwap, xPollinate
Using Web3.js, TypeScript, BSC-SDK
Avalanche Bridge to move between Polygon and Avalance
Smart Contract in Solidity, Vyper, Ethers.js, Web3.js, Rust
Fantom
Cross-chain transactions, asset swaps. This can be useful when DEX is available
Solana network
wrapping of assets to present Solana assets on XIO
Solana smart contracts in Rust, taking into account Proof of History Consensus
Harmony
Polygon[P] with Harmony[H] thereby enabling transfer of assets between P & H
Polkadot
Bridge Eth like networks with Polygon
Snowfork and other Rust based implementations are available
The component set above connects an XIO Processor Pool which allows a configurable set of processors to L1s, L2s and Bridges. The processors are discoverable based on a Bridge Fleet Manager having the roles of spinning up the various connection types based on the required processor pool configuration. The Fleet Manager is tasked with spinning up/down based the load and priority.
XIO ensures market coverage by connecting to various trading venues.
The above schema shows how the following can be integrated:
Client Market Data Streams - B2C2, Orderly, TickMill, Binance Tick data
Primary Data Access - using Rust API or JavaScript toolkit to wrap websockets, Web3.js
Execution and Smart Order Routing - using DMA pool, readiness to handle high volume load
Market Data and Liquidity Vendors - individual Rust processors dedicated to P2P connection
Active Client Connections - this layer adds the 1 to Many relationships and ensures uptime
Fault Tolerance and Resilience - using a deployed cloud composer to ensure managed load
XIO aims to allow users to connect to any trading venue via APIs.
Using a scalable and cloud based reactive architecture we intend to be able to provide a low to no-code ability to add new connectors and to integrate new venues and equally to decommisison venues.
Using a process composer, a new API Connection can be composed in a natural language and using our hot-hot technology, once a venue has been tested, approved by compliance, it can be switched on.
During the design phase we have use LLMs to model Automated Code Generation which use Connector Templates and collect APIs and Protocols and wrap those to create configuration guidance
Configuration Guidance and be used for
Smart Configuration - LLMs to suggest connector types and include request limits and settings
Visual Configuration Tools - LLMs and low-code to drag and drop to generate backend code
XIO’s execution reaches its full potential with a fluid UI and multi-venue integration.
Our build process uses highly iterative development approach where Proof of Concepts are deployed for early testing to test our Best Execution strategy early. Being able to split each workflow into flow below enables discrete engineering builds to be performance tested to ensure optimal latency.
The key building blocks are
XIO User Direct Market access connectors which connect XIO Server side to markets
XIO microprocessor based engineering optimising for throughput or execution finality
1-1 , Many to Many Processors to allow aggregation or single task execution
Light Weight low latency focus where needed removing hops and reducing internal latency
XIO focuses on operational independence and transparency, openly making available internal processes, decision-making criteria, and the execution of transactions. This will include transactions, data integrity, monitoring, fairness and clarity of reporting
XIO will enhance the trading experience through XIO Pro.
XIO will develop its own decentralized exchange (DEX) for more offerings.
XIO expands into traditional FX markets for increased trading options.
XIO positions itself as a leader in portfolio building with AI and algorithms.
