Project analysis / project analysis
ht.xyz: DEX routing from a quote to a transaction
A Swap button hides several independent stages: fetching data, selecting a route, checking conditions, interacting with a wallet and confirming the outcome. We examine these boundaries using the published scope of ht.xyz. The project closed in November 2026 following a change in the company’s strategic direction.
The documented project scope
The portfolio describes ht.xyz as a HyperEVM DEX and aggregator with its own aggregation logic between HyperEVM and HyperCore. Work covered swap, pools, a DeFi dashboard, wallet flows and a backend for tokens, quotes and analytics. The stack includes Next.js, TanStack Query, ethers, viem, Uniswap V3 SDK, NestJS and Prisma.
The public case does not disclose the route-search algorithm, contract addresses or audit results. The following discussion explains how to analyse responsibilities in this kind of product; examples do not describe the private protocol implementation.
A quote needs context
An expected output number is insufficient for an interface. Our approach to a quote contract is to carry its network, assets, exact input amount, route and freshness context together. Changing the amount or network should prevent the previous offer from being submitted.
That also addresses a common race: a user changes the amount, but a slow response to the previous request arrives later. The screen must reflect the current request, rather than whichever response arrived last.
text
Asset pair + network + amount
↓
Quote and route → freshness check
↓
Wallet confirmation → submission → outcome
Conceptual model, not the internal ht.xyz protocol diagram.Go beyond loading and success
In our user-journey model, wallet cancellation is distinct from an API failure, and submitting a transaction is distinct from confirmation. For every state, the team should know what the user can do next.
| State | Useful interface behaviour |
|---|---|
| No route | Explain that no offer is available without inventing a fallback price. |
| Stale quote | Request a new quote and let the user review changed conditions. |
| Signature cancelled | Allow another attempt without claiming completion. |
| Transaction submitted | Show its identifier and track the outcome separately. |
| External source unavailable | Explain the limitation instead of masking it with a success state. |
Backend, frontend and onchain logic share a contract
The frontend presents choices and state; the backend supplies consistent, available data; the onchain layer executes rules within contracts. Test these boundaries together: a correct screen cannot compensate for mismatched units or a wrong asset address.
For a new project, we would start with contract examples at system boundaries: an asset with different precision, a network change, an expired quote, an unavailable source and reopening the screen after submission. This is a recommended verification plan, not a claim that we performed an independent security audit of ht.xyz.
Questions to settle before building an aggregator
Estimation starts with networks, liquidity sources, allowed operations and the support model. Agree responsibility for contracts, independent security review, indexing and operations separately. An SDK reduces some integration work; it does not establish readiness of the whole product.
- Which networks, assets and sources belong in the first release?
- Who maintains the contracts, and which reviews are required before launch?
- How can the team reproduce a quote or transaction issue without collecting wallet secrets?
- What should a user see when an external source stops responding?
Sources and context
Working through a similar problem?
Tell us about your product, current constraints and intended outcome. We will identify a concrete next step.