How to Run a Trading Bot on a Funded Crypto Account

Running a trading bot on a funded crypto account is straightforward when you know the 3 connection types and what each requires. This guide covers all of them: API-connected custom bots (Python, JavaScript, any language), signal-based automation (TradingView webhooks, Telegram signals, third-party tools), and expert advisors (EAs).

The examples throughout use DXtrade, the platform Velotrade runs on. DXtrade is a professional trading platform available to traders globally, with no jurisdiction restrictions, and the same REST and WebSocket API works identically whether you are connecting from Europe, Asia, or the Americas. If your prop firm uses a different platform, the architecture principles here still apply. The specific endpoints will differ, but the core pattern is the same across any modern trading API: authenticate, monitor equity, place orders, handle errors.

What you need before connecting any automation

Connecting a bot before these are in place is a reliable way to blow a challenge on the first session.

A tested strategy with documented results. Backtests alone are not sufficient. Run the strategy forward in demo for a minimum of 2 weeks covering trending, ranging, and volatile market conditions. Document the results. If the system cannot produce consistent outcomes in demo, it is not ready for a funded evaluation.

A working knowledge of the firm's drawdown rules. Velotrade uses an end-of-day (EOD) trailing drawdown model. The floor only moves at day close, not tick by tick. Your bot must know the current floor, how close the account is to it, and what action to take when the gap narrows. Read the crypto prop firm rules explained guide before building any compliance logic.

Drawdown monitoring built into the bot. This is the single most common failure point for automated accounts. Your system must read live equity on every tick and compare it against the drawdown floor. A bot that places entries without checking account state will breach the account automatically if a losing run occurs at the wrong time.

A reconnection and error-handling plan. DXtrade session tokens expire after 30 minutes of idle activity. Your bot must handle token refresh, reconnection after network drops, and order rejection responses without entering duplicate positions or missing halts.

Demo tested on the DXtrade platform specifically. Not on a backtest engine, not on a different broker. Fill behavior, spread, minimum sizes, and API response timing may differ from a direct exchange connection. The system must be tested on the exact environment it will run in.

The 3 types of automated trading on funded accounts

There are 3 distinct automation architectures used on funded crypto accounts:

1. API-connected custom bots: scripts written in any language (Python, JavaScript, Go, Rust) that connect directly to the DXtrade REST and WebSocket API to place orders and monitor account state.
2. Signal-based automation: an external source generates the trade signal (TradingView alert, Telegram channel, proprietary model, AI output) and a middleware layer translates that signal into a DXtrade API call.
3. Expert Advisors (EAs): rule-based programs originally built for MT4 or MT5, either rebuilt using the DXtrade API or connected via a bridge adapter that translates MetaQuotes API calls to DXtrade-compatible format.

All 3 are permitted at Velotrade. The restriction is on strategy behavior, not the technology used to execute it. For a full breakdown of which strategy types are prohibited regardless of automation method, see algo and bot trading in crypto prop firms: what's allowed.

Type 1: API-connected custom bots

This is the most flexible approach. You write the strategy logic yourself, in any language, and connect directly to the platform API. Everything below uses DXtrade as the example, since that is what Velotrade is built on.

Authentication and credentials

DXtrade uses the same credentials for API access as for the desktop platform login. There is no separate key issuance, no application, and no approval process. Log in via the REST API using your username and password to receive a session token. Use that token in the Authorization header for subsequent requests.

The session token has a 30-minute idle timeout. If no API calls are made for 30 minutes, the token expires and subsequent requests return a 401 response. Your bot must handle this by either polling to keep the session alive or re-authenticating on a 401 error before retrying the request.

Full authentication flow and endpoint documentation is at the DXtrade developer portal. You can also find everything about API access for Velotrade funded accounts at velotrade.com/api-access.

Placing orders via REST API

Orders are placed via a POST request to:

POST https://dx.velotrade.com/dxsca-web/accounts/{accountCode}/orders

The required fields in the JSON body are:

Optional fields include limitPrice (required for LIMIT orders), stopPrice (required for STOP orders), takeProfitPrice, and stopLossPrice.

The full place-order reference with all optional parameters is at dx.velotrade.com/developers/#/DXtrade-REST-API?id=place-order. The Velotrade API access page also covers the integration in detail.

Reading live account data via WebSocket

The DXtrade WebSocket feed streams real-time account state including equity, unrealized P&L, margin used, free margin, and position-level data. Connect to the WebSocket endpoint after authenticating via REST, then subscribe to the account data feed using your account code.

Every account state update comes through this stream. Your drawdown compliance logic must consume this feed on every message, not on a polling interval. A 5-second poll interval can miss a rapid equity move in a volatile market. The WebSocket push model eliminates that risk.

The equity value from the WebSocket represents the current market-to-market value of the account. Compare this against the drawdown floor on every update.

Building drawdown compliance into your bot

This is the most critical section of this guide. Skip it and the account will breach itself.

Velotrade uses an EOD trailing drawdown model. The drawdown floor is set at account open as: initial balance minus the maximum drawdown allowed. The floor does not move intraday. It only moves up at the close of each trading day if the account has made profit. On the next day, the floor is recalculated based on the previous day's closing equity.

Your bot must:

1. Read the current drawdown floor at session start. Retrieve the account's current equity high-water mark and calculate the current floor before placing any order.
2. Subscribe to the WebSocket equity feed immediately after authenticating. Never place an order before this subscription is active and the first equity update has been received.
3. Compare live equity to the floor on every WebSocket update. Store the floor as a variable. On each equity message, calculate the gap: current_equity - floor. This is your remaining buffer.
4. Define a halt threshold. Do not wait until equity hits the exact floor. Set a conservative halt threshold, for example 20% of the buffer remaining. When equity drops below floor + (buffer * 0.2), halt all new entries and prepare to close open positions.
5. Close all positions if the daily loss limit is approached. The daily loss limit is separate from the overall drawdown floor. Track today's realized and unrealized P&L from the start of the trading day. If the combined P&L approaches the daily loss limit (a negative number), close all positions.
6. Handle the EOD model correctly at day close. At end of day, the floor may move up if the account closed in profit. Do not hardcode the floor at session start. Refresh it after each daily reset.

A bot that ignores this logic will breach the account automatically during a losing streak. The prop firm's risk system does not distinguish between a human error and an EA error. A breach is a breach.

"The biggest mistake algo traders make when they move to a funded account is assuming the risk rules work the same as on a personal exchange account. They do not. You are operating inside someone else's risk framework, and your bot needs to respect that on every single tick — not just when you remember to check." — Velotrade trading team

Type 2: Signal-based automation

Not everyone wants to write a full strategy engine. Signal-based automation is the middle ground: you use an external signal source you already trust, and a small middleware script handles the execution side.

How it works

Signal-based automation separates the decision layer from the execution layer. An external source generates a trade signal. A middleware script receives that signal and translates it into a DXtrade API order. The bot does not decide when to trade. It only translates and executes.

This architecture is common among traders who use TradingView strategies, follow Telegram signal channels, use paid signal services, or have proprietary models running outside the DXtrade environment. The signal source handles the entry logic. Your script handles authentication, order formatting, and compliance checks.

TradingView webhook to DXtrade

The workflow has 3 components:

1. TradingView alert: configure an alert on your chart or strategy. Set the notification method to "Webhook URL". Define the alert message in JSON format to include the action (buy/sell), symbol, and quantity.
2. Middleware server: a small server (a Flask app, a Node.js Express endpoint, a serverless function) that receives the webhook POST, validates the payload, authenticates against DXtrade, and submits the order via the place-order endpoint.
3. DXtrade REST API: receives the order and executes it on your funded account.

The middleware is where your compliance logic lives. Before submitting the order, the middleware must check live equity via the REST API or maintain a WebSocket connection to verify the account is not within the halt threshold. If the check fails, the order is dropped, not submitted.

A minimal Python middleware receives the TradingView webhook, extracts the signal parameters, re-authenticates if the session token has expired, checks account equity, and if all conditions are met, POSTs the order to DXtrade. The full API reference for this flow is at the DXtrade developer portal.

Third-party automation tools

Tools such as 3Commas, Cornix, or custom signal relay middleware can bridge external signal sources to DXtrade via the REST API. Velotrade does not restrict which third-party tool you use. The only restriction is on what the resulting strategy does.

Latency arbitrage and tick scalping that exploits platform data feed behavior remain prohibited regardless of which tool executes the order. The tool is irrelevant. The strategy is what gets evaluated.

When using a third-party tool, verify that it supports custom REST API endpoints and can handle DXtrade's authentication flow, including session token refresh. Not all third-party automation platforms support fully custom API integrations. If the tool only supports pre-built broker connectors, it may not work with DXtrade without custom development.

Type 3: Expert Advisors (EAs)

If you have been trading forex or crypto on MetaTrader for years, you probably have EAs you already trust. Here is the honest situation when moving them to a DXtrade-based funded account.

MT4 and MT5 EAs on DXtrade

MT4 and MT5 EAs are written against the MetaQuotes API (MQL4 and MQL5). DXtrade uses a different API architecture and does not natively accept MetaQuotes connections. An MT4 EA cannot connect to DXtrade directly.

There are 2 options:

Option 1: Rebuild the strategy logic using the DXtrade API. Extract the trading rules from the MQL4 or MQL5 code and reimplement them in any language that supports HTTP requests and WebSocket connections. Python and JavaScript are the most common choices. This is the cleaner approach for new builds and gives full control over the execution and compliance logic. The DXtrade API documentation at dx.velotrade.com/developers/#/ covers everything needed.

Option 2: Use a bridge adapter. A bridge adapter runs alongside MetaTrader, intercepts the EA's order calls, and translates them into DXtrade REST API calls. The EA continues to run in MT4 or MT5 as normal. The bridge handles the translation. This works for existing EAs you do not want to rewrite. The main tradeoff is latency: the translation layer adds execution delay compared to a direct API connection.

For a full explanation of DXtrade setup and platform navigation, see how to use DXtrade for crypto prop trading.

What to test before going live on a paid challenge

Run the system in demo for at minimum 2 weeks before starting any paid evaluation. The tests that matter:

Daily loss limit approach test. Manually simulate a losing session that brings account equity close to the daily loss limit. Does the bot halt correctly? Does it close open positions? Does it stop submitting new orders? This test must pass before the system is live.

Session timeout and reconnection test. Leave the bot idle for 35 minutes to force a session token expiry. Then trigger a trade signal. Does the bot re-authenticate before attempting the order? Does it handle the 401 response and retry? A bot that crashes on token expiry will miss exits on open positions.

Order rejection handling. Test what happens when an order is rejected due to insufficient margin, incorrect instrument code, or size below minimum. The bot must log the rejection and handle it gracefully, not loop indefinitely or crash.

EOD drawdown floor refresh. If your bot runs across multiple trading days, verify that it correctly reads the updated drawdown floor after each daily reset. Hardcoding the initial floor will cause compliance logic errors as the floor moves.

Reconnection with open positions. Disconnect the bot's network connection while a position is open, then reconnect. Does the bot read the current position state before attempting any new orders? A bot that re-enters a position that is already open doubles the risk exposure.

What automation is not allowed

The restriction is on strategy type, not technology. The same rules apply whether you trade manually or via a bot:

Latency arbitrage is prohibited. This is any strategy that profits from seeing a price update on an external feed before that update is reflected on the DXtrade platform. The profit comes from a data feed timing gap, not from market analysis. No payout is issued on these positions and accounts showing consistent latency arbitrage patterns are closed.

Tick scalping that exploits platform data feed behavior is prohibited. Standard scalping on legitimate market data is permitted. The prohibited version specifically targets pricing artifacts, fill behavior, or delayed updates that exist in the prop firm's simulation environment but would not exist on a live exchange. The test is whether the same strategy would be profitable if run directly on a live exchange with identical data. If the answer is no, the strategy is not compliant.

Coordinated multi-account bots are prohibited. Running the same bot simultaneously across multiple funded accounts owned by different people, or using a bot to guarantee evaluation outcomes across a group of challenge accounts, is not permitted. Correlated positions across accounts are detected automatically.

For the full list of permitted and prohibited strategies, see algo and bot trading in crypto prop firms. For a companion overview of the best crypto prop firms for algo traders, see best crypto prop firms for algo traders.

Payouts for automated accounts

Automated accounts follow the same payout process as manual accounts. There is no extended review period for bot activity and no additional documentation required for algorithmic traders.

Payouts are processed within 24 hours and paid in USDC or USDT. The payout request process is the same as for any funded account. No distinction is made between manual and automated trading in the payout workflow.

See all available funded account sizes and challenge structures at velotrade.com/challenges.

This guide reflects Velotrade's platform specifications and trading rules as of May 2026. Rules are subject to change. Always confirm current permitted and prohibited strategy types before deploying any automated system on a live challenge. Nothing in this article constitutes financial or investment advice.

---