×Закрыть

DOU Проектор: Kattana — професійний торговий термінал для криптовалют

У рубриці DOU Проектор всі охочі можуть презентувати свій продукт (як стартап, так і ламповий pet-проект). Якщо вам є про що розповісти — запрошуємо взяти участь. Якщо ні — можливо, серія надихне на створення власного made in Ukraine продукту. Питання і заявки на участь надсилайте на editors@dou.ua.

Всім привіт! Мене звати Богдан, я cпівзасновник торгового терміналу Kattana. Півроку тому ми з командою почали будувати продукт з нуля. З того часу ми багато чого досягли: сформували з нуля крос-функціональну команду, визначили рамки MVP і нещодавно запустили бета-версію нашого продукту для macOS та Windows.

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

Ідея

Ще в університетські роки я торгував акціями на Нью-Йоркській фондовій біржі (NYSE) і NASDAQ, працюючи в проп-трейдинговій компанії. Частина «проп» означає, що ти торгуєш капіталом компанії, а не своїм власним. Через запальний темперамент я завжди cхилявся до високоризикованих активів, наприклад, акцій фармацевтичних компаній, які можуть змусити посивіти будь-кого після входу в позицію через свою волатильність. Тож ця жага до нового привела мене згодом в криптотрейдинг. На цій арені все було як непахане поле. Примітивність інструментів для торгівлі просто вражала. У світі класичних фінансових ринків існує Bloomberg Terminal, який хоч і є монстром з точки зору функціоналу, впевнено займає лідерські позиції серед трейдингового ПЗ. Яким би складним та дорогим він не був, жодному новому продукту так і не вдалося порушити його лідерство. Трейдери — це особлива каста людей. У них з’являється відчуття приналежності до нобілітету, як тільки вони оволоділи складним функціоналом терміналу. Але Bloomberg — це для еліти, для всіх інших є простіші аналоги.

З криптовалютами все було по-іншому. Ринок — дуже фрагментований, як з точки зору ліквідності та доступних торгових пар, так і з боку наявних інструментів для торгівлі. Існує багато бірж та торгових майданчиків, на яких котируються різні монети. До того ж трейдинг, як будь-яка інша робота, вимагає професійних інструментів, які дозволяють робити її ефективно. На той час не існувало єдиного рішення, за допомогою якого трейдер міг би досліджувати ринок, відкривати заявки щодо купівлі чи продажу активів, а також аналізувати свою торгову успішність та ризики. Все це перешкоджає багатьом охочим займатись криптотрейдингом професійно, і врешті-решт, зводиться до втрат часу та коштів.

Таким чином, у нас виникла ідея створити власний Bloomberg для криптовалют, який би вирішив проблему фрагментованості ринків та інструментів і заклав би основу для нової фінансової системи.

Наша команда. На фото зліва направо: Ілля Щирий (Product Designer), Богдан Кіт (СEO), Дмитро Бєляєв (CTO)

Реалізація

Будь-який інноваційний продукт створюється в умовах глобальної невизначеності. Коли ми формуємо певні моделі чи гіпотези, ми керуємось досвідом, даними та інформацією, які маємо особисто, забуваючи, що у світі все багатогранно і є безліч речей, які існують поза нашим уявленням чи світоглядом.

Тому, перед тим як почати створювати продукт, важливо було провести додатковий аналіз ринку та аудиторії, щоб уникнути будь-яких упереджень. Ми прагнули зрозуміти не лише, наскільки гострою і важливою є ця проблема для криптотрейдерів, а й яке рішення найкраще підходить, щоб її вирішити.

Було сформовано низку гіпотез стосовно продукту, аудиторії та ринку. Після цього ми перейшли до їх безпосередньої перевірки через проведення користувацьких інтерв’ю з трейдерами. Чесно кажучи, це було доволі не тривіальне завдання через специфіку самого ринку та культ «повної анонімності» серед представників криптоспільноти. Але нам все-таки вдалось перевірити основні гіпотези, і що не менш важливо, визначити тип продукту, який би вирішував проблему найкращим доступним способом.

Після цього ми з командою окреслили технологічний стек, який ми збирались використовувати для створення продукту. Він був сформований на основі гіпотез, які нам вдалось підтвердити під час інтерв’ю та аналізу.

Враховуючи низку факторів, де безпека та індивідуальні налаштування інтерфейсу під потреби трейдера займають чільне місце, ми вирішили будувати торговий термінал у вигляді десктопного додатку. Стартаперський дух нашої компанії також вимагав якомога більш ефективного використання як фінансових, так і технічних ресурсів команди. Через це в плані технологій вибір пав на Electron JS, на базі якої створені такі продукти, як Slack, MS Visual Studio Code, Discord та ін. Знайти досвідченого технічного розробника зі знанням непопулярного фреймворку в наших широтах було ще тим завданням. В один момент уже здалося, що краще відмовитись від такої авантюри взагалі і перейти на нативні технології.

Все ж таки нам дуже пощастило, і до нашої команди приєднався Дмитро (СTO), а трохи згодом Ілля (Product Designer). Як результат, у липні цього року ми в трьох почали активну роботу над продуктом. На перших стадіях розробки ми кілька разів змінювали та уточнювали обсяг функціоналу для нашого MVP згідно з фідбеком, який отримували, та нової інформації, що відкривалася під час роботи. Змінювались біржі, які ми збирались підключати до терміналу, та їхня кількість. Це було пов’язано як з бізнесовим, так і технічним підґрунтям.

Перший high-level wireframe програми з базовим функціоналом




UX-архітектуру продукту можна подивитись за посиланням.

Стосовно функціоналу продукту, ми прагнули створити рішення, яке б на мінімально життєздатному рівні покрило б увесь робочий процес трейдера. Зазвичай, він складається з 3-х основних етапів: аналіз ринку та торгових пар (графіки, індикатори, графічні інструменти), безпосередня торгівля (відкриття ордерів, виставлення стоп-лосів, стратегії входження в позицію) та ризик-менеджмент (моніторинг ризиків в розрізі позицій та бірж, розрахунок торгової успішності через показник α — alpha).

Згідно з цим, основний дизайн-челендж полягав у тому, щоб зробити досвід трейдингу максимально простим для користувачів і в той же час надати їм гнучкість у налаштуванні інтерфейсу під особисті потреби. Таким чином, Kattana — це продукт з модульним дизайном, який дозволяє користувачу одночасно працювати в декількох вікнах (workspaces) із індивідуальним набором віджетів. Таке рішення дає змогу користуватись продуктом на кількох моніторах, не завдаючи шкоди загальній простоті використання.






Щоб краще розкрити тему технічних питань, я попросив Дмитра (CTO) трохи допомогти і поділитись своїм досвідом та підходами до створення нашого продукту.

Щоб зрозуміти, як і чому у нас все влаштовано певним чином, потрібно хоча б приблизно уявляти, як і що віддає криптобіржа. Почнемо з найскладнішого — ордер-буку (список відкритих заявок на купівлю та продаж). Для кожної відкритої торгової пари є два масиви заявок від 20 до 1000 елементів, які можуть прилітати кілька разів за секунду. Решта даних — це графіки, ордери, баланси, символи пар і сповіщення. Єдиного стандарту відповіді сервера для криптобірж не існує, у кожної з них свій API, зовні вони схожі між собою.

Загалом існувало три технічні складності:

  1. Стандартизувати відповіді з бірж (типи ордерів, формати символів пар, причини помилок).
  2. Змусити програму не гальмувати через часте перемальовування елементів.
  3. Зрозуміти, що робити в нестандартній ситуації (нічого — ?).

Щодо пункту 1, потрібно було визначити формат роботи з даними в програмі. Звичайно, у світі класичних фінансових ринків існують оптимізовані структури у вигляді cap’n’proto, рівні руки і C++. Але у світі криптовалютних ринків таких проривних речей майже немає, а основні дані біржі надсилають у вигляді JSON, всередині якого знаходиться масив. Оскільки «порівнювати» масив для пошуку змін не є оптимальним рішенням, то ці дані ми конвертуємо у список Hash, Set і так далі. Як можна виміряти ефективність цього підходу? Для цього в Node.js існують flame charts, через які можна спостерігати за виділеною пам’яттю, писати бенчмарки з різними структурами даних для того, щоб знайти найбільш ефективні. Наскільки це важливо? З точки зору бізнесу — дуже важливо. Потрібно, щоб програма запускалася на старому MacBook Pro зразка 2010 року і не споживала більше 5-10% CPU. Якщо в якийсь момент згаданих рішень буде недостатньо або вони почнуть з’їдати багато пам’яті, то ми перепишемо все на C++ у вигляді Node.js extension.

Але все ж таки найцікавішим і найменш очевидним технічним викликом був пункт 2. Якщо у користувача два вікна, в яких відкрито по дві пари на різних біржах, то перемальовувати всі дані при кожному оновленні не є хорошим рішенням. Найочевиднішим і простим було рішення викинути масиви, а замість них використовувати key-value hash в тих даних, які потрібно часто оновлювати. Розуміючи цей факт, ми доволі просто реалізували таку архітектуру:

  • Біржа -> Стандартизація даних -> Store -> Диспетчер -> Відображення даних.
  • Node.js <-> Electron <-> React / Redux.

В store ми зберігаємо всі ці об’єкти, диспетчер відповідає за потоки даних: нам не потрібно відправляти всі оновлення в усі вікна, а тільки оновлення пари і пов’язаного вікна. Також дані варто групувати перед відправкою, наприклад, на парі ETH / BTC в секунду може бути проведено 10 торгів (10 trading history events). Наш користувач побачить всі 10, але раз в секунду.

Все, що може оптимізувати рендеринг по типу memoize чи reselect, ми використовуємо. Також у нас є маленький бекенд, де ми застосовуємо рішення для пришвидшення процесу віддачі та запису даних, які описані у цьому відео. В цей час також працюємо над розширенням серверної частини продукту, за допомогою якої трейдери зможуть автоматизовувати свої торгові стратегії, а також відправляти ордери на біржу, які дозволяють автоматично зафіксувати збитки або прибуток, коли потрібно (stop-loss, take-profit). Такого функціоналу більшість бірж не пропонує.

У майбутньому ми плануємо використовувати дані для machine learning, але про це поки що рано говорити.

Результати і плани

На початку грудня 2018 ми випустили бета-версію Kattana для macOS. Трохи згодом також з’явилась версія для Windows. За цей час ми також отримали перші інвестиції та уклали стратегічне партнерство з Fund3, однією з компаній-лідерів у сфері інфраструктурних рішень для електронної торгівлі на криптовалютних ринках.

Наша середньострокова ціль — це знайти product-market fit. Тому на цьому етапі ми активно сфокусовані на так званих non-scalable каналах просування: соціальні мережі, Telegram, лідери думок, майданчики нових продуктів та інші. Працюючи з фідбеком, який отримуємо від наших користувачів та аналізуючи основні продуктові метрики, ми визначаємо подальший вектор розвитку продукту. Через високий рівень шахрайства з боку ICO, великі рекламні провайдери, такі як Google чи Facebook, наклали заборону на будь-яку рекламу, що хоч якось стосується криптовалют та блокчейну. Разом з дещо таємним характером нашої аудиторії — це становить серйозний челендж. Тим не менш, ми намагаємось активно тестувати різні доступні платні канали залучення аудиторії, щоб перевірити життєздатність нашої прогнозованої unit-економіки та бізнес-моделі на ринку.

Наша глобальна ціль — це поєднати продуктову та сервісну модель бізнесу, яка поширена на традиційних фінансових ринках, коли торгова платформа, через яку торгує трейдер також поєднана з брокерськими послугами. Це дозволить суттєво полегшити доступ до ринку криптоактивів з боку широкої аудиторії традиційних трейдерів, яких лякають ризики, пов’язані з втратою коштів через злам бірж чи втратою ключів доступу до гаманця. З іншого боку, такої моделі потребують інституціональні гравці, які поки лише роблять нервові ривки в бік криптоактивів, постійно оглядаючись на SEC та інші регуляторні органи.

Отже, ми прагнемо зробити ринок блокчейн-активів більш зрілим, тим самим заклавши якісний фундамент для нової, відкритої та прозорої фінансової системи.

Якщо у вас виникнуть питання щодо нашого продукту, будемо раді відповісти на них в коментарях чи поштою. Писати можна сюди: bohdankit.s@gmail.com.

LinkedIn

16 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Очень интересно, отслеживаю ваш продукт. Посмотрим, конкуренция между терминалами самих бирж и сторонними решениями, включая открытые. Ведь отчасти успех блумберга был в том, что вы как раз не указали — без терминала торговать на бирже вообще нельзя. А с криптой все немного по другому.

Рад, что такой продукт делают именно здесь.

P.S. В итоге непонятно :) Вы отдельная компания или подразделение TaaS или они вас купили :)

Дякую! Конкуренція дійсно суттєва.

На мою думкую, успіх Bloomberg був зумовлений в першу чергу тим, що вони зробили доступними величезну к-сть даних. Торгувати тоді на біржі можна було, щоправда й важко, але основна проблема полягала у тому, що трейдери в ручну малювали цінові графіки, спираючись на котирування, які оновлювались кілька разів в день. Bloomberg прибрав цю неефективність через використання комп’ютерів, які тоді тільки почали з’являтись.

P.S. Окрема компанія, а TaaS — наш інвестор :)

Спасибо! А теперь конкретики :)

Вы упоминаете о сложностях работы с API разных бирж. Сам не по наслышке знаю, так как работаю в этой области. Не пробовали использовать провайдеров данных, чтобы убрать у себя все сложности? Навскид, из отличного уровня — ссtx (опенсорс библиотека) и CoinAPI.io как провайдера.

Графики у вас на чем, если не секрет? И в догонку сразу — будет ли TradingView :)

И третье — по аналогии с блумберг-терминалом. Будет ли многооконность (для возможности комфортно работать на нескольких мониторах), встроенная командная строка (возможно, даже используя привычный синтаксис блумберга).

Как вариант, можете посмотреть на xtrd.io — у нас есть real-time market data и orders routing через FIX 4.4.

Интересно, в копилку провайдеров. Но список площадок удручает, он очень мал — но это для моих целей, а так вполне интересно, спасибо!

Ну, у нас вопрос был не в количестве, а в качестве. К очень многим exchanges у нас подключение через выделенные линии(например, Gemini идет через прямой cross-connect NY4 <-> NY5) или же через частные VLAN-ы, где мы подключаемся к приватным облакам бирж.

Ставка изначально делалась на то, что должно быть быстро и безопасно.

О, это уже интереснее! Почти к такому же пришли, но все же паблик решению. Отлично! А есть может технические данные именно по скорости и насколько различается?

У нас своя стойка в NY4.
Например, из нее до HK1 стандартный network latency где-то 174.2 — 174.6 ms, оттуда же, но уже в Европу(FK2) — 72 ms.
Software-added latency — порядка 50-100 микросекунд

Отвечу вместо Богдана

Навскид, из отличного уровня — ссtx (опенсорс библиотека) и CoinAPI.io как провайдера.

CCXT — классная библиотека и она у нас используется для проверки ключей, но она плохо подходит для торговых данных в реальном времени — поддержки вебсокета нет, а если дергать несколько раз в минуту данные по rest api — мы упремся в rate limit или нас забанит Cloudflare. С следующего релиза мы переносим трейдинг на бекенд — соглашение с одним из провайдеров, но ордербук\история\график пока остается на клиенте.

Графики у вас на чем, если не секрет? И в догонку сразу — будет ли TradingView :)

С января 2019 года — TradingView, но до этого мы использовали слегка пропатченый react-stockcharts. Было испробовано очень много библиотек, но некоторые тормозили, в некоторых пришлось бы изобретать велосипед для индикаторов (их не меньше 30).

И третье — по аналогии с блумберг-терминалом. Будет ли многооконность (для возможности комфортно работать на нескольких мониторах), встроенная командная строка (возможно, даже используя привычный синтаксис блумберга).

Многооконность у нас с первой версии и это одна из УТП программы, консольная строка пока не планируется, но было бы удобно ее иметь.

Спасибо. Да, моменты с лимитами есть, решения очень нетривиальны, в свое время несколько месяцев на это положили.

Погодите, то есть клиент напрямую тянет историю/бук/график каждый?

Погодите, то есть клиент напрямую тянет историю/бук/график каждый?

Да, можно прагматично разобрать варианты:

  • Клиент тянет бук\историю\график с биржи — лимиты по ip на клиенте — чуть сложнее разрабатывать — под каждую биржу адаптер к формату программы
  • Клиент тянет бук\историю\график с нашего бекенда — лимиты по ip на сервере — нагрузка на сервер — под каждую биржу адаптер к формату программы
Во-втором случае получим тоже, возможно чуть-чуть быстрее в реализации, но нагрузим публичными данными наши сервера без очевидной выгоды для клиента, для нас — по-упражняться в написании прокси. Но здесь могут быть исключения: например Bitstamp не имеет в своем API OHLCV (публичного) — нужно или искать провайдера или отдавать данные самому на основании истории.

Хмм, увы, не могу ощутить преимущества такого решения. Тем более, что серверно реализовать это не так сложно, масштабировать также проще. Да, данных как бы много, но вряд ли это существенный фактор в этом случае. А вот возможностей оптимизации намного больше. Но ок )

Конечно было бы сильно удобнее иметь всё на сервере и тонкого клиента (который только рендерит), на данном этапе выбор в сторону «клиент тянет orderbook/history/ohlcv с биржи» для нас оптимален. Если окажется что это ошибочное решение — переделаем.

Ohlc легко стоить из сырых трейдов. Год назад я строил кластер по сбору трейдов с 11 бирж по вебсокету и рест.
Параллельно строил свечи для ТВ.
Апи бирж крайне плохие и очень отличаются. Балансировки проксей, распределение данных в кластере, распределенные блокировщики для задач.
В целом стартап не потянул из-за постоянной адаптации под изменения и падения бирж.

Подтверждаю )) Истина. Правда у нас было 112 бирж ) пока делали, несколько закрылось буквально в процессе отладки )

Подписаться на комментарии