Execution Engine Parameters
A complete reference of every tunable parameter that governs the Velox execution engine — from latency thresholds to tick granularity.
Engine Configuration Overview
The Velox execution engine processes every swap through a deterministic parameter set that governs pricing precision, latency ceilings, and order routing behavior. Each parameter is tuned for the TRON mainnet environment — balancing settlement speed against network congestion, and precision against gas efficiency. These values are reviewed quarterly and adjusted based on observed network conditions and validator performance data.
All parameters below are immutable at the contract level for any given deployment version. Parameter updates require a new contract deployment with a mandatory 72-hour timelock, during which the community can verify the changes on-chain before they take effect.
Parameter Reference Table
Every engine parameter, its symbol, current value, and functional description.
| Parameter | Symbol | Value | Description |
|---|---|---|---|
| Max Latency Threshold | L_max | 2 800 ms | Upper bound for end-to-end swap execution. Swaps exceeding this threshold are automatically reverted and resubmitted with priority fee bump. |
| Rate Lock Window | T_lock | 15 s | Duration the quoted exchange rate is held firm after the user receives a quote. Expired quotes must be re-fetched before signing. |
| Tick Size (USDT) | Ï„_USDT | 0.01 USDT | Minimum increment for USDT input amounts. All user inputs are rounded down to this granularity before execution. |
| Tick Size (TRX) | Ï„_TRX | 0.01 TRX | Minimum increment for TRX input amounts. Maintains parity precision across both sides of the swap pair. |
| Minimum Swap Size (USDT) | Q_min_USDT | 10.00 USDT | Smallest allowable USDT input. Swaps below this amount are rejected to prevent uneconomical transactions where gas cost exceeds swap value. |
| Maximum Swap Size (USDT) | Q_max_USDT | 250 000.00 USDT | Per-transaction cap on USDT input. Larger orders must be split across multiple transactions or routed through the OTC desk. |
| Precision (USDT) | Ï_USDT | 6 decimals | Decimal precision for USDT arithmetic inside the engine. Matches TRC-20 USDT's native 6-decimal representation on TRON. |
| Precision (TRX) | Ï_TRX | 6 decimals | Decimal precision for TRX arithmetic. Uses 6-decimal SUN representation consistent with TRON's native currency precision. |
| Gas Reserve Multiplier | γ_mult | 1.35x | Multiplier applied to the estimated gas requirement when funding the gas reserve wallet. Provides a 35% buffer above network-estimated cost. |
| Retry Attempts | R_max | 3 | Maximum number of automatic retries for a failed swap before returning funds to the user. Each retry increments the gas fee by 18%. |
| Retry Backoff Interval | B_retry | 2.5 s | Delay between consecutive retry attempts. Allows pending transactions to resolve before re-submission. |
| Quote Refresh Interval | I_quote | 2.0 s | How frequently the engine fetches a fresh exchange rate from liquidity sources. Rates are served from cache between refresh cycles. |
| Slippage Tolerance (Default) | S_default | 0.50 % | Default maximum acceptable price movement between quote and execution. User-adjustable in 0.05% increments up to 5.00%. |
Order Routing Logic
Every swap entering the Velox engine is evaluated against a routing decision tree. The engine selects the optimal execution path based on order size, current liquidity depth, and network congestion at the moment of submission.
Liquidity Pool Assessment
The engine queries on-chain TRC-20 liquidity pools (SunSwap, JustSwap) and Velox's own aggregated reserves. The route with the deepest liquidity at the best effective rate is selected. If depth is insufficient for the requested size, the order is split proportionally across multiple venues.
Congestion-Aware Gas Pricing
Before submission, the engine samples the TRON mempool for pending transaction density. It applies the gas reserve multiplier (γ_mult = 1.35x) on top of the network's current median fee, ensuring the swap confirms within the 2.8-second average window even during peak traffic.
Atomic Execution & Fallback
All legs of a swap execute within a single atomic transaction. If any leg fails — due to insufficient liquidity, rate drift beyond slippage tolerance, or network error — the entire transaction is reverted. The engine then retries up to R_max times with the configured backoff interval before returning funds.
Precision & Operational Limits
Precision and limit parameters define the boundaries within which the engine operates safely. These constraints prevent integer overflow in fixed-point arithmetic, protect against dust attacks, and ensure each swap remains economically sensible for both the user and the protocol.
Arithmetic Precision
All internal calculations use 18-decimal fixed-point representation regardless of the token's native precision. This prevents rounding artifacts when computing exchange rates with small input amounts. The final output is truncated to the token's native decimal count (6 for both USDT and TRX).
Rate Precision
Exchange rates are stored with 8 decimal places of precision internally. When displayed to the user, rates are rounded to 4 decimal places. The 4 hidden digits of precision absorb minor price movements during the 15-second lock window without triggering slippage rejection.
Throughput Ceiling
The engine is rate-limited to 50 concurrent swaps in-flight at any moment. Swaps beyond this count are queued in FIFO order and processed as in-flight slots free up. The queue has a hard timeout of 30 seconds — queued orders that are not assigned a slot within that window are rejected gracefully.
Timelock Governance
Any parameter change requires a governance proposal, a 72-hour mandatory timelock, and an on-chain event emission. During the timelock, all parameter changes are visible on TronScan. Users can inspect pending changes and adjust their positions before they take effect.