Liquidius Maximus: Advanced High-Frequency Trading Defense System
Previous Report: here
Visualisations: here (so you understand how market attacks commence)
Trading View: here ( see our market making software in action on LIVE market and consider filling your bags💰 with $GNC, now as we’re just getting started) - when you look at history you also get to see the oscillating pump&dump high-frequency movements most of the fuss was about.
LIVE market depth view: here
Development Period: July 18 - August 5, 2025
Executive Summary
During this intensive three-week development period, we have created and further revised what may be one of the most sophisticated market making defense systems in the cryptocurrency space. Named “Liquidius Maximus,” this system was developed entirely on YouTube LIVE, demonstrating unprecedented transparency in financial software development.
The system was specifically designed to counter sophisticated market manipulation attacks that the Team has been experiencing since their listing on Xt.com exchange. The attackers from competing cryptocurrency establishments, presumably mostly “Bitcointalk” ( ‘lets create a 1000+ litecoin fork and push it down our ICO production/marketing factory’- kind of folks) and smaller groups such as “PWTG” - have been attempting to manipulate the GNC/USDT market through various hostile trading strategies with the main intent of sucking USDT from market makers making them bail out from deals.
Screen Shots Gallery
Besides what’s described in this report, our UI specialists and developers have been involved heavily in accountability and reporting mechanics of this groundbreaking market making software. The results? Folks, see for yourselves down below:
The spikes are processing/requests and horizontal lines are desired thresholds (the desired time for which an order is to be flashed onto the exchange for instance say 300 ms. If processing takes longer - these timing guarantees could not be met) - the reason why these live monitoring and charts exist to begin with. It allows us to get an insight into internals of each market making module, above - the high frequency orders’ flashing module and to make sure that processing overheads are low enough to uphold orders’ flashing frequency requirements.
The results are processed, higher level status inferred and if all good - all is Green 
, as seen above.
When things are not that great 
red lights light up. Here, worth mentioning - notice high-level knowledge / sub-states being inferred from current state / recent results - and advise / guidance given automatically to software Operator - along with reported severity of a particular state / event.
Here, orders’ flashing module components are monitored. It is precisely measured how long batch order placements take either to complete or cancel and whether these timing allow for desired order flashing frequency to be maintained.
Above- low level monitoring of how long particular software methods take to execute. That’s truly interesting to note and fathom - we do not use external software monitoring toolkits or frameworks - here - the software it monitors itself - at a level known from highest quality software development frameworks such as Visual Studio Performance monitoring suite. Just take a look below.
Above worth noticing is autonomous, internal self-profiling sub-system. Notice flame charts of internal methods’ invocations produced in real-time. No third party controls or libraries used. The system measures its own methods’ execution calls, parses execution stacks and prepares dynamic visualisations with on-hover effects. All as part of the market making software itself.
Worth mentioning - views such as above allow us to have a glimpse at internal states of very many orders associated with the orders’ flashing module. We can see whether these orders are flashed in sync properly (many sync modes supported).
We have many views such as the one above, giving us high level statistical insight into overall performance. Additional charts, such as the ones below, allow to give us an insight into statistical properties of orders places by particular trading strategies and sub-systems. We get to see these statistics by results, not by desired properties as many sub-systems interacting with each other often create results that are not that obvious to predict.
Core Innovation: The Flashing Orders Module
Achievement: High-Frequency Order Flashing System
What Was Built: A revolutionary order management system that rapidly places and cancels orders at intervals approaching the technical limits of SSL/TLS communication (~200ms).
Why It Was Needed: Traditional market making leaves orders exposed for extended periods, allowing hostile bots to execute manipulative trades. That is especially true with markets of low natural traffic, where an attacker can use this fact to exploit market making service to extract USDT profits by manipulating the market as described earlier. The Team observed coordinated pump & dump attempts and sandwich attacks that exploited static order books.
How It Works:
-
Orders are placed for milliseconds then immediately canceled
-
The system maintains internal tracking of “flashing” orders that may not even be visible on the exchange.
-
In other words, the system maintains a ‘solid’ state of the market, while a ‘fuzzy’ state is continuously being flashed onto the exchange.
-
When a hostile bot think a buy limit order is there - by the time the hostile bot issues a buy request - the order is already gone. And the hostile bot’s sell market order falls into an ‘air-pocket’.
-
Synchronization ensures both buy and sell sides flash in coordinated patterns
-
Timing intervals are set just above the technical threshold of API response times
Rationale: By creating temporal windows where orders exist only briefly, attackers cannot reliably execute against them. The system essentially turns market making into a game of chance for attackers, where the house (Liquidius Maximus in this case) always has the edge.
Achievement: Batch Order Processing Revolution
What Was Built: Complete integration with Xt.com’s batch API system, allowing up to 100 orders to be placed or canceled in a single API call.
Why It Was Needed: The team discovered that Xt.com’s Python SDK for batch processing was bugged. Additionally, API rate limits were constraining their ability to flash orders rapidly enough to defend against attacks.
How It Works:
-
Direct RESTful API implementation bypassing the buggy SDK
-
Custom authentication headers and payload formatting
-
Intelligent batching that groups orders without tight coupling to specific exchange APIs
-
Fallback mechanisms for exchanges that don’t support batching
Rationale: “Since Xt.com supports - we can deliver a single Payload - ordering for up to 100 (!) orders to be placed / removed simultaneously. Now, imagine how this improved performance of anti-hostile-bot mitigation maneuvers under same API calling frequency limitations.” This 100x improvement in order throughput was crucial for creating impenetrable temporal defenses.
Advanced Monitoring & Performance Analysis
Achievement: Custom-Built Performance Profiling Suite
What Was Built: An entire performance profiling system built from scratch, featuring flame charts, pie charts, and real-time performance metrics.
Why It Was Needed: The team needed microsecond-level visibility into their system’s performance to ensure the flashing intervals remained consistent and effective. As noted: “rarely one sees folks for whom it’s easier to implement a graphical code profiler with pie/flame charts than to Google and install one.”
How It Works:
-
Real-time flame charts showing method execution hierarchies
-
Time distribution analysis for identifying bottlenecks
-
Memory usage monitoring for all internal data structures
-
Thread synchronization visualization
-
Mutex congestion detection
Rationale: At the speeds they were operating (200-300ms cycles), even small performance degradations could create windows for attacks. The custom profiler allowed them to identify and eliminate mutex congestions that were taking 200ms, reducing them to “fractions of milliseconds.”
Achievement: Comprehensive Internal Monitoring Dashboard
What Was Built: A sophisticated Qt6-based monitoring system providing real-time visibility into every aspect of market making operations.
Why It Was Needed: Managing high-frequency operations across multiple compliance algorithms required unprecedented visibility. Traditional exchange interfaces couldn’t provide the granularity needed.
How It Works:
-
Live order book visualization with flashing order states
-
Performance metrics with color-coded health indicators
-
Attack detection alerts with pattern recognition
-
Memory structure monitoring to prevent degradation
-
API throttling impact measurement
Rationale: “Not a single Stone shall we leave unturned.” The team needed to see everything happening in their system to ensure no attack vector remained unexploited.
Market Compliance & Protection Mechanisms
Achievement: Multi-Layer Compliance Heuristics
What Was Built: A comprehensive suite of market compliance algorithms operating in harmony.
Why It Was Needed: Simply flashing orders wasn’t enough - the market needed to maintain certain characteristics to remain healthy and compliant with exchange requirements.
Components Implemented:
-
Depth Assurance Mechanics
-
What: Maintains specified USD depth on both buy and sell sides
-
Why: Prevents the market from appearing thin or manipulated
-
How: Continuously monitors total USD value of orders and spawns new ones with 5-15% safety buffers
-
Rationale: “500 USDT buy and sell side deficit, the algorithms proceeded with spawning additional 1151 USDT worth of orders”
-
-
Volume Compliance System
-
What: Ensures minimum daily trading volumes are met
-
Why: Many exchanges require minimum volumes to maintain listings
-
How: Tracks 24-hour rolling volumes and generates wash trades if needed
-
Rationale: Protects the listing while maintaining market integrity
-
-
Spread Management
-
What: Controls the gap between best bid and ask prices
-
Why: Wide spreads discourage legitimate trading and indicate unhealthy markets
-
How: Dynamically adjusts order placement to maintain tight spreads
-
Rationale: “Price-gap minimization heuristics” ensure the market remains attractive to real traders
-
-
Order Book Density
-
What: Maintains minimum order counts at various price levels
-
Why: Sparse order books are easily manipulated
-
How: Distributes orders across price levels to create depth
-
Rationale: Creates a robust market structure resistant to manipulation
-
Achievement: Advanced Attack Detection System
What Was Built: Real-time detection algorithms for multiple attack patterns.
Why It Was Needed: The team observed sophisticated coordinated attacks including pump & dumps and sandwich attacks. Manual detection was impossible at the speeds involved.
Attack Types Detected:
-
Pump & Dump Schemes
-
Detects sudden volume spikes followed by rapid sells
-
Configurable sensitivity parameters
-
Triggers defensive order adjustments
-
-
Sandwich Attacks
-
Identifies attempts to front-run legitimate trades
-
Monitors for suspicious order patterns
-
Automatically widens spreads during attacks
-
-
Decoy Sequences
-
“hostile bot operators seemingly began introducing decoy pump&dump sequences”
-
System learns and adapts to fake-out attempts
-
Rationale: “Bitcointalk and PWTG folks stand no chance.” By detecting attacks in real-time, the system can adjust its defensive parameters dynamically.
Risk Management & Financial Controls
Achievement: Comprehensive Risk Management Suite
What Was Built: Multi-level risk controls protecting capital while maintaining market making operations.
Why It Was Needed: High-frequency operations in hostile environments require sophisticated risk management to prevent catastrophic losses.
Components:
-
Real-time PnL Tracking
-
Monitors profit/loss across all operations
-
Accounts for locked assets in flashing orders
-
Provides hourly and daily rollups
-
-
Stop-Loss Mechanisms
-
Automatic position unwinding on drawdown limits
-
Price impact estimation before large trades
-
Gradual liquidation to minimize losses
-
-
Exposure Limiting
-
Controls maximum capital at risk
-
Dynamic adjustment based on market volatility
-
Per-side exposure limits
-
Rationale: “Good operational results 
” were only possible with proper risk controls. The system needed to survive sustained attacks without depleting capital.
Achievement: Autonomous Asset Management
What Was Built: Self-balancing algorithms that maintain optimal asset ratios.
Why It Was Needed: Manual rebalancing during high-frequency operations is impossible and error-prone.
How It Works:
-
Continuously monitors base/quote asset ratios
-
Executes rebalancing trades during quiet periods
-
Maintains reserves for defensive operations
Rationale: Ensures the system always has ammunition for both sides of the market, preventing depletion attacks.
Technical Infrastructure Achievements
Achievement: Time Oracle System
What Was Built: A sophisticated time synchronization system that doesn’t rely on local system time or exchange timestamps.
Why It Was Needed: “To offset for temporal time data unavailability (due to no transactions) from exchange” and “to treat local time as untrusted (many of us work from various time-zones).”
How It Works:
-
Synthesizes time from multiple sources
-
Handles gaps in exchange kline data
-
Provides consistent 24-hour time flow for algorithms
Rationale: Many algorithms require precise time synchronization. In a distributed team across time zones attacking a global market, a unified time source was critical.
Achievement: Memory Management Revolution
What Was Built: Aggressive memory management systems preventing degradation over long operations.
Why It Was Needed: Initial testing showed performance degradation after extended operations due to memory leaks and bloated data structures.
Solutions Implemented:
-
Order history pruning (discovered “excessive amount of elements in self.order_history”)
-
Container cleanup in finally blocks
-
Double buffering for order book processing
-
Aggressive garbage collection
Rationale: “No performance degradation over 15+ hour continuous operation” was achieved only through meticulous memory management.
Achievement: API Optimization Layer
What Was Built: Sophisticated API management including caching, throttling, and fallback mechanisms.
Why It Was Needed: API rate limits were constraining defensive capabilities, and failures could expose the system to attacks.
Features:
-
Intelligent request throttling with backoff
-
Caching layers for public and private data
-
Automatic failover mechanisms
-
Average delay monitoring and reporting
Rationale: “No lag caused by API access throttling” was essential for maintaining the timing precision required for effective defense.
Development Philosophy & Transparency
Achievement: Radical Development Transparency
What Was Built: A complete development process conducted live on YouTube, with real-time testing on live markets.
Why It Was Needed: The team wanted to demonstrate that their success wasn’t due to hidden tricks but superior engineering and mathematics.
What This Included:
-
Every bug exposed: “all the errors and Bugs
, everything on YouTube LIVE” -
Real market testing visible on Xt.com
-
Open discussion of strategies and rationales
-
AI-assisted development shown in real-time
Rationale: “Threat models backed by Math and physics (Time) - thus open for everyone to see.” By developing in the open, they proved their system’s robustness isn’t based on secrecy but on fundamental mathematical advantages.
Results & Future Vision
Achievement: Market Defense Success
What Was Achieved:
-
Consistent order flashing at 200-300ms intervals
-
Successful defense against multiple attack attempts
-
Stable market making with controlled risk
-
No performance degradation over extended operations
Metrics Observed:
-
Hostile bot failures: “missed hostile-bot dump
” followed by “missed hostile bot market buy ” -
Attack detection: “onboard logic is detecting the attack”
-
System stability: “very very Goood results”
Achievement: Platform-Agnostic Architecture
What Was Built: A system designed to work across multiple exchanges, not just Xt.com.
Why It Was Needed: The vision extends beyond defending GRIDNET to helping other projects under attack.
How It Works:
-
Abstract interface design
-
Exchange-specific adapters
-
Fallback mechanisms for missing features
Rationale: “We envision the system to be rented and leased to other third party projects who found themselves struggling while being targeted by current crypto establishment.”
Conclusion: A New Paradigm in Market Defense
Liquidius Maximus represents more than just sophisticated software - it’s a statement that innovative projects can defend themselves against entrenched interests. Every feature was built in response to observed attacks, every optimization driven by real-world requirements, and every line of code written in public view.
The team’s rallying cry echoes throughout the logs: “We don’t go gently into the Good Night, Sirs - and we’re leaving nobody behind.”
This isn’t just market making software - it’s a shield for innovation in the cryptocurrency space, built by Wizards who refuse to let established players crush new ideas through market manipulation.
As they put it: “Our spaceship is being prepared, Sirs… throughout the years, it’s been made rigid and resilient from each and every side imaginable Sirs, now - also financial.”
“Everything we do - we do it all for YOU - always” - GRIDNET Wizards
”