Dynamic execution method and device of on-chain resource transaction, electronic equipment and product

Abstract

The embodiment of the invention is suitable for the field of block chains, and provides a dynamic execution method and device for on-chain resource transaction, electronic equipment and a product, and the method comprises the steps: obtaining a resource transaction request submitted by a user on a chain; the resource transaction request comprises a first object to be transacted, a transaction resource and a second object expected to be transacted; obtaining on-chain transaction information; the on-chain transaction information is used for describing on-chain dynamic working conditions when the first object and the second object are transacted; dynamically generating a time weighting curve according to the on-chain transaction information; the time weighted curve comprises a time window, a plurality of transaction time points in the time window, and resource transaction volumes corresponding to the plurality of transaction time points respectively; and executing the resource transaction request based on the time weighted curve, and completing the on-chain transaction of the transaction resource. By adopting the method, the unpredictability of transaction execution can be improved to inhibit external arbitrage behaviors, and the on-chain resource configuration efficiency and the transaction success rate are optimized.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, and in particular relates to a dynamic execution method, device, electronic device and product for on-chain resource transactions. Background Technology

[0002] In the field of blockchain technology, the matching mechanism for on-chain resource transactions mainly relies on liquidity pools to realize the automatic exchange and circulation of resources. Time-weighted execution strategies are widely used as a core means to reduce the impact of transactions on resource value.

[0003] In existing technologies, time-weighted execution of on-chain transactions typically employs a time-weighted curve with fixed parameters. This means that core parameters such as the time window for transaction splitting and the proportion of transaction volume allocation at each time point are pre-set, and the curve shape and execution rhythm remain unchanged throughout the entire execution process.

[0004] However, the execution process of this fixed-time weighted curve method is highly predictable, making it susceptible to manipulation and arbitrage by external programs. Specifically, the parameters of the fixed-time weighted curve are highly transparent, allowing external programs (such as MEV bots and arbitrage scripts) to accurately predict key information such as the execution time of transactions and the distribution patterns of transaction volume by analyzing the preset rules of the curve. Furthermore, by manipulating the order of transaction submissions and exploiting differences in block packaging timing, related operations can be performed before and after the execution of the target transaction to achieve targeted arbitrage. In other words, existing transaction execution methods have the problem of being unable to suppress predictable arbitrage behavior. Summary of the Invention

[0005] This application provides a method, apparatus, electronic device, and product for the dynamic execution of on-chain resource transactions, which can solve the problem that existing transaction execution methods cannot suppress foreseeable arbitrage behavior.

[0006] Firstly, embodiments of this application provide a dynamic execution method for on-chain resource transactions, the method comprising: Retrieve resource transaction requests submitted by users on-chain; resource transaction requests include a first object to be traded, the resource to be traded, and a second object to be traded. Obtain on-chain transaction information; on-chain transaction information is used to describe the dynamic on-chain status when the first object and the second object conduct a transaction. A time-weighted curve is dynamically generated based on on-chain transaction information; the time-weighted curve includes a time window, multiple transaction time points within the time window, and the resource transaction volume corresponding to each of the multiple transaction time points. Execute resource transaction requests based on time-weighted curves to complete on-chain transactions of the traded resources.

[0007] Secondly, embodiments of this application provide a dynamic execution device for on-chain resource transactions, the device comprising: The first acquisition module is used to acquire resource transaction requests submitted by users on the chain; the resource transaction request includes a first object to be traded, the resource to be traded, and a second object to be traded. The second acquisition module is used to acquire on-chain transaction information; the on-chain transaction information is used to describe the dynamic on-chain conditions when the first object and the second object conduct a transaction. The generation module is used to dynamically generate time-weighted curves based on on-chain transaction information. The time-weighted curve includes a time window, multiple transaction time points within the time window, and the resource transaction volume corresponding to each of the multiple transaction time points. The first execution module is used to execute resource transaction requests based on the time-weighted curve and complete the on-chain transaction of the transaction resources.

[0008] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect above.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0010] Fifthly, embodiments of this application provide a computer program product that, when run on an electronic device, causes the electronic device to execute the method described in the first aspect.

[0011] The beneficial effects of this application's embodiments compared to existing technologies are as follows: By acquiring the first object, transaction resource, and second object in a user's on-chain resource transaction request, the transaction requirements can be clearly defined. Subsequently, by collecting on-chain transaction information describing the dynamic on-chain conditions of both parties, real-time data support can be provided for adjusting the transaction strategy based on the dynamic on-chain conditions, avoiding the limitations of information lag in traditional fixed execution models. Furthermore, by dynamically generating a time-weighted curve containing time windows, transaction time points, and corresponding resource transaction volumes based on real-time on-chain transaction information, dynamic adaptation of the transaction strategy to the on-chain conditions can be achieved, avoiding the rigidity of fixed curves in response to market changes. Finally, executing transactions according to this time-weighted curve, by splitting the transaction rhythm and transaction volume, can not only reduce the price impact of large-scale digital resource transactions on the market to reduce slippage and protect user profits, but also improve the unpredictability of transaction execution to suppress external arbitrage behavior, optimizing on-chain resource allocation efficiency and transaction success rate. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart illustrating the implementation of a dynamic execution method for on-chain resource transactions according to an embodiment of this application; Figure 2 This is a flowchart illustrating the implementation of a dynamic execution method for on-chain resource transactions according to another embodiment of this application; Figure 3 This is a schematic diagram illustrating an implementation method for generating a time-weighted curve in a dynamic execution method for on-chain resource transactions provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating one implementation method for generating a time-weighted curve in a dynamic execution method for on-chain resource transactions provided in another embodiment of this application; Figure 5 This is a schematic diagram illustrating one implementation method of executing on-chain transactions in a dynamic execution method for on-chain resource transactions provided in an embodiment of this application; Figure 6 This is a schematic diagram illustrating one implementation method of executing on-chain transactions in a dynamic execution method for on-chain resource transactions provided in another embodiment of this application; Figure 7 This is a schematic diagram illustrating one implementation of an on-chain transaction execution method in a dynamic execution method for on-chain resource transactions provided in another embodiment of this application; Figure 8 This is a schematic diagram of the structure of a dynamic execution device for on-chain resource transactions provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0014] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0015] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0016] It should be noted that the information collection process (such as patient information collection process, physiological information collection process, etc.) / feature extraction process involved in this application is carried out with the user's knowledge and permission. That is, the information collection process / feature extraction process complies with the requirements of laws and regulations and does not constitute an act that harms the public interest.

[0017] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0018] In the field of blockchain technology, the matching mechanism for on-chain resource transactions mainly relies on liquidity pools to realize the automatic exchange and circulation of resources. Time-weighted execution strategies are widely used as a core means to reduce the impact of a large number of digital resource transactions on the value of resources.

[0019] In existing technologies, time-weighted execution of on-chain transactions typically employs a time-weighted curve with fixed parameters. This means that core parameters such as the time window for transaction splitting and the proportion of transaction volume allocation at each time point are pre-set, and the curve shape and execution rhythm remain unchanged throughout the entire execution process.

[0020] However, the execution process of this fixed-time weighted curve method is highly predictable, making it susceptible to manipulation and arbitrage by external programs. Specifically, the parameters of the fixed-time weighted curve are highly transparent, allowing external programs (such as MEV bots and arbitrage scripts) to accurately predict key information such as the execution time of transactions and the distribution patterns of transaction volume by analyzing the preset rules of the curve. Furthermore, by manipulating the order of transaction submissions and exploiting differences in block packaging timing, related operations can be performed before and after the execution of the target transaction to achieve targeted arbitrage. In other words, existing transaction execution methods have the problem of being unable to suppress predictable arbitrage behavior.

[0021] Based on this, in order to suppress foreseeable arbitrage behavior during the transaction process, this application provides a dynamic execution method for on-chain resource transactions. This method can be applied to electronic devices such as tablets, laptops, ultra-mobile personal computers (UMPCs), and netbooks. This application does not impose any restrictions on the specific type of electronic device.

[0022] Please see Figure 1 , Figure 1The diagram illustrates an implementation flowchart of a dynamic execution method for on-chain resource transactions provided in an embodiment of this application. The method includes the following steps: S101. Obtain the resource transaction request submitted by the user on the chain.

[0023] The aforementioned resource transaction request includes a first object to be traded, the resource to be traded, and a second object to be traded.

[0024] In one embodiment, the aforementioned resource transaction request refers to a formal transaction instruction submitted by a user in the blockchain network to realize the exchange or transfer of specific transaction resources, and is the input that triggers the on-chain transaction execution process.

[0025] The aforementioned transaction resources refer to the quantified quantity of the first object actually exchanged when a user initiates a transaction. These resources are typically clearly labeled with their smallest or standard unit and are used to calculate the ratio of transaction volume to available resources in the liquidity pool, and to allocate execution amounts at various transaction points in time. For example, when a user exchanges 10 units of digital resource A for digital resource B, "10 units of digital resource A" constitutes the transaction resource.

[0026] The aforementioned transaction resources include, but are not limited to, data resources, on-chain service rights resources, and digital resources, etc., and are not limited thereto. In this embodiment, taking digital resources as an example, the aforementioned available resource information may include: Digital resource type: digital certificate resources, digital copyright resources, etc.; Resource quantity: the specific quantity of this type of digital resource held by the user; Chain identifier: a marker that distinguishes the corresponding chain of the digital resource; Real-time value: the current value of the digital resource.

[0027] The first object mentioned above refers to the underlying asset corresponding to the user's existing resource to be traded. It is the resource being transferred out in the transaction, typically a specific digital resource within the blockchain network. Its resource identifier (such as contract address or resource ID) needs to be clearly identified to locate the corresponding liquidity pool. For example, when a user plans to exchange digital resource A for digital resource B, digital resource A is the first object.

[0028] The second object mentioned above refers to the target resource that the user hopes to acquire through the transaction. It is the resource to be transferred in the transaction and forms a trading pair with the first object. Similarly, its resource identifier must be clearly defined to match the liquidity pool supporting the trading pair. For example, when a user plans to exchange digital resource A for digital resource B, digital resource B is the second object.

[0029] In one embodiment, the electronic device can achieve this by listening to transaction broadcast events on the blockchain network or by connecting to the transaction triggering interface of a smart contract. For example, it can capture encrypted transaction data packets sent by users to the transaction pool, decrypt and parse the format, and extract the transaction intent-related fields to form structured resource transaction request data.

[0030] S102, Obtain on-chain transaction information.

[0031] The aforementioned on-chain transaction information is used to describe the dynamic on-chain conditions when the first object and the second object conduct a transaction.

[0032] In one embodiment, the aforementioned on-chain transaction information is a data set reflecting the dynamic on-chain conditions during the transaction between the first and second objects. This includes, but is not limited to, price liquidity information affecting transaction slippage and execution (e.g., price volatility, liquidity pool depth), network operation information affecting transaction execution efficiency and cost (e.g., on-chain transaction fees, block intervals), and transaction execution information affecting transaction success rate (e.g., transaction confirmation speed, smart contract status). In this embodiment, the on-chain transaction information is not limited.

[0033] It should be noted that, in this embodiment, "operating condition" refers to the real-time dynamic operating state of the blockchain network system during the process of supporting transaction execution, which is directly related to the transaction behavior of the first and second objects.

[0034] The electronic devices can obtain the information directly by connecting to the blockchain node or by calling the smart contract interface; there are no restrictions on this. For example, for the trading pair corresponding to the first and second objects (such as a liquidity pool contract or a DEX trading contract), the read-only interface (View function) of the contract can be called directly to obtain the aforementioned on-chain transaction information.

[0035] S103. Dynamically generate time-weighted curves based on on-chain transaction information.

[0036] The time-weighted curve includes a time window, multiple transaction points within the time window, and the resource transaction volume corresponding to each of the multiple transaction points.

[0037] In one embodiment, the aforementioned time-weighted curve is a visualized / data-driven execution scheme for on-chain resource transactions, dynamically allocating the execution rhythm and volume of transactions based on time. The time-weighted curve binds time to resource transaction volume, splitting transaction behavior within a preset time period (e.g., the aforementioned time window) to avoid the market impact of a single large-scale digital resource transaction. Simultaneously, it adjusts the curve shape (such as slope, peak position, and transaction point density) according to real-time on-chain conditions, achieving the goal of adapting to the environment and optimizing transactions, rather than employing a fixed execution strategy.

[0038] The aforementioned time window represents the total transaction execution cycle corresponding to the time-weighted curve, i.e., the complete time interval from the initiation of the first split transaction to the completion of the last split transaction. Its duration is not a fixed value: a base duration can be preset (such as 1 hour or 4 hours), or it can be dynamically adjusted based on on-chain transaction information (for example, extending the time window when there is on-chain congestion and shortening it when there is sufficient liquidity). It serves as the basic time framework for split transaction timing and transaction volume allocation.

[0039] The aforementioned transaction time points are the specific moments within a time window when a single split transaction is executed, representing discrete execution nodes on the time-weighted curve. For example, within a 1-hour time window, 6 transaction time points can be set (one every 10 minutes), or the node density can be dynamically adjusted based on on-chain conditions (e.g., increasing the number of time points to one every 5 minutes when liquidity is tight). Each time point corresponds to an independent on-chain transaction operation, and its intervals and distribution are determined by the curve shape.

[0040] The resource transaction volume mentioned above refers to the specific digital resource quantity corresponding to each transaction time point, that is, the quantified value of the resources actually executed on the chain at that moment, which is the quantified dimension of the time-weighted curve. The sum of the resource transaction volume at all transaction time points is equal to the total transaction resources to be executed this time (or the remaining transaction resources), and its allocation ratio is determined by the on-chain transaction information (e.g., allocating a high proportion in the early stage to achieve rapid execution, or distributing evenly to reduce impact).

[0041] In one embodiment, when generating the time-weighted curve, the constraints can be defined in advance. For example, the total number of transaction resources to be executed (e.g., 100 units of digital resource A) and the base duration of the time window (e.g., a preset 1 hour) are not limited.

[0042] The on-chain transaction information quantification process standardizes and quantifies the acquired on-chain transaction information (price volatility, liquidity pool depth, gas fees, etc.) to determine the threshold ranges for each indicator. At this point, electronic devices can match curve parameters and shapes to dynamically adjust the core parameters of the curve (time window duration, number / interval of transaction time points, and percentage of transaction volume at each time point) based on the quantified on-chain transaction information, forming a curve with the corresponding shape. That is, a time-weighted curve.

[0043] For example, if the on-chain transaction information meets the conditions of low volatility and sufficient liquidity, the time window is shortened to 30 minutes, and a small number of transaction time points are set (e.g., 3). In the early stage, 70% of the transaction resources are allocated to each transaction time point (for rapid and concentrated execution), and in the later stage, 30% of the transaction resources are allocated to each transaction time point (for a smooth conclusion).

[0044] S104. Execute resource transaction requests based on time-weighted curves to complete on-chain transactions of the traded resources.

[0045] In one embodiment, an on-chain transaction refers to a transaction in a blockchain network that transfers ownership of digital resources (or on-chain resources) through cryptographic algorithm verification and node consensus confirmation. This transaction is characterized by transparency and irreversibility, which will not be described in detail here.

[0046] In one embodiment, the electronic device can monitor the time progress in real time. When a certain transaction time point marked on the time-weighted curve is reached, it automatically generates a corresponding number of on-chain transaction instructions. These on-chain transaction instructions clearly specify the resource identifiers of the first and second objects, as well as the resource transaction volume at that time point. A reasonable transaction fee is set based on the current on-chain gas fee situation. The transaction instructions are broadcast to the blockchain network through a smart contract interface. Transaction confirmation and status synchronization await blockchain nodes to package the transaction. If the transaction is successfully written into a block and confirmed (usually requiring a preset number of confirmed blocks, such as 1-3 blocks), the completion status, actual transaction price, slippage, and other data at that time point are recorded. If the transaction fails due to network congestion, insufficient gas fees, or other reasons, the electronic device can perform a retry operation according to a preset retry strategy (such as retrying twice within 10 minutes, or retrying after adjusting the fee). If the retry fails, manual intervention or transaction splitting and adjustment is triggered. Once the transaction at the last transaction time point is confirmed, the electronic device can aggregate the actual transaction data from all transaction time points, verify whether the total transaction volume equals the transaction resources to be executed (allowing for minor errors, such as ±0.1%), and calculate indicators such as overall transaction slippage and average execution cost. It then generates a transaction execution report and provides it to the user, thus completing the entire transaction process.

[0047] In this embodiment, by acquiring the first object, the transaction resource, and the second object from the user's on-chain resource transaction request, the transaction requirements can be clearly defined. Then, by collecting on-chain transaction information describing the dynamic on-chain conditions of both parties, real-time data support can be provided for adjusting the transaction strategy based on the dynamic on-chain conditions, avoiding the limitations of information lag in traditional fixed execution models. Furthermore, by dynamically generating a time-weighted curve containing time windows, transaction time points, and corresponding resource transaction volumes based on real-time on-chain transaction information, dynamic adaptation of the transaction strategy to the on-chain conditions can be achieved, avoiding the rigidity of fixed curves that cannot cope with market changes. Finally, the transaction is executed according to this time-weighted curve. By splitting the transaction rhythm and transaction volume, not only can the price impact of large-scale digital resource transactions on the market be reduced to decrease slippage and protect user profits, but the unpredictability of transaction execution can also be improved to suppress external arbitrage behavior, optimizing on-chain resource allocation efficiency and transaction success rate.

[0048] In another embodiment, it should be noted that if all transactions are executed based on a time-weighted curve, when transaction resources are limited, multiple on-chain transaction fees (Gas fees) may be generated due to the forced splitting of transactions into multiple transaction time points. Furthermore, the cumulative slippage of the split small transactions may be higher than that of a single instant transaction.

[0049] Therefore, in order to balance the convenience of short-term resource transactions with the security and stability of long-term resource transactions, electronic devices can be configured to... Figure 2 The steps S201-S203 shown represent on-chain transactions. Details are as follows: S201. Calculate the ratio of trading resources to available resources in the liquidity pool.

[0050] The aforementioned liquidity pool is a trading pool that supports transactions between the first and second objects.

[0051] In one embodiment, the aforementioned liquidity pool is a resource reserve pool in the blockchain that is hosted by a smart contract and is specifically used to support the exchange and circulation of specific resource trading pairs (i.e., the trading pair consisting of the first object and the second object mentioned above).

[0052] The aforementioned liquidity pool consists of resources from a first object and resources from a second object stored in pairs. When a user initiates an exchange transaction for this trading pair, they can interact with the liquidity pool for resources, rather than engaging in traditional peer-to-peer transactions.

[0053] This involves determining the total amount of resources (i.e., available resources) in the liquidity pool that are currently available for trading in the first or second object, and simultaneously determining the quantitative amount of trading resources initiated by the user. Based on the ratio of these two factors, the scale of the transaction can be quantified.

[0054] S202. If the ratio is less than the first preset ratio, the resource transaction request will be executed using the immediate transaction execution method to complete the transaction of all resources.

[0055] In one embodiment, the first preset ratio is a threshold used to classify the impact of transaction size on the liquidity pool. It can be preset according to factors such as the daily transaction volume of the liquidity pool, resource volatility characteristics, and market stability requirements (for example, the value range of the first preset ratio can be 5% to 10%).

[0056] The aforementioned instant transaction execution method is a transaction model that contrasts with time-weighted curve execution. It refers to an execution method that does not split transaction resources or set multiple execution plans at different times. Instead, it broadcasts all transaction resources as a single transaction instruction to the blockchain network at once, completing the transaction instantly based on the available resources in the current liquidity pool. Typically, this transaction method does not require waiting for a time window; after the transaction instruction is submitted, it prioritizes matching with available resources in the liquidity pool or market orders, quickly completing the transfer of ownership and block confirmation.

[0057] As an example, when choosing the instant transaction execution method, the electronic device can generate a single transaction instruction containing all transaction resources, clearly specifying the resource identifiers and transaction resources of the first and second objects, setting the transaction fee according to the current on-chain transaction fees, submitting it to the blockchain network to interact with the target liquidity pool, completing resource exchange and block confirmation, and realizing the instant transaction of all transaction resources.

[0058] It should be noted that by defining whether trading resources will cause a significant price impact on the liquidity pool, when the ratio of trading resources to available resources in the liquidity pool is lower than the first preset ratio, it can be considered that the trading volume has a low degree of liquidity occupation in the pool, will not cause significant slippage, and the trading efficiency is high; otherwise, it may lead to a large price deviation.

[0059] S203. If the ratio is greater than or equal to the first preset ratio, then the transaction resources of the second preset ratio shall be executed in an instant transaction execution mode, and the steps of obtaining on-chain transaction information and subsequent steps shall be executed for the remaining transaction resources.

[0060] In one embodiment, the second preset ratio can be set according to actual needs, and there is no limitation thereto. For example, the second preset ratio can be 30%.

[0061] Specifically, when the actual ratio is greater than or equal to the first preset ratio, the electronic device can determine that the resource transaction request is a large-scale digital resource transaction request. At this time, the electronic device can complete the on-chain transaction through a two-stage execution path.

[0062] For example, in the first stage: the second preset proportion of trading resources is executed immediately. That is, the electronic device can adopt an immediate transaction execution method, prioritizing the processing of the second preset proportion of trading resources. By generating a single transaction instruction corresponding to the amount of digital resources, the transaction is quickly completed through interaction with the liquidity pool. This not only satisfies the user's immediate trading needs for a portion of the trading resources but also allows for the locking in of some trading profits in advance, avoiding additional risks from subsequent market fluctuations.

[0063] Phase Two: Dynamic Execution of Remaining Transaction Resources to Control Impact Risk. For the remaining transaction resources, electronic devices can execute step S102 above to generate a time-weighted curve. Finally, based on the time-weighted curve, transactions and transaction volumes are split to complete on-chain transactions. Furthermore, by distributing transactions, the price impact on the market from a large concentration of remaining resources is effectively reduced, slippage losses are minimized, and arbitrage activities by external programs manipulating transaction timing are suppressed.

[0064] In this embodiment, precise stratification of transaction execution methods is achieved by setting a first preset ratio and a second preset ratio. This not only allows for efficient, low-slippage, and low-fee transactions when the ratio of transaction resources to available liquidity pool resources is less than the first preset ratio, but also avoids the additional costs and time losses associated with splitting executions, meeting users' immediate needs for small-amount transactions. Furthermore, for large-scale digital resource transactions with a ratio equal to or greater than the first preset ratio, a reasonable share of immediate execution can be allocated through the second preset ratio, quickly locking in some core profits. Simultaneously, the remaining transaction resources follow the process of acquiring on-chain transaction information, generating time-weighted curves, and dynamically executing, effectively dispersing the price impact of large-scale digital resource transactions on the market, reducing slippage risk and price volatility, and suppressing external arbitrage. Therefore, this not only avoids the rigid limitations of a single execution mode, but also achieves a balance between the convenience of small-scale digital resource transactions and the security and stability of large-scale digital resource transactions, while ensuring transaction success rates and reasonable resource allocation, thus improving the cost-effectiveness of on-chain transactions and the overall user experience.

[0065] In another embodiment, the on-chain transaction information includes at least one of the following: price volatility, available resources in the liquidity pool, the ratio of transaction resources to available resources, and on-chain transaction fees; for the aforementioned time-weighted curve, the electronic device can, according to, such as Figure 3 The steps S301-S306 shown generate time-weighted curves. Details are as follows: S301. For any type of on-chain transaction information, determine the threshold range corresponding to the on-chain transaction information.

[0066] In one embodiment, the available resources and proportions have already been explained above and will not be described again.

[0067] The aforementioned price volatility refers to the degree of price fluctuation of a trading pair consisting of the first and second objects within a preset time window (such as 1 minute or 5 minutes), reflecting the stability of the trading pair. Electronic devices can quantify this volatility based on transaction price data within a specific period, using methods such as price change and standard deviation. For example, if the price of the trading pair fluctuates from 100 units of digital resource B to 105 units of digital resource B and then falls back to 102 units of digital resource B within 5 minutes, the corresponding price change range is ±5%, which can be quantified as the volatility for that period.

[0068] Typically, price volatility directly affects the risk of slippage in transactions: the higher the volatility, the more unstable the value of resources, and the greater the probability that the actual transaction price will deviate from expectations when a large number of digital resource transactions are executed in a concentrated manner. Therefore, it is necessary to adjust the execution rhythm through time-weighted curves (such as dispersing transaction time points) to avoid risks.

[0069] The on-chain transaction fees (Gas fees) mentioned above are compensation fees paid by users to network nodes for computing power consumption when initiating transactions and executing smart contracts in a blockchain network. These fees are typically positively correlated with network congestion (the more transactions to be packaged, the higher the fee), transaction complexity, and transaction data volume, and are denominated in the native token of the corresponding blockchain (e.g., Ethereum uses digital resource A for payment). On-chain transaction fees are a component of transaction execution costs. In high-fee scenarios, time-weighted curve optimization (such as extending the time window and evenly distributing transaction volume) is needed to reduce the cost per execution and avoid excessively high total fees due to frequent transaction splitting.

[0070] In one embodiment, the threshold range is a quantified range with clear boundaries defined for a single type of on-chain transaction information (such as price volatility, on-chain transaction fees, etc.), which is used to subsequently match the corresponding time-weighted curve generation strategy.

[0071] The electronic device can pre-set multiple threshold ranges corresponding to each type of on-chain transaction information. For example, regarding price volatility, the threshold ranges can be determined based on historical volatility data and a slippage control target. For instance, by analyzing the 10-minute volatility data of a target trading pair over the past 30 days, when price volatility is ≤2%, slippage is generally below 0.3% (meeting the control target); when price volatility is >5%, slippage is greater than 1% (exceeding the acceptable range). Based on this, low volatility ranges (0%~2%), medium volatility ranges (2%~5%), and high volatility ranges (>5%) can be defined.

[0072] The above is only an example of price volatility. The threshold ranges for different types of on-chain transaction information may be different, which will not be explained in detail.

[0073] S302. If the threshold range corresponding to the price volatility is the preset low volatility range, and the available resources are located in the preset resource sufficiency range, then the first time weighted curve is generated.

[0074] The time window in the aforementioned first time weighted curve is divided into a continuous first stage and a second stage. The proportion of a single transaction in the first stage is greater than that in the second stage, and the execution frequency of a single transaction in the first stage is greater than that in the second stage.

[0075] In one embodiment, the aforementioned low volatility range is a quantitative threshold range defined for price volatility, reflecting a stable price state. When the price of a transaction is within a low volatility range, market expectations are stable, and the risk of slippage due to the concentrated execution of a large number of digital resource transactions is low. Therefore, a curve strategy for rapid, concentrated execution can be adopted.

[0076] The aforementioned resource sufficiency range is a quantitative threshold range defined for the available resources in a liquidity pool, reflecting the adequacy of resource reserves within the pool. Its boundaries are typically determined based on the daily carrying capacity of the liquidity pool and transaction slippage control objectives. For example, a resource sufficiency range might be defined as a total available first or second object resource quantity ≥ 5000 standard units. Within this range, the liquidity pool's resources can be considered sufficient to support a large volume of digital resource transactions, without concern about insufficient resource reserves leading to unexecuted transactions or a surge in slippage.

[0077] The first stage mentioned above is the preceding continuous stage within the first time-weighted curve time window, and it is the main trading stage for transaction execution. Based on the favorable trading environment of low volatility range and abundant resources range, a large number of trading resources can be executed quickly to lock in the expected price and improve trading efficiency. It usually occupies the first half or the first two-thirds of the time window (such as the first 30 minutes of a 1-hour time window).

[0078] The second stage described above is the continuous stage following the first stage within the first-time weighted curve time window. It is the final adjustment stage of transaction execution, used to handle the remaining small amount of trading resources and avoid the impact of small price fluctuations that may have been caused by the concentrated trading in the first stage, thus smoothly completing all transactions. Typically, it occupies the latter half or the latter third of the time window (such as the last 30 minutes of a 1-hour time window).

[0079] The aforementioned percentage of single transaction volume refers to the percentage of resource transaction volume corresponding to a single transaction time point within a certain stage, relative to the total pending transaction resources. For example, if the total transaction resources are 100 units of digital resource A, and 30 units of digital resource A are executed at a certain transaction time point in the first stage, then the percentage of that transaction volume is 30%; if 5 units of digital resource A are executed at a certain transaction time point in the second stage, then the percentage is 5%.

[0080] The execution frequency mentioned above refers to the number of times a single transaction is executed per unit of time within a certain stage, reflecting the intensity of transaction execution. For example, if there are 5 transaction time points within 10 minutes in the first stage, the execution frequency can be 0.5 times / minute; if there are 2 transaction time points within 1 minute in the second stage, the execution frequency is 0.2 times / minute. The higher the frequency, the more intensive the transaction execution, and the faster the transaction volume can be allocated.

[0081] It should be noted that the aforementioned first-time weighted curve is a time-weighted curve adapted to the dual favorable conditions of low volatility and abundant resources. This curve is typically characterized as "faster at the beginning and slower at the end, more at the beginning and less at the end." That is, the first stage uses a high-proportion, high-frequency execution strategy to quickly lock in core profits, and then the second stage uses a low-proportion, low-frequency execution strategy to smoothly conclude the transaction, ensuring trading efficiency while minimizing price volatility risk.

[0082] In one embodiment, the electronic device can divide the time window into a first stage focusing on rapid and concentrated transaction execution and a second stage emphasizing a smooth conclusion. Then, parameters such as the number of transaction time points, the percentage of single transaction volume, and the execution frequency are set differently for each stage. For example, the first stage is configured with a larger number of transaction time points, a higher percentage of single transaction volume, and a higher execution frequency to quickly complete the execution of a large number of transaction resources. The second stage is configured with a smaller number of transaction time points, a lower percentage of single transaction volume, and a lower execution frequency to handle remaining resources. Finally, based on the distribution pattern of the above parameters, a first-time weighted curve is formed, characterized by a fast start and a slower finish, with more transactions at the beginning and fewer at the end. This ensures that the first-time weighted curve accurately matches the favorable operating conditions, achieving an optimal balance between transaction efficiency and risk control.

[0083] In another embodiment, the electronic device can also output a first-time weighted curve based on a pre-trained curve prediction model. The curve prediction model can take on-chain transaction information, the corresponding threshold ranges for those transactions, and transaction resources as input, and the first-time weighted curve as output; this will not be described in detail here.

[0084] S303. If the threshold range corresponding to the price volatility is the preset high volatility range, then a second time-weighted curve is generated.

[0085] In the aforementioned second time-weighted curve, the proportion of single transaction volume in the first stage is less than that in the second stage, and the execution frequency of a single transaction in the first stage is less than that in the second stage.

[0086] In one embodiment, the percentage of single transaction volume and execution frequency mentioned above have already been explained and will not be described again.

[0087] It should be noted that the aforementioned high volatility range is a quantitative threshold range defined for price volatility, reflecting the state of drastic fluctuations in resource value. Within this high volatility range, it can be assumed that trading pair prices fluctuate wildly and market expectations are chaotic. Executing a large number of digital resource transactions in this situation can easily trigger significant slippage. Therefore, a cautious, trial-and-error strategy followed by increased volume is necessary to mitigate risk.

[0088] The aforementioned second time-weighted curve is a time-weighted curve adapted to high volatility ranges. In contrast to the first time-weighted curve, this second time-weighted curve exhibits a slower initial pace followed by a faster pace, and fewer transactions initially followed by more. The first phase involves low-percentage, low-frequency execution to test the market and avoid significant losses from price fluctuations in early digital resource transactions. The second phase then involves high-percentage, high-frequency execution to quickly complete the remaining transactions, improving trading efficiency while controlling risk.

[0089] The generation method of the second time-weighted curve can be similar to that of the first time-weighted curve, and will not be described in detail.

[0090] S304. If the threshold range corresponding to the on-chain transaction fee is the preset high fee range, then a third time-weighted curve is generated.

[0091] Among them, the total duration of the time window in the third time-weighted curve is greater than the preset benchmark total duration, and the resource transaction volume corresponding to multiple transaction time points is evenly distributed.

[0092] In one embodiment, the aforementioned high-fee range is a quantitative threshold range defined for on-chain transaction fees, reflecting a significantly high level of transaction costs on the blockchain network. The threshold range corresponding to on-chain transaction fees can be determined through historical on-chain transaction fee data statistics, network computing power cost analysis, and transaction execution cost control targets. For example, in the Ethereum network, a gas fee > 100 gwei can be set as a high-fee range. In a high-fee range, the network may be considered congested, resulting in high transaction fees per transaction. In this case, frequently splitting transactions or shortening execution cycles can easily lead to a significant increase in total transaction costs; therefore, it is necessary to control costs by optimizing time windows and transaction volume allocation.

[0093] The aforementioned preset benchmark total duration is the default time window duration set for the time-weighted curve under normal on-chain operating conditions (such as transaction fees being in the low to medium range, price volatility being stable, and liquidity being sufficient), and serves as a reference benchmark for adjusting the time window.

[0094] It's important to note that when on-chain transaction fees fall within a preset high-fee range (i.e., a quantitative range where blockchain network transaction costs are significantly high), electronic devices can set the total duration of the time window to be greater than the preset baseline total duration (the default time window duration under normal operating conditions). By extending the execution cycle, the number of transactions per unit time is reduced, avoiding the accumulation of high transaction fees due to frequent transaction initiation. Furthermore, resource transaction volume can be evenly distributed proportionally across all transaction points within the time window. This mitigates the slippage risk of large-scale digital resource transactions in a single transaction and prevents the accumulation of transaction fees due to excessive transaction splitting, ultimately achieving a balance between optimal transaction costs and controllable execution risks in high-fee scenarios.

[0095] The method for generating the third time-weighted curve can be similar to that for generating the first time-weighted curve, and will not be explained further.

[0096] S305. If the threshold range corresponding to the available resources is the preset resource shortage range, or the threshold range corresponding to the ratio is the preset high ratio range, then a fourth time-weighted curve is generated.

[0097] In the fourth time-weighted curve mentioned above, the number of transaction time points within the time window is greater than the preset benchmark number.

[0098] In one embodiment, the aforementioned resource shortage interval is a quantitative threshold range defined for the available resources in the liquidity pool, reflecting the scarcity of resources within the pool. The resource shortage interval can be determined based on the liquidity pool's minimum carrying capacity, historical transaction slippage data, and risk control objectives. For example, a resource shortage interval can be defined as the total available resources of the first / second object in the liquidity pool being less than 1000 standard units. When the liquidity pool is in the resource shortage interval, it can be considered that the resources within the liquidity pool are insufficient to support a large number of digital resource transactions. Concentrated execution of transactions could easily lead to a surge in slippage or even transaction failure. Therefore, it is necessary to reduce the impact by refining transaction splitting.

[0099] The aforementioned high-proportion range is a quantitative threshold range defined by the ratio of trading resources to available resources in the liquidity pool, reflecting an excessively high level of liquidity utilization within the pool. The high-proportion range can be set based on the liquidity pool's resilience. For example, a high-proportion range could be defined as a ratio of trading resources to available resources > 10%. When within this high-proportion range, the trading volume is considered excessively large relative to the liquidity in the pool; a single or few executions could severely impact resource value, necessitating increased trading frequency to mitigate the impact.

[0100] The aforementioned preset benchmark number can be the default number of transaction time points set for the time-weighted curve by electronic devices under normal on-chain conditions (such as sufficient liquidity, appropriate proportions, and stable price fluctuations). It serves as a reference benchmark for adjusting the granularity of transaction splitting. For example, it can be set to 10 transaction time points.

[0101] The aforementioned fourth time-weighted curve is a time-weighted curve adapted to two types of high-impact risk conditions: resource shortage intervals and high-proportion intervals. Its core feature is the high-density splitting of transaction time points. That is, by setting the number of transaction time points within the time window to be greater than the preset benchmark number, the total transaction resources are split into more small transactions for dispersed execution, thereby reducing the impact of each transaction on the liquidity pool, controlling slippage risk, and avoiding transaction failures.

[0102] Understandably, in scenarios with insufficient resources or excessively high transaction volume, splitting transaction time points with high density not only disperses the market impact of a single transaction and effectively controls slippage losses, but also adapts to the carrying capacity of the liquidity pool and improves the transaction success rate; at the same time, it does not require excessively extending the time window, thus taking into account the transaction execution efficiency under the premise of controllable risk and avoiding excessively long transaction cycles due to working conditions.

[0103] In one embodiment, the generation method of the fourth time-weighted curve may be similar to that of the first time-weighted curve, and will not be described in detail.

[0104] S306. One of the first time-weighted curve, the second time-weighted curve, the third time-weighted curve, and the fourth time-weighted curve shall be determined as the time-weighted curve.

[0105] In one embodiment, when the on-chain transaction information collected in real time only meets the triggering condition of one of the four curves, the curve can be directly determined as the final time-weighted curve without additional filtering, ensuring that the time-weighted curve matches the current single working condition.

[0106] However, in multi-condition matching scenarios, electronic devices can determine the time-weighted curve from multiple curves based on priority or random selection.

[0107] For example, when on-chain information simultaneously meets the triggering conditions of two or more curves (such as simultaneously meeting high volatility and high on-chain transaction fees, i.e., simultaneously matching the second time-weighted curve and the third time-weighted curve; or simultaneously meeting high proportion and high on-chain transaction fees, i.e., simultaneously matching the third time-weighted curve and the fourth time-weighted curve), the curve with the highest priority can be selected as the final time-weighted curve.

[0108] In this embodiment, the method for determining the time-weighted curve is not limited.

[0109] It should be noted that the four curves mentioned above are merely examples for low volatility, resource-sufficient, high volatility, high-cost, resource-scarce, or high-proportion ranges in this embodiment, and do not exhaust all possible trading strategies. In this embodiment, the scenarios for setting the time-weighted curve for each threshold range are not limited.

[0110] In this embodiment, specific threshold ranges are defined based on on-chain transaction information such as price volatility and available liquidity pool resources. Four time-weighted curves with corresponding differentiated characteristics are then generated based on different combinations of threshold ranges and single threshold range scenarios. Finally, the appropriate curve is determined for execution. This approach allows for efficient and concentrated trading to lock in profits in favorable conditions such as low volatility and abundant resources. In high volatility and risky conditions, the second time-weighted curve mitigates slippage losses through initial probing and subsequent volume increases. In high-fee scenarios, the third time-weighted curve extends the time window and evenly distributes trading volume to control total costs. Furthermore, in high-risk scenarios with insufficient resources or high proportions of transactions, the fourth time-weighted curve increases the number of trading time points to disperse market impact and ensure transaction feasibility. Therefore, generating time-weighted curves in this manner avoids the rigid limitations of a single trading strategy and achieves a balance between trading efficiency, risk control, and cost optimization under different on-chain conditions.

[0111] In another embodiment, the electronic device may also be based on, for example... Figure 4 The S401-S402 steps shown generate the time-weighted curve. Details are as follows: S401. If the path from the first object to the second object is a direct transaction path, then the time-weighted curve corresponding to the direct transaction path is dynamically generated based on the on-chain transaction information.

[0112] In one embodiment, a direct transaction path refers to a transaction path in which a user-initiated resource transaction allows the first object and the second object to be directly exchanged without the need for a third-party resource as an intermediary, or through indirect steps such as cross-chain bridges or multi-step resource conversion.

[0113] In one embodiment, the method for generating the time-weighted curve can be described with reference to the examples above, and will not be explained further.

[0114] S402. If the path from the first object to the second object is an indirect transaction path, then the sub-time weighted curve corresponding to each sub-transaction path is dynamically generated based on the on-chain transaction information, and the multiple sub-time weighted curves are determined as a time weighted curve.

[0115] The aforementioned indirect transaction path consists of multiple sub-transaction paths, each with its starting and ending points being adjacent transaction objects. For example, this indirect transaction path refers to a multi-stage transaction path where the transaction from the first object to the second object requires at least one intermediate transaction object, making direct resource exchange impossible. For instance, in the path TokenA→TokenB→TokenC, TokenA must first be exchanged for TokenB (an intermediate object), and then TokenB must be exchanged for TokenC.

[0116] It should be noted that, since the indirect transaction path consists of multiple consecutive sub-transaction paths, an execution strategy needs to be formulated separately for the on-chain conditions of each sub-transaction path. That is, a sub-time-weighted curve corresponding to each sub-transaction path is generated. At this point, multiple sub-time curves are connected based on the order of the sub-transaction paths to obtain the time-weighted curve.

[0117] The aforementioned sub-transaction path is the smallest transaction unit composed of adjacent transaction objects in an indirect transaction path. That is, the indirect transaction path is divided into multiple direct transaction segments from the start point to the end point. Taking TokenA→TokenB→TokenC as an example, it can be divided into two sub-transaction paths: (TokenA, TokenB) and (TokenB, TokenC). Each sub-transaction path corresponds to a direct transaction segment of an independent adjacent transaction object.

[0118] Based on this, in a sub-trade path, the starting point is the initial transaction object of the sub-trade path, and the ending point is the target transaction object of the sub-trade path. The two are adjacent transaction objects.

[0119] The generation method for the sub-time-weighted curve corresponding to each sub-transaction path can be similar to the generation method for the time-weighted curve corresponding to the direct transaction path. For example, obtaining on-chain transaction information in the sub-transaction path. At this time, this on-chain transaction information will be used to describe the on-chain dynamic working conditions of the transaction object corresponding to the starting point and the transaction object corresponding to the ending point in the sub-transaction path during the transaction.

[0120] In one embodiment, the electronic device can generate the aforementioned direct transaction path and / or indirect transaction path based on a pre-set path generation model. For example, the path generation model can be generated based on factors such as whether the transaction objects are in the same liquidity pool, whether slippage is within an acceptable range, and whether on-chain transaction fees are reasonable; these will not be described in detail here.

[0121] In this embodiment, for direct transaction paths, a single time-weighted curve is generated based on the on-chain transaction information within the direct transaction path, achieving a precise balance between efficiency and risk in a concise transaction scenario. Furthermore, for indirect transaction paths, they are broken down into multiple sub-transaction paths, and sub-time-weighted curves are generated for each before integration. This ensures that the strategy of each intermediate step is tailored to its specific on-chain conditions, while avoiding strategy deviations caused by the superposition of multiple steps. This comprehensively covers the scenario requirements of both direct and indirect transaction paths, improving the execution efficiency and risk control of on-chain transactions under different paths.

[0122] In another embodiment, for indirect transaction paths, the electronic device can be based on, for example... Figure 5 The S501-S502 steps shown represent on-chain transactions. Details are as follows: S501. For the target sub-transaction path in the sub-transaction path where the transaction is currently being executed, obtain the transaction progress of the target sub-transaction path.

[0123] In one embodiment, among the multiple sub-transaction paths into which an indirect transaction path is divided, the sub-transaction path in which the transaction operation is currently being executed is the target sub-transaction path. For example, in the indirect transaction path "TokenA→TokenB→TokenC", if the transaction "TokenB→TokenC" is currently being executed, then (TokenB, TokenC) is the target sub-transaction path.

[0124] The aforementioned transaction progress refers to the proportion of completed transactions in the target sub-transaction path to the total transaction volume of that sub-path (or the proportion of completed transaction time to the total time window of that sub-path), which can quantify the execution status of the target sub-transaction path.

[0125] For example, if the total transaction volume of the target sub-transaction path is 1000 units of tokens, and 300 units have been executed, then the transaction progress is 30%.

[0126] S502. If the transaction progress of the target sub-transaction path reaches the preset progress, then start the execution of the on-chain transaction of the sub-time weighted curve corresponding to the next sub-transaction path until the transaction of the last sub-transaction path is completed.

[0127] In one embodiment, the aforementioned preset progress is a quantitative execution threshold pre-set for a sub-trading path to trigger the start of the next sub-trading path. It is typically defined as a percentage of the completed transaction volume to the total transaction volume of the sub-trading path or a percentage of the executed time to the total duration of the sub-trading path's time window. For example, it may be set to 50% or 70%.

[0128] Understandably, by setting a preset schedule, it is possible to ensure that the execution of each sub-trading path in the indirect trading path is orderly and avoids the risk of the preceding transactions not being completed stably due to starting too early, or the problem of low overall trading efficiency due to starting too late.

[0129] The next sub-transaction path mentioned above refers to the sub-transaction path that immediately follows the currently executed target sub-transaction path in the sub-transaction path sequence after the indirect transaction path is broken down. Its starting point is the end point of the current target sub-transaction path (i.e., the intermediate transaction object), and its ending point is the next transaction object in the sequence. It is the next continuous execution link in the indirect transaction process.

[0130] For example, when an indirect transaction path is split into three sub-transaction paths: TokenA→TokenB, TokenB→TokenC, and TokenC→TokenD, if the current target sub-transaction path is TokenA→TokenB, then TokenB→TokenC is the next sub-transaction path.

[0131] It should be noted that when the next sub-transaction path is initiated, this sub-transaction path can also be considered the target sub-transaction path. Based on this, the electronic device can continuously track the transaction progress of the new target sub-transaction path, and when it reaches the preset progress, the next sub-transaction path will be initiated, thus forming a loop until all sub-transaction paths are completed.

[0132] In this embodiment, by acquiring the transaction progress of the current target sub-transaction path in the indirect transaction path in real time, and starting the execution of the next sub-transaction path with the preset progress as the trigger condition, until the transaction of the last sub-transaction path is completed, not only can the orderly and smooth connection of each sub-transaction path be achieved, avoiding efficiency loss caused by transaction interruption or invalid waiting, but also the risk of resource loss and transaction failure caused by chaotic connection in multi-stage transactions can be effectively avoided by accurately controlling the execution status of each sub-path, thus ensuring the smooth progress and efficient completion of the entire indirect transaction path.

[0133] In another embodiment, the electronic device may also be based on, for example... Figure 6 Steps S601-S604, as shown, execute on-chain transactions. Details are as follows: S601. If the transaction progress of the target sub-transaction path is equal to the preset progress, then start the execution of the on-chain transaction by the sub-time weighted curve corresponding to the next sub-transaction path.

[0134] S602. During the transaction process of the target sub-transaction path, calculate the actual transaction price of the two transaction objects in the target sub-transaction path and the price offset relative to the preset benchmark price of the target sub-transaction path.

[0135] Step S601 is similar to step S502 above, and will not be described further.

[0136] In one embodiment, the aforementioned actual transaction price refers to the real-time transaction price at which the two corresponding transaction objects (starting resource and ending resource) are actually exchanged during the transaction execution process of the target sub-transaction path. It is the real execution price of the on-chain transaction and will fluctuate in real time with changes in market supply and demand, liquidity, etc.

[0137] The aforementioned preset benchmark price is a reference price determined before the target sub-trading path is initiated, based on factors such as the historical price data of the trading pair corresponding to the sub-trading path, the real-time market fair price, and the preset pricing target of the strategy. It serves as a benchmark for measuring whether the actual trading price is reasonable.

[0138] The aforementioned price offset represents the degree of deviation of the actual transaction price from the preset benchmark price. It is usually presented as an absolute difference or a percentage and is used to quantify the deviation between the actual transaction price and the expected price.

[0139] It should be noted that during the current transaction process of the target sub-trading path, the electronic device can simultaneously detect the actual transaction prices of the two corresponding trading objects and calculate the price deviation of the actual transaction price relative to the preset benchmark price in order to understand the deviation between the actual transaction and the expected price, and provide real-time data support for the dynamic adjustment of subsequent trading strategies.

[0140] S603. If the price offset is greater than the preset offset threshold, then stop executing the on-chain transaction corresponding to the next sub-transaction path.

[0141] S604. If the price offset is not greater than the preset offset threshold, continue to execute the on-chain transaction corresponding to the next sub-transaction path until the transaction of the last sub-transaction path is completed.

[0142] In one embodiment, if a price deviation is detected to be greater than a preset deviation threshold, it can be considered that the current resource value deviates too much from expectations, and continuing the transaction may result in losses exceeding acceptable limits. Therefore, the electronic device can stop executing the on-chain transaction corresponding to the next sub-transaction path.

[0143] Furthermore, if the price deviation does not exceed a preset deviation threshold, the deviation between the actual transaction price and the expected benchmark price can be considered to be within a controllable range, and the transaction risk is within an acceptable range. The electronic device can continue to execute the on-chain transaction corresponding to the next sub-transaction path as planned, and continue to repeat this judgment process until all transactions in the last sub-transaction path in the indirect transaction path are completed.

[0144] In this embodiment, the execution of the next sub-transaction path is initiated based on a preset progress as the trigger condition. Simultaneously, during the transaction of the current target sub-transaction path, the price deviation of the actual transaction price relative to the preset benchmark price is detected in real time. Based on whether the deviation exceeds a preset deviation threshold, the on-chain transaction of the next sub-transaction path is dynamically decided to stop or continue. This not only ensures the orderliness and continuity of the connection between each sub-transaction path through the progress trigger mechanism, avoiding transaction interruption or inefficient waiting, but also avoids the risk of excessive loss due to a large deviation of the price from the expectation by using real-time monitoring of the price deviation and threshold determination. This achieves a balance between connection efficiency and risk control in the indirect transaction process.

[0145] In another embodiment, when executing a resource transaction request based on a time-weighted curve, the electronic device can, according to, such as Figure 7 Steps S701-S702, as shown, complete the on-chain transaction of the transaction resources. Details are as follows: S701. Superimpose random disturbances onto the time-weighted curve to adjust at least one of the transaction time point or the corresponding resource transaction volume to obtain the target time-weighted curve.

[0146] S702. Execute resource transaction requests based on the target time-weighted curve to complete the on-chain transaction of the transaction resources.

[0147] In one embodiment, the aforementioned random disturbance refers to a random adjustment variable introduced to disrupt the execution pattern of the original time-weighted curve, which conforms to preset constraints (such as upper limit of disturbance amplitude, probability distribution rules). The random disturbance should be both controllable and random.

[0148] Randomness can be considered as the generation of adjustment values ​​based on probability models (such as uniform distribution, normal distribution), to prevent the execution strategy from being captured by external arbitrage; controllability can be considered as the adjustment range being strictly limited to preset thresholds (such as trading volume ±5%, time point ±3 minutes), to ensure that it does not deviate from the core trading objectives of the original curve (such as total trading volume, overall execution cycle).

[0149] The superposition method refers to the specific implementation logic of incorporating random disturbances into the original time-weighted curve to adjust the trading parameters. It can be superimposed in the following ways: Transaction time point overlay: For each preset transaction time point in the time-weighted curve, an adjustment amount is randomly generated within a preset time interval (such as T minutes) to shift the transaction time point forward or backward. For example, if the original transaction time points are at the 5th, 10th, and 15th minutes, after overlaying the disturbance, they may become at the 4.8th, 10.3rd, and 14th minutes, avoiding concentrated execution at fixed transaction time points.

[0150] Resource transaction volume overlay: For each transaction time point in the time-weighted curve, a random adjustment is generated within a preset percentage range (e.g., ±P%) to correct the transaction volume. For example, if the original single transaction volume is 50 units, it may become 48 units or 52 units after overlaying the disturbance, thus preventing the market shock patterns caused by fixed transaction volumes from being exploited.

[0151] In this embodiment, by superimposing random disturbances that meet preset constraints on the original time-weighted curve, the transaction time point or the corresponding resource transaction volume is controlled and randomly fine-tuned to form a target time-weighted curve, and on-chain transactions are executed based on the target curve. The impact of centralized transactions on the market can be reduced through decentralized fine-tuning. At the same time, without deviating from the core transaction objective, the concealment, anti-interference ability and execution stability of the transaction strategy are further improved, ensuring that on-chain transactions are completed efficiently and securely.

[0152] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0153] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a dynamic execution device for on-chain resource transactions provided in this application embodiment. The dynamic execution device for on-chain resource transactions in this embodiment includes modules for execution... Figures 1 to 7 The steps in the corresponding embodiments. Please refer to the details. Figures 1 to 7 as well as Figures 1 to 7 The relevant descriptions in the corresponding embodiments are shown below. For ease of explanation, only the parts relevant to this embodiment are shown. See also... Figure 8 The dynamic execution device 800 for on-chain resource transactions may include: a first acquisition module 810, a second acquisition module 820, a generation module 830, and a first execution module 840, wherein: The first acquisition module 810 is used to acquire resource transaction requests submitted by users on the chain; the resource transaction request includes a first object to be traded, the transaction resource, and a second object to be traded.

[0154] The second acquisition module 820 is used to acquire on-chain transaction information; the on-chain transaction information is used to describe the dynamic on-chain conditions when the first object and the second object conduct a transaction.

[0155] The generation module 830 is used to dynamically generate a time-weighted curve based on on-chain transaction information. The time-weighted curve includes a time window, multiple transaction time points within the time window, and the resource transaction volume corresponding to each of the multiple transaction time points.

[0156] The first execution module 840 is used to execute resource transaction requests based on the time-weighted curve and complete the on-chain transaction of the transaction resources.

[0157] In one embodiment, the dynamic execution device 800 for on-chain resource transactions further includes: The calculation module is used to calculate the ratio of trading resources to available resources in the liquidity pool; the liquidity pool is a trading pool that supports trading between the first object and the second object.

[0158] The first execution module is used to execute resource transaction requests in an instantaneous transaction execution mode if the ratio is less than the first preset ratio, thereby completing the transaction of all transaction resources.

[0159] The second execution module is used to execute the transaction resources of the second preset ratio in an instant transaction execution mode if the ratio is greater than or equal to the first preset ratio, and to execute the steps of obtaining on-chain transaction information and subsequent steps for the remaining transaction resources.

[0160] In one embodiment, the on-chain transaction information includes at least one of price volatility, available resources in the liquidity pool, the ratio of transaction resources to available resources, and on-chain transaction fees; the generation module 830 is further configured to: For any type of on-chain transaction information, determine the corresponding threshold range for that transaction information; If the threshold range corresponding to price volatility is a preset low volatility range, and the available resources are located in a preset resource-sufficient range, then a first-time weighted curve is generated; the time window in the first-time weighted curve is divided into a continuous first stage and a second stage, the proportion of a single transaction volume in the first stage is greater than the proportion of a single transaction volume in the second stage, and the execution frequency of a single transaction in the first stage is greater than the execution frequency of a single transaction in the second stage. If the threshold range corresponding to price volatility is the preset high volatility range, a second time-weighted curve is generated; in the second time-weighted curve, the proportion of single transaction volume in the first stage is less than that in the second stage, and the execution frequency of a single transaction in the first stage is less than that in the second stage. If the threshold range corresponding to the on-chain transaction fee is the preset high fee range, a third time-weighted curve is generated; the total duration of the time window in the third time-weighted curve is greater than the preset benchmark total duration, and the resource transaction volume corresponding to multiple transaction time points is evenly distributed. If the threshold range corresponding to available resources is the preset resource shortage range, or the threshold range corresponding to the ratio is the preset high ratio range, then a fourth time-weighted curve is generated; in the fourth time-weighted curve, the number of transaction time points within the time window is greater than the preset benchmark number. One of the first time-weighted curve, the second time-weighted curve, the third time-weighted curve, and the fourth time-weighted curve is determined as the time-weighted curve.

[0161] In one embodiment, the generation module 830 is further configured to: If the path from the first object to the second object is a direct transaction path, then a time-weighted curve corresponding to the direct transaction path is dynamically generated based on the on-chain transaction information. If the first object to the second object is an indirect transaction path, then the sub-time weighted curve corresponding to each sub-transaction path is dynamically generated based on the on-chain transaction information, and the multiple sub-time weighted curves are determined as a time weighted curve; the indirect transaction path is composed of multiple sub-transaction paths, and the starting point and ending point of each sub-transaction path are adjacent transaction objects.

[0162] In one embodiment, the first execution module 840 is further configured to: For the target sub-transaction path currently executing a transaction within the sub-transaction path, obtain the transaction progress of the target sub-transaction path; If the transaction progress of the target sub-transaction path reaches the preset progress, the on-chain transaction will be executed by the sub-time weighted curve corresponding to the next sub-transaction path until the transaction of the last sub-transaction path is completed.

[0163] In one embodiment, the first execution module 840 is further configured to: If the transaction progress of the target sub-transaction path is equal to the preset progress, then the on-chain transaction will be executed by starting the sub-time weighted curve corresponding to the next sub-transaction path. During the transaction process of the target sub-transaction path, calculate the actual transaction price of the two transaction objects in the target sub-transaction path and the price deviation relative to the preset benchmark price of the target sub-transaction path. If the price offset is greater than the preset offset threshold, the on-chain transaction corresponding to the next sub-transaction path will be stopped. If the price offset is not greater than the preset offset threshold, the on-chain transaction corresponding to the next sub-transaction path will continue to be executed until the transaction of the last sub-transaction path is completed.

[0164] In one embodiment, the first execution module 840 is further configured to: By superimposing random disturbances onto the time-weighted curve and adjusting at least one of the transaction time point or the corresponding resource transaction volume, the target time-weighted curve is obtained. Execute resource transaction requests based on the target time-weighted curve to complete on-chain transactions of the traded resources.

[0165] When it is understood that, Figure 8 In the schematic diagram of the dynamic execution device for on-chain resource transactions shown, each module is used for execution. Figures 1 to 7The steps in the corresponding embodiments, and for Figures 1 to 7 The steps in the corresponding embodiments have been explained in detail in the above embodiments. Please refer to them for details. Figures 1 to 7 as well as Figures 1 to 7 The relevant descriptions in the corresponding embodiments will not be repeated here.

[0166] Figure 9 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Figure 9 As shown, the electronic device 900 of this embodiment includes: a processor 910, a memory 920, and a computer program 930 stored in the memory 920 and executable by the processor 910, such as a program for a dynamic execution method of on-chain resource transactions. When the processor 910 executes the computer program 930, it implements the steps of the various embodiments of the dynamic execution method of on-chain resource transactions described above, for example... Figure 1 S101 to S104 are shown. Alternatively, the processor 910 implements the above when executing the computer program 930. Figure 8 The functions of each module in the corresponding embodiments, for example, Figure 8 For details on the functions of each module shown, please refer to [link / reference]. Figure 8 The relevant descriptions in the corresponding embodiments.

[0167] For example, the computer program 930 can be divided into one or more modules, one or more of which are stored in the memory 920 and executed by the processor 910 to implement the dynamic execution method for on-chain resource transactions provided in this application embodiment. One or more modules can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 930 in the electronic device 900. For example, the computer program 930 can implement the dynamic execution method for on-chain resource transactions provided in this application embodiment.

[0168] Electronic device 900 may include, but is not limited to, processor 910 and memory 920. Those skilled in the art will understand that... Figure 9 This is merely an example of electronic device 900 and does not constitute a limitation on electronic device 900. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device may also include input / output devices, network access devices, buses, etc.

[0169] The processor 910 may be a central processing unit, or it may be other general-purpose processors, digital signal processors, application-specific integrated circuits, off-the-shelf programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0170] The memory 920 can be an internal storage unit of the electronic device 900, such as a hard disk or RAM of the electronic device 900. The memory 920 can also be an external storage device of the electronic device 900, such as a plug-in hard disk, smart memory card, flash memory card, etc., equipped on the electronic device 900. Furthermore, the memory 920 can include both internal storage units and external storage devices of the electronic device 900.

[0171] This application provides a computer-readable storage medium, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the dynamic execution method for on-chain resource transactions as described in the above embodiments.

[0172] This application provides a computer program product that, when run on an electronic device, causes the electronic device to execute the dynamic execution method for on-chain resource transactions in the above embodiments.

[0173] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A dynamic execution method for on-chain resource transactions, characterized in that, Includes the following steps: Obtain the resource transaction request submitted by the user on the blockchain; the resource transaction request includes a first object to be traded, the resource to be traded, and a second object to be traded. Obtain on-chain transaction information; the on-chain transaction information is used to describe the dynamic on-chain conditions when the first object and the second object conduct a transaction; A time-weighted curve is dynamically generated based on the on-chain transaction information; the time-weighted curve includes a time window, multiple transaction time points within the time window, and the resource transaction volume corresponding to each of the multiple transaction time points; The resource transaction request is executed based on the time-weighted curve to complete the on-chain transaction of the transaction resource.

2. The method according to claim 1, characterized in that, The method further includes: Calculate the ratio of the transaction resources to the available resources in the liquidity pool; the liquidity pool is a transaction pool that supports transactions between the first object and the second object; If the ratio is less than the first preset ratio, the resource transaction request will be executed using the real-time transaction execution method to complete the transaction of all the transaction resources; If the ratio is greater than or equal to the first preset ratio, then the real-time transaction execution method is used to execute the second preset ratio of transaction resources, and the steps of obtaining on-chain transaction information and subsequent steps are executed for the remaining transaction resources.

3. The method according to claim 1, characterized in that, The on-chain transaction information includes at least one of price volatility, available resources in the liquidity pool, the ratio of the transaction resources to the available resources, and on-chain transaction fees; the step of dynamically generating a time-weighted curve based on the on-chain transaction information includes: For any type of on-chain transaction information, determine the threshold range corresponding to the on-chain transaction information; If the threshold range corresponding to the price volatility is a preset low volatility range, and the available resources are located in a preset resource sufficiency range, then a first time-weighted curve is generated; the time window in the first time-weighted curve is divided into a continuous first stage and a second stage, the proportion of a single transaction volume in the first stage is greater than the proportion of a single transaction volume in the second stage, and the execution frequency of a single transaction in the first stage is greater than the execution frequency of a single transaction in the second stage. If the threshold range corresponding to the price volatility is a preset high volatility range, then a second time-weighted curve is generated; in the second time-weighted curve, the proportion of single transaction volume in the first stage is less than the proportion of single transaction volume in the second stage, and the execution frequency of single transaction in the first stage is less than the execution frequency of single transaction in the second stage. If the threshold range corresponding to the on-chain transaction fee is a preset high-fee range, a third time-weighted curve is generated; the total duration of the time window in the third time-weighted curve is greater than the preset baseline total duration, and the resource transaction volume corresponding to the multiple transaction time points is evenly distributed. If the threshold range corresponding to the available resources is a preset resource shortage range, or the threshold range corresponding to the ratio is a preset high ratio range, then a fourth time-weighted curve is generated; in the fourth time-weighted curve, the number of transaction time points within the time window is greater than the preset benchmark number. One of the first time-weighted curve, the second time-weighted curve, the third time-weighted curve, and the fourth time-weighted curve is determined as the time-weighted curve.

4. The method according to claim 1, characterized in that, The step of dynamically generating a time-weighted curve based on the on-chain transaction information includes: If the path from the first object to the second object is a direct transaction path, then a time-weighted curve corresponding to the direct transaction path is dynamically generated based on the on-chain transaction information. If the first object to the second object is an indirect transaction path, then a sub-time-weighted curve corresponding to each sub-transaction path is dynamically generated based on the on-chain transaction information, and multiple sub-time-weighted curves are determined as the time-weighted curve; the indirect transaction path is composed of multiple sub-transaction paths, and the starting point and ending point of each sub-transaction path are adjacent transaction objects.

5. The method according to claim 4, characterized in that, The step of executing the resource transaction request based on the time-weighted curve to complete the on-chain transaction of the transaction resource includes: For the target sub-transaction path currently executing a transaction within the sub-transaction path, obtain the transaction progress of the target sub-transaction path; If the transaction progress of the target sub-transaction path reaches the preset progress, the on-chain transaction will be executed by the sub-time weighted curve corresponding to the next sub-transaction path until the transaction of the last sub-transaction path is completed.

6. The method according to claim 5, characterized in that, If the transaction progress of the target sub-transaction path reaches a preset progress, then the on-chain transaction is initiated based on the sub-time weighted curve corresponding to the next sub-transaction path, until the transaction of the last sub-transaction path is completed, further including: If the transaction progress of the target sub-transaction path is equal to the preset progress, then the on-chain transaction is executed by starting the sub-time weighted curve corresponding to the next sub-transaction path; During the transaction process of the target sub-transaction path, calculate the actual transaction price of the two transaction objects in the target sub-transaction path and the price offset relative to the preset benchmark price of the target sub-transaction path; If the price offset is greater than a preset offset threshold, then the execution of the on-chain transaction corresponding to the next sub-transaction path will be stopped; If the price offset is not greater than the preset offset threshold, the on-chain transaction corresponding to the next sub-transaction path will continue to be executed until the transaction of the last sub-transaction path is completed.

7. The method according to any one of claims 1-6, characterized in that, The step of executing the resource transaction request based on the time-weighted curve to complete the on-chain transaction of the transaction resource includes: By superimposing random disturbances onto the time-weighted curve and adjusting at least one of the transaction time points or the corresponding resource transaction volumes, a target time-weighted curve is obtained. The resource transaction request is executed based on the target time-weighted curve to complete the on-chain transaction of the transaction resource.

8. A dynamic execution device for on-chain resource transactions, characterized in that, The device includes: The first acquisition module is used to acquire resource transaction requests submitted by users on the blockchain; the resource transaction request includes a first object to be traded, the resource to be traded, and a second object to be traded. The second acquisition module is used to acquire on-chain transaction information; the on-chain transaction information is used to describe the on-chain dynamic working conditions when the first object and the second object conduct a transaction. The generation module is used to dynamically generate a time-weighted curve based on the on-chain transaction information; the time-weighted curve includes a time window, multiple transaction time points within the time window, and the resource transaction volume corresponding to each of the multiple transaction time points; The first execution module is used to execute the resource transaction request based on the time-weighted curve and complete the on-chain transaction of the transaction resource.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, When the computer program product is run on an electronic device, the electronic device executes the method as described in any one of claims 1 to 7.

Images