Python Bybit Pump & Dump Early Detection Engine – $1,000

Fixed Budget: USD $1,000 – Complete Project

I am looking for an experienced quantitative trading developer to design, develop, validate and deliver a professional standalone Python 3.12 module for detecting early pump and dump movements on Bybit USDT perpetual futures.

IMPORTANT: This is NOT an MT4/MT5 indicator, Expert Advisor or a request to build a complete trading bot.

I already have an existing Python trading bot. It is not part of this development assignment and must not be modified.

I need a separate detection engine that can eventually provide actionable LONG and SHORT signals to my existing system through a documented interface.

1. Main Objective

The objective is to detect significant upward and downward price movements as early as realistically possible, preferably within seconds or the first 1–2 minutes when sufficient market evidence exists.

The system must identify:

• Early LONG opportunities.

• Early SHORT opportunities.

• Emerging pump and dump movements.

• Short squeezes and liquidation cascades.

• Aggressive buying and selling pressure.

• Liquidity-driven price acceleration.

• Potential exhaustion and reversal opportunities.

The system must not wait until most of the price movement has already occurred.

2. Market Coverage

The module must dynamically monitor all eligible Bybit USDT perpetual contracts, including major, mid-cap, small-cap and newly listed instruments.

Symbols must not be arbitrarily excluded because of market capitalization.

Each opportunity must instead be evaluated according to actual liquidity, spread, order-book depth, estimated slippage and execution risk.

3. Real-Time Detection

The module must process live market events using Bybit APIs and WebSockets.

Required analysis includes:

• Individual executed trades.

• Aggressive taker buy/sell volume.

• Cumulative Volume Delta (CVD).

• Trade frequency and volume acceleration.

• Relative volume and abnormal market activity.

• Price momentum and acceleration.

• Incremental Level 2 order-book updates.

• Bid/ask liquidity imbalance.

• Liquidity consumption, withdrawal and absorption.

• Spread, market depth and estimated slippage.

• Open interest and liquidation data where relevant.

The developer must design the quantitative decision rules, adaptive thresholds and signal scoring methodology.

Signals must be event-driven and must not require mandatory M1/M5 candle-close confirmation.

4. Intelligent Signal Selection

Every opportunity must be evaluated through explainable decision states:

• WATCH

• CANDIDATE

• CONFIRMED

• REJECTED

Each decision must include a timestamp, symbol, direction, relevant metrics and measurable acceptance or rejection reasons.

The system must distinguish genuine directional pressure from false breakouts, poor liquidity, excessive spread, unfavorable execution costs and movements that are already too extended.

LONG and SHORT detection must be developed and validated separately.

5. Historical Data and Validation

The developer is responsible for obtaining and verifying genuine historical Bybit market data, including individual trades, incremental Level 2 order-book updates and the snapshots required for reconstruction.

The system must support reproducible chronological historical replay using the same core detection logic as the live system.

No look-ahead bias, future-data leakage, unrealistic fills or optimization on the final untouched test dataset is permitted.

Historical testing must account for:

• Trading fees.

• Bid/ask spread.

• Slippage and market impact.

• Order-book liquidity.

• Execution latency.

• Funding costs.

• Applicable portfolio risk limits.

All important filters must undergo reproducible ablation testing.

Rejected signals and major market movements that were detected late or completely missed must also be reported.

6. Mandatory Historical Performance Requirements

The completed system must satisfy ALL of the following conditions on genuinely untouched out-of-sample historical data:

A. Profit Factor

At least 1.50 separately for LONG and SHORT, after realistic trading costs.

B. Net Expectancy

Positive separately for LONG and SHORT after costs.

C. Minimum Trade Count

At least 100 independent CLOSED out-of-sample trades for LONG and 100 for SHORT.

D. Maximum Drawdown

Maximum portfolio drawdown must not exceed 15% under predefined portfolio risk settings.

E. Robustness

The strategy must remain net profitable after removing its five largest winning trades.

All results must be reproducible from the delivered code, datasets and configuration.

These are mandatory final acceptance conditions, not guarantees of future profitability.

7. Existing Trading Bot

The existing trading bot must not be rebuilt or unnecessarily modified.

The new detection engine must operate independently and expose a clean Python integration interface.

The existing trading system uses:

• TP1: close 20% of the original position.

• TP2: close another 20%.

• Remaining 60%: ATR Chandelier trailing.

• No fixed TP3.

• Optional break-even only after TP2.

The detector must not replace or change these exit rules, leverage settings or risk limits.

8. Demo Trading and Delivery

After successful historical validation, the system must undergo 2–4 weeks of actual Bybit Demo Trading.

Final delivery must include:

• Complete Python 3.12 source code.

• All required configuration files.

• Live detection engine.

• Historical replay engine.

• Historical data sources, manifests and integrity audit.

• Reproducible backtest scripts.

• Complete LONG and SHORT trade logs.

• Signal and rejection logs.

• Filter-ablation reports.

• Missed-opportunity analysis.

• Historical performance reports.

• Bybit Demo Trading results.

• Installation and operating documentation.

• Automated tests.

A 10-business-day independent review period is required before final acceptance.

9. Budget and Payment Protection

Maximum total project budget: USD $1,000, fixed and all-inclusive.

I am willing to reserve the agreed project amount through the official MQL5 Freelance payment protection system.

However:

• No direct upfront payment to the developer.

• No advance release of reserved funds.

• No paid research or feasibility stages.

• No partial milestone payments.

• No additional historical data charges.

• Final payment only after successful completion and acceptance, subject to the official MQL5 Freelance rules.

The complete technical requirements and acceptance procedure must be agreed and documented before the project begins.

If the system fails any mandatory acceptance requirement, it does not qualify for successful final acceptance. Any dispute or refund will be handled under the official platform rules.

10. Developer Qualifications

I am NOT looking for a developer who will simply implement a predefined RSI, MACD or volume strategy.

I need a specialist capable of independently researching, designing and validating a genuine quantitative detection strategy.

Applicants must answer:

1. Have you previously developed Bybit or cryptocurrency order-flow trading systems?

2. Have you worked with real tick-by-tick trades and incremental Level 2 order-book data?

3. Can you provide evidence of reproducible historical strategy validation?

4. Can you independently design and test the complete LONG/SHORT detection methodology?

5. Can you accept the mandatory historical performance criteria as final acceptance requirements?

6. Can you accept the $1,000 all-inclusive budget and MQL5-protected payment arrangement?

7. What is your realistic delivery timeline?

Please do not apply if you can only provide an indicator, a basic trading bot, screenshots of backtests or unverified profitability claims.

I understand that genuine quantitative research may fail to achieve the specified performance. I do not expect fabricated results or guaranteed profits. However, successful delivery requires meeting the agreed objective acceptance criteria.

Only serious applicants with relevant technical experience should apply.