# GRIDNET OS Market Making Development Report (Part 2)
**URL:** https://talk.gridnet.org/t/gridnet-os-market-making-development-report-part-2/1081
**Category:** GRIDNET OS - Main
**Tags:** article
**Created:** [August 5, 2025, 8:57pm UTC](https://talk.gridnet.org/t/gridnet-os-market-making-development-report-part-2/1081 "2025-08-05T20:57:17Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@TheOldWizard](https://talk.gridnet.org/u/TheOldWizard)
#### Post date: [August 5, 2025, 8:57pm UTC](https://talk.gridnet.org/t/gridnet-os-market-making-development-report-part-2/1081/1 "2025-08-05T20:57:17Z")
## Liquidius Maximus: Advanced High-Frequency Trading Defense System
Previous Report: [here](https://talk.gridnet.org/t/gridnet-os-development-report-battling-infrastructure-attacks-and-market-manipulation/)
Visualisations: [here](https://gridnet.org/recentAttacks.html) (so you understand how market attacks commence)
Trading View: [here](https://www.xt.com/en/trade/gnc_usdt) ( 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](https://www.xt.com/en/trade-order/gnc_usdt)
### 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](http://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](http://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](http://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](http://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** :
1. **Depth Assurance Mechanics**
2. **Volume Compliance System**
3. **Spread Management**
4. **Order Book Density**
### 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** :
1. **Pump & Dump Schemes**
2. **Sandwich Attacks**
3. **Decoy Sequences**
**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** :
1. **Real-time PnL Tracking**
2. **Stop-Loss Mechanisms**
3. **Exposure Limiting**
**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](http://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](http://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
---
### Author:  [@TheOldWizard](https://talk.gridnet.org/u/TheOldWizard)
#### Post date: [August 5, 2025, 8:58pm UTC](https://talk.gridnet.org/t/gridnet-os-market-making-development-report-part-2/1081/2 "2025-08-05T20:58:19Z")
#
# GRIDNET OS Liquidius Maximus: Day-by-Day Development Report
## July 18 - August 5, 2025
* * *
## Day 1: July 18, 2025 (Friday)
### Initial Infrastructure Setup
**No development logs recorded this day** - Preparation phase
* * *
## Day 2: July 19, 2025 (Saturday)
### Market Making Mechanics Evaluation & Flashing Orders Implementation
**09:39 - Morning Session Begins**
- Live development stream starts on YouTube
- Focus: “further evaluation of market making mechanics”
**11:31 - Flashing Orders Module Development**
- **Major Development** : Implementation of flashing orders system
- **Issue Identified** : Software needs to properly account for locked assets when flashing orders are used
- Team realizes reliance on exchange API to provide ‘locked’ asset amounts is problematic
**11:40-11:43 - Balance Retrieval Revision**
- Screenshots show before/after implementation
- **Solution** : Revised balance calculation to account for orders registered with Flashing Orders module
- **Key Insight** : “the order MIGHT NOT be visible on the target exchange BUT - the transactions’ scheduling and higher strategy and market-making algorithms surely NEED to account”
**12:30 - Exponential Backoff Implementation**
- Improving high-frequency order flashing sub-system
- Adding exponential back-off mechanisms for rate limiting
**13:36 - Edge Case Handling**
- Improving Flashing Orders module management
- Focus on scenarios like “when market making Operations are stopped”
**18:02-22:26 - Evening Session: Order Scheduling Overhaul**
- Vast improvements to order scheduling system
- Multiple code quality improvements
- Simplification of transaction scheduling logic
**Key Quote of the Day** : “everything for YOU and everything on YouTube LIVE - almost each and every day since the early 2017 🪄”
* * *
## Day 3: July 20, 2025 (Sunday)
### State Management & Hostile Bot Detection
**08:57 - Early Morning Start**
- Continuing market making software development
**11:03-11:40 - AI-Aided Analysis**
- Implementing state transition analysis
- Using AI assistance for complex state management
- Creating pseudocode and TLA+ analysis documentation
**17:17-17:20 - Documentation Sprint**
- 13 screenshots of pseudocode and TLA+ analysis
- Making internal logic transparent and verifiable
**17:29 - First Bug Detection**
- Error handling improvements
- “all the errors and Bugs 🐛, **everything** on YouTube LIVE”
**20:23-21:20 - Shutdown Procedure Enhancement**
- Improving software shutdown in relation to Orders’ Flashing module
- Ensuring no leftover or partially filled orders remain on exchange
- Multiple consecutive shutdowns and resumptions tested
**22:32 - Hostile Bot Activity Detected**
- **Critical Discovery** : “hostile bot operators seemingly began introducing decoy pump&dump sequences”
- First evidence of sophisticated attack patterns
* * *
## Day 4: July 21, 2025 (Monday)
### Depth Assurance Algorithms & UI Integration
**10:49 - Major Algorithm Improvements**
- “vastly improving depth assurance algorithms”
- Focus on: performance, order aggregation, order book maintenance
- Positioning orders “in face of detected attacks”
**13:19-13:40 - Flashing Orders Reporting**
- New features implemented:
**13:56 - Thread-Safe Statistics**
- Implementing thread-safe methods for statistical data access
- Ensuring data integrity during high-frequency operations
**14:41 - Market Depth Reconciliation**
- Reconciling near depth and further market depth assurance mechanics
- Making systems compatible with flashing orders philosophy
**18:10 - Hourly PnL Calculations**
- Looking into hourly USDT loss/profit calculations
- Essential for risk management
**19:01 - Performance Validation**
- “very good results in regards to high-frequency flashing orders’ mechanics”
- Good synchronization despite Python implementation
**20:00-20:45 - Edge Case Validation**
- Validating cleanup of market making transaction remainders
- Looking into autonomous market restrictions
* * *
## Day 5: July 22, 2025 (Tuesday)
### Time Oracle & Volume Assurance
**09:40 - Morning Analysis**
- Market making software analysis session
- Reviewing collected logs and metrics
**10:44-11:03 - Depth Assurance Testing**
- Live testing showing:
- Later tested with 5% safety buffer
**12:04-12:19 - Custom Time Oracle Implementation**
- **Major Innovation** : Custom sophisticated Time Oracle
- Uses local time adjusted by kline data from exchange
- **Rationale** :
**16:07 - Volume Assurance Mechanics**
- Implementing revised trading volume assurance
- Ensuring minimum daily volumes maintained
**18:07-18:32 - Graceful Shutdown Improvements**
- Deep dive into fallback handling mechanics
- Ensuring all open transactions cancelled during critical failures
- Implementing graceful shutdown procedures
**20:57 - Attack Mitigation Configuration**
- Making Sandwich/Pump&Dump attack mitigation more configurable
- Adding UI components for attack sensitivity adjustment
* * *
## Day 6: July 23, 2025 (Wednesday)
### API Optimization & Real-Time Visualization
**10:59 - Performance Evaluation**
- Further market making software evaluation on [Xt.com](http://Xt.com)
- Real-world testing continues
**11:10-11:34 - API Throttling Enhancement**
- **New Feature** : Display average delay caused by API throttling
- Implemented averaging over past 100 delays
- Critical for understanding performance constraints
**15:19-15:47 - UI Visualization Improvements**
- Improving Flashing Order Book module visualization
- **Innovation** : “automated centering around current market price on no scroll activity for 5 seconds”
- Enhanced live data feed from Flashing Order Book
**17:32-17:48 - Depth Assurance Compatibility**
- Vastly revised total depth and near depth (\<2% price range) assurance
- Made compatible with flashing orders philosophy
- Improved consolidation of existing orders
**23:13 - Late Night Improvements**
- Further improvements to internal order management
- Better tracking as orders are registered with exchanges
* * *
## Day 7: July 24, 2025 (Thursday)
### Thread Safety & Performance Optimization
**08:52-10:13 - Morning Debugging Session**
- Upgrading flashing orders handling
- Improving thread safety during high-frequency order placement
- Optimizing thread-safe container traversal
**10:50-11:11 - Attack Pattern Recognition**
- Multiple hostile bot activities detected:
- **Quote** : “Bitcointalk and PWTG folks stand no chance”
**11:57 - Total Market Depth Reconciliation**
- Reconciling depth maintenance mechanics
- Observing hostile bots “prepping at same time”
**16:44-17:29 - Synchronization Improvements**
- Improving spread-assurance order synchronization
- High-level scheduling of compliance heuristics
- Results visible on [Xt.com](http://Xt.com) in real-time
**20:31-21:07 - Documentation & Testing**
- Live documentation improvements
- Refined depth assurance mechanics
- Extensive live testing on [Xt.com](http://Xt.com)
* * *
## Day 8: July 25, 2025 (Friday)
### Price Gap Mitigation & Analytics
**09:06-09:57 - Price Gap Logic**
- Looking into price-gap mitigation logic
- Part of market manipulation defense
**10:30 - Double Buffering Implementation**
- **Performance Enhancement** : Introducing double buffering for order book processing
- Prevents processing delays during updates
**13:44-13:49 - Order Analytics Module**
- Implementing comprehensive Order Analytics
- **Quote** : “not a single Stone shall we leave unturned”
- Showcasing sophisticated internal UI: “if you ever thought exchanges have sophisticated user interfaces - you haven’t seen ours”
* * *
## Day 9: July 26, 2025 (Saturday)
### Batch Order Processing Breakthrough
**12:15 - Weekend Development Continues**
- Market making software development session
**13:00 - Order Tracking Improvements**
- Tightening integration with exchange API
- Better order state tracking
- Orphaned order detection
**14:06 - Major Announcement**
- **Game-Changing Feature** : “Within upcoming 24-72 hours - we’ll be incorporating support of batch orders”
- [Xt.com](http://Xt.com) supports canceling 10 orders in single call
- Will “vastly improve protection guarantees against hostile trading bots”
**16:41-17:09 - Batch Implementation Begins**
- Starting implementation of batch order support
- No tight coupling with specific exchange APIs
- Fallback to unitary operations if batch not supported
- Similar implementation for batch cancellations
* * *
## Day 10: July 27, 2025 (Sunday)
### Batch Processing Success & Performance Breakthrough
**09:51 - Early Progress Check**
- Continuing batch order implementation
**14:54-15:23 - Batch Processing Live**
- Looking into batched processing of transactions
- Ensuring proper ID sanitization
- Preserving traceability
**19:50-20:28 - Exceptional Results**
- **Major Discovery** : “[Xt.com](http://Xt.com)’s Python based batched processing API/library is bugged”
- **Solution** : Resort to direct low-level RESTful invocations
- Custom [Xt.com](http://Xt.com) authentication and headers implemented
**20:35 - Performance Breakthrough**
- **Achievement** : “literally achieving micro-second scale synchronisation between orders flashed on each side”
- Can deliver single payload with up to 100 orders placed/removed simultaneously
- **Quote** : “imagine how this improved performance of anti-hostile-bot mitigation maneuvers”
**22:13-23:13 - Fine-Tuning**
- Reviewing batch order placement implementation
- Beautiful asynchronous task scheduling observed
- Price-gap minimization now uses high-frequency compliance
- **Result** : “no lag caused by API access throttling”
* * *
## Day 11: July 28, 2025 (Monday)
### Transaction History Integration & Performance Polish
**09:41 - Stability Focus**
- Revising market making software
- Focus on reliability over long runs
**09:55 - Order Book Compliance**
- Improved order-book count compliance heuristics
- Made it possible to select “None” as trading strategy (compliance only mode)
**12:13-13:29 - Transaction Data Integration**
- **Major Enhancement** : Tighter integration with [Xt.com](http://Xt.com) data feeds
- Integrating public and private transaction histories
- Implementing caching layers to limit API requests
- Standardized data retrieval (exchange agnostic)
**15:33-16:31 - Performance Achieved**
- Transaction frequency assurance implemented
- Additional caching layers added
- **Quote** : “everything on YouTube LIVE kind Sirs, everything for **YOU** ”
* * *
## Day 12: July 29, 2025 (Tuesday)
### Risk Management & Advanced Flashing Modes
**09:48 - Feature Expansion**
- Making features opt-in (like autonomous sell wall flattening)
- Adding new functionalities
**10:19 - Volume Buffer Concept**
- Altering volume assurance mechanics
- Implementing “surplus volume buffer” concept
**11:20 - TPM Reporting Fix**
- Fixed TPM (Transactions Per Minute) reporting
- **Quote** : “the Software which will govern some of the major world-wide markets”
**14:27 - New Flashing Modes**
- **Strategic Enhancement** : Introducing new high-frequency flashing modes
- Making system future-proof against evolving attacks
- **Quote** : “As Bitcointalk and PWTG investigate how to ‘crack’ current strategies - we’ll be having additional methods”
**14:55 - Mode Descriptions**
- Chaotic asynchronous placement
- Batched, market-side synced modes
- Batched high-frequency with both-sides synchronization
- **Key Insight** : “hostile Bitcointalk / PWTG bot has no chance - offers are gone for longer than they are there”
* * *
## Day 13: July 30, 2025 (Wednesday)
### Risk Management Suite & PnL Implementation
**09:29 - Risk Management Focus**
- Looking into risk management algorithms
- Starting comprehensive risk system implementation
**10:52 - PnL Calculation Improvements**
- Vastly improved PnL calculations
- Accounting for flashing orders and locked assets
**11:26 - Stop-Loss Mechanics**
- Revising stop-loss mechanisms
- Price impact estimation
- Accountability improvements
**17:41-18:03 - Comprehensive Risk UI**
- Extensive risk management UI panels
- Multiple configuration options for:
- **Quote** : “We won’t only win over those funny folks - we will be making owners of Bitcointalk run for their money”
**18:40 - Success Metrics**
- “Good operational results ✅”
- System remains resilient to hostile operations
**19:54-20:17 - Memory Management**
- Profiling high-frequency operations
- Proper management of containers and maps
- Ensuring no memory leaks
* * *
## Day 14: August 2, 2025 (Saturday)
### Performance Analysis & Error Handling
**10:14 - Log Analysis**
- Looking into collected performance logs
- Making adjustments based on findings
**22:06-23:58 - Reliability Improvements**
- Continuing market making mechanics revision
- Improving error handling
- Upgrading edge case support
**00:34 - Automatic Adjustments**
- Playing with automatic price/volume adjustments
- Based on market movement patterns
* * *
## Day 15: August 3, 2025 (Sunday)
### Performance Profiling Revolution
**09:58 - Unexpected API Limits**
- Discovered 403 responses from [Xt.com](http://Xt.com) batch API
- Hitting limits below documented thresholds
- Implementing sub-batching layer as workaround
**22:42 - Performance Deep Dive**
- **Major Development** : Building custom performance profiler
- Ensuring data structures properly maintained
- Critical for operations happening “many times each second”
**22:54-23:44 - Profiler Implementation**
- Built entire Qt6-based monitoring component
- Real-time data structure monitoring
- **Achievement** : “sophisticated Qt6 based internal data-structure monitoring and reporting graphical component”
- **Quote** : “rarely one sees folks for whom it’s easier to implement a graphical code profiler than to Google and install one”
* * *
## Day 16: August 4, 2025 (Monday)
### Custom Profiling Suite Completion
**09:37 - Monitoring Enhancement**
- Incorporating additional market making monitoring
**10:45-11:01 - Visualization Implementation**
- New visualization for high-frequency order book flashing
- Real-time performance metrics display
- System health indicators showing when “main thread processing time exceeded orders’ flashing interval”
**14:01-15:53 - Flame Chart Implementation**
- **Major Achievement** : Custom flame chart profiler
- Visual profiling with:
**17:10-17:16 - Performance Issue Found**
- Discovered “excessive amount of elements in self.order\_history”
- Causing overheads in batch cancellation processing
- Fixed with proper bounds checking
**18:13 - Performance Analysis**
- Determined 200ms flashing threshold is the technical limit
- Due to “HTTP/TLS traversal” and server processing time
- **Conclusion** : “neither we nor hostile bots would be able to do it” faster
* * *
## Day 17: August 5, 2025 (Tuesday)
### Final Optimizations & Victory Lap
**09:32-10:18 - Long-Term Performance Validation**
- Collecting data on long-time operation performance
- Fixed pie chart rendering for better visibility
- **Result** : “close to none overhead imposed after 15+ hours of operations”
**12:49-13:08 - Performance Analysis**
- SSL/TLS transport layer identified as majority overhead
- Would require WebSocket/BER encoding for improvement
- Batch processing confirmed as best available solution
**13:16-13:41 - Final Optimizations**
- Eliminated mutex congestion bottlenecks
- **Achievement** : “What took 200ms now takes a fraction of milliseconds”
- Performance profiling showed expected overhead
**14:29 - Mission Success**
- All green status indicators
- Flashing interval set “right above the technical TLS/SSL threshold”
- **Victory Quote** : “no hostile Bitcointalk / PWTG bots hold power upon us”
**19:54-21:51 - Project Wrap-Up**
- Final UI refinements
- Performance verification
- **Team Statement** : “we probably have performed most pair/coding sessions live in human history”
**Final Log Entry (22:19)**
- Music playing, system operational
- Ready for any attacks: “let them come, attack our market making, we’re ONLY waiting”
* * *
## Project Summary Statistics
- **Development Days** : 17 intensive days
- **Key Innovations** : 5 major breakthroughs
- **Performance Improvement** : 100x through batching
- **Flashing Speed Achieved** : 200-300ms (technical limit)
- **Uptime Test** : 15+ hours with no degradation
- **Transparency** : 100% developed on YouTube LIVE
**Final Team Message** : “Everything we do - we do it all for YOU - always” 🪄
---
### Author:  [@TheOldWizard](https://talk.gridnet.org/u/TheOldWizard)
#### Post date: [August 6, 2025, 12:18pm UTC](https://talk.gridnet.org/t/gridnet-os-market-making-development-report-part-2/1081/3 "2025-08-06T12:18:21Z")
# Diagram 1: Order Flashing Time-Based Protection
```auto
Time (ms): 0 200 400 600 800 1000 1200 1400 1600 1800 2000
|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|
SELL SIDE: ▓▓▓▓▓░░░░░▓▓▓▓▓░░░░░▓▓▓▓▓░░░░░▓▓▓▓▓░░░░░▓▓▓▓▓░░░░░
BUY SIDE: ▓▓▓▓▓░░░░░▓▓▓▓▓░░░░░▓▓▓▓▓░░░░░▓▓▓▓▓░░░░░▓▓▓▓▓░░░░░
Bot Attack: ----X----X-----X---X------X----X-----X---X----X-----
(failed attempts - orders not there)
▓ = Orders visible on exchange
░ = Orders hidden (cancelled)
X = Bot attempting to execute trade
PROTECTION MECHANISM: Orders exist for ~200ms, then disappear for ~200ms
Result: Hostile bots have <50% chance of finding orders available
```
# Diagram 2: Batch Order Processing Protection
```auto
Traditional Order Placement (Vulnerable):
─────────────────────────────────────────
API Call 1: Place Order A ──────────> Exchange (200ms)
API Call 2: Place Order B ──────────> Exchange (200ms)
API Call 3: Place Order C ──────────> Exchange (200ms)
Total: 600ms exposure window
Liquidius Maximus Batch Protection:
────────────────────────────────────
┌─ Order 1 ─┐
├─ Order 2 ─┤
API Batch Call: ────┼─ Order 3 ─┼───> Exchange (200ms)
├─ ... ─┤
└─ Order 100┘
Total: 200ms for ALL orders
Result: 100x reduction in attack window!
```
# Diagram 3: Flashing Order State Machine
```auto
┌─────────────┐
│ START │
└──────┬──────┘
│
▼
┌──────────────────┐
│ Calculate Orders │
│ (size, price) │
└────────┬─────────┘
│
┌────────────▼────────────┐
│ BATCH 100 ORDERS │
│ Single API Call │
└────────────┬────────────┘
│
╔═══════▼════════╗
║ ORDERS VISIBLE ║ ← 200-300ms
║ ON EXCHANGE ║
╚═══════╤════════╝
│
┌────────────▼────────────┐
│ BATCH CANCEL ALL │
│ Single API Call │
└────────────┬────────────┘
│
╔═══════▼════════╗
║ ORDERS HIDDEN ║ ← 200-300ms
║ (Air Pocket) ║
╚═══════╤════════╝
│
└──────┐
│
┌───────────────────▼──────┐
│ Check: Continue Trading? │
└───────────┬──────────────┘
YES│ │NO
│ │
└─────┘──> END
│
└─── Repeat Cycle
```