When people talk about trading infrastructure, they usually imagine cloud servers and remote execution environments. Many trading platforms run their engines entirely on centralized infrastructure while users interact with the system through a web interface.
However, arbitrage trading introduces somewhat different requirements. Execution reliability, transparency of system behavior, and control over the runtime environment become critically important. For this reason, the PRO version of HETHA.IO uses a different architecture: the execution layer runs locally on the user’s machine.
This approach separates execution infrastructure from the analytical interface, allowing users to maintain direct control over the runtime environment while continuing to use a centralized dashboard to monitor system activity.
Execution Challenges in Arbitrage Systems
In arbitrage trading, identifying a profitable chain is only the first step. The more difficult task is ensuring that it can be executed reliably.
Execution depends on many factors: orderbook liquidity, exchange responsiveness, connection stability, and current system load. Even when an arbitrage opportunity exists mathematically, unstable execution conditions can cause the chain to fail to close as expected.
When the trading engine operates entirely on remote infrastructure, users often have limited visibility into what is happening. From the outside, the system appears as a “black box”.
Local execution creates a different model. The runtime environment becomes observable, and users gain access to system behavior that would otherwise remain hidden.
Local Runtime and Centralized Monitoring
In the PRO version of HETHA.IO, the system is divided into two layers:
Execution layer
runs locally on the user’s machine.
Analytical layer
is accessible through the HETHA.IO dashboard.
The execution engine evaluates arbitrage chains and performs trading logic inside a local virtual machine. At the same time, operational data is synchronized with the platform interface. Users continue to observe:
- arbitrage chains
- execution results
- statistics
- moneyflow
through the same dashboard used in other versions of the system.
From the user’s perspective, the monitoring interface remains the same. The only difference is where the execution processes run.
HETHA.IO dashboard showing balances and execution statistics
Why a Virtual Machine Is Used
Running trading infrastructure locally introduces an important challenge: maintaining a consistent runtime environment across different operating systems.
To solve this problem, the PRO version of HETHA.IO is distributed as a preconfigured virtual machine. This environment includes the operating system and all components required for the arbitrage engine.
This approach ensures consistent runtime behavior across Windows, macOS, and Linux systems. It also eliminates dependency conflicts and simplifies system deployment.
As a result, the trading environment remains stable regardless of the user’s computer configuration.
Execution Transparency
One of the advantages of the local model is execution transparency.
Because the trading engine runs inside the user’s environment, it is possible to observe how the system behaves during operation. Execution logs are available both inside the local environment and in the user’s personal dashboard.
This makes it possible to analyze execution processes, track system behavior, and study how arbitrage chains are handled under different market conditions.
In systems with fully remote execution, this type of internal information often remains inaccessible. The local model, combined with log and statistics visibility in the dashboard, makes system behavior more observable and easier for users to understand.
System Integration and User Identification
Although execution takes place locally, the system remains integrated with the HETHA.IO platform.
Each PRO package is generated individually and linked to a specific user account. When the local environment starts, embedded identification parameters allow the system to automatically associate the running instance with the correct account.
This allows the local runtime environment to synchronize operational data with the platform dashboard while the execution engine itself continues to run on the user’s machine.