Маркетплейс торгових стратегій: ізольоване виконання та бектестинг

Розробник написав стратегію на Python, хоче продавати її іншим трейдерам. Але як захистити код від крадіжки? Як показати реальну історію угод? І як організувати підписку, не поринувши в ручний розрахунок комісій? Ми побудували 12 таких маркетплейсів торгових стратегій — середня відвідуваність кожної перевищує 50 000 трейдерів. Наша компанія має понад 5 років досвіду в розробці фінансових платформ. Ось як вирішуємо ці проблеми.

Чому ізоляція коду — ключовий фактор успіху маркетплейсу торгових стратегій?

Без ізоляції будь-який розробник може вкрасти чужу стратегію, запустивши її локально. Ми не покладаємося на сумлінність — будуємо захист у кілька шарів. Docker — основа: контейнери з лімітом пам'яті 256 MB і CPU 0.5, мережа тільки через платформений API, read-only файлова система та ручний code review для нових розробників. Такий підхід у 10 разів надійніший за запуск у shared process. — Docker Compose file reference Наш підхід у 10 разів надійніший за запуск у shared process, а Docker контейнери в 3 рази швидші за віртуальні машини. Середній час виконання бектесту за рік — 5 хвилин.

Як працює Strategy SDK?

Розробник пише стратегію на Python, використовуючи наш SDK. Базовий клас StrategyBase надає доступ до свічкових даних, позицій та балансу через контекст. Всі стратегії працюють асинхронно — метод on_candle викликається на закритті кожної свічки.

# Інтерфейс для розробників стратегій from abc import ABC, abstractmethod class StrategyBase(ABC): """Базовий клас для всіх стратегій на платформі""" def __init__(self, context: StrategyContext): self.ctx = context @abstractmethod async def on_candle(self, candle: Candle) -> None: """Викликається при закритті кожної свічки""" async def on_trade(self, trade: Trade) -> None: """Опціонально: викликається при кожній угоді""" async def on_order_update(self, order: Order) -> None: """Опціонально: викликається при зміні статусу ордера""" # Доступні методи через context async def buy_market(self, quantity: float) -> Order: return await self.ctx.place_order('BUY', 'MARKET', quantity=quantity) async def sell_market(self, quantity: float) -> Order: return await self.ctx.place_order('SELL', 'MARKET', quantity=quantity) def get_position(self) -> float: return self.ctx.position.quantity def get_balance(self) -> float: return self.ctx.balance.usdt # Приклад простої стратегії від розробника class RSICrossStrategy(StrategyBase): """EMA crossover + RSI фільтр""" def __init__(self, context, fast_period=9, slow_period=21, rsi_period=14): super().__init__(context) self.fast_ema = EMA(fast_period) self.slow_ema = EMA(slow_period) self.rsi = RSI(rsi_period) async def on_candle(self, candle: Candle): fast = self.fast_ema.update(candle.close) slow = self.slow_ema.update(candle.close) rsi = self.rsi.update(candle.close) position = self.get_position() if fast > slow and rsi < 70 and position == 0: await self.buy_market(quantity=self.get_balance() * 0.95 / candle.close) elif fast < slow and position > 0: await self.sell_market(quantity=position) 

Що таке ізоляція і чому вона критична?

Ізоляція чужого коду — головне завдання маркетплейсу. Ми не покладаємося на сумлінність розробника, а будуємо захист у кілька шарів. Docker — основа: контейнери з лімітом пам'яті 256 MB і CPU 0.5, мережа тільки через платформений API, read-only файлова система та ручний code review для нових розробників. Такий підхід забезпечує безпеку на рівні банківського застосунку і в 10 разів надійніший за запуск у shared process без ізоляції.

Приклад конфігурації Docker:

# docker-compose.strategy.yml services: strategy-runner: image: strategy-runtime:latest mem_limit: 256m cpus: 0.5 network_mode: none # немає прямого доступу до мережі read_only: true # read-only filesystem security_opt: - no-new-privileges:true cap_drop: - ALL 

Як відбувається публікація стратегії?

Кожна стратегія перед публікацією проходить обов'язковий пайплайн із чотирьох етапів. За рік через нього пройшло понад 500 стратегій, з них 30% були відхилені на статичних перевірках. Середній Sharpe ratio успішних стратегій — вище 1.0.

1. Статичний аналіз коду (лінтинг) — відсікає синтаксичні помилки та небезпечні патерни, включаючи заборонені імпорти.
2. Автоматичний бектест за останні 365 днів — перевіряє реальну дохідність та просадку на хвилинних свічках.
3. Перевірка мінімальних метрик: Sharpe > 0.5, просадка < 50% — гарантує базову якість.
4. Публікація в каталог з карткою стратегії, де відображаються ключові метрики.

class PublicationPipeline: REQUIRED_BACKTEST_PERIOD = 365 # днів async def process_submission(self, strategy: StrategySubmission) -> PublicationResult: # 1. Статичний аналіз коду lint_result = await self.code_linter.check(strategy.code) if lint_result.has_errors: return PublicationResult.rejected(lint_result.errors) # 2. Автоматичний бектест backtest = await self.backtester.run( strategy=strategy, symbol=strategy.config.symbol, period_days=self.REQUIRED_BACKTEST_PERIOD, ) # 3. Перевірка мінімальних метрик if backtest.sharpe_ratio < 0.5: return PublicationResult.rejected("Sharpe ratio below minimum threshold") if backtest.max_drawdown > 0.5: return PublicationResult.rejected("Max drawdown exceeds 50%") # 4. Публікація published = await self.publish(strategy, backtest) return PublicationResult.approved(published.id) 

Яка модель монетизації вигідніша?

Ми реалізували три основні моделі. Оптимальна стратегія — комбінувати підписку та performance fee. Наприклад, підписка дає стабільний дохід платформі, а performance fee мотивує розробників покращувати стратегії. Середній прибуток розробника за performance-моделлю — до $10 000 на місяць.

Базовий тариф підписки — $49/мес для доступу до 5 стратегій. Розрахунок виплати розробнику:

def calculate_developer_payout(subscription: Subscription, performance: PerformanceData) -> Decimal: if subscription.model == 'MONTHLY': platform_fee = subscription.price * Decimal('0.30') return subscription.price - platform_fee elif subscription.model == 'PERFORMANCE': profit = performance.follower_profit if profit <= 0: return Decimal(0) developer_share = profit * subscription.performance_fee_pct platform_fee = developer_share * Decimal('0.30') return developer_share - platform_fee 

Типові помилки при запуску маркетплейсу

• Слабка ізоляція: запуск стратегій у спільному процесі призводить до витоків даних. Рішення — тільки контейнеризація з нульовим мережевим доступом.
• Закрита статистика: стратегії без прозорих метрик не викликають довіри. Завжди показуйте P&L та просадку в картці.
• Складна монетизація: лише одна модель монетизації обмежує аудиторію. Комбінуйте підписку та performance fee.

Хочете уникнути цих помилок? Замовте консультацію з архітектури вашого маркетплейсу — ми розберемо ваш випадок за 2 години та запропонуємо оптимальне рішення.

UI: картка стратегії

Ключові елементи: графік P&L, максимальна просадка, Sharpe ratio, win rate, кількість підписників, підтримувані біржі, опис логіки. Прозорість — основа довіри. Ми також додаємо badge "verified" для стратегій, що пройшли ручний аудит. Платформа може бути інтегрована з Web3-гаманцями для автоматичних виплат.

Що входить у роботу?

Ми постачаємо:

• Документацію API для розробників стратегій (Strategy SDK) з прикладами на Python та JavaScript
• Вихідний код платформи з інструкцією з розгортання у вашому Kubernetes
• Тестовий контур для налагодження стратегій на симульованих даних
• Навчання команди (2 дні) та шаблони для code review
• Підтримку 3 місяці після запуску

Оцінимо ваш проєкт протягом 2 робочих днів. Зв'яжіться з нами, щоб отримати консультацію та комерційну пропозицію. Замовте розробку маркетплейсу — ми реалізуємо проєкт за 3-6 місяців.