Contact person: Business Client

Phone:Show

Email:Show

Location: Odesa, Ukraine

Budget: Recommended by industry experts

Time to start: As soon as possible

Project description:
"Technical Specification for Developing a Trading System with Delta-Neutral Spread Arbitrage Strategy between Perpetual Futures and Spot Pairs on OKX Cryptocurrency Exchange
Key Points:

The system implements a delta-neutral strategy between spot pairs and perpetual futures on OKX.
Development is carried out in Java to ensure speed and parallelism.
A hybrid approach is used: real-time online spread calculations and offline parameter optimization using a genetic algorithm.
The architecture is based on microservices interacting through Kafka and RabbitMQ, with data storage in PostgreSQL and OpenSearch.
Infrastructure budget is up to $500/month, prototype development time is 2 weeks, and full system development time is 1 month.
Introduction
The goal of the project is to create an automated trading system based on Java that implements a delta-neutral spread arbitrage strategy between perpetual futures and spot pairs on the OKX cryptocurrency exchange. The strategy aims to minimize market risk by simultaneously opening opposite positions in the spot and futures markets, allowing profits to be made from price differences and funding fees, while reducing the impact of market volatility.

System Architecture
The system is built on a microservice architecture based on Java, ensuring scalability and fault tolerance. The main components and their interactions are presented in the table:

Service Responsibility Technologies/Tools Notes
Market Monitoring Service Real-time collection of spread data between spot and futures, normalization, and sending to Kafka. OKX API, WebSocket, Java Data is stored in PostgreSQL and OpenSearch.
Data Analysis Service Processing historical data, calculating metrics for GA, and forming vectors for pgvector. Java (Spring Boot), PostgreSQL Runs on a schedule (once a day).
GA Training Service Optimizing strategy parameters on historical data using GA and saving results. Java (Genetic Algorithm lib), pgvector Dedicated instance for resource-intensive tasks.
Trade Execution Service Executing trade orders on OKX, managing positions, and hedging. OKX API, Java Requires minimal latency.
Authorization Service Authentication and user rights management (if the system is multi-user). JWT, PostgreSQL, Java Currently minimal functionality.
API Gateway Routing requests between services, ensuring security (rate limiting, validation). Spring Boot, Nginx Preparation for future scaling.
Service Interaction Scheme:

Spread data flows from the Monitoring Service to Kafka, where it is consumed by the Analysis Service and Trade Execution Service.
GA results are stored in PostgreSQL with pgvector and cached for quick access.
RabbitMQ is used for internal notifications (e.g., about opening/closing trades).
Functional Requirements
Trading Strategy Logic
The system must calculate the spread between the spot price and the perpetual futures price in real-time for selected pairs (e.g., BTC/USDT, ETH/USDT). When a spread exceeding a set threshold is detected, the system checks:

Availability of such spread history in the GA vector (if yes, uses optimal parameters from the database).
If no data is available, calculates trade parameters online (using predefined formulas, e.g., based on volatility or volumes).
After opening a position, the system must automatically hedge risks (e.g., by opening opposite positions in futures).

Risk Management
Limits on maximum position size (as a percentage of the deposit).
Stop-loss and take-profit levels dynamically adjusted based on GA data.
Monitoring liquidity and slippage.
Genetic Algorithm (GA)
The GA should optimize the following parameters:

Entry/exit points (spread in pips or %).
Position size.
Risk limits (maximum loss per trade).
Input Data for GA: historical spreads, results of previous trades, volatility.

Output Data: parameter vector stored in pgvector for quick search by key (spread, pair, time interval).

Execution Frequency: once a day (at night, when market load is low).

Data and Processing
Database Structure
PostgreSQL:
Tables for storing:
Market data (time, pair, spot price, futures price, spread).
Trades (time, pair, trade type, size, result).
Strategy parameters (optimized by GA).
pgvector:
Storing GA parameter vectors for quick search by similar spreads.

OpenSearch:
Service logs.
Performance analytics (execution time, errors).
Kafka:
Topics for streaming spread data, trade signals, and trade results.

Algorithmic Logic
Pseudocode for the main decision-making algorithm:

public class TradingAlgorithm {
public void handleSpread(SpreadData spreadData) {
// 1. Calculate current spread
double currentSpread = calculateSpread(spreadData);

// 2. Check for spread in the database
OptimalParams optimalParams = pgvectorSearch(currentSpread);

if (optimalParams != null) {
// 3. Use GA parameters
executeTrade(optimalParams);
} else {
// 4. Calculate parameters online
OptimalParams params = calculateOnlineParams(spreadData);
executeTrade(params);
}

// 5. Hedge the position
hedgePosition(spreadData);
}

private double calculateSpread(SpreadData data) {
// Calculate spread based on spot and futures prices
return [login to view URL]() - [login to view URL]();
}

private OptimalParams pgvectorSearch(double spread) {
// Search in GA vector by key (spread, pair, interval)
return queryPgvector(spread);
}

private OptimalParams calculateOnlineParams(SpreadData data) {
// Calculate trade parameters based on heuristics and market data
return new OptimalParams(
[login to view URL]() * 0.8, // Example: 80% of current spread
[login to view URL]([login to view URL]() * 0.1, 1000), // 10% of available balance, but no more than 1000
[login to view URL]() * 0.5, // Stop-loss at 50% of spread
[login to view URL]() * 1.5 // Take-profit at 150% of spread
);
}

private void executeTrade(OptimalParams params) {
// Execute trade via OKX API
[login to view URL](params);
}

private void hedgePosition(SpreadData data) {
// Hedge position (e.g., open opposite position in futures)
[login to view URL](data);
}
}
Security
All OKX API keys must be stored encrypted in PostgreSQL.
Access to services only through authentication (JWT for API, internal tokens for inter-service communication).
Rate limiting on the API gateway to protect against DDoS.
Daily database backups.
Monitoring and Logging
OpenSearch + Kibana for log and metric visualization.
Monitoring key metrics:
Delays in spread processing.
Percentage of successful trades.
Profit/loss ratio.
Server load (CPU, RAM, network).
Alerting: Notifications in Telegram/Slack for critical errors (e.g., failed trades, service crashes).
Infrastructure Components
Component Purpose Configuration Monthly Cost Notes
PostgreSQL Data storage 4 vCPU, 8GB RAM, 100GB SSD Up to $50 With pgvector plugin.
OpenSearch Logs and analytics Locally in Docker (for now) $0 (planned $150) Migrate to cloud in the future.
Kafka Streaming data transfer 2 brokers, 2GB RAM each ~$150
RabbitMQ Internal notifications 1 instance, 1GB RAM $5–10
Market Monitoring Service Data collection from exchange 2 vCPU, 4GB RAM Up to $10
Trade Execution Service Order execution 2 vCPU, 4GB RAM, low ping Up to $10 Locate closer to OKX servers.
Data Analysis Service Data processing for GA 4 vCPU, 8GB RAM $10–20
GA Service Parameter optimization 8 vCPU, 16GB RAM $20–40 Runs once a day.
API Gateway Request routing 1 vCPU, 2GB RAM $5–10
Auth Service Authentication 1 vCPU, 1GB RAM $5–10
Financial and Time Constraints
Budget: Up to $500/month (including all servers and services).
Development Priorities:
Market Monitoring Service and data collection.
Trade Execution Service (minimum functionality).
Integration with OKX API.
Data Analysis Service and GA (can be implemented later, initially using simple formulas).
Timeline: Prototype (data collection + simple strategy) — 2 weeks, full system with GA — 1 month.
Expected Result
The expected result is a working trading system in Java that meets all specified requirements and is capable of:

Collecting and processing data on spreads between spot and futures pairs on OKX.
Implementing a delta-neutral spread arbitrage strategy using a genetic algorithm to optimize parameters.
Ensuring security and fault tolerance through microservice architecture and appropriate protection mechanisms.
Operating within the specified budget and time constraints.
Being ready for scaling and expanding functionality in the future." (client-provided description)