How a 100 USDT Position Generated $3.9M in Volume and Left Bad Debt on the Protocol
Muhammad Abdullah8 min read·Just now--
A Race Condition in a Hybrid Exchange’s Close-Position Logic Led to 39,000x Amplification, Cascading Liquidations, and Protocol-Absorbed Bad Debt
During a security assessment of a hybrid derivatives exchange, I discovered a critical race condition in the order matching engine. A single 100 USDT position — triggered by concurrent close-position requests — generated $3.9 Million in trading volume, produced 394 individual trade fills across 59 unique order IDs, and left bad debt on the protocol that the exchange had to absorb out of its own reserves.
All of this from a position that should have simply been closed. The entire execution completed within 341-millisecond windows.
Here’s how it worked.
What Is a Hybrid Exchange?
Traditional crypto exchanges fall into two camps:
- CEX (Centralized): Fast matching, custodial wallets, off-chain order books. Binance, OKX, etc.
- DEX (Decentralized): On-chain settlement, non-custodial, slower execution. dYdX, Hyperliquid, etc.
Hybrid exchanges try to get the best of both: on-chain settlement and custody (your funds live in smart contracts on L1/L2), but off-chain order matching for speed. You deposit via a smart contract, trade on an off-chain matching engine (the kernel), and withdrawals settle back on-chain.
The kernel is the critical piece. It processes orders, manages positions, calculates margin, and triggers liquidations — all off-chain, all centralized, and in this case, vulnerable to race conditions.
The Liquidation Engine
In derivatives trading, your positions are margined — you put up collateral (margin) to hold leveraged positions. If your losses approach your margin, the liquidation engine steps in:
- Monitors all positions against margin requirements continuously
- When `account equity < maintenance margin`, triggers liquidation
- Creates market orders to close the underwater position
- If account goes negative, the exchange absorbs the loss (no insurance fund in this case)
The key detail: the liquidation engine runs as an asynchronous process. It doesn’t block order execution. It checks, detects, then acts — with a measurable delay between detection and action.
The Attack: Single-Packet Race Condition
What Is a Single-Packet Attack?
Pioneered by James Kettle of PortSwigger, the single-packet attack is a technique for exploiting race conditions in web applications with extreme precision.
The core idea: HTTP/2 multiplexes multiple requests over a single TCP connection. If you carefully construct multiple HTTP/2 requests and send them in a single TCP packet, the server’s networking stack delivers all requests to the application layer simultaneously — within microseconds of each other.
This eliminates network jitter. Traditional concurrent requests arrive with milliseconds of variance due to TCP handshake timing, packet scheduling, etc. A single-packet attack compresses that to near-zero.
What Is State Machine Smashing?
Most web applications are implicit state machines. An order goes through states: `pending → validated → executed → settled`. A user session goes `unauthenticated → authenticated → authorized`.
State machine attacks exploit the assumption that transitions happen atomically — that between reading a state and acting on it, the state won’t change. When you send concurrent requests, you can break this assumption.
The pattern:
- Request A reads state S₀
- Request B reads state S₀ ← same state, before A modifies it
- Request A transitions state to S₁
- Request B acts on stale S₀ ← BUG: should have seen S₁
This is a Time-of-Check-to-Time-of-Use (TOCTOU) vulnerability. The “check” (reading position state) and the “use” (executing the order) are not atomic.
The Vulnerability: Close-Position Flag
The exchange had a `close-position` flag on market orders. Instead of specifying a side and quantity, you just say “close whatever I have open.”
The engine:
- Reads your current position (direction + size)
- Determines the order side (opposite of position)
- Creates a market order with quantity = position size
- Executes against the order book
- Updates position state
These steps were not atomic. No lock, no mutex, no serialized transaction. Multiple concurrent requests could all read step 1 before any of them reached step 5.
The Amplification Loop
This is where it stops being a typical TOCTOU and starts being something worse.
Unlike a standard race condition where you get a double-spend or a duplicate action, this one created an exponential amplification loop.
The reason: the close-position flag doesn’t specify a side — it dynamically determines it based on current position direction. So when the position flips, the next batch of close-position requests flips direction with it.
Starting position: LONG 100 USDT
Wave 1: Multiple requests read LONG 100 → N× SELL 100 = position flips to SHORT, amplified
Wave 2: Next batch reads the new SHORT → N× BUY = position flips to LONG, further amplified
Wave 3: Next batch reads the amplified LONG → N× SELL = position flips again, even larger
…this ping-pong continues across multiple race events…
Final: $3,898,906.77 in total volume from a 100 USDT starting position
Amplification: 39,000x
Trade fills: 394 across 59 unique order IDs
Execution windows: 341ms each
Each wave amplifies because multiple orders execute against the same directional state before it flips. The growth is multiplicative, not additive. And because the position keeps ping-ponging between long and short, each flip seeds the next round with a larger position — feeding the amplification loop.
Full Kill Chain
T+0.000s — A single HTTP/2 packet hits the API gateway carrying N close-position requests. They arrive within microseconds of each other — true concurrency, not sequential.
T+0.001s — The engine fans out the requests in parallel. Each worker queries position state independently. Each reads LONG 100 USDT. None of them know the others exist.
T+0.050s — Worker #1’s SELL executes. The position is closed. The engine is satisfied.
T+0.051s — Workers #2 through #N’s SELLs execute against a position that's already gone. The system happily opens an unauthorized SHORT instead.
T+0.100s — Next batch reads SHORT, issues BUYs, flips to LONG. Amplified.
T+0.200s — Reads LONG, issues SELLs, flips to SHORT. Larger.
T+0.341s — Execution window closes. 394 fills across 59 unique order IDs. Position size now completely untethered from collateral.
The attack was carried out using Turbo Intruder in Burp Suite. Following script was used in the turbo intruder:
The Aftermath
- Volume generated: $3,898,906.77 (from a 100 USDT seed)
- Fees collected by the exchange: $561.22 — pocket change
- Final state: a position too large to liquidate before equity went negative
As per protocol’s documentation: “Liquidation is triggered before equity goes negative, ensuring balances never fall below zero.” This guarantee was violated. The liquidation engine — running asynchronously — couldn’t keep up with the speed of unauthorized position creation. By the time it acted, the account was deep underwater, and the protocol was left holding the bag.
Observe the -ve Balance of the account. This is the bad debt accumulated by the protocol.
Why This Is Worse Than a Typical Race Condition
Exploitation Potential
Free Option Attack
An attacker could:
- Deposit minimum amount ($50)
- Open small position (100 USDT notional)
- Fire concurrent close-position requests
- Get millions in unauthorized notional exposure (I confirmed $3.9M from 100 USDT)
- If market moves favorably (within the seconds before liquidation): close for outsized profit
- If market moves unfavorably: get liquidated, lose only the $50 deposit — protocol absorbs the bad debt
Downside: capped at deposit. Upside: scales with the amplified position. This is a free option— and in finance, free options don’t exist unless something is broken.
Hedged Extraction (Two Accounts)
- Account A: LONG → race close-position → generates massive SHORT
- Account B: SHORT → race close-position → generates massive LONG
- Market moves either direction → one account profits, other gets liquidated
- Exchange absorbs the negative balance on the losing account
- Net result: guaranteed profit minus fees
Rewards Farming
The unauthorized trades generated ~$3.9M in artificial trading volume from a 100 USDT position. This inflated trading can pollute quest progress and earned points— all from exploit-generated activity. If points have monetary value (airdrops, fee discounts, tier upgrades), this is directly exploitable for financial gain.
The Fix
The core fix is straightforward: make close-position atomic.
Additional defenses:
- Deduplication: Track pending close-position orders per user per symbol. Reject duplicates.
- Execution-time margin check: Re-validate margin at execution, not just at order acceptance.
- Circuit breaker: Block execution if it would create a negative balance.
- Direction Specification: Commonly during closing the direction of the trade is specified and kernel act accordingly.
Takeaways
1. Off-chain engines inherit web vulnerabilities. Just because your matching engine processes financial orders doesn’t mean it’s immune to HTTP-layer race conditions. If the API endpoint is a web server, it’s a web target.
2. Close-position is a deferred computation. When a flag tells the server “figure out what to do,” the gap between figuring and doing is a race window. Explicit orders (side=SELL, qty=108) are harder to race because the parameters are fixed at request time.
3. Asynchronous liquidation creates exploitation windows. If position creation is instant but liquidation takes 10 seconds, that’s a 10-second free option on an overleveraged position.
4. State machine transitions must be atomic. Any multi-step process (read state → decide action → execute action → update state) where concurrent requests can interleave is a TOCTOU vulnerability. In financial systems, the impact is denominated in dollars.
In web security, a race condition costs you a session. In derivatives, it costs the protocol its solvency.
The vulnerability you just read about wasn’t found by reading Solidity. It was found by treating the matching engine like the web service it actually is — and most DeFi protocols ship with that exact blind spot. Teams pour audit budget into the on-chain code and leave the kernel, the API, and the event processors largely untouched. That’s where the production bugs live.
If your protocol has off-chain components and no one has stress-tested them adversarially, that’s the gap I fill. Smart contracts, off-chain infrastructure, and the messy boundary between them — Solana, EVM, or both.
Book a call: Calendly Or email me first: [email protected] — happy to chat before anything formal.
