Imagine: a bot trades a strategy that performed perfectly in backtesting. But in real markets, a sudden volatility spike, slippage higher than expected, and one trade wipes out 30% of the account. Without limits, that's a disaster. With properly configured guardrails, it's a controlled loss that doesn't break the strategy. In DeFi, risks like oracle manipulation (e.g., Chainlink) and flash loan attacks add up—limits protect against them. Contact us to discuss your case.
We design limit systems that operate at the core of the trading bot—they verify every order before it hits the exchange. Over our work, we've implemented limit modules for 30+ projects: from spot bots on Binance to complex DeFi strategies on Ethereum and Solana. Here's how such a system works and what matters.
What Types of Limits Does a Bot Need?
Position Limits
- Max position size per instrument: maximum position size for a single instrument, can be absolute (0.5 BTC) or relative (5% of portfolio).
- Max total exposure: total exposure across all open positions. Limits overall leverage—often used with margin requirements.
- Max positions count: number of simultaneously open positions. Protects against a strategy that tries to open positions in every instrument at once.
- Concentration limit: maximum share of capital in one asset. If three different positions correlate with BTC, their combined weight must not exceed X%.
Loss and P&L Limits
- Max daily loss: maximum loss per trading day; when reached, trading stops until next day. Professional traders set 2-5% of account.
- Max weekly/monthly loss: similar for longer periods.
- Max drawdown: maximum drawdown from historical peak; when reached, pause and review strategy.
- Per-trade max loss: maximum loss per single trade; if stop-loss fails, forced close.
Operational Limits
- Max orders per minute: protects against accidental flood of exchange API.
- Max order size: maximum size of a single order (protection from calculation errors).
Example of Dynamic Limit Calculation
When ATR is high, position size automatically decreases to keep the same expected dollar risk. This prevents excessive losses during high volatility and protects against unexpected drawdowns.
Why Pre-Trade Validation Is Critical
Limit checks must be performed before sending the order, not after. Otherwise, the loss has already occurred. We implement synchronous pre-trade validation in the same thread as signal generation:
def validate_order(order, portfolio_state, limits): # Check position size current_pos = portfolio_state.get_position(order.symbol) new_pos_size = current_pos.size + order.quantity if new_pos_size > limits.max_position_size[order.symbol]: raise LimitViolation("MAX_POSITION_SIZE", ...) # Check daily loss if portfolio_state.daily_pnl < -limits.max_daily_loss: raise LimitViolation("DAILY_LOSS_LIMIT", ...) # Check total exposure new_exposure = portfolio_state.total_exposure + order.notional_value if new_exposure > limits.max_total_exposure: raise LimitViolation("MAX_EXPOSURE", ...) return True Pre-trade validation runs in <1ms and ensures no order violating limits is ever sent. In high-frequency trading, this is critical to avoid losses from MEV or unexpected price movements.
Dynamic vs Static Limits: How Effective?
Static limits are good, but markets change. Dynamic limits adapt to conditions: when VIX or ATR is high, position sizes automatically shrink to keep the same expected dollar risk. During low liquidity (Asian night session), limits tighten. As drawdown grows, we gradually reduce limits following the Kelly criterion: the smaller the capital, the smaller the absolute stakes.
Backtesting over the last year shows: dynamic limits cut maximum drawdown almost in half compared to static limits while achieving the same total return. Here are typical settings for different market regimes:
| Market Regime | Max Position (BTC) | Max Daily Loss ($) | Max Exposure ($) |
|---|---|---|---|
| Low volatility | 1.0 | 5,000 | 50,000 |
| Medium volatility | 0.7 | 3,000 | 35,000 |
| High volatility | 0.4 | 1,500 | 20,000 |
| Crisis (VIX > 40) | 0.2 | 500 | 10,000 |
This approach gives the bot more flexibility: it doesn't miss profitable trends but is protected in crises.
Monitoring and Alerting for Limits
Operators should see current limit usage in real time. We provide a dashboard with a table:
| Limit | Max | Current | Usage % |
|---|---|---|---|
| Daily loss | $5,000 | $1,230 | 24.6% |
| Max exposure | $50,000 | $31,500 | 63.0% |
| BTC position | 1.0 BTC | 0.45 BTC | 45.0% |
At 80% fill, a warning is triggered; at 100%, an action (pause/stop) and alert via Telegram/Slack. Example implementation of a dynamic limit based on ATR:
def get_dynamic_max_position(portfolio, symbol, limits, atr): base_position = limits.max_position_size[symbol] atr_factor = min(1.0, limits.base_atr / (atr if atr > 0 else 1)) return base_position * atr_factor * (portfolio.equity / limits.initial_equity) Here the limit depends on current volatility (ATR) and decreases as capital draws down.
What's Included in the Limit System Development
- Documentation: limit specification, behavior on trigger, operator manual.
- Source code: validation module, adapters for your infrastructure (CEX/DeFi), configuration examples.
- Testing: unit tests, integration tests, load testing (up to 1000 orders/sec).
- Monitoring and alerting: ready-made metrics for Prometheus/Grafana, Telegram/Slack integration.
- Training: a session for your team on setup and operation.
- Support: 3 months of maintenance with 4-hour response time.
How We Develop a Turnkey Limit System
The process includes five stages:
- Strategy analysis: review bot logic, typical risks, historical drawdowns.
- Limit scheme design: select limit set, define thresholds, decide which limits will be dynamic.
- Module implementation: write code in Solidity (for DeFi) or Python/Node.js (for CEX), implement pre-trade and post-trade checks.
- Integration and testing: connect monitoring, alerting, perform load testing and formal audit (Slither, Mythril).
- Deployment and maintenance: deploy the system, train operators, provide 3 months of support.
Development timelines range from 2 to 4 weeks depending on complexity. Cost is calculated individually after analyzing your project. Get a consultation—let's discuss your case and propose the optimal solution.