An automatic system for detecting and recording liquidity price differences across different blockchain versions

Abstract

An automatic system for detecting and recording liquidity price differences across multiple blockchain versions, characterized in that it comprises the following components electrically interconnected along the data flow: a secure access gateway for filtering and distributing external JSON-RPC traffic; an event listener node for real-time capture of on-chain events from decentralized exchanges; a state replication processor for replicating the state of multi-version liquidity pools in local shared memory; a slippage evaluation accelerator consisting of an FPGA or GPU hardware card for evaluating slippage in cross-tick swaps in constant time; a path search processor to perform arbitrage path search and yield evaluation in milliseconds; an atomic execution node for bundling and submitting arbitrage transactions for execution in the same block.

Description

Technical field

[0001] This utility model application concerns the field of blockchain networks and decentralized finance (DeFi). In particular, it concerns a system for automatically detecting and recording liquidity price differences between different versions of blockchains. Background technology

[0002] Arbitrage bots typically use scripting languages ​​such as Python, JavaScript, or Golang. They call public RPC nodes or third-party APIs and poll event logs such as swap, mint, or burn. They then use simplified mathematical models to calculate price differences during individual jumps and execute corresponding transactions. However, this method encounters structural bottlenecks during high-frequency market fluctuations: Polling-based scanning requires page-by-page scanning of blocks or logs. Network round trips and JSON parsing often take several hundred milliseconds to several seconds. This causes the local state to lag behind the on-chain price movement, missing short-term arbitrage opportunities—in the worst case, slippage can even erode potential profits.

[0003] Furthermore, the segmented model of concentrated liquidity ("ticks") used by Uniswap v3 makes it difficult to calculate nonlinear price curves with high precision within millisecond response times – a balance between efficiency and accuracy is hardly achievable. Existing solutions either simulate step-by-step price calculations directly on-chain, which is associated with high call costs and limited throughput, or rely on simple linear approximations. The former are inefficient and scale poorly, while the latter lead to significant deviations, particularly at the edges of concentrated liquidity areas – often resulting in the unavailability of supposed arbitrage opportunities ("pseudo-arbitrage").

[0004] At the same time, in scenarios with cross-version (v2 / v3) and multi-stage paths, the number of possible cyclic combinations grows exponentially. Conventional traversal algorithms such as Bellman-Ford or depth-first search (DFS) reach their limits and cannot meet the requirements of real-time search. The resulting "path explosion" leads to potentially profitable compound opportunities being truncated or overlooked.

[0005] More critically, even if a profitable forward trading path is identified without atomic bundling of arbitrage and price imbalance transactions within the same block, the profits can easily be intercepted by MEV snaders. Existing script-based bots lack a holistic mechanism for latency compression and atomic execution, ranging from on-chain event monitoring, path discovery, and signature generation to bundling and submitting the transactions. This prevents a tightly coupled arbitrage cycle of "detection-decision-execution," further limiting the actual return and success rate.

[0006] The problems encountered in previous technology, such as delayed synchronization, high computational complexity, path explosion, and the lack of atomic bundling in transaction processing, represent precisely the technical bottlenecks that the present invention aims to overcome. Disclosure of the invention

[0007] The present utility model invention aims to develop an end-to-end arbitrage framework for Uniswap with cross-version compatibility and millisecond response time to address the above-mentioned technical weaknesses.

[0008] The present utility model invention relates to a system for automatically detecting and recording liquidity price differences across different versions of blockchains. The system comprises components electrically connected in the direction of data flow:

[0009] Secure access gateway used to filter and distribute external JSON-RPC data streams;

[0010] Event listener node that captures on-chain events from decentralized exchanges in real time;

[0011] State replication processor that replicates the state of multi-version liquidity pools in local shared memory;

[0012] Slippage evaluation accelerator, consisting of an FPGA or GPU hardware card, used for constant-time evaluation of slippage in cross-tick swaps;

[0013] Path search processor that performs arbitrage path search and profit evaluation within milliseconds;

[0014] Atomic execution node that bundles arbitrage trades and submits them for execution in the same block.

[0015] Furthermore, the secure access gateway consists of a firewall and a load balancer on Layer 4 / 7 and supports the gradual switching of data traffic (Grey Release / Canary Deployment).

[0016] Furthermore, the event listener node consists of several lightweight Ethereum full node servers that capture the swap, mint, burn, and collect events in real time via the eth_subscribe channels logs and newHeads.

[0017] Furthermore, a replication engine implemented in C++ runs inside the state replication processor, which replicates the storage of the triple (reserve0, reservel, k) for v2 liquidity pools and, for v3 liquidity pools, additionally the sqrtPriceX96 values ​​and liquidity snapshots of all initialized ticks.

[0018] Furthermore, the slippage evaluation accelerator is directly connected to the state replication processor via PCIe and uses a linear regression model or a piecewise quadratic regression model to enable constant runtime evaluation with O(1).

[0019] Furthermore, the path search processor uses a NUMA-optimized, lock-free ring buffer queue and executes an optimized version of the SPFA algorithm, with a single search pass taking only 2-3 milliseconds in a 16-core CPU environment.

[0020] Furthermore, when a negative cycle is detected, the path search processor updates the dynamic profit threshold τ (t) = µ 100 + k · σ 100 , online with each new block.

[0021] Where µ 100 , σ 100The average or standard deviation of the net profit over a window of the last 100 blocks, and k ranges from 0.5 to 1.0. The threshold is updated online with each new block.

[0022] Furthermore, the atomic execution node performs the bundling and signing of transactions via the Flashbots private RPC interface, so that the arbitrage path and the triggering transaction are bundled into the same block. The total delay remains within a single block cycle.

[0023] With the approach described above, the present utility model invention achieves the following advantageous effects:

[0024] On-chain events are converted into Redis streams via a self-developed listener, keeping the block synchronization delay at approximately 50 ms. Thanks to the improved SPFA algorithm combined with multi-core parallel processing, the full graph search across more than 500 active liquidity pools remains stable at 2-5 ms. The entire process, from discovery to decision-making to transaction bundling, is completed within a single block cycle—an order of magnitude faster than traditional script-based bots.

[0025] Uniswap v3 uses a constant-term linear or piecewise quadratic regression method for cross-tick slippage estimation, limiting the off-chain estimation error to ≤0.3%. Combined with a dynamically updated profit threshold, this effectively filters out spurious arbitrage opportunities caused by gas fees or slippage, significantly improving the true return.

[0026] A unified interface simultaneously manages both v2 constant product pools and v3 concentrated liquidity pools, enabling the search for cross-version, multi-hop cycles within the same graph. This allows for approximately 30–40% more cyclical arbitrage opportunities to be identified compared to single-version bots.

[0027] The system is implemented in modern C++20 using NUMA-optimized, lock-free data structures and can already track several thousand liquidity pools on a single 16-core server. Cross-chain expansion simply requires the loading of new AMM plugins without rewriting the core code, significantly reducing hardware and maintenance costs compared to an interpreted implementation.

[0028] In summary, the present invention simultaneously optimizes the tradable profit rate, the execution success rate, and the operating costs through a four-stage closed loop of “millisecond synchronization + millisecond path search + precise pricing + atomic execution,” thus creating a holistic, difficult-to-replicate barrier to competition. Description of the drawings Fig. shows a schematic representation of the physical deployment architecture of the present utility model invention. Fig. shows a schematic flow diagram of the algorithm of this utility model application. Examples of implementation

[0029] In the following, a preferred embodiment of the system proposed in the present utility model for automatically detecting and recording liquidity price differences across different blockchain versions is explained in detail with reference to the drawings.

[0030] The illustrated examples serve only to explain the present utility model and do not represent a limitation of the scope of protection.

[0031] As in Fig.As shown, the present utility model proposes a system for automatically detecting and recording liquidity price differences across different blockchain versions, consisting of an on-chain data capture and a status mirroring layer;

[0032] The system includes a firewall and load balancers; external on-chain JSON-RPC traffic first passes through the firewall and is then forwarded to the backend listener nodes via a Layer 4 or Layer 7 load balancer. and a cluster of RPC listener servers;

[0033] The system runs lightweight Ethereum nodes locally and subscribes directly to the eth_subscribe channels for logs and newHeads via its own RPC listeners.

[0034] The listeners capture key events such as swap, mint, burn, and collect (v3) in real time and convert them into atomic updates such as trading pair addresses, reserve changes, and tick interval shifts.

[0035] As well as a Redis cluster, where all events are written to Redis streams after encoding and sorted by block height, allowing backend consumers to play the events sequentially while avoiding state splits caused by block rollbacks.

[0036] The primary node writes while the replica nodes copy in real time to ensure high availability.

[0037] Local replication and pricing layer; Includes a cluster of local replication engines, where consumer threads reimplement Uniswap v2 / v3 logic in C++ to replicate events one by one and maintain a pool state table in shared memory;

[0038] For v2 pools, a triple of (reserve0, reservel, k) is used, while v3 pools additionally store sqrtPriceX96 as well as liquidity snapshots for each initialized tick to ensure byte-accurate compliance with the on-chain math model.

[0039] and a slippage estimation module (hardware accelerator card) designed for efficient processing of v3 cross-tick swaps in millisecond scenarios; the present utility model invention uses offline-fitted linear regression or piecewise quadratic regression models to approximate cumulative slippage.

[0040] Specifically, for the local high-frequency estimation of the actual slippage and fees of a swap, the price determination process of v2 and v3 is uniformly abstracted in this invention as follows: outAmount=f(inAmount, s) where s denotes the state of the liquidity pool and inAmount represents the amount of tokens contributed to this swap;

[0041] For v2, f(x, s) is equivalent to the classical constant product formula: f(x, s)=(1−Y)y Δxx+Δx, Where (x, y) represent the current reserves of both sides, Δx = inAmount, γ is the fee rate;

[0042] For v3, if the input amount is within a single tick interval, the official exact formula is applied (Uniswap v3 Whitepaper § 4.2).

[0043] If multiple ticks need to be exceeded, the cumulative estimation of slippage is performed using linear regression or piecewise quadratic approximation, with a computational complexity of O(1) and an off-chain error of ≤ 0.3%.

[0044] This approximation logic is implemented in FPGA or GPU accelerator cards and connected directly to the engine node via PCIe.

[0045] Path search and profit evaluation layer;

[0046] Includes a cluster for finding negative circles for arbitrage; the system models the entire DEX liquidity network as a weighted, directed graph G(V,E); nodes V are token contract addresses, and edges E represent tradable paths.

[0047] Specifically, the search node is based on C++20 and a NUMA-aware, lock-free ring buffer implementation; the seed set is partitioned into hash buckets and mapped to the cores of the local NUMA node, while only the reduced candidates of negative circles are exchanged between nodes, significantly reducing cache coherence disruptions.

[0048] On a 16-core CPU, the runtime of a single search round is stable at 2 - 3 ms and can be scaled horizontally to 64 cores, maintaining a linear acceleration in the sub-millisecond range.

[0049] Using a hierarchical queue, path pruning, and batch-parallel, improved SPFA algorithm, profitable paths are found in 2-5 ms for a pool size of over 500.

[0050] After detecting negative circles, the system immediately recalculates the net profit, taking into account real costs (including gas, commission, and flashbots fees) and compares it with the dynamic threshold τ(t) to avoid gas-wasting low-value transactions;

[0051] Specifically, the dynamic threshold τ (t) is determined according to the formula τ (t)= µ 100 + k · σ 100 set.

[0052] Where µ 100 , σ 100 The mean or standard deviation of the net profit in the window of the last 100 blocks. The parameter k is typically chosen between 0.5 and 1.0. The threshold is updated online with each new block, so the limit automatically increases or decreases depending on network load.

[0053] The atomic execution layer includes Flashbots execution nodes that perform transaction bundling, signing, and dispatch internally via a private RPC tunnel or a direct Flashbots interface to ensure that the arbitrage path and the triggering transactions are packaged in the same block. Typical process:

[0054] The search node creates a bundle → signing → Flashbots Relay → block proposer, keeping the total latency within a single block cycle. Operational and monitoring layer

[0055] Includes a centralized log platform (ELK) that unifies the operational logs of engine, search, and execution nodes into Elasticsearch using Filebeat; Kibana provides search and visualization capabilities.

[0056] As well as monitoring and alarm systems (Prometheus / Grafana) that capture over 100 metrics such as CPU utilization, memory, QPS, and synchronization delay; Alert Manager sends alarms when thresholds are exceeded.

[0057] The Operations Console terminal provides administrators with access to the operations network via VPN. There, they can adjust parameters such as unified pricing and constant time approximation of v3 slippage online, as well as review historical logs.

[0058] This embodiment utilizes a five-stage closed-loop process of "event stream mirroring → state replication → constant-time evaluation → millisecond negative-loop search → Flashbot's atomic execution" to compress the entire process of "data synchronization → path discovery → transaction initiation" within a single block cycle (≈ 12 seconds). This effectively overcomes blockchain delays, path explosions, and MEV competition, significantly improving the efficiency of arbitrage detection across different DEX versions. Any equivalent changes to component deployment, hardware implementation, or algorithm details that do not depart from the core principle of the present invention are also within the scope of this utility model.

Claims

[1] An automatic system for detecting and recording liquidity price differences across multiple blockchain versions, characterized by that it comprises the following components electrically connected along the data flow: a secure access gateway for filtering and distributing external JSON-RPC traffic; an event listener node for real-time capture of on-chain events from decentralized exchanges; a state replication processor for replicating the state of multi-version liquidity pools in local shared memory; a slippage evaluation accelerator consisting of an FPGA or GPU hardware card for evaluating slippage in cross-tick swaps in constant time; a path search processor to perform arbitrage path search and yield evaluation in milliseconds; an atomic execution node for bundling and submitting arbitrage transactions for execution in the same block. [2] The system for automatically detecting and recording liquidity price differences across multiple blockchain versions according to claim 1, characterized by that the secure access gateway consists of a firewall and a Layer 4 / Layer 7 load balancer and supports grayscale traffic switching. [3] The system for automatically detecting and recording liquidity price differences across multiple blockchain versions according to claim 1, characterized by that the event listener node consists of several lightweight Ethereum full nodes that capture swap, mint, burn, and collect events in real time via the eth_subscribe logs and newHeads channels. [4] The system for automatically detecting and recording liquidity price differences across multiple blockchain versions according to claim 1, characterized bythat the state replication processor uses an internally running C++ replication engine, which stores the triple (reserve0, reserve1, k) for Uniswap v2 pools and additionally sqrtPriceX96 and liquidity snapshots of the respectively initialized ticks for v3 pools. [5] The system for automatically detecting and recording liquidity price differences across multiple blockchain versions according to claim 1, characterized by that the slippage evaluation accelerator is directly connected to the state replication processor via PCIe and achieves a constant runtime O(1) for the evaluation using linear regression or segmented quadratic regression. [6] The system for automatically detecting and recording liquidity price differences across multiple blockchain versions according to claim 1 or 5, characterized bythat the path search processor uses a NUMA-aware, waitless ring buffer queue and executes an improved SPFA algorithm, with a single search round taking 2 - 3 ms in a 16-core CPU environment. [7] The system for automatically detecting and recording liquidity price differences across multiple blockchain versions according to claim 1, characterized by that the path search processor, upon detection of a negative cycle, based on the dynamic profit threshold τ (t)= µ 100 + k · σ 100 , updates the threshold online with each new block; where µ 100 , σ 100 represent the mean or standard deviation of the net profit over the window of the last 100 blocks, and k empirically lies in the range of 0.5 to 1.

0. [8] The system for automatically detecting and recording liquidity price differences across multiple blockchain versions according to claim 1, characterized bythat the atomic execution node performs transaction bundling and signing via a private Flashbots RPC interface, bundling the arbitrage path and the triggering transaction in the same block, keeping the overall latency within a single block period

Images