CEX Triangular Arbitrage Bot

About the Project

An improved version of my arbitrage system, now within one exchange to eliminate transfer delays.

The Evolution

After creating the Cross CEX Arbitrage Bot, I came up with the idea to do triangular arbitrage within the same exchange, so you don't have to deal with wait times between exchanges. With triangular arbitrage, you profit from price inefficiencies between three different trading pairs on one platform.

How It Works

Triangular arbitrage exploits price discrepancies between three related trading pairs on a single exchange. Here's a concrete example of how it works:

Example Scenario:
Imagine you have $1,000 USDT and you notice these prices on an exchange:

• BTC/USDT = $50,000 (1 BTC costs 50,000 USDT)
• ETH/BTC = 0.04 (1 ETH costs 0.04 BTC)
• ETH/USDT = $2,100 (1 ETH costs 2,100 USDT)

The Arbitrage Cycle:

1. Step 1: Convert $1,000 USDT → 0.02 BTC (1,000 ÷ 50,000)
2. Step 2: Convert 0.02 BTC → 0.5 ETH (0.02 ÷ 0.04)
3. Step 3: Convert 0.5 ETH → $1,050 USDT (0.5 × 2,100)

Result: You end up with $1,050 USDT instead of your original $1,000 — that's a $50 profit (2.5% return) before exchange fees! The price inefficiency between ETH/USDT ($2,100) and the implied price through BTC ($2,000 = 0.04 × 50,000) created this arbitrage opportunity.

What the Bot Does: It continuously monitors hundreds of three-pair combinations, calculates if going through the cycle yields more than the direct trade, and accounts for exchange fees and orderbook slippage to determine actual profitability in real-time.

When a profitable opportunity is found, it is immediately executed automatically to maximize the chance.

Practical Challenges

Building this for real exchanges came with non-trivial constraints that the bot had to handle dynamically:

• Precision per pair and exchange: Symbols use different price/amount precisions. For example, Binance BTC/USDT can allow up to 5 decimals, while on KuCoin it might be limited to 2. The bot normalizes per-market precision and rounds correctly to avoid invalid order errors.
• Min/Max order constraints: Each market has minimum and maximum order amount and/or notional (cost). The sizing logic checks these limits and skips or resizes cycles that fall outside the allowed bands so orders don’t get rejected.
• Slippage estimation: Real profitability depends on where fills occur in the book. I estimate slippage by simulating fills across the depth (walking the book) and include maker/taker fees to compute the effective cycle return. Getting this right was a significant challenge.

The Reality

Here too, I discovered that there's too much competition and it's therefore not practically usable for retail traders. The opportunities are often picked up within milliseconds by professional trading firms that use co-located servers (servers physically close to the exchange) and low-latency WebSockets to analyze orderbooks even faster instead of via polling.