How chain recalculation works inside HETHA
Arbitrage in HETHA is implemented as a distributed process where market data passes through several layers before becoming an actual arbitrage opportunity. The goal of this architecture is not to “find signals,” but to continuously verify whether a potential route remains executable under the current market structure.
The process begins with order books. Worker nodes receive incremental updates from exchanges and maintain synchronized order book states in real time. These updates are applied incrementally rather than by rebuilding the book from scratch, which allows the system to react to even small market changes with minimal latency.

Not every update triggers deeper computation. Many ticks do not meaningfully affect weighted prices or available depth and are filtered out early. Only changes that alter key order book parameters are forwarded for further processing. This prevents unnecessary recalculations and keeps the pipeline stable under high update rates.
Why chains must be recalculated continuously
In HETHA, arbitrage chains are not stored as static routes. Every chain is a short-lived structure that exists only as long as the current order books support it. Once a meaningful change occurs in any relevant market, the system forms a new set of candidate chains that must be recalculated.
This recalculation step is handled by the GPU. A large number of chains are evaluated in parallel against the latest market state. For each chain, the system checks whether the route still aligns with prices, whether sufficient liquidity exists at every step, and whether profitability remains positive after fees.

Even a small shift in one order book — a change in depth, spread, or weighted level — can invalidate an entire chain. This is not an edge case but a normal outcome of operating in fast-moving markets.
Validation as a structural filter
Recalculation alone is not enough. After each rebuild, chains go through validation against the live order books. If a chain deviates from current data, takes too long to generate, or no longer reflects executable prices, it is immediately discarded.
This constant ranking and elimination process runs continuously and results in millions of recalculations per hour. Only a small fraction of chains survive long enough to become visible to the user or reach the execution module.
The key point is that chains are removed not because the logic was incorrect, but because the market has already moved. Validation ensures that outdated assumptions never propagate further down the pipeline.
From signals to a structured system
This mechanism — continuous reconstruction combined with strict validation — is what transforms HETHA from a signal-based approach into a structured arbitrage system. Instead of reacting to historical snapshots or price gaps, the system maintains an up-to-date representation of what the market can actually execute at any given moment.
Arbitrage becomes an ongoing process rather than a one-time search. The pipeline remains active, adaptive, and synchronized with real market structure, ensuring that only chains supported by current liquidity and pricing survive.
This architectural choice is what allows HETHA to operate reliably under high update rates and changing market conditions, treating arbitrage as infrastructure rather than as a feed of opportunities.
