Цю сторінку перекладено автоматично. Оригінал англійською мовою є канонічним. Читати англійською →
Перейти к основному содержимому

Журнал змін

Зміни API та виведення з використання для тестнету й альфа-версії основної мережі Hypercall.

Політика змін експериментального API​

Усі ендпоінти /experimental і явно позначені як експериментальні повідомлення WebSocket є нестабільними. Зміни, що порушують сумісність, можуть набувати чинності з попередженням за один день (24 години). Це стосується видалення або перейменування полів чи ендпоінтів, зміни типів полів, а також зміни поведінки запитів або відповідей. Повідомлення в цьому журналі змін вказуватимуть зачеплені інтерфейси, необхідні зміни на стороні клієнта, а також дату й час набуття чинності. Клієнти повинні стежити за цими повідомленнями й оновлюватися до зазначеного часу. Ця політика не змінює зобов'язань щодо сумісності для неекспериментальних ендпоінтів і підписок.

Поточний інтерфейс описано в експериментальному API комбінацій. Ця політика не оголошує доступність або негайну зміну схеми.

Див. також: Довідник REST API · WebSocket API · Автентифікація

Без нового релізу - 6 жовтня 2026 року​

Додано​

  • Публічна політика PM-маржі: GET /v1/pm-margin/policy повертає активну політику портфельної маржі (тип, версію, режим гамма-накладки та повний перелік базових активів) без автентифікації. Відповідь містить сильний ETag і Cache-Control: public, max-age=60, stale-while-revalidate=300; надішліть If-None-Match, щоб отримати 304 Not Modified без тіла, поки політика не змінилася. Див. Параметри ризику PM.
  • Стиснення WebSocket у продакшені: узгодження permessage-deflate, описане в записі за 30 вересня, тепер увімкнено в продакшен-конфігурації. Клієнтів, які не пропонують це розширення, зміна не зачіпає.

Без нового релізу - 5 жовтня 2026 року​

Додано​

  • Жодних змін лімітів запитів або рівнів у цей період не випущено; ліміти запитів не змінилися, а нові подання TEE-перп ордерів зараховуються менеджеру Account так само, як інші подання перп ордерів. Жоден ендпоінт не виведено з використання.
  • Маршрути тригерних і пакетних TEE-перп ордерів: POST /v1/tee-perp/orders/submit-trigger подає один нативний стоп-лосс або тейк-профіт, а POST /v1/tee-perp/orders/submit-batch подає згрупований ордер (na, normalTpsl або positionTpsl). Обидва використовують той самий EIP-712 підпис ключем застосунку, що й POST /v1/tee-perp/orders/submit, проходять ту саму перевірку портфельної маржі та завжди містять builder code Hypercall.
  • Попередній перегляд TEE-перп: POST /v1/tee-perp/preview виконує перевірку маржі для ордера, пакета або зміни кредитного плеча без запису в журнал, резервування nonce чи виклику енклаву та повертає рішення, стабільний reasonCode, показники маржі, ціни ліквідації на майданчику та знайдений бісекцією maxSize. Відповіді на подання ордерів, пакетів і змін кредитного плеча тепер містять той самий reasonCode. Див. коди причин.
  • Ринки TEE-перп: GET /v1/tee-perp/markets перелічує ринки перпів, які приймає Hypercall, та їхні індекси активів. Кожен ринок, що має ціновий фід Hypercall, сітку сценаріїв PM і USDC-маржинальний ринок Hyperliquid, приймається на всіх TEE-маршрутах. Будь-який інший ринок відхиляється з market_not_supported.
  • Нагадування щодо маршрутів: TEE-маршрути є опціональними на рівні API: API-клієнти обирають їх, викликаючи ендпоінти /v1/tee-perp/, а ордери, які їх не використовують, проходять шляхом директив через контракт акаунта. У застосунку Hypercall TEE є маршрутом для перпів за замовчуванням, а маршрут через смарт-контракт доступний як розширене налаштування в Settings.

Змінено​

  • Ідентифікатори запитів, обрані клієнтом, мають бути свіжими UUIDv7. POST /v1/tee-perp/cancels/submit-prepared (і nonceReservationRequestId, і requestId) та POST /liquidation/standard-margin (request_id) повертають 400, якщо ідентифікатор запиту не є UUIDv7 (наприклад, v4 з crypto.randomUUID()), якщо вбудована в нього позначка часу старша за 1 годину або якщо вона більш ніж на 30 секунд у майбутньому. Генеруйте новий UUIDv7 для кожного нового запиту й використовуйте його повторно лише для повторення того самого запиту протягом години.
  • Повторні спроби TEE-ордерів, скасувань і змін кредитного плеча через межу цього релізу відхиляються. Серверні ідентифікатори для POST /v1/tee-perp/orders/submit, POST /v1/tee-perp/cancels/submit, POST /v1/tee-perp/cancels/submit-by-oid, POST /v1/tee-perp/schedule-cancel/submit і POST /v1/tee-perp/leverage/submit змінилися в цьому релізі. Повторна спроба запиту, вперше надісланого до оновлення, повертає 400 через повторно використаний nonce замість початкового підтвердження; початковий запит залишається чинним. Підпишіть і надішліть новий запит зі свіжим nonce.
  • Розміри ніг RFQ перевіряються на точність під час подання: розмір ноги RFQ з понад 6 знаками після коми (дрібніше за 0.000001) відхиляється під час подання RFQ, а помилка вказує найбільший виконуваний розмір, до якого слід округлити вниз. Раніше RFQ приймався, а потім кожна котирувальна заявка маркетмейкера завершувалася помилкою, тож тейкери бачили загальний тайм-аут через відсутність котирувань. Хеш підписаних ніг не змінився: округлюйте розмір самостійно перед підписанням.

Без нового релізу - 4 жовтня 2026 року​

Додано​

  • Кредитне плече TEE-перп: POST /v1/tee-perp/leverage/submit змінює кредитне плече для окремого ринку та режим cross або isolated через TEE-маршрут, використовуючи те саме правило маржі, що й під час допуску ордерів. Відхилена зміна повертає стабільний reasonCode, наприклад insufficient_margin або leverage_requires_flat_account.

Без нового релізу - 2 жовтня 2026 року​

Додано​

  • Маршрути скасування та запланованого скасування TEE-перп: POST /v1/tee-perp/cancels/submit (за клієнтським ідентифікатором ордера), POST /v1/tee-perp/cancels/submit-by-oid і POST /v1/tee-perp/schedule-cancel/submit (dead-man's switch) доступні на TEE-маршруті.

Без нового релізу - 30 вересня 2026 року​

Додано​

  • Стиснення WebSocket: /ws підтримує permessage-deflate за RFC 7692 з server_no_context_takeover, що вмикається окремо для кожного середовища. Клієнти, які пропонують це розширення, отримують великі повідомлення у стиснутому вигляді; на клієнтів, які його не пропонують, це не впливає. Див. Стиснення.
  • Пакетні індикативні ринкові дані: новий канал indicative_market_data_v2 доставляє рядки indicative_market_data у вигляді фреймів IndicativeMarketDataBatch, кожен з яких містить рядки, опубліковані протягом одного пакетного вікна (25 мс за замовчуванням), у порядку надходження та без об'єднання. Його підтвердження має вигляд {"type":"Subscribed","channel":"indicative_market_data_v2","batch":true}; якщо маркера немає, поверніться до indicative_market_data, який не змінився. Рядки надходять із затримкою до одного вікна. З permessage-deflate пакетні фрейми приблизно в п'ять разів менші, ніж рядки, стиснуті поодинці. Див. Пакетна доставка. Короткочасне поле підписки "batch": true видалено; сервери його ігнорують.
  • Невідомі канали відхиляються: Subscribe на канал, якого не існує, тепер повертає {"type":"Error","code":"unknown_channel","channel":"<name>","message":"Unknown channel '<name>'"} замість підтвердження Subscribed з подальшою тишею. Повідомлення Error отримують необов'язкові поля code і channel. Виведені з експлуатації канали зберігають свою наявну помилку.
  • Rust-клієнт: WsClient::subscribe_indicative_market_data(symbols) підписується на indicative_market_data_v2 і повертається до indicative_market_data, коли сервер підтверджує підписку без пакетного маркера або відхиляє канал. Вимкнути це можна через WsClient::with_batched_indicative(false), а зупинити через WsClient::unsubscribe_indicative_market_data(), який працює з тим каналом, на якому зупинився вибір. Несумісна зміна (до версії 1.0): аргумент batch методу видалено, WsMessage::Subscribe втрачає поле batch, а WsMessage::Subscribed і WsMessage::Error отримують необов'язкові поля, тому літерали структур і вичерпні шаблони потрібно оновити.

Змінено​

  • Несумісна зміна: портфельна маржа вимагає уніфікованого акаунта HyperCore. POST /margin-mode з portfolio тепер завершується помилкою 400 з кодом pm_account_not_unified, якщо HyperCore не повідомляє, що Account перебуває в режимі unifiedAccount. Спершу ввімкніть його директивою hl_set_abstraction, дочекайтеся підтвердження, а потім повторіть спробу. Неуніфікований PM Account ніколи не міг бути оцінений, тому це замінює пізнішу, непрозору помилку.
  • GET /portfolio пояснює відсутність потоку капіталу PM. Коли Account з портфельною маржею не має актуального капіталу HyperCore, відповідь буде 409 pm_account_not_unified, якщо HyperCore ніколи не публікував цей Account і повідомляє інший режим, або 503 pm_account_equity_pending, який можна повторити, доки актуальний уніфікований знімок не надійде до рушія (із зазначенням режиму HyperCore, якщо він не уніфікований). Інші помилки оцінки PM зберігають загальну відповідь 503.
  • Попередня перевірка RFQ для мейкерів відокремлює помилки ціноутворення. Котирування, яке майданчик не може оцінити (наприклад, через відсутню поверхню імпліцитної волатильності), тепер відхиляється з причиною pricing_unavailable замість margin_rejected. margin_rejected тепер означає лише рішення щодо маржі на акаунті мейкера.

Без нового релізу - 2 вересня 2026 року​

Додано​

  • Публічна симуляція ризику: POST /risk/simulate/portfolio дає попередній перегляд накладань або замін позицій за марк-ціною. POST /risk/simulate/orders дає попередній перегляд фінансового допуску для ордерів, що залишаються в книзі, або атомарних ордерів. Обидва ендпоінти використовують один незмінний знімок рушія, підтримують Standard і Portfolio Margin, не вимагають автентифікації та ніколи не змінюють стан акаунта чи журналу. Попередній перегляд ордерів не включає гарантій щодо маршрутизації, зіставлення, нонсів і зупинки торгівлі, тому пізніший реальний ордер може відрізнятися після зміни стану рушія.
  • Упорядковані базові набори відкритих ордерів: POST /risk/simulate/orders приймає необов'язковий параметр hypothetical_open_orders, допускає їх послідовно як GTC-ордери в книзі та повідомляє їхній сукупний ефект разом із запропонованим ордером або атомарним пакетом.

Міграція опціонів на Standard Margin​

Обсяг: Standard Margin розпізнає сумісні опціонні спреди, метелики та інші портфелі в межах кожного базового активу та експірації. Календарні спреди зберігають окремі групи експірацій. Фінансування в USDC і наявні маршрути ордерів залишаються без змін.

Адитивний контракт для коштів: зведення портфеля в REST і WebSocket додають standard_margin, що містить cash_margin, initial_margin_headroom, maintenance_margin_headroom і діагностику сумісних експірацій. Наявні поля initial_margin і maintenance_margin зберігають своє історичне значення, похідне від NAV. Використовуйте явні поля запасу коштів для допуску та ліквідації в SM. Відсутність розбивки означає, що можливість недоступна, а не нульовий ризик.

Несумісна зміна семантики позицій: margin_posted і maintenance_margin для окремої позиції є автономною діагностикою до застосування групового захисту. Не підсумовуйте їх для визначення вимог до акаунта та не оцінюйте за ними вартість закриття однієї ноги. Використовуйте вимоги до акаунта та групову розбивку.

Несумісна зміна: поле, що допускає null: опціонні позиції SM тепер повертають liquidation_price: null у повідомленнях портфеля REST і WebSocket. Оновіть декодери, які вимагають десятковий рядок, і відображайте недоступну ціну або запас акаунта. Повернення колишньої ціни спотворило б ризик групової ліквідації. Ця зміна вимагає скоординованого переходу бекенду та клієнтів; це не твердження про сумісність зі строгими старими декодерами.

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

Rust-бібліотеки: ціни ліквідації позицій портфеля стають необов'язковими, а зведення маржі додають публічне поле розбивки, що вимагає відповідних оновлень літералів структур. Наявні сигнатури допоміжних функцій маржі, похідних від NAV, залишаються без змін; споживачі ризик-даних, що враховують кошти, повинні використовувати явний контракт SM. Бібліотека ліквідатора також вимагає авторитетного запасу maintenance_margin у серіалізованих знімках маржі та сформованих кандидатах. Перебудуйте ці знімки з актуальних зчитувань; не виводьте відсутній запас коштів зі збереженого NAV.

Перевірка: власні споживачі розрізняють PM і SM, недоступний контекст коштів зупиняє автоматизовані рішення щодо ризику, а формати запитів і підписів ордерів залишаються без змін. Цей невипущений запис не означає розгортання чи підтримку поетапного впровадження зі змішаними версіями.

Без нового релізу - 15 серпня 2026 року​

Додано​

  • Обсяг активів колекції: GET /accounts/{wallet}/collection тепер повертає точний канонічний номінальний обсяг базового активу за весь час для кожного активу у вигляді десяткового рядка в адитивному полі assets[].volume.

Без нового релізу - 14 серпня 2026 року​

Повідомлення про застарілість​

  • Поле username у профілі застаріло: Поле username у відповіді Rust GET /profile застаріло і може бути видалене 7 вересня 2026 року або пізніше. Натомість зчитуйте вибрані імена користувачів з GET /username?wallet=... в Analytics API. Якщо цей ендпоінт повертає 404, сформуйте adjective_noun.xx локально з канонічного гаманця. Успішні відповіді /profile тепер містять заголовки Deprecation, Sunset, X-Deprecation-Removal-Unix і Warning протягом періоду міграції.
  • Решта застарілих полів username у відповідях: Поле username у відповідях застарілих Rust GET /username і POST /username, а також у відповідях таблиць лідерів змагань, і надалі може бути видалене відповідно до графіка від 20 серпня 2026 року. Контракт Analytics API GET /username і підписаного POST /username є заміною для вибраних імен користувачів. Клієнти таблиць лідерів повинні формувати відображувані імена adjective_noun.xx локально з канонічного wallet або wallet_address, якщо вибране ім'я відсутнє. Наведений нижче детермінований алгоритм імені акаунта є нормативним.

Детермінований алгоритм імені акаунта​

Вхідні дані: Обріжте пробіли та переведіть у нижній регістр канонічний EVM-гаманець. Значення має відповідати ^0x[0-9a-f]{40}$. Некоректні вхідні дані дають Unknown.

Упорядковані списки слів: Зберігайте саме цей порядок.

adjectives = [swift, silent, long, short, deep, wide, sharp, calm, cold, quiet, bold, thin, idle, vivid, grim, amber, slate, rapid, steady, hollow, rogue, plain, lucky, brisk, stark]
nouns = [theta, vega, gamma, delta, rho, basis, carry, skew, strike, tenor, vol, wick, candle, ladder, condor, collar, straddle, strangle, butterfly, spread, hedge, premium, tick, lot]

Хеш-функція: Використовуйте 32-бітну FNV-1a над ASCII-байтами. Кожне множення виконується з переповненням до беззнакового 32-бітного цілого, що еквівалентно JavaScript Math.imul(hash, 0x01000193) >>> 0.

fnv1a32(value, seed = 0x811c9dc5):
  hash = uint32(seed)
  for byte in ascii(value):
    hash = uint32(hash XOR byte)
    hash = uint32(hash * 0x01000193)
  return hash

wallet = trim(input).lowercase()
adjective_hash = fnv1a32(wallet)
noun_hash = fnv1a32(wallet + "#2", adjective_hash)
adjective = adjectives[adjective_hash modulo 25]
noun = nouns[noun_hash modulo 24]
suffix = last 2 characters of wallet
display_name = adjective + "_" + noun + "." + suffix

Тестові вектори:

ГаманецьВідображуване ім'я
0x000000000000000000000000000000000000002avivid_candle.2a
0xd9fe4c6bf4271fd685409cd01b7eece052c886c8silent_theta.c8

Додано​

  • Публічний API бейджів: Analytics Worker тепер надає реєстр бейджів через GET /badges, пагінований список власників через GET /badges/{slug}, стан окремого акаунта через GET /badges/accounts/{wallet} і зручні для кешування пакети до 100 гаманців через GET /badges/accounts?wallet=.... Подіум і обсяг за весь час використовують матеріалізовані покоління таблиць лідерів. Право на статус засновника зафіксовано для акаунтів, які вперше з'явилися до 1 серпня 2026 року UTC. Кількість повідомлень Trollbox, пов'язаних з гаманцем, оновлюється щогодини, а здобуті рівні зберігаються після видалення повідомлення.
  • Досягнення серій і колекцій у профілі: GET /accounts/{wallet}/streak?days=14|61|365 повертає календар серії. GET /accounts/{wallet}/collection повертає незалежну сітку активів колекції без параметра часового вікна. Серія рахує послідовні дні UTC із кваліфікованим виконанням. Колекція рахує різні базові активи, якими ви торгували, і порівнює їх з поточним каталогом лістингу. Розв'язані самозіставлення не враховуються. Статус Complete для колекції зберігається, навіть якщо каталог згодом розшириться.
  • Імена Hyperliquid у рядках таблиць лідерів: Рядки data[], які повертають ендпоінти таблиць лідерів змагань і за весь час, тепер містять поле hyperliquid_name, що може мати значення null. Analytics Worker визначає імена лише для гаманців на поверненій сторінці, групує виклики HyperEVM і кешує позитивні та негативні результати на десять хвилин. Це поле відокремлене від застарілого згенерованого username. Клієнти можуть надавати йому перевагу, якщо воно не null, а в іншому разі використовувати детерміноване ім'я акаунта.

Без нового релізу - 3 серпня 2026 року​

Несумісні зміни​

  • Зображення профілю видалено з Rust API: POST /profile/image більше не доступний, а GET /profile більше не повертає profile_image_url.

Без нового релізу - 29 липня 2026 року​

Несумісні зміни​

  • REST-ендпоінт свічок видалено: GET /candles більше не доступний і тепер повертає 404. Клієнти повинні припинити викликати цей ендпоінт.
  • Доставку свічок через WebSocket припинено: Hypercall більше не публікує повідомлення CandleUpdate у канали candles:<UNDERLYING>:<RESOLUTION>. Клієнти повинні припинити підписуватися на ці канали. Замінний потік свічок у цьому релізі недоступний.

Без нового релізу - 27 липня 2026 року​

Додано​

  • Час публікації індикативних даних: кожне корисне навантаження WebSocket indicative_market_data тепер містить published_at, мітку часу за годинником API в мілісекундах, коли це навантаження було надіслано. Використовуйте published_at - rfq_provider_quotes[].updated_at, щоб виміряти вік котирування провайдера на момент публікації. Не порівнюйте жодне з цих значень із системним годинником клієнта. Наявне поле timestamp і надалі є часом оновлення вихідного агрегату.
  • Транспортний годинник WebSocket: клієнти, яким потрібна консервативна тривалість від публікації до отримання, можуть надіслати {"type":"ClockSync","nonce":"<client nonce>"} і дочекатися {"type":"ClockSynced","nonce":"<same nonce>","server_at":<API milliseconds>} перед підпискою. Поєднуйте зразок API з монотонним часом, що минув на клієнті. Не порівнюйте server_at із системним годинником клієнта.

Без нового релізу - 22 липня 2026 року​

Додано​

  • Напрямок угоди в публічній історії: кожна угода, яку повертає GET /trades, тепер містить taker_side зі значенням Buy або Sell. Сторона мейкера завжди протилежна.
  • Курсорна пагінація для угод: передайте after_trade_id у GET /trades, щоб отримати новіші угоди у порядку зростання trade_id. Продовжуйте з останнього повернутого ID. Курсорний режим не можна поєднувати з offset, option_id, underlying або account; наявні запити зі зсувом і фільтрами не змінилися.

Без нового релізу - 20 липня 2026 р.​

Критичні зміни​

  • Повільні WebSocket-споживачі відключаються: з'єднання /ws розриваються, коли перевищено будь-який граничний поріг безпеки для окремого з'єднання. Застосовуються такі пороги: 16 384 повідомлення в черзі, 8 MiB закодованих даних у черзі, 5 секунд віку черги та 5 секунд на один запис у сокет. Це операційні пороги безпеки, а не гарантії пропускної здатності чи обіцянки сумісності. У разі порушення порогу черги, обсягу в байтах або віку надсилається код закриття 1008 з компактною JSON-причиною, що містить error: "slow_consumer", class, cause і recovery. З'єднання, яке не може прийняти навіть фрейм закриття, може бути розірване без читабельної причини. Курсор повторного відтворення поки недоступний. Клієнти мають перепідключитися, повторно автентифікуватися, якщо це потрібно, повторно підписатися та виконати дію відновлення: повторно отримати знімок для впорядкованих публічних даних, звірити приватні довговічні події через REST або повторно отримати стан портфеля. Клієнти не повинні розраховувати на безперервну доставку під час перепідключення. Маршрут надходження даних від провайдерів котирувань /ws/quotes є окремим і не змінився.
  • Незмінні індикативні оновлення об'єднуються: indicative_market_data більше не надсилає кожне оновлення котирування, що змінює лише мітку часу. Якщо ціни, обсяги та доступність провайдера не змінилися, для кожного інструмента надсилається не більше одного оновлення актуальності на секунду. Фінансові зміни ціни або обсягу та видалення провайдерів і далі публікуються негайно. Клієнти, які використовували кожну мітку часу джерела як подію, мають натомість використовувати останній отриманий знімок.
  • WebSocket-команди спільно використовують ліміти запитів REST у межах одного процесу API: підписані команди /ws PlaceOrder, SubmitRfq, SubmitAutoExecuteRfq і AcceptRfqQuote тепер використовують той самий кеш RateLimitCache у пам'яті для кожного гаманця, що й їхні REST-аналоги в цьому процесі API. Ліміти не є загальнокластерними, і різні репліки API ведуть незалежні вікна. Гаманець враховується лише після відновлення підпису та авторизації агента, тому зазначення іншого гаманця не може витратити його ліміт. Виділений под доставки WebSocket не обходить ці ліміти. WebSocket-команди, що перевищують ліміт, повертають повідомлення Error замість HTTP-заголовків обмеження запитів.

Виправлення​

  • Протитиск пам'яті WebSocket: шлях власника сокета тепер зберігає облік черги від прийняття до завершеного запису в сокет. Він фіксує закодовані байти, вік черги, час серіалізації, фактичні байти фрейму, затримку від публікації до запису, збої запису та закриття через перевантаження за класом доставки.
  • Дубльований індикативний трафік: повторні індикативні знімки повного ланцюга з незмінними фінансовими полями пригнічуються перед публічним розповсюдженням.

Без нового релізу - 13 липня 2026 р.​

Додано​

  • Коди помилок API: JSON-відповіді з помилками HTTP 4xx і 5xx, згенеровані API, додають поля code і message, зберігаючи наявні поля. Розгалужуйте логіку за стабільним машинозчитуваним code, а message використовуйте для відображення або діагностики. Див. Помилки та причини відхилення.

Без нового релізу - 3 липня 2026 р.​

Додано​

  • Видимість котирувань RFQ-провайдерів: GET /options-summary може включати необроблені індикативні котирування RFQ-провайдерів котирувань, якщо передати include_rfq_provider_quotes=true або зворотно сумісний псевдонім rfq_provider_quotes=true. Обмежте кількість котирувань провайдерів для кожного інструмента за допомогою rfq_provider_quotes_limit, provider_quotes_limit або limit.
  • Потік індикативних ринкових даних: повідомлення WebSocket IndicativeMarketData тепер включають rfq_provider_quotes, щоб клієнти могли переглядати набір індикативних RFQ-котирувань кожного провайдера, що стоїть за агрегованими бід і аск.

Виправлення​

  • Параметри запиту зведення опціонів: довідник REST API тепер документує нові параметри запиту котирувань провайдерів для /options-summary.
  • Недоступні котирування провайдерів: RFQ-котирування провайдерів, які більше не доступні, оперативно зникають із відповідей ринкових даних.

Без нового релізу - 26 червня 2026 р.​

Повідомлення про застарілість​

  • Пропущений маршрут ордера: PlaceOrder приймає пропущений route щонайменше до 4 липня 2026 р. POST /order трактує пропущений route як best_execution і повертає заголовки Deprecation, Sunset, X-Deprecation-Removal-Unix і Warning. Клієнти мають надсилати route і включати його в типізовані дані PlaceOrder. route не стане обов'язковим до 4 липня 2026 р., але може стати обов'язковим пізніше.

Додано​

  • Необов'язковий маршрут ордера: POST /order тепер приймає необов'язкове підписане поле route у PlaceOrder. Клієнти можуть надсилати best_execution, book_only або rfq_only. Пропущений route за замовчуванням відповідає поточній поведінці best_execution протягом запланованого періоду застарілості.
  • Маршрут ордера лише через книгу: клієнти можуть надіслати route=book_only, щоб пропустити пошук RPI/RFQ і відправити ордер безпосередньо до книги заявок. route=best_execution зберігає наявну поведінку «спочатку RPI, потім книга». route=rfq_only зарезервовано, і наразі він відхиляється для /order, доки не буде реалізовано семантику історії ордерів лише через RFQ.
  • Валідація маршруту масових ордерів: POST /bulk_order підтримує route=book_only для запитів з урахуванням маршруту. Пропущений route зберігає наявну поведінку лише через книгу. route=best_execution і route=rfq_only відхиляються для масових ордерів, оскільки масовий ендпоінт не виконує маршрутизацію RPI/RFQ.

Без нового релізу - 25 червня 2026 р.​

Виправлення документації​

Без нового релізу - 10 червня 2026 р.​

Виправлення документації​

  • Базові URL довідника API: виправлено згенерований довідник REST API, щоб публічні середовища вказувалися як https://testnet-api.hypercall.xyz для тестнету та https://api.hypercall.xyz для продакшену.

Без нового релізу - 10 червня 2026 р.​

Виправлення​

Виконання​

  • Виконання RPI при порожній книзі: одноногий RPI тепер розглядає ліміт користувача як верхню або нижню межу виконання, коли в книзі немає виконуваної ліквідності. Відповідні відповіді з покращенням ціни на рівні відображеного ліміту можуть бути виконані замість відхилення через те, що вони не покращують сам ліміт. Якщо виконувана ліквідність у книзі є, провайдери котирувань і далі мають покращити ціну книги щонайменше на один тік. Див. Пріоритет ордерів.
  • Відповіді провайдерів котирувань: відповіді RFQ тепер дотримуються того самого правила лімітної ціни, що й API. Природні котирування на рівні ліміту тейкера приймаються, коли немає орієнтира в книзі, тоді як котирування поза лімітом тейкера або котирування, що не покращують виконувану ліквідність книги, і далі відхиляються.

Trollbox​

  • Маршрутизація в основній мережі: продакшн-Trollbox тепер спрямовано на воркер основної мережі, тому чат застосунку використовує робоче середовище Trollbox.

Без нового релізу - 1 червня 2026 р.​

Див. також: Публікація про запуск основної мережі

Несумісні зміни​

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

Додано​

Основна мережа​

  • Альфа-версія основної мережі: Hypercall працює на app.hypercall.xyz з розрахунком у реальних USDC та опціонами SPCX як стартовим ринком.
  • Стартовий ринок SPCX: опціони SpaceX доступні в основній мережі з коллами, путами, стредлами, стренглами та спредами з визначеним ризиком. Контракти SPCX в основній мережі експіруються о 16:00 ET. Ринок використовує ту саму модель маршрутизації ордерів, що описана в Пріоритеті ордерів.
  • Конфігурація ланцюга основної мережі: підключення гаманця, підписання опціонних ордерів, адреси контрактів і тексти UI для конкретного середовища тепер визначаються активною конфігурацією основної мережі/тестнету замість жорстко закодованих припущень тестнету.
  • Продакшн-обмеження торгівлі: стартова конфігурація залишає торгівлю незупиненою, зберігаючи контрольовані налаштування ризику для альфа-розгортання.
  • Продакшн API: публічний продакшн API доступний для клієнтів основної мережі.

Поповнення​

  • Депозити USDC: користувачі можуть вносити USDC на рахунок Hypercall через застосунок. Процес показує маршрут, вихідний ланцюг, стан ретранслятора, рахунок призначення та зараховану суму до і після надсилання.
  • Атрибуція депозитів Exchange: події депозиту USDC в Exchange явно містять рахунок зарахування, тому бекенд-сервіси зараховують кошти на призначений рахунок Hypercall замість визначення власника за msg.sender. Див. Контракти: онбординг.
  • Депозитні запи: фронтенд підтримує процеси «міст і депозит» через застосунок, зокрема відстеження котирувань і статусу ретранслятора.
  • Виведення коштів: підтримку виведення в основній мережі реалізовано через системні дії та відображено в діях поповнення рахунку.
  • Вибір маршруту депозиту: дії депозиту обирають активний маршрут з конфігурації контракту, що дозволяє тому самому UI слідувати шляхам поповнення, специфічним для середовища.
  • Юридичне підтвердження: процеси налаштування рахунку та поповнення містять стартове юридичне підтвердження з опублікованими Умовами використання та Політикою конфіденційності.

Виконання​

  • RPI для одноногих ордерів: одноногі опціони за наявності права маршрутизуються через аукціон Retail Price Improvement, а потім повертаються до книги заявок, якщо жодне кваліфіковане котирування не перемагає.
  • RFQ для багатоногих пакетів: пакети багатоногих стратегій маршрутизуються через RFQ для виконання за принципом «все або нічого». Продакшн-ордери подвійного режиму надають перевагу RFQ там, де потрібне пакетне виконання.
  • Стартові комісії: комісії мейкера і тейкера вимкнені в стартовій конфігурації. Див. Комісії.
  • Маршрутизація комбінованих ордерів: комбіновані ордери маршрутизуються через бекенд-шляхи RPI/RFQ, а не через пакетні припущення лише на фронтенді.
  • Шорти постачальників котирувань: зареєстровані постачальники котирувань можуть заповнювати необхідні шорт-ноги для ліквідності RFQ/RPI, тоді як публічний стартовий обсяг залишається обмеженим.

Виправлення​

  • Доступ до сторінки депозиту: сторонні маршрути поповнення на хості застосунку та поведінку модального вікна депозиту розблоковано для продакшн-процесу поповнення.
  • Скасування білого списку депозитів: обмеження за білим списком депозитів у продакшні вимкнено для доступу до поповнення на запуску.
  • Розмір RFQ: розміри RFQ у режимі вартості точно округлюються перед надсиланням, що запобігає дрейфу дробової точності в розмірах пакетів.
  • Котирування виплат багатоногих стратегій: графіки виплат багатоногих стратегій використовують резолвер котирувань ніг, тому значення на графіку відповідають обраному пакету.
  • Від'ємні значення: від'ємні значення тепер відображаються з явним знаком в елементах UI на запуску.
  • Очищення застарілих адрес депозиту: застарілі адреси депозиту та невикористаний стан мосту видалено після перевірки запуску.

Без нового релізу - 22 травня-1 червня 2026 р.​

Див. також: Публікація про запуск основної мережі

Несумісні зміни​

  • Портфельну маржу вимкнено поза тестнетом: середовища, відмінні від тестнету, тепер відхиляють налаштування портфельної маржі. Альфа-версія основної мережі використовує лише стандартну маржу.
  • Нормалізація станів ордерів: мітки життєвого циклу ордерів послідовніше розрізняють стани підтверджено/відкрито та частково/повністю виконано. Клієнти, які відображають необроблені рядки статусу, повинні розглядати їх як канонічні стани для користувачів.

Додано​

Поповнення та рахунки​

  • Вибір маршруту депозиту: застосунок обирає маршрути депозиту з активної конфігурації контракту замість жорстко закодованих припущень щодо середовища.
  • Депозитні запи Exchange: у тестнеті з'явився процес «міст і депозит» на боці застосунку, який пізніше було випущено в основній мережі, зокрема обробка котирувань/статусу ретранслятора.
  • Явне зарахування депозитів: депозити USDC в Exchange зараховуються на рахунок, указаний у події депозиту, що усуває неоднозначну атрибуцію, коли транзакцію надсилає роутер або зап.
  • Стандартне виведення USDC: стандартні гаманці можуть надсилати запити на виведення USDC через шлях API/системних дій.
  • Ініціалізація маржі під час налаштування рахунку: налаштування API-ключа тепер ініціалізує підтримуваний режим маржі під час онбордингу, зменшуючи ймовірність того, що поповнений рахунок опиниться в недійсному торговому стані.
  • Централізовані налаштування рахунку: уподобання та налаштування рахунку нормалізовано, тож поповнення, агентські ключі, видимість Trollbox і налаштування профілю використовують єдину поверхню рахунку.

Ринки та торгівля​

  • Ринки «незабаром»: застосунок може показувати картки ринків «незабаром», не відображаючи їх як доступні для торгівлі.
  • Дробовий відкритий інтерес активів: відкритий інтерес активів відображає дробові значення замість їх обрізання для менших ринків.
  • Індикативний ризик з живого каталогу: індикативні списки ринків RFQ/ризику формуються з живого каталогу, а не із застарілого списку на фронтенді.
  • Ринковість за референсними бід/аск: введення ордерів використовує референсні дані бід/аск, щоб визначити, чи є ордер ринковим.
  • Розкреслення IV зі змішаних джерел: розрахунки імпліцитної волатильності в зведенні опціонів усувають перехрещення цін бід/аск зі змішаних джерел перед обчисленням IV.
  • Нативні закріплені рядки марок: рядки марок стратегій переведено на нативну закріплену поведінку для чистішої прокрутки ланцюга опціонів.

UI та контент​

  • Темний режим: застосунок отримав повне опрацювання темного режиму для всієї торгової поверхні.
  • Стани взаємодії: стани взаємодії фронтенду доопрацьовано для фінального шліфування перед запуском.
  • Розділення домашньої сторінки Hypercall та Insights: публічну веб-маршрутизацію оновлено, Insights виділено в окремий ресурс, а домашня сторінка продукту вказує на живу торгову поверхню.
  • Пояснення RPI проти RFQ: опубліковано статтю про виконання RPI та додано посилання на неї в матеріали запуску.

Виправлення​

  • Торгованість у бігучому рядку: вивід бігучого рядка обмежено лише лістинговими ринками, щоб користувачі не бачили неторговані активи як активні.

Без нового релізу - 28 квітня - 21 травня 2026​

Дивіться також: Оновлення продукту, тиждень 7

Несумісні зміни​

  • Видалено невикористовувані поверхні API: невикористовуваний ендпоінт /limit_iv і дублікат маршруту /profile/username-request видалено. Клієнтам слід використовувати задокументовані маршрути з довідника REST API.
  • Посилено правила резервного виконання пакетів RFQ: багатоногі RFQ є пакетними угодами і більше не покладаються на семантику резервного виконання через книгу заявок для довільного багатоногого виконання. Для поведінки резервного виконання через RPI/книгу заявок використовуйте подання одноногих ордерів.
  • Налаштовувані ID ланцюга для підпису: підпис опціонних ордерів більше не передбачає єдиного ID ланцюга тестнету. Клієнти мають визначати ланцюг для підпису з активного середовища.

Нові можливості​

Ринки​

  • Ринок SPCX у тестнеті: до тестнету додано опціони на SpaceX до IPO, з датами експірації, обмеженими датою IPO 12 червня.
  • Фільтрація лістингових ринків у бігучому рядку: бігучий рядок ринків у production і staging показує лише лістингові ринки, тож недоступні активи не відображаються як доступні для торгівлі.
  • Модель волатильності за монейністю з урахуванням торгової сесії: моделювання волатильності враховує контекст сесії під час ціноутворення ринків, чутливих до монейності.

Конструктор стратегій​

  • Конструктор стратегій в 1 клік: поширені опціонні структури, як-от стредли, стренгли, вертикальні спреди та залізні кондори, можна обрати з галереї стратегій замість того, щоб збирати їх нога за ногою.
  • Розширений конструктор: розширений режим додає керування діапазоном страйків, вибір далекої експірації для календарних структур і побудову стратегій із ногами на продаж.
  • Нова форма багатоногого ордера: введення пакетів перебудовано з обробкою котирувань для кожної ноги, зворотним відліком до експірації котирування, повідомленнями про прослизання і зручнішим процесом прийняття найкращого котирування.
  • Мітки та бейджі стратегій: заголовки стратегій тепер показують компактні мітки, класифікацію дебет/кредит і коротші назви, коли контекст тикера або експірації вже зрозумілий.
  • Індикатори опціонного ланцюжка: представлення ланцюжка отримали позначки вибраних ніг, закріплені рядки mark-ціни, мітки DTE, стрілки точки беззбитковості та індикатори позицій у представленнях ланцюжка, ширини і спреду.

RPI і RFQ​

  • Retail Price Improvement: одноногі ордери на відповідні інструменти проходять через аукціон RPI, перш ніж перейти до книги заявок. Див. Пріоритет ордерів.
  • Потік індикативних ризиків RFQ: індикативні котирування та оновлення ризиків транслюються через WebSocket, що зменшує потребу в опитуванні для активних поверхонь котирувань.
  • Високорівневий конструктор RFQ-клієнта: Rust-клієнт і торговий CLI отримали допоміжні функції для формування запитів котирувань RFQ.

Акаунт і ключі агентів​

  • Панель відкликання ключів агентів: налаштування акаунта тепер показують активні ключі агентів із можливістю відкликання. Див. Автентифікація агентів.
  • Сповіщення про ключі агентів: користувачі із забагато активних ключів отримують сповіщення-рекомендацію з посиланням на панель відкликання.
  • Вибір ланцюга, готовий до основної мережі: ID ланцюга для підпису, ланцюг гаманця Privy і поведінка перемикання гаманця тепер визначаються конфігурацією середовища.

Trollbox​

  • Trollbox для десктопу: у десктопному застосунку запущено перетягувану панель чату з налаштуваннями для її показу або приховування.
  • Міст із Telegram: повідомлення, відповіді, медіа, реакції, атрибуція пересланих повідомлень, стікери та картки команд синхронізуються між веб-Trollbox і Telegram.
  • Прив'язка акаунта Telegram: користувачі можуть прив'язати Telegram до гаманця за допомогою одноразового коду.
  • Глибокі посилання та прев'ю в Trollbox: посилання на повідомлення мають OG-прев'ю, медіазображення та маршрути застосунку для поширених повідомлень.

Профіль та інтерфейс​

  • Зображення профілю: користувачі можуть завантажувати, обрізати або імпортувати зображення профілю, а якщо його не задано, використовується детермінований резервний аватар.
  • Процес перегляду ордера: введення ордерів на мобільних пристроях отримало крок перегляду та підтвердження подання свайпом.
  • Доопрацювання теми та макета: змінні теми, підписи графіків, швидкі дії, позначки стратегій і стани кнопок доопрацьовано на десктопі та мобільних пристроях.
  • Продуктивність: сторінки активів і таблиця лідерів зменшили кількість зайвих запитів і показують більше корисних даних під час першого відображення.
  • Єдиний капітал акаунта: портфельна маржа і читання фіда Hydromancer використовують стан портфеля для капіталу акаунта, що покращує узгодженість між відображеннями маржі.

Виправлення​

  • Невідповідність одиниць продажу в тирах: виправлено обробку одиниць продажу та відкат рядків маржі для допуску ордерів за тирами.
  • Налаштування тиру для першого ордера: гаманці без стану тиру тепер ініціалізуються під час першого ордера замість отримання помилки про відсутній тир.
  • Інструменти з минулою експірацією: звірка каталогу тепер обробляє відсутні пари пут/колл і активні інструменти з минулою експірацією під час тіків експірації.
  • Стабільність Trollbox: виправлено WebSocket-heartbeat, маршрутизацію середовищ, завантаження аватарів, нормалізацію медіа, збереження реакцій і обробку відключення через неактивність.

Без нового релізу - 17–27 квітня 2026 р.​

Див. також: Оновлення продукту, тиждень 6

Нове​

RFQ​

  • Система торгівлі за запитом котирувань (RFQ): новий режим торгівлі для ринків без глибокої ліквідності в книзі заявок. Надішліть RFQ, отримуйте котирування в реальному часі через автентифікований канал rfq WebSocket і приймайте або відхиляйте їх. Якщо котирувань не надійшло, запит перетворюється на лімітну заявку в книзі заявок. Дає змогу швидко лістити нові активи (US500, USOIL, GOLD, HYPE) без очікування органічної ліквідності.
  • Режим автовиконання: новий тип підпису EIP-712 SubmitAutoExecuteRfq попередньо авторизує виконання до лімітної ціни. Перше прийнятне котирування в межах ліміту виконується негайно за один цикл запит-відповідь. Якщо котирування не надійшли або всі перевищують ліміт, запит перетворюється на лімітну заявку в книзі заявок.
  • Картки котирувань RFQ: котирування показують ціни за кожною ногою, загальну чисту премію та таймер зворотного відліку до закінчення терміну дії. Прийняти або відхилити можна одним кліком.
  • Контроль прослизання: налаштовуваний допуск прослизання (1%, 2%, 3%, 5%) відносно індикативної ціни під час надсилання RFQ.

Багатоногова торгівля​

  • Конструктор багатоногових опціонних заявок: клік на опціон у ланцюжку додає його як ногу до форми багатоногової RFQ-заявки. Ноги накопичуються, кнопка X видаляє окремі ноги. Ноги зберігаються в URL (?legs=), тож багатоногові заявки переживають оновлення сторінки і ними можна ділитися.
  • Автовизначення стратегій: розпізнає та підписує 28 типів стратегій: бичачий/ведмежий колл-/пут-спред, довгий/короткий стредл, довгий/короткий стренгл, календарний спред, діагональний спред, залізний кондор, залізний метелик, колл-/пут-метелик, колл-/пут-кондор, ризик-реверсал, колар, синтетична довга/коротка позиція, ратіо-спред, бекспред, бокс-спред, нефритова ящірка, чайка, метелик зі зламаним крилом, конверсія з розщепленим страйком. Назви стратегій ведуть на документацію.
  • Сукупна виплата, графік і греки: багатоногове представлення показує сукупну діаграму виплат, сукупний графік теоретичної ціни (сума теоретичних цін усіх ніг) та агреговані греки (дельта, гамма, тета, вега) з коригуванням знака для ніг на продаж.
  • Перемикач греків контракту і стратегії: перемикайтеся між греками на рівні окремого контракту та агрегованими на рівні стратегії в нижній панелі.
  • Максимальну кількість ніг збільшено до 10: раніше було 4.

Ліквідація​

  • Двофазна система ліквідації: часткова ліквідація через IOC-заявки на закриття, якими керує бекенд, з ескалацією до повної ліквідації через ончейн-аукціон, коли часткової ліквідації недостатньо.
  • Вкладка «Ліквідації»: нова вкладка в нижній панелі з подіями ліквідації для підключеного гаманця.
  • GET /liquidations: публічна історія переходів ліквідації з курсорною пагінацією, яку сторонні боти-ліквідатори використовують для пошуку кандидатів.
  • Приклад бота-ліквідатора: новий крейт liquidator, що демонструє моніторинг ліквідацій зі стандартною маржею та підписані заявки на ліквідацію в Hypercall.

Інтерфейс​

  • Атрибуція P&L на графіку капіталу: увімкніть іконку шарів, щоб бачити заповнені області з накопиченням для кожної позиції на графіку капіталу. Розбивка горизонтальними стовпцями під графіком групує позиції за базовим активом, показує реалізований P&L за кожним символом і підтримує фільтрацію чекбоксами, щоб виокремити або приховати окремі позиції. Наведення перехрестя оновлює розбивку. Див. посібник для десктопа.
  • Розгортувана панель ринків із хлібними крихтами: ліва панель ринків згортається, щоб звільнити більше місця для торгової області. Хлібні крихти показують контекст навігації (наприклад, Assets > BTC > Options).
  • Дзвіночок сповіщень: замінює мегафон оголошень. Випадне меню з вкладками «Сповіщення» (виконання) та «Оголошення». Індикатор непрочитаного відображається вже під час першого рендерингу завдяки SSR. Стан приховування для кожного гаманця зберігається в localStorage.
  • Меню акаунта при наведенні: наведення на кнопку профілю відкриває випадне меню з капіталом, P&L, купівельною спроможністю та кількістю позицій. Користувачі, які ще не встановили ім'я, бачать підказку «Choose name».
  • Довідка в навігації: кнопка довідки на панелі навігації веде на документацію.
  • Індикатор недоступності сервісу: червоний індикатор у заголовку, коли бекенд недоступний.
  • Індикатор рейтингу в таблиці лідерів: живий значок рейтингу на панелі навігації (замінює посилання на таблицю лідерів) з індикаторами змін, що показують зміну рейтингу під час торгівлі.
  • Сторінки деталей розрахованих позицій: детальне представлення кожної позиції з графіком теоретичної ціни, окремими виконаннями, розбивкою реалізованого P&L і зрозумілими назвами інструментів (наприклад, «BTC $55,000 Call Apr 14»).
  • Динамічні зображення для соцмереж: згенеровані OG-зображення для всіх сторінок, якими можна поділитися: інструменти (графік теоретичної ціни + греки), багатоногові стратегії (діаграма виплат + назва стратегії), профілі (статистика P&L + рейтинг), таблиця лідерів (топ-5 із медалями) та підтвердження угод.
  • Перебудовано панель навігації на десктопі: футер прибрано, кнопку підключення перенесено в заголовок, відображаються підказки гарячих клавіш (Ctrl+K).
  • Виправлено обрізання ціни в заголовку графіка: ціни більше не виходять за межі заголовків графіків на десктопі.

PWA​

  • Перехід на кореневі маршрути: усі маршрути об'єднано з /mobile/* у кореневі /*. Застарілі шляхи /mobile/* автоматично перенаправляються. Єдина схема URL для десктопа і мобільної версії.
  • Процес оновлення PWA на iOS: користувачі, які встановили стару PWA /mobile, бачать нативне модальне вікно оновлення з покроковими інструкціями встановлення для iOS (Share > View More > Add to Home Screen) з офіційною іконографікою Apple.
  • Заставки iOS і попереднє завантаження навігації: понад 12 заставок під конкретні пристрої усувають білий спалах під час холодного старту. Попереднє завантаження навігації отримує сторінку, поки запускається service worker.
  • Ярлики застосунку: довге натискання на іконку на головному екрані дає швидкий доступ до Portfolio і Deposit.
  • Блокування вимкнення екрана: екран залишається увімкненим під час торгових сесій у режимі автономної PWA. Блокування автоматично відновлюється після повернення до застосунку.
  • Постійне сховище: запитує navigator.storage.persist(), щоб браузер не видаляв кешовані ресурси застосунку.

API​

  • instrument_type у подіях WebSocket: події виконання та оновлення заявок тепер містять instrument_type ("option" або "perp"). Зворотно сумісне доповнення.
  • Фільтр ?symbol= для GET /profile/trades: фільтрує історію угод за символом інструмента. Зменшує обсяг відповіді для трейдерів із великим обсягом торгівлі, які запитують конкретні інструменти.
  • Виконання перпів пересилаються через WebSocket: виконання перпів Hydromancer тепер публікуються у фід WebSocket (раніше були відсутні).
  • AcceptRfqQuote і PlaceOrder через WebSocket: повний життєвий цикл заявки (надсилання RFQ, отримання котирувань, прийняття, розміщення заявки) тепер може працювати через одне з'єднання WebSocket без жодного REST-виклику.
  • Поле fills у PerpOrderResult: Rust SDK тепер повертає виконання безпосередньо у відповідях на заявки по перпах. Поля: coin, side, size, price.

Виправлення​

  • Фантомні заявки IOC/FOK: частково виконані заявки IOC і FOK залишали невиконаний залишок у книзі заявок як фантомні заявки. Тепер залишки скасовуються одразу після часткового виконання, а статус встановлюється в Canceled замість PartiallyFilled.
  • Резервування премії для закривальних купівель: заявки на купівлю, що закривають коротку позицію, помилково резервували премію, зменшуючи капітал і спричиняючи хибну ліквідацію. Тепер резервування премії пропускається для заявок на купівлю, що закривають позицію.
  • Прострочені ланцюжки після деплою: ланцюжки опціонів із минулою експірацією ненадовго з'являлися як Active після перезапуску сервера. Тепер під час завантаження інструменти перевіряються за мітками часу експірації та одразу позначаються як ExpiredPendingPrice.
  • Резервний варіант RFQ без котирувань: RFQ з автовиконанням, що не отримав прийнятних котирувань, раніше показував помилку. Тепер він розміщує лімітну заявку в книзі заявок.
  • Точність лідерів руху в біжучому рядку: лідери руху в рядку тікерів тепер обчислюються з кешу зведення опціонів за зміною теоретичної ціни відносно теоретичної ціни 24 години тому, з фільтрацією лише за опціонами з котируваннями. Раніше використовувалися сирі дані BBO, що давали зашумлені або застарілі значення.
  • price_change у зведенні опціонів: як еталон BBO для розрахунку зміни ціни тепер використовується лише бід із книги заявок, замість резервного порівняння mark і theo, яке могло давати оманливі значення.

Без нового релізу - 14–16 квітня 2026​

Зміни, що порушують сумісність​

  • PUT /order і PUT /bulk_order: нові ендпоінти для атомарної заміни заявок. Скасовують наявну заявку й розміщують нову в тому самому такті рушія. Якщо скасування не вдається (заявку вже виконано або не знайдено), нова заявка не розміщується. Використовують новий тип підпису EIP-712 ReplaceOrder. Клієнтам, які використовують старий патерн «скасувати, потім розмістити», слід перейти на нові ендпоінти.

Нове​

API​

  • GET /profile/realized-pnl: повертає реалізований PnL за кожним символом, агрегований з виконань і розрахунків. Приймає необов'язковий параметр competition_id, щоб обмежити результати вікном змагання.
  • Поле realized_pnl у GET /profile/trades: кожен рядок виконання тепер містить реалізований PnL, віднесений до цієї конкретної угоди.
  • net_deposits і компоненти атрибуції в GET /profile/historical-pnl: точки історичних знімків капіталу тепер містять накопичені чисті депозити й розбивку атрибуції P&L.
  • Поле prev_day_px у GET /markets: відповідь ринків тепер містить референсну ціну попереднього дня для кожного інструмента.

UI​

  • Мегафон оголошень: іконка мегафона в заголовках десктопної і мобільної версій зі значком кількості непрочитаних. Натискання відкриває спливне вікно зі списком оголошень (заголовок, текст, дата, необов'язкове зображення або посилання). Стан «прочитано/приховано» зберігається окремо для кожного гаманця.
  • Редагування й заміна заявок: на десктопі іконка олівця біля відкритих заявок дає змогу редагувати ціну й розмір прямо в рядку, галочка надсилає зміни, X скасовує, під час редагування рядок підсвічується бурштиновим. На мобільному натискання на заявку показує кнопки Cancel і Update.
  • Розраховані позиції на сторінці учасника: новий розділ «Settled Positions» між Positions і Trade History. Показує реалізований PnL за кожним символом від опціонів, що досягли експірації, і закритих угод із зеленим/червоним кольоровим кодуванням. Як відбувається розрахунок опціонів, див. у розділі Розрахунок.
  • Стовпець реалізованого PnL в історії угод: показує реалізований PnL для кожного виконання з кольоровим кодуванням; для виконань, що відкривають позицію, показано прочерк.
  • Керування API-ключами більше не блимає під час завантаження: список агентів відображається одразу, а не з'являється після завантаження сторінки.
  • Порожня таблиця позицій прихована: якщо в користувача немає відкритих позицій, розділ позицій повністю приховано замість показу порожніх заголовків таблиці.
  • Кнопки підключення в порожньому стані: відновлено відсутні кнопки підключення гаманця на екранах порожнього стану.

PnL​

  • P&L тепер враховує сплачену премію: реалізований PnL тепер ураховує премію, сплачену за відкриття позиції. Раніше показувалася лише валова виплата. Приклад: гаманець, який раніше показував +162Kреалізованогоприбутку,теперкоректнопоказує+162K реалізованого прибутку, тепер коректно показує +27K з урахуванням сплаченої премії $135K.
  • Розраховані опціони згруповано за базовим активом: атрибуція більше не перелічує кожен окремий символ, що досяг експірації; розраховані позиції згорнуто в групи за базовим активом (наприклад, «BTC (settled)»).
  • Поточний капітал більше не падає до нуля для позицій OTM: виправлено злам, коли вартість позиції поза грошима (OTM) різко падала до нуля на живому хвості графіка капіталу.
  • Атрибуція відображається для гаманців лише з позиціями, що досягли експірації: гаманці без відкритих позицій, але з розрахованими опціонами, тепер коректно показують атрибуцію PnL.

Виправлення​

  • GET /profile повертав 500: виправлено для гаманців із неповними агрегованими даними.
  • Нереалізований PnL застарівав після перезапуску сервера: портфелі тепер переоцінюються одразу після перезапуску, а не чекають наступного оновлення марк-ціни.
  • Помилка на одиницю в DTE на діаграмах виплат: виправлено розрахунок кількості днів до експірації, який зміщував лінії точки беззбитковості й максимального збитку.
  • Перехоплення фокусу: виправлено перехоплення фокусу під час взаємодії з інтерфейсом.
  • Покращення відображення графіків: різні виправлення відображення графіків.

Без нового релізу - 11–13 квітня 2026​

Нове​

Push-сповіщення​

Торгівля​

  • Вкладка Greeks (десктоп): нова вкладка в нижній панелі, що показує для кожної позиції дельту, гамму, тету, вегу, ро та IV. Заголовки стовпців мають підказки з посиланнями на довідник грецьких показників. Рядки проміжних підсумків за кожним базовим активом; загальний підсумок портфеля, коли позиції охоплюють кілька базових активів.
  • Сортування стовпців таблиці лідерів: стовпці прибутку, обсягу й ефективності в таблиці лідерів тепер можна натиснути для сортування.
  • Покращення форми заявки: швидкий вибір суми, покращені підказки, адаптивні розміри.
  • Графік PnL на сторінці учасника: профілі учасників тепер показують графік капіталу в часі.
  • Статистику HC/HL перенесено в бічну панель: статистику HyperCore і HyperLiquid переміщено в бічну панель.
  • Прибрано рядки заявок нульового розміру: список заявок більше не показує заявки з нульовим розміром.

Режим Ghost​

  • Режим Ghost: неавтентифіковані користувачі можуть переглядати ринки, книги заявок і графіки без підключення гаманця. Сторінка налаштувань також доступна без автентифікації. Подробиці див. у посібнику для десктопа.
  • Динамічні фавікони для кожного активу: іконка вкладки браузера показує зелене кільце з іконкою активного активу. Під час перегляду опціонів відображаються варіанти для колів і путів.

Графіки​

  • Візуалізація поверхні волатильності: інтерактивний 3D-переглядач поверхні волатильності за адресою /risk/vol-surface для всіх базових активів, що торгуються. Як формуються поверхні волатильності, див. у розділі Оракули.
  • Графік портфеля за замовчуванням використовує 5-хвилинний інтервал: плавніше відображення для нових облікових записів (вигляд 8H замість 4D).
  • Графік оновлюється під час зміни налаштувань: перемикання режиму графіка в налаштуваннях тепер набуває чинності одразу, без перезавантаження сторінки.

API​

  • Фільтр експірації в GET /options-summary: передайте ?expiry=YYYY-MM-DD, щоб обмежити відповідь однією датою експірації.

Обліковий запис​

  • Відображувані імена користувачів: гаманці можуть установити відображуване ім'я, яке показується в таблиці лідерів і на сторінках учасників. Імена набувають чинності миттєво (без перевірки модератором). Їх можна редагувати прямо в рядку як у налаштуваннях десктопної версії, так і в налаштуваннях мобільної версії.

Виправлення​

  • Сторони бід/аск були інвертовані для деяких заявок: виправлено неправильне призначення сторони залежно від напрямку заявки в мережі.
  • Час завантаження опціонного ланцюжка скорочено приблизно на 60%: швидше завантаження завдяки фільтрації за експірацією в API та попередньому завантаженню даних графіків для видимих страйків.
  • Перемикання ринків тепер миттєве: на десктопі під час перемикання базових активів сторінка повністю не перезавантажується.
  • Збій під час перемикання тенорів на десктопі: виправлено збій і повільну роботу під час перемикання між тенорами опціонів.
  • Прокручування сторінки облікового запису на десктопі: довга історія угод тепер прокручується коректно.
  • Помилка 404 для /preferences на мобільному: сторінка налаштувань тепер доступна на мобільному.
  • Купівельна спроможність оновлюється після депозиту: баланс тепер оновлюється одразу після депозиту з крана тестнету, без потреби оновлювати сторінку.
  • Бар'єр торгівлі показується, коли агента не налаштовано: показуються дії з налаштування замість непрацюючої кнопки підпису.
  • Банери помилок зникають автоматично: постійні банери помилок тепер закриваються самостійно.
  • Макет таблиці лідерів на мобільному: виправлено стиснуті значення на мобільному порівняно з десктопом.
  • Усунено мерехтіння під час перенаправлення: прибрано видимі перенаправлення під час переходу до застосунку.

Без нового релізу - 7–10 квітня 2026​

Див. також: Тиждень 4: Desktop запущено

Додано​

API​

  • GET /historical-theos: теоретичні ціни опціонів у часі замість сирої історії цін останніх угод. Налаштовувані часові інтервали та ліміти. Див. Довідник REST API.
  • GET /historical-theos/batch: отримання рядів теоретичних цін для до 50 інструментів в одному запиті. Параметри: instrument_names=A,B,C&interval=1h&limit=100.
  • realized_pnl у GET /profile/trades: виконання тепер повертають реалізований PnL.

UI​

  • Греки тепер використовують теоретичні марки: усі розрахунки греків використовують теоретичні ціни замість цін останніх угод, що значно підвищує точність для неліквідних страйків.
  • Графік теоретичної ціни на сторінках інструментів: сторінки опціонних контрактів показують графік історичної теоретичної ціни (замінює сиру історію цін угод).
  • Позиція безпосередньо на сторінці інструмента: ваша відкрита позиція за активним інструментом відображається прямо на сторінці контракту.
  • Покращення порожніх станів: кращі тексти та макет для порожніх графіків і порожніх станів.

Виправлення​

  • Ліміт депозиту з крана: кран тестнету тепер враховує залишок дозволеної суми на гаманець замість фіксованого максимуму.
  • Періодичні помилки 503 у GET /portfolio: виправлено періодичні серверні помилки на ендпоінті портфеля.
  • Індикатори завантаження: усунено фантомні індикатори завантаження під час завантаження сторінки.
  • GET /profile/trades повертав 500: виправлено для гаманців із виконаннями.
  • Зсув макета сторінки учасника: виправлено зсув вирівнювання на сторінці учасника.
  • Мітка графіка за замовчуванням: уточнено, що налаштування графіка за замовчуванням стосується активів.

Без нового релізу - 1–6 квітня 2026​

Див. також: Оновлення продукту, тиждень 3

Зміни, що порушують сумісність​

  • Змінено модель портфельної маржі: формулу початкової маржі змінено з scanning_risk на max(scanning_risk, option_floor) + gamma_overlay. Три нові поля у відповідях портфеля через REST і WebSocket: scanning_risk, option_floor, gamma_overlay. Доступний баланс тепер дорівнює equity - total_margin_used (було cash - total_margin_used). Капітал тепер включає нереалізований PnL безстрокових контрактів.
  • Зміни в GET /risk/grid: видалено параметр include_open_orders. Модель сценаріїв змінено з одновісної {scenario_type, value} на комбіновані шоки {spot_shock_pct, vol_shock_pct, pnl_weight, is_tail}. PnL найгіршого сценарію тепер зважений.

Додано​

Desktop​

  • Торговий макет для desktop: повноцінна desktop-оболонка з багатопанельним торговим видом, навігацією з клавіатури, графіком ціни інструмента, компактними символами опціонів і переходом за кліком від позицій/заявок до інструментів.

API​

  • Опціонні інструменти тепер включають символ і ціну базового активу: відповіді для опціонних інструментів містять їхній базовий актив. Див. Довідник REST API.

Змагання та таблиця лідерів​

  • Система змагань: нові ендпоінти: GET /competitions, GET /leaderboard, GET /competition-metric-ranks, POST /submitUsernameRequest. Щомісячний розклад (з 1-го до 1-го числа о 16:00 ET). Змагання в тестнеті зі справжніми призами (500/500/300/$200 у SYN). Маркетмейкери виключені з рейтингу.
  • UI таблиці лідерів: значок рангу ("Rank #X" або заклик "Trade to win"), картка розподілу призів, інтеграція Hyperliquid Names, форматовані символи опціонів ("04/10 $59,000 Call"), P&L за лотами FIFO, відносні мітки часу (5m, 2h, 3d).
  • Markdown в описах змагань: описи змагань підтримують форматування markdown.

Портфель​

  • Портфельна маржа: крос-маржування між корельованими позиціями. Інструменти з минулою експірацією виключені з гамма-надбавки.

UI​

  • Компактні символи опціонів: зручний для читання формат у всьому UI: "04/10 $59,000 Call".
  • Кнопка Max у формі заявки: максимальний розмір одним кліком на основі доступної маржі.
  • Роздільники тисяч: усі поля цін і розмірів відображаються з комами.
  • Клік на позицію/заявку → інструмент: натискання на рядок позиції або заявки переходить до відповідного контракту.
  • Сторінка налаштувань: підказки, циклічна зміна значків і синхронізований стан налаштувань між сесіями.

Виправлення​

  • Центрування графіків за UTC: графіки активів центруються за межами UTC; переходи між таймфреймами стабілізовано.
  • Жести свайпу (мобільна версія): виправлено нестабільну поведінку свайпу для скасування та свайп-навігації.
  • Видалення префікса з URL на desktop: видалено префікс /mobile з URL на desktop; виправлено вибір страйку.

Без нового релізу - 24–31 березня 2026​

Див. також: Оновлення продукту, тиждень 2

Додано​

Графіки​

  • Графік історичного PnL: графік капіталу в часі на головній сторінці з інтерактивним перехрестям. Торкніться або клацніть, щоб переглянути будь-яку точку; показує мітку часу та оновлює відображення балансу.
  • Графік активу: графік спотової ціни для кожного активу з віссю Y, обмеженою діапазоном видимого періоду.

Керування заявками​

  • Заголовки розділів: розділи позицій, заявок та історії мають окремі заголовки для зручнішого перегляду.
  • Видалення заявок свайпом (мобільна версія): проведіть ліворуч по відкритій заявці, щоб скасувати її.
  • Підтвердження скасування заявки: окремий діалог скасування заявки.
  • Клік на рядок заявки → сторінка контракту: натискання на заявку відкриває детальний вигляд інструмента.
  • Оновлений вигляд відкритих заявок: оновлено стилі відкритих заявок.

З'єднання​

  • Банери відключення WebSocket: видимі банери, коли потік WS обривається або бекенд недоступний.

Греки​

  • Греки позицій на сторінці активу: сукупні дельта, гамма, тета, вега на сторінці деталей активу.
  • Греки контракту на сторінці контракту: греки для кожної позиції у вигляді контракту.
  • Точки беззбитковості для різних типів опціонів: точки беззбитковості розраховуються та відображаються для коллів, путів і спредів.

Історія угод​

  • Час виконання в GET /profile/trades: рядки історії угод тепер містять мітку часу виконання.
  • Збереження експірації в ланцюжку опціонів: вибрана експірація зберігається в параметрах запиту URL і відновлюється під час навігації.
  • Опціонні інструменти включають символ і ціну базового активу: опціонні інструменти містять свій базовий актив у відповідях.

Обліковий запис​

  • Система імен користувачів: задайте відображуване ім'я для адреси свого гаманця, яке показується в таблиці лідерів і на сторінках учасників.

Виправлення​

  • GET /profile/trades повертав 500: виправлено для гаманців із виконаннями.
  • Порядок відображення позицій за замовчуванням: позиції за замовчуванням показують вартість, потім PnL, потім собівартість (раніше було непослідовно).
  • Футер заявки показує час до експірації: додано відображення TTE; затримка підпису в 1 секунду запобігає випадковому подвійному надсиланню.
  • Вихід на мобільних пристроях: стан сесії коректно очищується під час виходу.
  • Фон світлої теми: виправлено колір фону у світлій темі.
  • Плавніші переходи між сторінками: зменшено візуальні ривки під час навігації.
  • Фон під час свайпу: виправлено відображення фону під час свайп-взаємодій.

Без нового релізу - 16–23 березня 2026​

Див. також: Оновлення продукту, тиждень 1

Нове​

Тема й оформлення​

  • Темний режим Midnight: нова висококонтрастна темна тема на додачу до наявного світлого режиму.
  • Автоматичний режим теми: тема автоматично відповідає налаштуванню світлого/темного режиму пристрою. Для нових користувачів за замовчуванням увімкнено автоматичний режим.

Дашборд і статистика​

  • Поля статистики HL і HC: перемикання між статистикою Hyperliquid і статистикою Hypercall на дашборді.
  • Співвідношення пут/колл: до панелі статистики Hypercall додано співвідношення пут/колл.
  • Бейджі результатів: візуальні бейджі для результатів угод (прибуток, збиток, експірація без вартості тощо) з круговою діаграмою в заголовку позиції.

Опціонний ланцюг​

  • Сортування страйків і збереження вибору: страйки можна сортувати, а вибір зберігається між сесіями.
  • Початкове значення цільової ціни: сторінка цільової ціни заповнюється поточною ціною базового активу замість порожнього поля.
  • Нормалізація ціни базового активу: узгоджене відображення ціни базового активу на всіх сторінках, включно з даними перпів DEX.

UX ордерів​

  • Повідомлення про скасування для виконаних/прострочених ордерів: спроби скасувати вже виконані або прострочені ордери показують "This order has already been completed or cancelled" замість необробленої помилки.

Налаштування​

  • Сторінка налаштувань: підказки, циклічне перемикання бейджів і синхронізований стан налаштувань між сесіями.

Виправлення​

Підключення​

  • Оновлення даних після перепідключення WebSocket: ордери, виконання та портфель повторно завантажуються після перепідключення WS замість показу застарілих даних.
  • Затримка перепідключення WS: таймер backoff тепер скидається після стабільного з'єднання. Раніше він ніколи не скидався, через що після кількох звичайних розривів кожне перепідключення чекало 30 секунд.

Ордери​

  • Ордери-привиди на інструментах після експірації: ордери на інструментах, за якими відбувся розрахунок, тепер коректно очищаються, що запобігає помилкам "Orderbook not found" під час скасування.
  • Відхилення від'ємного грошового балансу: ордери BUY, які зробили б грошовий баланс від'ємним, тепер відхиляються під час подання. Повідомлення про відхилення: "Insufficient cash (Standard)". Це обмеження можна обійти для ордерів buy-to-close, що зменшують ризик. Див. Стандартна маржа.

Інтерфейс​

  • Анімація цільової ціни: виправлено підстрибування/зависання анімації на сторінці цільової ціни.
  • Обрізання мобільного графіка активу: виправлено обрізання швидких дій на мобільному графіку активу.
  • Зависання завантаження мобільного PWA: виправлено проблему, через яку мобільний PWA зависав на "Loading...".

Відомі проблеми​

Перш ніж налагоджувати поведінку клієнта, спершу перевірте сторінку статусу Hypercall на наявність активних інцидентів і технічного обслуговування.

Поведінку стейджингу та відомі проблеми повідомляють разом із наданням доступу; за подробицями зверніться до команди.

Політика версіонування​

Мітки стабільності:

  • Стабільний: шляхи маршрутизатора та основні структури запитів/відповідей навряд чи зміняться

Несумісні зміни: будуть задокументовані тут разом із посібниками з міграції.

Посилання​

Останнє оновлення