Set Up and Use the Cross Exchange Arbitrage Bot

What the Cross Exchange Arbitrage Bot Does

The Cross Exchange Arbitrage Bot is presented as a Windows desktop tool for identifying price differences across cryptocurrency exchanges. According to its README, it monitors Binance, OKX, Bybit, Kraken, Gate, and decentralized exchanges in real time.

When the same asset trades at different prices, the bot estimates whether the difference remains profitable after taker fees, withdrawal costs, and expected slippage. If a spread passes the configured threshold, the bot can attempt to buy on the cheaper exchange and sell on the more expensive exchange simultaneously.

The project makes trading and profitability claims that are not independently verified by the README. Review downloaded files carefully, test with small amounts, and never risk funds you cannot afford to lose.

Key Features

• Cross-exchange scanning: Watches supported centralized exchanges and DEXes for price differences.
• Simultaneous execution: Attempts to submit the buy and sell legs together rather than transferring assets during the opportunity.
• Fee-aware filtering: Accounts for taker fees, slippage, and withdrawal costs when calculating the net spread.
• Triangular mode: Looks for three-market loops on one exchange, such as BTC to an altcoin, then USDT, and back to BTC.
• Funding-rate monitoring: Tracks funding differences in perpetual markets.
• Local API configuration: The README states that exchange keys remain in a local configuration and should have trading permission without withdrawal permission.
• Session records: Writes spreads, rejected opportunities, and fills to arb.csv.

Understand the Trading Model

Cross-exchange arbitrage requires balances on both exchanges before a trade begins. For example, the bot may need quote currency on Binance to buy an asset and the same asset on Bybit to sell it. This pre-positioning avoids waiting for a blockchain transfer, but it creates inventory and exchange-custody risk.

A visible spread is not the same as a profitable trade. The README gives an example in which an asset is quoted at $2.841 on Binance and $2.849 on Bybit. The displayed difference is approximately 0.28%, but fees and estimated slippage reduce the projected net spread to 0.15%.

[15:22:09] SPREAD ALT9: Binance $2.841 vs Bybit $2.849 (+0.28%)
[15:22:09] FEES   Taker x2: 0.10%   Slippage est: 0.03% | Net: +0.15%
[15:22:09] PLAN   Buy 0.35 BTC worth on Binance | Sell same on Bybit

The README emphasizes that many opportunities should be rejected because their gross spread disappears after costs. Rejection is therefore an expected part of the scanner's behavior.

Installation and Setup

1. Download and inspect the package

Use the project's download page, then extract the package into a dedicated directory such as C:\Bots\Cross-Arb.

Because the setup runs a downloaded executable and the README does not document a checksum or build-from-source verification process, scan the archive and executable before opening them. Confirm the download source, review file signatures where available, and consider testing in an isolated environment first.

2. Install dependencies

Open PowerShell, move to the extracted directory, and run the dependency installation command shown in the README. This step requires npm to be available on the system.

cd C:\Bots\Cross-Arb
npm install

3. Create restricted exchange API keys

Create separate API credentials through each exchange's official account dashboard. Enable only the permissions required for trading. Do not enable withdrawals. Then add the credentials with the provided key commands:

.\carb.exe keys add binance --trade-only
.\carb.exe keys add bybit --trade-only

Repeat the documented pattern only for exchanges supported by the installed package. Verify the final permissions directly in each exchange dashboard. A non-withdrawal key reduces one category of risk, but a trading-enabled key can still place harmful orders if it is compromised or configured incorrectly.

4. Configure scanning limits

The following command selects Binance, Bybit, and OKX, sets a minimum net spread of 0.15%, and caps each leg at $350:

.\carb.exe config --min-net-spread 0.15 --max-leg 350 --exchanges binance,bybit,okx

Choose values that reflect fees, liquidity, account balances, and your risk tolerance. A small threshold can admit opportunities that disappear because of latency or unexpected slippage.

5. Start the bot

.\carb.exe start

Watch the first session closely. Confirm that the exchanges, symbols, order sizes, fee assumptions, and account balances match your intended setup.

Configure Rules with config.json

The README also provides a config.json example:

{
  "exchanges": ["binance", "bybit", "okx"],
  "min_net_spread_pct": 0.15,
  "max_leg_usd": 350,
  "daily_profit_target_usd": 100,
  "fee_math": {
    "taker_both_sides": true,
    "slippage_buffer_pct": 0.05,
    "reject_below_net": true
  },
  "triangular_mode": false,
  "funding_monitor": true
}

• exchanges: Defines the venues included in the scan.
• min_net_spread_pct: Sets the minimum spread after modeled costs.
• max_leg_usd: Limits the configured value of each trade leg.
• daily_profit_target_usd: Records the daily target value used by the configuration.
• taker_both_sides: Includes taker costs for both sides in fee calculations.
• slippage_buffer_pct: Adds a buffer for the difference between the observed and executed price.
• reject_below_net: Rejects opportunities below the net-spread requirement.
• triangular_mode: Enables or disables single-exchange triangular scanning.
• funding_monitor: Enables monitoring of perpetual funding differences.

Do not assume that the example values are appropriate for every exchange or market. Compare the configuration with the current fee schedules and minimum order requirements published by each exchange.

Read the Console Output

The console labels make it possible to follow an opportunity through its lifecycle:

• SCAN: Reports the number of pairs and exchanges being monitored.
• SPREAD: Shows the two prices and the gross percentage difference.
• FEES: Displays modeled fees, slippage, and the resulting net spread.
• PLAN: Describes the intended buy and sell legs.
• EXEC: Reports fill prices for each submitted order.
• DONE: Reports the realized percentage and amount shown by the application.

[15:22:11] EXEC   Leg 1: BUY filled @ 2.8412 (Binance)
[15:22:11] EXEC   Leg 2: SELL filled @ 2.8487 (Bybit)
[15:22:11] DONE   +0.14% realized — $4.90 on this leg

A planned return and a realized return can differ. Use the actual exchange fills, fees, and account balance changes when checking results rather than relying only on the application's summary.

Verify Every Trade

1. Record both fill IDs. Match the identifiers printed by the bot with the order history on each exchange.
2. Confirm executed quantities. Ensure that the buy and sell legs filled for the intended amounts.
3. Check actual prices and fees. Recalculate the result using the fill prices and fees reported by the exchanges.
4. Review arb.csv. Compare the session log with the exchanges' official records.
5. Inspect rejected spreads. Confirm that the configured fee and slippage filters are excluding opportunities below the net threshold.
6. Recheck API permissions. Make sure withdrawal access remains disabled for every key.

Advanced Tips and Risk Controls

Keep trade sizes conservative

Larger orders may consume multiple order-book levels and experience more slippage. The README explicitly advises using small sizes and notes that real spread capacity is limited. Begin with a low max_leg_usd value and compare estimated slippage with actual fills before considering changes.

Maintain inventory on both venues

Simultaneous execution requires assets to be available on both sides. Monitor balance drift after each trade because repeated buying on one exchange and selling on another can leave the accounts unbalanced. The README identifies this inventory requirement as a risk the bot cannot remove.

Use a realistic net-spread floor

The minimum threshold should exceed modeled costs by a margin appropriate for latency and changing liquidity. The fee model is only an estimate until orders fill. Review taker rates, account fee tiers, and slippage assumptions regularly.

Evaluate triangular and funding modes separately

Triangular arbitrage and funding-rate monitoring use different market structures from a two-exchange spot spread. Keep triangular_mode disabled unless you understand the three conversion legs and their cumulative fees. Treat funding differences as monitoring information rather than guaranteed returns.

Protect API credentials

• Create unique keys for this application rather than reusing existing credentials.
• Never grant withdrawal permission.
• Apply exchange-supported IP restrictions if they fit your setup.
• Keep local configuration files out of shared folders and backups that are not encrypted.
• Revoke the keys immediately if the machine or downloaded package may be compromised.

Conclusion

The Cross Exchange Arbitrage Bot README describes a tool that scans multiple exchanges, filters spreads using fee and slippage estimates, and can submit paired trades. Its most useful controls are the minimum net spread, maximum leg size, exchange selection, fee model, and local trade-only API configuration.

Arbitrage is not risk-free. Partial fills, changing prices, exchange outages, inventory exposure, incorrect fee assumptions, and compromised API credentials can all cause losses. Verify the software before running it, start conservatively, and reconcile every reported result against the exchanges' own records.