Реалізація розміщення ринкового ордера в мобільному додатку біржі
Ми проектуємо та впроваджуємо форму розміщення ринкового ордера для мобільних біржових додатків. Ринковий ордер виконується миттєво за найкращою доступною ціною — користувач вводить лише кількість, ціну не вказує. Це спрощує інтерфейс порівняно з лімітним, але породжує проблему slippage: користувач натиснув «Купити» за ціни 42 000, а виконався за 42 150. Ми показуємо цю різницю заздалегідь та запобігаємо несподіванкам. Для мобільної торгівлі швидкість та зручність вводу — вирішальні фактори. Замовте реалізацію під вашу маржу — отримайте прозорий UI із захистом від прослизання.
Як працює форма ринкового ордера?
Форма відображає поточну найкращу ціну з ордербуку (ask для купівлі, bid для продажу), яка оновлюється через WebSocket. Поруч — оціночна вартість угоди: Amount × bestAsk. Підпис «Орієнтовно» та попередження про slippage при низькій ліквідності. Ми використовуємо Market order як базове поняття.
При обсязі 10 BTC по парі BTC/USDT з глибиною ордербуку всього 3 BTC на першому рівні, slippage може досягати 1.2% (близько 500 USDT). Це критично для великих угод — ми обчислюємо точну оцінку через середньозважену ціну (WAP). Оцінка ліквідності через WAP — ключовий елемент. Для порівняння, метод простого відсотка від best price помиляється в 3 рази частіше: WAP дає точність до 0.1% при повному снапшоті ордербуку.
Що таке slippage і як його оцінити?
Низька ліквідність — коли глибини ордербуку не вистачає, щоб поглинути весь обсяг за першим рівнем. Якщо користувач хоче купити 10 BTC, а на найкращому рівні доступно лише 3 BTC — реальна ціна буде вищою. Проста евристика: пройтися по рівнях ордербуку та обчислити weighted average price (WAP) для вказаного обсягу.
// Android — розрахунок середньозваженої ціни виконання зі снапшоту ордербуку fun estimateMarketPrice(asks: List<Pair<BigDecimal, BigDecimal>>, targetQty: BigDecimal): BigDecimal { var remaining = targetQty var totalCost = BigDecimal.ZERO for ((price, qty) in asks) { val fill = minOf(remaining, qty) totalCost += fill * price remaining -= fill if (remaining <= BigDecimal.ZERO) break } return if (remaining > BigDecimal.ZERO) BigDecimal.ZERO // недостатньо ліквідності else totalCost.divide(targetQty, 8, RoundingMode.HALF_UP) } Така оцінка дає реалістичні очікування та знижує кількість скарг на «неправильне» виконання. Для порівняння, лімітний ордер не схильний до slippage, але може взагалі не виконатися.
| Параметр | Ринковий ордер | Лімітний ордер |
|---|---|---|
| Швидкість виконання | Миттєво | Залежить від ціни |
| Контроль slippage | Через WAP | Не потрібен |
| Складність UI | Вища (оцінка ціни) | Нижча (вказати ціну) |
| Метод оцінки slippage | Точність | Складність |
|---|---|---|
| WAP за ордербуком | Висока при повному снапшоті | Середня |
| Простий відсоток від best price | Низька | Низька |
| Симуляція виконання | Дуже висока | Висока |
Приклад розрахунку WAP на реальних даних
Для пари ETH/USDT з ордербуком: ask1: 2000 USDT з обсягом 5 ETH, ask2: 2005 USDT з обсягом 10 ETH. При купівлі 12 ETH WAP = (5*2000 + 7*2005)/12 ≈ 2002.92 USDT. Різниця з best ask 2000 USDT становить 0.15% slippage.Які проблеми вирішуємо?
- Недостатня ліквідність: обчислюємо WAP і показуємо реальну ціну виконання. Якщо обсяг не може бути виконаний — попереджаємо червоним індикатором.
- Подвійне підтвердження: для великих сум (вище порогу) — alert з PIN або біометрією (Face ID / Touch ID / Android BiometricPrompt). Ринковий ордер не можна скасувати після відправлення, тому підтвердження обов'язкове.
- Два режими вводу: кількість базової валюти або сума у котируваній. Перемикач BTC/USDT над полем Amount — стандартний UX для бірж. Режим вводу за сумою особливо корисний при торгівлі з фіксованим бюджетом: користувач вводить, скільки USDT готовий витратити, а додаток автоматично обчислює кількість базової валюти з урахуванням поточної ціни та очікуваного slippage. Це вирішує проблему нестачі ліквідності для великих сум — користувач бачить, що його ордер може бути виконано частково.
Що входить у реалізацію?
- WebSocket-інтеграція для оновлення ціни в реальному часі
- Розрахунок WAP з ордербуку з урахуванням глибини
- Перемикач режиму вводу (кількість/сума)
- Діалог підтвердження з порогом для PIN/біометрії
- Обробка помилок: недостатня ліквідність, обрив з'єднання
- Документація та код-рев'ю
Процес роботи та терміни
- Аналіз: вивчаємо API біржі (Binance, Bybit та ін.) та вимоги до UI.
- Проектування: погоджуємо макети та логіку підтвердження.
- Реалізація: пишемо код з урахуванням threading та реактивності (Combine/Coroutines).
- Тестування: перевіряємо на тестовому ордербуку з різною глибиною.
- Деплой: публікуємо в TestFlight/Internal Track для UAT.
Орієнтовні терміни: від 2–3 днів на базову форму до 1–2 тижнів з біометрією та кастомними порогами. Вартість розраховується індивідуально — зв'яжіться з нами для оцінки.
Наш досвід: понад 5 років у розробці біржових додатків для iOS та Android. Реалізовані проєкти включають інтеграцію з Binance, Bybit та KuCoin. Гарантуємо дотримання App Store Review Guidelines (Section 4.2/5.1) та безпеку даних.
Отримайте консультацію щодо вашого проєкту — оцінимо складність інтеграції ринкових ордерів та запропонуємо оптимальне рішення.