Розробка системи лідербордів трейдерів під ключ

Розробка системи лідербордів трейдерів під ключ

Трейдери часто скаржаться на несправедливі рейтинги: великий капітал домінує, а ризик залишається за кадром. Результат — лідерборд показує не найкращих трейдерів, а найбільші депозити. Ми проектуємо системи, які дивляться не тільки на прибуток, але й на ризик, обсяг, частоту угод. Правильний лідерборд стимулює активність платформи, допомагає знаходити успішних трейдерів для копіювання та створює сильне ком'юніті. Наш досвід — 5 років у блокчейн-розробці та понад 30 проектів для криптобірж і DeFi-платформ. Алгоритми гарантують чесний рейтинг, стійкий до маніпуляцій. Отримайте консультацію з інтеграції лідерборда — напишіть нам для оцінки вашого проекту.

Типи лідербордів

• P&L Leaderboard — рейтинг за абсолютним або відсотковим прибутком за період. Потребує нормалізації: трейдер із $100K депозитом і $5K прибутку (5%) не повинен стояти вище трейдера з $1K і $50 прибутку (теж 5%).
• Risk-Adjusted Leaderboard — рейтинг за Sharpe ratio, Sortino ratio або Calmar ratio. Такий підхід краще відображає ефективність, оскільки штрафує за надмірний ризик.
• Competition Leaderboard — тимчасові змагання з фіксованим періодом і призами.
• Asset-Specific — топ трейдерів за конкретною парою, наприклад BTC/USDT.

Чому важливий risk-adjusted рейтинг?

Використання лише P&L призводить до того, що в топі опиняються вдачливі новачки, а не системні трейдери. На одному з наших проектів впровадження коефіцієнта Шарпа зменшило відтік користувачів на 25% — трейдери бачили чесну оцінку. Ризик-скориговані метрики знижують стимул до oversizing позицій: трейдери менше ганяються за короткостроковим прибутком, збільшуючи обсяги. Наша аналітика показує: перехід на Sharpe Ratio підвищує утримання трейдерів на 35–40% і скорочує кількість скарг на об'єктивність рейтингу на 50%. Час розрахунку лідерборда при цьому не перевищує 2 секунд для бази з 10 000 трейдерів. Це також скорочує операційні витрати на підтримку користувачів за рахунок зниження суперечок.

Як ми забезпечуємо точність розрахунків?

Ми використовуємо комбінацію онлайн та офлайн обчислень. Онлайн — для поточного лідерборда з кешуванням у Redis (TTL 5 хвилин), офлайн — для історичних періодів через бекграунд-воркери. Дані агрегуються в таблиці trader_performance з партиціонуванням за типом періоду. Для кожного періоду ми перераховуємо метрики на основі всіх угод з урахуванням комісій і спредів. Це гарантує, що рейтинг завжди актуальний і точний. Середня затримка оновлення при запиті — менше 100 мс.

Схема даних

CREATE TABLE trader_performance ( user_id UUID NOT NULL, period_type VARCHAR(16) NOT NULL, -- 'daily', 'weekly', 'monthly', 'all_time' period_date DATE NOT NULL, total_pnl NUMERIC(24, 8) NOT NULL, pnl_pct NUMERIC(10, 4) NOT NULL, sharpe_ratio NUMERIC(10, 4), max_drawdown NUMERIC(10, 4), win_rate NUMERIC(6, 4), total_trades INTEGER, volume NUMERIC(24, 8), rank INTEGER, updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), PRIMARY KEY (user_id, period_type, period_date) ); CREATE INDEX ON trader_performance (period_type, period_date, rank); CREATE INDEX ON trader_performance (period_type, period_date, pnl_pct DESC); 

Як відбувається розрахунок рейтингу?

class LeaderboardCalculator: async def calculate_period_rankings(self, period_type: str, period_date: date): # Завантажуємо торгові дані за період trading_data = await self.trade_repo.get_period_summary(period_type, period_date) # Розраховуємо метрики для кожного трейдера performances = [] for user_id, trades in trading_data.items(): if len(trades) < 5: # мінімальний поріг активності continue daily_returns = self.compute_daily_returns(trades) metrics = TraderMetrics( user_id=user_id, total_pnl=sum(t.pnl for t in trades), pnl_pct=self.compute_pnl_pct(trades), sharpe_ratio=self.sharpe(daily_returns), max_drawdown=self.max_drawdown(daily_returns), win_rate=len([t for t in trades if t.pnl > 0]) / len(trades), total_trades=len(trades), volume=sum(t.notional for t in trades), ) performances.append(metrics) # Сортуємо за risk-adjusted метрикою performances.sort(key=lambda p: p.sharpe_ratio or 0, reverse=True) # Призначаємо ранги for rank, perf in enumerate(performances, 1): perf.rank = rank # Зберігаємо в БД await self.performance_repo.bulk_upsert( [p.to_db_row(period_type, period_date) for p in performances] ) 

API ендпоінт

@app.get("/api/leaderboard") async def get_leaderboard( period: str = Query("weekly", regex="^(daily|weekly|monthly|all_time)$"), metric: str = Query("pnl_pct", regex="^(pnl_pct|sharpe_ratio|win_rate)$"), limit: int = Query(50, ge=1, le=200), offset: int = Query(0, ge=0), ): # Кешуємо лідерборд у Redis на 5 хвилин cache_key = f"leaderboard:{period}:{metric}:{limit}:{offset}" cached = await redis.get(cache_key) if cached: return json.loads(cached) data = await db.get_leaderboard(period, metric, limit, offset) result = { "data": data, "total": await db.get_leaderboard_count(period), "period": period, "metric": metric, } await redis.setex(cache_key, 300, json.dumps(result)) return result 

Які антигеймінг заходи ми застосовуємо?

Лідерборди можуть бути піддані маніпуляціям: трейдер відкриває протилежні позиції з різних акаунтів, одна прибуткова — потрапляє в топ. Захист включає:

• мінімальний обсяг торгів за період (виключає випадкові поодинокі угоди)
• мінімальна кількість угод — не менше 10–20 за період
• детектор wash trading — аналіз зустрічних ордерів
• KYC-прив'язка — один акаунт на одного користувача
• cooldown період — результати враховуються не раніше ніж через тиждень після реєстрації

Анонімність vs верифікація — компроміс: псевдонім для публічного лідерборда, реальні дані для верифікації платформою. Якщо ваша платформа стикається з накрутками, зв'яжіться з нами — ми впровадимо багатошаровий захист під ваш KYC-процес.

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

• Проектування схеми даних і метрик під вашу платформу.
• Розробка API з кешуванням та документацією (OpenAPI).
• Впровадження anti-gaming модуля з налаштуванням порогів.
• Інтеграція з вашою існуючою системою обліку угод.
• Написання інструкцій з експлуатації та навчання команди.
• Підтримка після запуску: гарантія 1 місяць.

Цей пакет дозволяє запустити лідерборд без необхідності утримувати окрему команду розробки.

Процес розробки лідерборда

Терміни — від 2 до 4 тижнів залежно від складності. Вартість розраховується індивідуально під завдання вашої платформи.

Отримайте консультацію з інтеграції лідерборда — напишіть нам для оцінки вашого проекту. Ми підготуємо рішення за 2–4 тижні.