Розбір проєкту / розбір проєкту
ht.xyz: маршрутизація DEX від котирування до транзакції
Кнопка Swap приховує кілька незалежних етапів: отримання даних, вибір маршруту, перевірку умов, дію в гаманці й підтвердження результату. Розглядаємо ці межі на основі опублікованого scope ht.xyz. Проєкт закрито в листопаді 2026 року через зміну напряму розвитку компанії.
Підтверджений обсяг роботи
ht.xyz описаний у портфоліо як HyperEVM DEX і агрегатор із власною логікою агрегації між HyperEVM та HyperCore. Роботи охоплювали swap, pools, DeFi-dashboard, wallet-flow, backend для токенів, котирувань та аналітики. Стек включає Next.js, TanStack Query, ethers, viem, Uniswap V3 SDK, NestJS і Prisma.
Публічний кейс не містить алгоритму пошуку маршрутів, контрактних адрес або результатів аудиту. Нижче ми пояснюємо спосіб аналізувати відповідальності такого продукту; приклади не є описом непублічної реалізації протоколу.
Котирування має контекст
Для інтерфейсу число очікуваного виходу недостатнє. Наш підхід до контракту котирування — разом із ним передавати мережу, активи, точну вхідну суму, маршрут і контекст актуальності. Зміна суми або мережі повинна робити попередню пропозицію непридатною для відправлення.
Це допомагає розібрати типову гонку: користувач змінив суму, але повільна відповідь на попередній запит прийшла пізніше. Стан екрана має відповідати поточному запиту, а не порядку надходження відповідей.
text
Пара активів + мережа + сума
↓
Котирування й маршрут → перевірка актуальності
↓
Підтвердження в гаманці → відправлення → результат
Концептуальна модель; не схема внутрішнього протоколу ht.xyz.Не зводити всі стани до loading та success
У нашій моделі користувацького сценарію скасування в гаманці відрізняється від помилки API, а відправлення транзакції — від підтвердження. Для кожного стану команда має знати, що користувач може зробити далі.
| Стан | Корисна поведінка інтерфейсу |
|---|---|
| Немає маршруту | Показати відсутність пропозиції без вигаданого fallback-курсу. |
| Котирування застаріло | Запросити нове й дати перевірити змінені умови. |
| Користувач скасував підпис | Повернути можливість повторити дію, не називаючи її виконаною. |
| Транзакцію відправлено | Показати ідентифікатор і окремо відстежувати результат. |
| Зовнішнє джерело недоступне | Пояснити обмеження та не маскувати його успішним станом. |
Backend, frontend та onchain-логіка мають спільний контракт
Frontend відповідає за зрозумілий вибір і відображення стану; backend — за доступні й узгоджені дані; onchain-частина — за виконання правил у межах контрактів. Межі потрібно перевіряти разом: коректний екран не компенсує невідповідність одиниць або помилкову адресу активу.
Для нового проєкту ми починали б із контрактних прикладів на межах систем: токен з іншою точністю, зміна мережі, прострочене котирування, недоступне джерело та повторне відкриття екрана після відправлення. Це рекомендований план перевірки, не твердження про проведений аудит ht.xyz.
Що з'ясувати перед розробкою агрегатора
Оцінка починається з мереж, джерел ліквідності, дозволених операцій та моделі підтримки. Потрібно окремо погодити відповідальність за контракти, незалежну перевірку безпеки, індексацію й експлуатацію. Наявність SDK скорочує частину інтеграційної роботи, але не визначає готовність усього продукту.
- Які мережі, активи й джерела входять у перший реліз?
- Хто підтримує контрактну частину та які перевірки потрібні до запуску?
- Як команда відтворить проблему за котируванням і транзакцією без збирання секретів гаманця?
- Що побачить користувач, якщо зовнішнє джерело перестане відповідати?
Джерела та контекст
Маєте подібну задачу?
Розкажіть про продукт, поточні обмеження й потрібний результат — визначимо предметний наступний крок.