Cross-Exchange Arbitrage Robot on BAS

Overview

Cross-exchange arbitrage is a simple idea with an unforgiving implementation: the same asset is priced slightly differently across exchanges, and you can earn on that difference by buying where it is cheaper and selling where it is dearer. All of the difficulty is in the details and the speed.

This Browser Automation Studio robot covers the full cycle across four venues - Binance, Bybit, Mexc and Bitget: it keeps a permanent price scanner, finds pairs with a sufficient spread, decides according to a configured strategy, executes, and reports to Telegram.

Problem

Arbitrage cannot be done by hand, and speed is only part of the reason. Before a trade turns out profitable, several things have to line up at once: the fees on both exchanges, the liquidity in the order book (a spread on paper is useless if the volume will not fill), the rounding precision for each pair on each venue, the available withdrawal networks and the wallet addresses for moving funds between exchanges.

While a person checks all of that, the difference disappears. And skipping the checks means a trade that looked profitable closes at a loss on fees and slippage.

Solution

The robot is organised around modes, and that is the key architectural decision. Before any trading it can run in a fill decimals, wallets and networks mode - collecting, once, the technical map of the venues without which any profit calculation is a lie. There is a scanner-only mode, where the robot finds and displays opportunities but executes nothing. And there is full arbitrage, where a qualifying opportunity becomes a trade immediately.

Selection parameters are explicit: trade amount, minimum spread percentage, the set of exchanges, and the trading pairs - ticked from a shared list. Each venue’s keys and the file of deposit wallet addresses live in their own settings tabs rather than inside the script.

A separate test mode runs against one specific exchange pair (Bybit → Binance, for instance), so logic can be verified on a limited circuit instead of the whole portfolio at once.

Features

• Spread scanner across four exchanges: Binance, Bybit, Mexc, Bitget
• Three operating modes: fill decimals/wallets/networks, scanner only, full arbitrage
• Parameter-driven selection: trade amount, minimum spread percentage, chosen exchanges and trading pairs
• Fees, liquidity and per-pair rounding precision accounted for before profit is calculated
• Automatic execution against a qualifying opportunity
• Support for spot and unified trading accounts
• Test mode on a selected exchange pair for verifying logic on a limited circuit
• API keys and wallet addresses stored in settings tabs, separate from the logic
• A Telegram feed per find: pair, volume, buy and sell prices per exchange, spread percentage, estimated profit
• Reporting on completed trades and alerts on events needing operator attention
• Error handling and recovery - the scan loop survives a single failed API call

Development Process

The most underestimated part turned out to be not the trading logic but building the technical map of the exchanges. Rounding precision, minimum order sizes, available withdrawal networks and deposit addresses differ per venue, and without them a profit calculation is fiction: a trade on a 0.5% spread comfortably goes negative if rounding ate part of the volume and the withdrawal took an expensive network. So filling in that data was split out into its own step, run before any trading happens.

The second decision was the scanner-only mode. A robot that trades immediately cannot be observed: there is no telling whether it finds few opportunities or finds plenty of bad ones. Separating discovery from execution makes it possible to watch the Telegram feed for a week and work out which spread threshold is worth anything at all before putting money behind it.

Telegram here is not decoration but the only practical observation surface: a message per find with the pair, volume, both exchange prices, the spread and the estimated profit is a log you can read from a phone, and at the same time a record for working out afterwards why a trade did or did not happen.

Results

• The full arbitrage cycle - scan, filter, decide, execute, report - runs without a human in it
• Four exchanges in one loop instead of comparing browser tabs by hand
• Profit calculation rests on real fees, precisions and networks rather than a paper spread
• Scanner-only mode allows the strategy to be calibrated without risking money
• Every find and every order is visible in Telegram, so the robot’s behaviour can be reviewed after the fact
• Keys and wallets are lifted out of the logic into settings, so configuration changes without touching the script

What Was Learned

The main takeaway is that in a trading robot the work is not in the strategy but in the accuracy of the data underneath it. The idea of arbitrage fits in one sentence; all the remaining time goes into making the profit calculation match the reality of each specific exchange. A robot that computes spreads but knows nothing about rounding and withdrawal networks loses money just as reliably as one with no strategy at all.

The second is that observability has to arrive before execution. Scanner-only mode and the Telegram feed proved more useful than any optimisation: they turn a black box into a stream of decisions you can read. The same idea shows up elsewhere in this portfolio as the live console in the RPA Automation Panel or the per-step screenshots in Etsy Keyword Finder - automation you cannot watch does not deserve trust.