Customizable cryptocurrency trading

Abstract

1. A computing device for exchanging tokens via a distributed smart contract running on a blockchain, the computing device comprising: at least one hardware processor in a network-connected server that executes code of the distributed smart contract running on the blockchain, the code being for: managing a primary reserve of multiple tokens of a primary virtual currency; receiving from client terminals in communication with the network-connected server multiple values ​​of multiple adjustable parameters that define a function for calculating an exchange rate for effecting an exchange between the primary virtual currency and a secondary virtual currency; and, in response to a transaction request to convert between the primary tokens and secondary tokens of the secondary virtual currency, executing the transaction request using a bonding curve defined by the multiple values ​​of the multiple adjustable parameters.

Description

[Technical Field]

[0001] Related Applications This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 417,723, filed October 20, 2022, the contents of which are incorporated herein by reference in their entirety. [Background technology]

[0002] In some embodiments thereof, the present invention relates to a decentralized application for managing virtual currency, and more particularly, but not exclusively, to a system and method for a decentralized application for customizable virtual currency trading.

[0003] Advances in blockchain technology provide a decentralized (i.e., decentralized) approach that allows almost any entity to create its own custom cryptocurrency and / or create its own smart contract to provide cryptocurrency exchange services. Some smart contracts that run on the blockchain are designed to allow users to convert between different types of cryptocurrencies. Summary of the Invention

[0004] According to a first aspect, a computing device for exchanging tokens via a distributed smart contract running on a blockchain comprises at least one hardware processor of a network-connected server executing code of the distributed smart contract running on the blockchain, the code being for managing a primary reserve of a plurality of tokens of a primary virtual currency, receiving from client terminals in communication with the network-connected server a plurality of values ​​of a plurality of adjustable parameters defining a function for calculating an exchange rate for converting between the primary virtual currency and a secondary virtual currency, and in response to a transaction request for converting between the primary tokens and a secondary token of the secondary virtual currency, executing the transaction request using a bonding curve defined by the function having the plurality of values ​​of the plurality of adjustable parameters.

[0005] According to a second aspect, a method of exchanging tokens via a distributed smart contract executed on a blockchain includes managing a primary reserve of a plurality of tokens of a primary virtual currency; obtaining, from a client terminal in communication with the networked server, a plurality of values ​​of a plurality of adjustable parameters that define a function for calculating an exchange rate for converting the primary virtual currency and a secondary virtual currency; and, in response to a transaction request for converting the primary token and a secondary token of the secondary virtual currency, executing the transaction request using a bonding curve defined by the function having the plurality of values ​​of the plurality of adjustable parameters.

[0006] According to a third aspect, a computing device for exchanging tokens via a distributed smart contract running on a blockchain comprises at least one hardware processor of a networked server that executes code of the distributed smart contract running on the blockchain, the code being for: managing a primary reserve of a plurality of primary tokens of a primary virtual currency and managing a secondary reserve of a plurality of secondary tokens of a secondary virtual currency; receiving transaction requests to convert between the primary tokens and secondary tokens of the secondary virtual currency; executing the transaction request, in response to the transaction request converting from the primary token to the secondary token, using a first bonding curve implicitly defined by a function and a first set of values ​​for a plurality of adjustable parameters; and executing the transaction request, in response to the transaction request converting from the secondary token to the primary token, using a second bonding curve implicitly defined by the function and a second set of values ​​for the plurality of adjustable parameters that differ from the first set, the second bonding curve being different from the first bonding curve.

[0007] In further embodiments of the first, second and third aspects, the primary reserve is managed without managing a secondary reserve of secondary tokens of the secondary virtual currency.

[0008] In further embodiments of the first, second and third aspects, the plurality of tunable parameters are selected to meet hardware and / or software resource requirements for execution of the code of the distributed smart contract.

[0009] In further embodiments of the first, second and third aspects, the method further comprises code for dynamically monitoring execution of the code of the distributed smart contract and dynamically adapting the plurality of tunable parameters to meet resource requirements of the hardware and / or software.

[0010] In further embodiments of the first, second and third aspects, the resource requirements are selected from the group consisting of calculation precision in the absence of floating point arithmetic, overflow, underflow, unsigned integers, computational complexity, storage requirements, and memory requirements.

[0011] In further embodiments of the first, second and third aspects, the plurality of values ​​of the adjustable parameters are obtained from a user via a user interface running on the client terminal in communication with the networked server.

[0012] In a further embodiment of the first, second and third aspects, one of the x-axis and y-axis represents the balance of the primary reserve, the other axis is undefined and the function represents all possible exchange rates for the conversion of the primary token and the secondary token.

[0013] In further embodiments of the first, second and third aspects, the transaction request for an exchange using the function with applied parameters is executed on the blockchain using basic mathematical operations selected from addition, subtraction, multiplication and division, and excluding all Taylor series, polynomial approximations and numerical methods of generating function outputs.

[0014] In a further embodiment of the first, second and third aspects, at least two of the plurality of tunable parameters are calculated outside the blockchain.

[0015] In further embodiments of the first, second and third aspects, the bonding curve comprises a first bonding curve and further comprises a second bonding curve defined by the function, the first bonding curve being defined by a first set of values ​​for the adjustable parameters and the second bonding curve being defined by a second set of values ​​for the adjustable parameters, the first bonding curve being for conversions from the primary virtual currency to the secondary virtual currency and the second bonding curve being for conversions from the secondary virtual currency to the primary virtual currency, and the first bonding curve and the second bonding curve having a common adjustable parameter with different values.

[0016] In further embodiments of the first, second and third aspects, a first exchange rate for conversion of the primary virtual currency to the secondary virtual currency is calculated according to the first bonding curve and a second exchange rate for conversion of the secondary virtual currency to the primary virtual currency is calculated according to the second bonding curve, wherein the first bonding curve is different from the second bonding curve and the first exchange rate is different from the second exchange rate.

[0017] In further embodiments of the first, second and third aspects, the transaction includes receiving the secondary token, automatically adding the secondary token to a secondary reserve according to the second bonding curve, and automatically withdrawing a primary token from the primary reserve according to the first bonding curve.

[0018] In a further embodiment of the first, second and third aspects, a transaction performed using the first bonding curve deterministically affects another transaction performed using the second bonding curve.

[0019] In further embodiments of the first, second and third aspects, the method further comprises obtaining a strategy from the client terminal, the strategy defining values ​​of the parameters for the first bonding curve and the second bonding curve.

[0020] In a further embodiment of the first, second and third aspects, the plurality of adjustable parameters comprises: n, P indicating the starting value of the range of exchange rates for converting the primary virtual currency to the secondary virtual currency a , P indicating the end value of the range of exchange rates for converting the primary virtual currency to the secondary virtual currency b , P denotes the slope at x=x0 and y=y0, which indicates the geometric mean price. Q, R, S, which indicates the difference in the square root of the intercept and slope, The marginal exchange rate is P a y, which indicates the balance of the primary token, equal to int , The range is y=y int x, which indicates the balance of secondary tokens obtained when the balance of the primary token becomes zero, int , x0, which indicates the x-coordinate of the geometric mean price; y0, which indicates the y coordinate of the geometric mean price; x indicating the x asymptote or vertical asymptote asym , y indicating the y-asymptote or horizontal asymptote asym , Geometric and / or algebraic reconstruction of the above matters; The method includes a base set of adjustable parameters selected from the group consisting of:

[0021] In a further embodiment of the first, second and third aspects, different values ​​are assigned to the same set of said basic parameters for different bonding curves implicitly defined by said function.

[0022] In further embodiments of the first, second and third aspects, a single distributed smart contract running on the blockchain implements different sets of values ​​for the tunable parameters for different instances of the function, the single distributed smart contract implementing each reserve of a particular token, corresponding bonding curves defined by the function having the different sets of values ​​for the plurality of tunable parameters define primitives for unidirectional exchange between an external token and the particular token of each reserve, and a plurality of the primitives are linked together to define unidirectional routes for token exchange.

[0023] In further embodiments of the first, second and third aspects, the function is defined according to a hyperbola with asymptotes at x=0 and y=0, expressed as xy=k, where x denotes the primary token and y denotes the secondary token.

[0024] In further embodiments of the first, second and third aspects, the function includes at least one adjustable asymptote and a graph of the function has at least one point in common with a constant volume bonding curve expressed as xy=k.

[0025] In further embodiments of the first, second and third aspects, the slope of each of the at least one bonding curve at the at least one common point is the same as the first derivative of xy=k, and each of the at least one bonding curves is defined to have a point at coordinates x=x0 and y=y0 on the corresponding bonding curve's implicit curve whose first derivative is equal to the first derivative of the constant volume bonding curve at the same coordinates.

[0026] In further embodiments of the first, second and third aspects, the bonding curve is defined as the implicit curve of the invariant function and is used to enumerate a range of exchange rates between a primary virtual currency and a secondary virtual currency.

[0027] In further embodiments of the first, second and third aspects, each exchange rate of a plurality of exchange rates for conversion between the primary virtual currency and the secondary virtual currency is represented as a secant between two points of the function, a first point representing the balance of the primary reserve before the exchange occurs and a second point representing the balance of the primary reserve after the exchange occurs.

[0028] In further embodiments of the first, second and third aspects, each parameter is assigned to one of a plurality of sets, each parameter of each set being mathematically related to the other parameters in said set, and each parameter being mathematically related among the sets of other parameters, sufficient to unambiguously describe a unique invariant function-implied curve pair.

[0029] In further embodiments of the first, second and third aspects, the limit exchange rate for conversion between the primary virtual currency and the secondary virtual currency is calculated according to a first derivative of the bonding curve implicitly defined by the function with an applied adjustable parameter.

[0030] In further embodiments of the first, second and third aspects, the primary reserve and the secondary reserve are linked, and when the transaction request includes an amount of secondary tokens, the amount of primary tokens is obtained from the primary reserve according to the first bonding curve and the amount of secondary tokens is deposited into the secondary reserve according to the second bonding curve.

[0031] Unless otherwise defined, all technical and / or scientific terms used herein have the meanings commonly understood by those skilled in the art to which the invention pertains. In practicing or testing embodiments of the present invention, methods and materials similar or equivalent to those described herein can be used, but exemplary methods and / or materials are described below. In case of conflict, the present patent specification, including definitions, will control. Additionally, the materials, methods, and examples are for illustrative purposes only and are not intended to be necessarily limiting.

[0032] Several embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings. Referring now to the drawings in detail, it is emphasized that the items shown are exemplary for explaining embodiments of the invention and are presented for purposes of explanatory discussion. In this regard, the description taken together with the drawings will make apparent to those skilled in the art how embodiments of the invention may be practiced. [Brief explanation of the drawings]

[0033] [Figure 1a] Schematic diagram showing an invariant function characterized by having a point with coordinates x=x0, y=y0 on its curve (which corresponds to the graph of Equations 1a-c), according to some embodiments of the present invention. [Figure 1b] Schematic diagram showing an invariant function characterized by having a point with coordinates x=x0, y=y0 on its curve (which corresponds to the graph of Equations 1a-c), according to some embodiments of the present invention. [Figure 1c] Schematic diagram showing an invariant function characterized by having a point with coordinates x=x0, y=y0 on its curve (which corresponds to the graph of Equations 1a-c), according to some embodiments of the present invention. [Figure 2a] Schematic diagram showing the case where the negative slope (-dy / dx) of the tangent at the point is P and is equal in both the customizable function and the equations 1d-e, according to some embodiments of the present invention. [Figure 2b]Schematic diagram showing the case where the negative slope (-dy / dx) of the tangent at the point is P and is equal in both the customizable function and the equations 1d-e, according to some embodiments of the present invention. [Figure 2c] Schematic diagram showing the case where the negative slope (-dy / dx) of the tangent at the point is P and is equal in both the customizable function and the equations 1d-e, according to some embodiments of the present invention. [Figure 3a] Schematic diagram of the case where the parameter k is a hyperbolic constant in Equations 1a-c (i.e., xy=k) and indicates the magnitude of the constant product curve that shares the coordinates x=x0, y=y0 with the curve of the novel invariant function, according to some embodiments of the present invention. [Figure 3b] Schematic diagram of the case where the parameter k is a hyperbolic constant in Equations 1a-c (i.e., xy=k) and indicates the magnitude of the constant volume implicit curve that shares coordinates x=x0, y=y0 with the implicit curve of the novel invariant function, according to some embodiments of the present invention. [Figure 3c] Schematic diagram of the case where the parameter k is a hyperbolic constant in Equations 1a-c (i.e., xy=k) and indicates the magnitude of the constant volume implicit curve that shares coordinates x=x0, y=y0 with the implicit curve of the novel invariant function, according to some embodiments of the present invention. [Figure 3d] Schematic diagram of the case where the parameter k is a hyperbolic constant in Equations 1a-c (i.e., xy=k) and indicates the magnitude of the constant volume implicit curve that shares coordinates x=x0, y=y0 with the implicit curve of the novel invariant function, according to some embodiments of the present invention. [Figure 3e] Schematic diagram of the case where the parameter k is a hyperbolic constant in Equations 1a-c (i.e., xy=k) and indicates the magnitude of the constant volume implicit curve that shares coordinates x=x0, y=y0 with the implicit curve of the novel invariant function, according to some embodiments of the present invention. [Figure 3f]Schematic diagram of the case where the parameter k is a hyperbolic constant in Equations 1a-c (i.e., xy=k) and indicates the magnitude of the constant volume implicit curve that shares coordinates x=x0, y=y0 with the implicit curve of the novel invariant function, according to some embodiments of the present invention. [Figure 3g] Schematic diagram of the case where the parameter k is a hyperbolic constant in Equations 1a-c (i.e., xy=k) and indicates the magnitude of the constant volume implicit curve that shares coordinates x=x0, y=y0 with the implicit curve of the novel invariant function, according to some embodiments of the present invention. [Figure 4a] Schematic diagrams of the cases where the parameters xasym and yasym indicate the "vertical" and "horizontal" asymptotes of the new function's decay curve, respectively, according to some embodiments of the present invention. [Figure 4b] Schematic diagrams of the cases where the parameters xasym and yasym indicate the "vertical" and "horizontal" asymptotes of the new function's decay curve, respectively, according to some embodiments of the present invention. [Figure 4c] Schematic diagrams of the cases where the parameters xasym and yasym indicate the "vertical" and "horizontal" asymptotes of the new function's decay curve, respectively, according to some embodiments of the present invention. [Figure 4d] Schematic diagrams of the cases where the parameters xasym and yasym indicate the "vertical" and "horizontal" asymptotes of the new function's decay curve, respectively, according to some embodiments of the present invention. [Figure 4e] Schematic diagrams of the cases where the parameters xasym and yasym indicate the "vertical" and "horizontal" asymptotes of the new function's decay curve, respectively, according to some embodiments of the present invention. [Figure 4f] Schematic diagrams of the cases where the parameters xasym and yasym indicate the "vertical" and "horizontal" asymptotes of the new function's decay curve, respectively, according to some embodiments of the present invention. [Figure 4g] Schematic diagrams of the cases where the parameters xasym and yasym indicate the "vertical" and "horizontal" asymptotes of the new function's decay curve, respectively, according to some embodiments of the present invention. [Figure 4h]Schematic diagrams of the cases where the parameters xasym and yasym indicate the "vertical" and "horizontal" asymptotes of the new function's decay curve, respectively, according to some embodiments of the present invention. [Figure 4i] Schematic diagrams of the cases where the parameters xasym and yasym indicate the "vertical" and "horizontal" asymptotes of the new function's decay curve, respectively, according to some embodiments of the present invention. [Figure 4j] Schematic diagrams of the cases where the parameters xasym and yasym indicate the "vertical" and "horizontal" asymptotes of the new function's decay curve, respectively, according to some embodiments of the present invention. [Figure 4k] Schematic diagrams of the cases where the parameters xasym and yasym indicate the "vertical" and "horizontal" asymptotes of the new function's decay curve, respectively, according to some embodiments of the present invention. [Figure 4l] Schematic diagrams of the cases where the parameters xasym and yasym indicate the "vertical" and "horizontal" asymptotes of the new function's decay curve, respectively, according to some embodiments of the present invention. [Figure 5a] 1 is a schematic diagram where the parameters xint and yint represent the x- and y-intercepts of the regression curve of the novel function, according to some embodiments of the present invention. [Figure 5b] 1 is a schematic diagram where the parameters xint and yint represent the x- and y-intercepts of the regression curve of the novel function, according to some embodiments of the present invention. [Figure 5c] 1 is a schematic diagram where the parameters xint and yint represent the x- and y-intercepts of the regression curve of the novel function, according to some embodiments of the present invention. [Figure 5d] 1 is a schematic diagram where the parameters xint and yint represent the x- and y-intercepts of the regression curve of the novel function, according to some embodiments of the present invention. [Figure 5e] 1 is a schematic diagram where the parameters xint and yint represent the x- and y-intercepts of the regression curve of the novel function, according to some embodiments of the present invention. [Figure 5f]1 is a schematic diagram where the parameters xint and yint represent the x- and y-intercepts of the regression curve of the novel function, according to some embodiments of the present invention. [Figure 5g] 1 is a schematic diagram where the parameters xint and yint represent the x- and y-intercepts of the regression curve of the novel function, according to some embodiments of the present invention. [Figure 6a] 1 is a schematic diagram of the slopes of the tangents at the y-intercept y=yint and x-intercept x=xint of the novel gradient curve, denoted by parameters Pa and Pb, respectively, according to some embodiments of the present invention. [Figure 6b] 1 is a schematic diagram of the slopes of the tangents at the y-intercept y=yint and x-intercept x=xint of the novel gradient curve, denoted by parameters Pa and Pb, respectively, according to some embodiments of the present invention. [Figure 6c] 1 is a schematic diagram of the slopes of the tangents at the y-intercept y=yint and x-intercept x=xint of the novel gradient curve, denoted by parameters Pa and Pb, respectively, according to some embodiments of the present invention. [Figure 6d] 1 is a schematic diagram of the slopes of the tangents at the y-intercept y=yint and x-intercept x=xint of the novel gradient curve, denoted by parameters Pa and Pb, respectively, according to some embodiments of the present invention. [Figure 6e] 1 is a schematic diagram of the slopes of the tangents at the y-intercept y=yint and x-intercept x=xint of the novel gradient curve, denoted by parameters Pa and Pb, respectively, according to some embodiments of the present invention. [Figure 6f] 1 is a schematic diagram of the slopes of the tangents at the y-intercept y=yint and x-intercept x=xint of the novel gradient curve, denoted by parameters Pa and Pb, respectively, according to some embodiments of the present invention. [Figure 7a-1] 1 is a schematic diagram illustrating an exemplary method for detecting parameters n and u that indicate the relative sizes of two rectangles, according to some embodiments of the present invention; [Figure 7a-2] 1 is a schematic diagram illustrating an exemplary method for detecting parameters n and u that indicate the relative sizes of two rectangles, according to some embodiments of the present invention; [Figure 7a-3] 1 is a schematic diagram illustrating an exemplary method for detecting parameters n and u that indicate the relative sizes of two rectangles, according to some embodiments of the present invention; [Figure 7b-1] 1 is a schematic diagram illustrating an exemplary method for detecting parameters n and u that indicate the relative sizes of two rectangles, according to some embodiments of the present invention; [Figure 7b-2] 1 is a schematic diagram illustrating an exemplary method for detecting parameters n and u that indicate the relative sizes of two rectangles, according to some embodiments of the present invention; [Figure 7b-3] 1 is a schematic diagram illustrating an exemplary method for detecting parameters n and u that indicate the relative sizes of two rectangles, according to some embodiments of the present invention; [Figure 7c-1] FIG. 1 is a schematic diagram illustrating an exemplary method for detecting a parameter Q that indicates the relative size of two rectangles, according to some embodiments of the present invention. [Figure 7c-2] FIG. 1 is a schematic diagram illustrating an exemplary method for detecting a parameter Q that indicates the relative size of two rectangles, according to some embodiments of the present invention. [Figure 7d-1] FIG. 1 is a schematic diagram illustrating an exemplary method for detecting a parameter Q that indicates the relative size of two rectangles, according to some embodiments of the present invention. [Figure 7d-2] FIG. 1 is a schematic diagram illustrating an exemplary method for detecting a parameter Q that indicates the relative size of two rectangles, according to some embodiments of the present invention. [Figure 8a] 22 uses n instead of f(x), according to some embodiments of the present invention. [Figure 8b] 22 uses n instead of f(x), according to some embodiments of the present invention. [Figure 8c] 22 uses n instead of f(x), according to some embodiments of the present invention. [Figure 9a] 23a-c using n instead of f(a, x, x0, y, y0) according to some embodiments of the present invention. [Figure 9b]23a-c using n instead of f(a, x, x0, y, y0) according to some embodiments of the present invention. [Figure 9c] 23a-c using n instead of f(a, x, x0, y, y0) according to some embodiments of the present invention. [Figure 10-1] 1 is a schematic diagram illustrating the state of Alice's primitive strategy before any exchanges have been performed, according to some embodiments of the present invention. [Figure 10-2] 1 is a schematic diagram illustrating the state of Alice's primitive strategy before any exchanges have been performed, according to some embodiments of the present invention. [Figure 11] 1 is a schematic diagram illustrating the difference in relative changes in either half of Alice's strategy, according to some embodiments of the present invention. [Figure 12] 1 is a schematic diagram illustrating the difference in relative changes in either half of Alice's strategy, according to some embodiments of the present invention. [Figure 13a] A schematic diagram illustrating the accumulation of additional USDTKN at current prices, initially meeting its homogeneous bonding curve and gradually returning to the upper end of the re-accumulation target, in accordance with some embodiments of the present invention. [Figure 13b] FIG. 1 includes a graph showing the first case where Alice's balance of USDTKN exceeds yint on her curve, according to some embodiments of the present invention. [Figure 14] FIG. 1 illustrates components of a system for conducting cryptocurrency transactions using one or more bonding curves with values ​​for tunable parameters of the function, according to some embodiments of the present invention. [Figure 15] 1 is a flowchart illustrating a method for conducting cryptocurrency transactions using one or more bonding curves having values ​​for tunable parameters of a function, according to some embodiments of the present invention. [Figure 16] FIG. 1 is a sequence diagram illustrating the creation of two or more bonding curve strategies for converting virtual currencies, according to some embodiments of the present invention. [Figure 17]FIG. 1 is a sequence diagram illustrating depositing funds using the strategy according to some embodiments of the present invention. [Figure 18] FIG. 1 is a sequence diagram illustrating the withdrawal of funds using the strategy according to some embodiments of the present invention. [Figure 19] FIG. 1 is a sequence diagram illustrating a trade using the strategy according to some embodiments of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0034] In some embodiments thereof, the present invention relates to a decentralized application for managing virtual currency, and more particularly, but not exclusively, to a system and method for a decentralized application for customizable virtual currency trading.

[0035] As used herein, terms such as bonding curve, function, invariant function, novel invariant function, customizable function, and customizable invariant function are used interchangeably. A bonding curve may refer to a function having values ​​for adjustable parameters, as described herein. For example, a first bonding curve and a second bonding curve may be based on the same function and the same adjustable parameters but have different sets of values ​​assigned to the adjustable parameters. A first bonding curve may be defined by a first set of values ​​assigned to the adjustable parameters of the function. A second bonding curve may be defined by a second set of values ​​assigned to the adjustable parameters of the function.

[0036] The terms primary token and secondary token may be used interchangeably in some cases. The terms primary token and secondary token may be used arbitrarily, and either one of the two tokens and / or reserve and / or pool tokens may be primary and the other secondary. The terms primary and secondary are used for convenience and clarity. In most cases, the terms primary and secondary refer to tokens that cannot be minted and / or burned by a smart contract, and both tokens are managed by other external, unrelated smart contracts as cryptocurrencies traded on the open market, such as Bitcoin, Ethereum, etc.

[0037] As used herein, the terms virtual currency and token are used interchangeably. Tokens may be created for different purposes and / or uses, such as, for example, representation of currency, club membership points, frequent flyer points, reward points, part of a game, etc. Tokens may also be customized virtual currencies issued based on other virtual currencies offered by the Ethereum network, Lisk, RootStock, or other networks.

[0038] One aspect of some embodiments of the present invention relates to a system, method, computing device, and / or code instructions (stored on a data storage device and executable by one or more processors) for exchanging tokens via a distributed smart contract running on a blockchain using a bonding curve (optionally an asymmetric curve) with selectable and / or adaptable values ​​of adjustable parameters. The processor manages a primary reserve of tokens of a primary virtual currency. Values ​​of the adjustable parameters defining a function for calculating an exchange rate between the primary virtual currency and a secondary virtual currency are optionally obtained from a client terminal (e.g., used by a user). The values ​​may be customizable, e.g., selected and / or adapted by the client terminal. In response to a transaction request for conversion between a primary token and a secondary token of a secondary virtual currency, the processor executes the transaction request using a bonding curve defined by the function and the values ​​of the adjustable parameters.

[0039] The bonding curves may be asymmetric. A first bonding curve may provide for the conversion of secondary tokens to primary tokens by providing primary tokens in response to receiving secondary tokens. A second bonding curve, defined by a different value of the adjustable parameter, may provide for the conversion of primary tokens to secondary tokens by providing secondary tokens in response to receiving primary tokens. Different exchange rates may apply depending on the direction of the exchange (i.e., TO and FROM) according to the first and second bonding curves, even when the same amount is exchanged.

[0040] Optionally, multiple reserves of different types of virtual currencies are managed. Each reserve may be associated with one or more bonding curves that define exchanges between other virtual currencies and the managed virtual currency. Each reserve and bonding curve may be considered a primitive that defines a specific one-way exchange between two virtual currencies. Multiple primitives may be used to define a customizable set of one-way token exchanges. For example, to exchange token A to token C, a transaction may be defined as token A → token B → token C (i.e., there is no direct exchange from token A to token C). To exchange token A for token C, token A must first be exchanged for token B, and then token B must be exchanged for token C. As another example, a single primitive may be used alone to define a specific direction of conversion, for example, from one type of virtual currency to another type of virtual currency (e.g., token A → B). If a single primitive is used alone, a transaction from token B to token A cannot be performed.

[0041] At least some embodiments of the systems, methods, apparatus, and / or code instructions described herein address technical challenges associated with smart contracts that manage virtual currencies running on a blockchain and / or improve upon the art of smart contracts that manage virtual currencies running on a blockchain and / or improve upon the prior art of smart contracts that manage virtual currencies running on a blockchain.

[0042] At least some embodiments described herein address the technical challenge of improving the efficiency of computational and / or processing resource utilization for executing smart contracts that manage virtual currencies on a blockchain. For example, this can reduce processor utilization, processing time, memory usage, and / or storage requirements. Standard approaches for executing smart contracts that manage virtual currencies according to fixed rules do not distinguish between smart contracts that require additional processing and / or computational resources and those that can run on fewer processing and / or computational resources. At least some embodiments described herein address this technical challenge by enabling smart contracts to be customized based on the processing and / or computational resources they require. Customization, according to some embodiments, allows smart contracts that require additional processing and / or computational resources to acquire those resources. In contrast, using standard approaches, these smart contracts may not be allocated the additional resources or may incur increased costs for acquiring the additional resources. Customization, according to some embodiments, also allocates fewer processing resources to smart contracts that can run on fewer processing and / or computational resources. This avoids occupying resources that would otherwise be unnecessary, making those resources available for other smart contracts.

[0043] At least some embodiments of the systems, methods, apparatus, and / or code instructions described herein improve the computational efficiency of computing devices that execute smart code on a blockchain. This is achieved by reducing the computational resources required to execute the smart code, e.g., by providing lower processor utilization, faster processing time, and / or less allocated memory. Tunable parameters of functions seeded by smart contracts can be selected to run using fewer computational resources than those used by standard smart contracts that operate based on standard, fixed, non-customizable rules.

[0044] At least some embodiments described herein address the technical challenges associated with rigid rules in smart contracts governing virtual currencies. Users are bound by the rules defined by the smart contract. All users are bound by the same rules. This rigid rule, which applies to all users, limits the user experience. At least some embodiments described herein address the technical challenges described above by enabling users to customize smart contracts. Each user can define different customizations for their smart contract. Customizing smart contracts provides an improved user experience for users of smart contracts. Each user can define primitives that generate different bonding curves by setting different values ​​for tunable parameters of the function, with each bonding curve defining a specific direction of conversion from a first virtual currency to a second virtual currency. Depending on the user's preferences, a set of primitives can be defined to provide conversion between multiple virtual currencies. The ability to independently define a single primitive that defines only one-way transactions and does not allow reverse transactions contrasts with prior art, which only provides symmetric transactions between two virtual currencies. The configuration of linking multiple primitives to provide a set of one-way transactions for multiple cryptocurrencies, each with a different bonding curve, also contrasts with prior art that only provides symmetric transactions between two cryptocurrencies.

[0045] At least some embodiments described herein address the technical challenge of applying the same rules to both buying and selling cryptocurrencies. Users are bound by the same exchange rate that applies equally to both buying and selling. At least some embodiments described herein address the above technical challenge by allowing different rules to be applied to buying and selling. A user can define a first set of rules for buying and a second set of rules for selling. Allowing users to define different rules for buying and selling provides an improved user experience for users of smart contracts.

[0046] Examples of prior art relating to smart contracts managing virtual currencies running on a blockchain include, for example, U.S. Patent No. 11,188,896, entitled "SMART CONTRACT OF A BLOCKCHAIN ​​FOR MANAGEMENT OF CRYPTOCURRENCIES" (hereinafter referred to as "Patent '896") and / or U.S. Patent No. 11,574,291, entitled "METHODS FOR EXCHANGING AND EVALUATING VIRTUAL CURRENCY" (hereinafter referred to as "Patent '923"), filed on January 8, 2018, both of which are incorporated herein in their entirety and which have at least one common inventor with the present application.

[0047] At least some embodiments described herein improve the art of exchanging tokens between different participants within a decentralized application environment, such as a blockchain, and / or improve the implementation of smart contracts therefor.

[0048] At least some embodiments described herein improve upon decentralized finance (DeFi) application technology. DeFi applications are decentralized systems of applications built on public blockchains to fulfill the need for economic and / or financial primitives for cryptocurrencies. A decentralized exchange (DEX) is a protocol that enables permissionless exchange of cryptocurrency tokens between users. A typical example is a smart contract (a “liquidity pool”) that collects crowdsourced capital from users (the “liquidity providers”) and issues receiving tokens (the “pool tokens”) in return. The pool tokens represent the liquidity providers’ pro rata stake in the overall liquidity pool, so any percentage of the pool token supply is redeemable for the same percentage of the liquidity pool. The composition of the liquidity pool can change over time as users (the “traders”) exchange their tokens for tokens in the liquidity pool. DeFi applications use immutable function DEXs, where the exchange rate is determined by a mathematical formula that forces the liquidity pool’s composition to follow a predetermined profile (referred to as a “bonding curve”). Prominent examples are constant products and constant sums, although refinements to these concepts have also emerged to adjust the behavior of protocols and associated liquidity pools. The "value" function and the "stable swap" function are notable variations on common archetypes.

[0049] At least some embodiments described herein address the technical challenge of liquidity providers in DEXs being bound by the parameters of the liquidity pools to which they contribute their tokens. That is, the discretion of individual liquidity providers to determine their own exchange rates and implement precise trading strategies is constrained by a predetermined, generalized interpretation of their intentions. At least some embodiments described herein address the above technical challenge or improve upon the above-mentioned techniques by providing a means for users to provide liquidity according to their trading preferences. This is made possible by customizable, invariant functions encompassing an infinite set of bonding curves, which may include constant sum and / or constant product models. Thus, each liquidity provider can own their own liquidity pool and may be the only participant in that pool. Furthermore, because each liquidity pool can be controlled by a set of bonding curves rather than a single bonding curve, tokens can be deployed asymmetrically. While existing approaches assume that tokens sold by a liquidity pool are bought back by that pool at the same exchange rate, in the asymmetric paradigm described herein, the sell and buyback rates and their relative accelerations can be set independently of each other.

[0050] In general terms, some embodiments described herein support a "buy low, sell high" trading mindset, allowing liquidity providers to determine their own unique pool characteristics, supported by an infinitely customizable bonding curve and associated smart contract infrastructure. Each pool and its contents may be the proprietary property of its creator, or may be open to community participation by issuing its own pool token, the latter being a new type of subscriber trading product and a decentralized counterpart to the copy trading of traditional centralized exchanges.

[0051] As can be seen, the improvements according to at least some of the embodiments described herein address technical challenges that have significantly limited the applicability of the DEX protocol.

[0052] At least some embodiments described herein address the above-mentioned technical challenges or improve upon the above-mentioned techniques by using an asymmetric liquidity pool design using an invariant function and / or an infinite set of associated bonding curves and / or one or more instances of these bonding curves to support any trading strategy across any number of cryptocurrency tokens within the same pool.

[0053] At least some embodiments described herein address the above-mentioned technical challenges or improve upon the above-mentioned techniques by providing an immutable function, together with adjustable parameters, that allows users to determine the behavior of a liquidity pool with respect to exchange rates and price acceleration for all liquidity contained in that pool. Unlike conventional approaches, the functions described herein are (optionally infinitely) customizable. This customizable function may be limited in scope, precision, and / or resolution by the virtual machine of the distributed ledger system on which it is deployed.

[0054] At least some embodiments described herein address the above-mentioned technical challenges or improve upon the above-mentioned techniques by providing an asymmetric liquidity pool, as described herein. The asymmetric liquidity pool is designed to simultaneously use multiple bonding curves to achieve an explicit trading profile that aligns with the creator's objectives and biases. Unlike traditional approaches, the asymmetric liquidity pool allows decisive action by liquidity providers. The asymmetric liquidity pool allows for the execution of planned plans while maintaining liquidity in the cryptocurrency token economy.

[0055] Different subsets of adjustable parameters may be defined (e.g., over-parameterization), and specific forms of invariant functions may be explicitly derived from these subsets, which belong to a larger set of possible groupings of curve parameters and associated rearrangements of the general formula. This flexibility allows for application-specific constraints to be accommodated, including, but not limited to, computational precision when floating-point arithmetic is unavailable, overflow and underflow prevention, the use of unsigned integers, computational complexity, storage and memory requirements, or direct or indirect constraints imposed by the underlying hardware or software that determine the function's output.

[0056] At least some embodiments described herein improve upon traditional approaches. For example, in DeFi protocols currently using a centralized liquidity model, exchanges are reversible, and users who provide tokens to a smart contract system exchange them in both directions according to the system's state. This manifests as a symmetric exchange profile, excluding nominal fees, which forces users of the protocol to accept reverse exchanges at the same rate as forward exchanges. In contrast, at least some embodiments described herein improve upon traditional approaches by setting forward and reverse exchange rates separately and, optionally, giving users full control. Thus, unlike traditional AMMs, a user's position is simultaneously described by two or more bonding curves. This configuration creates a technical feature in DeFi smart contract systems and represents a technical improvement over existing approaches. The asymmetric liquidity pool configuration provides what can best be described as support for automated trading strategies, in addition to formal limit order functionality. The term "user strategy" is used herein as a specific analogy for liquidity provision. Each strategy can be usefully interpreted as its own liquidity pool, given the established meaning of that term. However, the behavior of the strategies described herein differs significantly from standard DeFi archetypes, except that each is a smart contract system involving cryptocurrency tokens for the express purpose of conducting an exchange.

[0057] Furthermore, as described herein, the initial calculations of B and S are performed during strategy creation, which can be performed with the assistance of off-chain resources, and the on-chain calculations performed during subsequent swaps (optionally only) use only basic mathematical operations: addition, subtraction, multiplication, and division. This is also true for the formulas described herein for calculating marginal exchange rates and swaps. This eliminates the need for Taylor expansions or other polynomial approximations, numerical analysis techniques for generating function outputs, etc. The freedom to select appropriate parameters and / or customized formulas to suit the virtual machine on which a decentralized application runs addresses the technical challenge of reducing the amount of computational resources required to execute a smart contract.

[0058] The embodiments described herein will now be described in detail with respect to their use to improve the computational efficiency of computing devices (e.g., processors) that execute smart contracts and / or other distributed applications on a blockchain.

[0059] Mathematical computations on size-constrained fixed-point infrastructures involve a fundamental trade-off between precision and valid input range. In any computation, the only type of operation that can reduce the precision of the output is division. The usual solution is to restructure the computation so that division is performed only as the final step. However, as a result, intermediate results of the computation become prone to overflow, causing the entire transaction to be unwound. This means that restructuring the computation effectively narrows the range of inputs that can be successfully processed. For example, consider the following expression:

number

number

[0060] Below, we elaborate on these concepts with a view to distinguishing between mathematically redundant but computationally distinct versions of the invariant functions described in this disclosure. First, we consider an implementation of the invariant function using constants x0, y0, and n, and another implementation using constants S, B, and y int Two different implementations are described in comparison with each other, with another immutable function implementation using

[0000] . Next, the flexibility of the implementation described herein is briefly compared with Uniswap V3 and Kyber DMM, which are industry standards for centralized liquidity based on embodiments described with reference to the '896 and / or '923 patents.

[0061] Some embodiments of the present disclosure relate to asymmetric liquidity systems, including (so-called centralized liquidity) bonding curves. Each bonding curve can be described by a set of parameters that define its unique price behavior. Because each parameter can be expressed in terms of other parameters, it is possible to present intuitive choices to users and process their input to transform the data into a more computationally tractable form while preserving its meaning. From a product perspective, users need only decide the price interval at which they will offer their liquidity to the market and the number of tokens they will include in that price interval. Note that the user choices presented here are accurate but simplified. The purpose of this description is not to exhaustively discuss the full range of applicability, but rather to demonstrate the flexibility of some embodiment implementations given the constraints of the computing environment in which they are executed. These user-facing parameters are defined in more detail herein. A simplified version is presented below, focusing only on the parameters presented to the user before further processing.

[0062] [Table 1]

[0063] Using these inputs, it is contemplated that any term described herein can be accessed using the formulas contained herein. For example, parameters n, y0, and x0 can be calculated using formulas 11b, 11d, and 13n described herein.

number

[0064] This processing allows the protocol to use Equations 2d-h, which are invariant functions described herein. For clarity, each of these forms may be redundant with one another; that is, they may be different algebraic expressions of the fundamental relationships that exist between the constants n, y0, and x0 and the points (x, y) that satisfy those relationships.

number

[0065] The x and y coordinates can be defined relative to each other using Equations 3-4e described herein. The marginal price equation is defined by Equations 5-6e described herein. The token swap equation and swap-dependent price equation are defined by Equations 7-10e described herein. To make this explanation easier to understand, Equation 8e is modified to use Δx as the main term, and is referred to as Equation S1. Equation 8e is a general swap equation, where -Δy indicates the quantity of target tokens a trader will receive in exchange for Δx source tokens. This equation is appropriate when a trader specifies Δx (the amount to pay) and measures -Δy (the amount to receive). Equation S1 is an inverse swap equation, appropriate for calculating the transaction volume Δx required to achieve a trader's request to receive -Δy target tokens.

number

[0066] P a and P b are expected to remain constant until the user changes their values, whereas y int Note that may change as a result of normal protocol operation. Some information may be pre-computed before execution (i.e., in advance). Pre-computed information can be found at runtime to achieve the following: Improved accuracy (reduced accuracy loss) Improved performance (reduced gas costs)

[0067] For example, the following can be pre-computed:

number

[0068] In fixed-point infrastructures like Ethereum (and other blockchains), each constant must have a scaling factor applied to it to remove any fractional part, and only the integer part of each resulting value must be used. Runtime calculations must take all of these scaling factors into account, undoing the scaling of intermediate results as needed. The scaling of each constant value must be high enough that the loss of precision is negligible, but at the same time not so high that it falls below system requirements to avoid invalid input ranges that would cause arithmetic overflows.

[0069] Another approach based on at least some embodiments described herein is described below: The parameters S and B (Eqs. 20a-c) described herein may be calculated directly from user inputs as shown in Table S1.

number

[0070] Processing in this manner provides access to Equation 21a, an invariant function described herein. The x and y coordinates can be defined relative to one another using Equations 21b-c described herein. The marginal price equation is defined by Equations 21d-e described herein. The token swap equation and swap-dependent price equation are defined by Equations 21f-i described herein. To make this explanation easier to understand, Equation 21g is modified to use Δx as the main term, and is referred to as Equation S2. Equation 21g is a general swap equation, where -Δy is suitable for a trader specifying Δx source tokens and representing the quantity of target tokens they will receive in exchange. Equation S2 is a reverse swap equation, suitable for a trader requesting -Δy as target tokens and calculating the trading volume Δx required to achieve this.

number

[0071] A comparison of two different implementations based on the theory detailed herein is given in the invariant function expressions Equation 2h (using constants x0, y0, and n) and Equation 21a (using constants S, B, and y int In both cases, three constant values ​​must be maintained in addition to the token balance y. However, the latter implementation has the following advantages: Total number of operations (e.g., gas cost) Total number of division operations (e.g., loss of precision) The overall size of intermediate results (e.g., the possibility of overflow)

[0072] y int In the implementation using S and B, y is used directly as its own constant, so there is no loss of precision in processing after receiving it as input from the user. int The user's liquidity is calculated based on the specified price range P a and P bNote that this parameter is dynamically adjusted by the protocol during normal operation as needed to keep it within this range. This aspect of the disclosure is described herein, and examples of updating this parameter are provided, for example, in Tables 5, 7, and 11. int There are also ongoing operational benefits to using directly: Under certain conditions, it may be necessary to update the size of the user's curve, as shown in FIG. 11 and described herein.

[0073] When this situation occurs, both the x0 and y0 constants need to be updated, but the y int In an implementation that uses y as the constant itself, int Only y needs to be updated. int Direct updates to y do not require any numerical computation. These updates are made when the token balance y is updated to y int occurs when the value of y exceeds int is updated to be equal to y. The Boolean operations required to compare two numbers and update one equal to the other are computationally trivial. On the other hand, implementations involving x0 and y0 are significantly more complex. First, this conditional statement converts the stored constants y0 and n to y before performing the Boolean operations. int Then, if an update is required, a new y int The need to re-decompose the values ​​of into x0 and y0 further increases the computational burden and introduces additional accuracy issues. As mentioned above, the optimal scaling factors for the values ​​of S and B are: Each scaling factor must be high enough that the loss of precision is negligible. · Each scaling factor must not be so high as to cause a runtime overflow.

[0074] An additional consideration is the overall size required to store these values ​​in a contract on a blockchain such as Ethereum. On-chain storage read and write operations are typically among the most gas-intensive, so storing the four values ​​(y, y int,S,B) It is desirable to keep everything in as little storage as possible.

[0075] At least some implementations according to the embodiments described herein include an entity referred to herein as a strategy. Each strategy may include two or more entities referred to herein as orders. Each order may include the four values ​​described above. Thus, each strategy includes two sets of these four values. Strategies may be created, for example, by a market maker (i.e., a liquidity provider) or traded by a market taker (i.e., a trader). Each strategy may be traded independently of all other strategies. When targeted for trading, the following storage access operations may be performed:

[0076] [Table 2]

[0077] A source order can refer to a component of a strategy of a maker (e.g., liquidity provider) that has a token balance with the same identity as what a taker (e.g., trader) is sending to the protocol. For example, if a trader sends TKN1 to the protocol and receives TKN2, the maker's order with a balance of TKN1 is the source order.

[0078] A target order can be referred to as the opposite of a source order. Using the example above, the manufacturer's order with a balance of TKN2 is the target order.

[0079] In an example implementation, 112 bits are typically sufficient to represent y (e.g., current token balance / liquidity), which is approximately 5×10 33This means that it can handle very large numbers, such as 5 followed by 33 zeros, and is large enough to represent any practical balance, even in tokens with a large number of decimal places. For example, If the token has 18 decimal digits, the maximum is 5×10 15 (500 billion) tokens allowed, If the token has 22 decimal digits, the maximum is 5×10 11 (500 billion) tokens allowed, If the token has 24 decimal digits, the maximum is 5 x 10 9 (5 billion) tokens allowed.

[0080] y int The value of is also derived directly from the value of y, so it requires the same number of bits (112 bits).

[0081] The value B, which stores the square root of the lowest exchange rate, may need to be scaled to an integer value large enough to hold most of the information. Allocate 64 bits to this and 2 32 By scaling by the factor of B, B becomes 1 / 2 32 From 2 32 The range of values ​​is 1 / 2 resolution. 32 This allows the effective exchange rate to be expressed as 1 / 2 64 From 2 64 On average, 1 / 2 of the range 16 It may be possible to obtain a resolution of

[0082] Similarly, for the value S that stores the difference between the square root of the highest exchange rate and the square root of the lowest exchange rate, 64 bits are allocated to it, and 2 32 By scaling by the factor of , S becomes 1 / 2 32 From 2 32 The range of values ​​is 1 / 2 resolution. 32 This allows the effective exchange rate to be expressed as 1 / 2 64 From 2 64 On average, 1 / 2 of the range16 It may be possible to obtain a resolution of

[0083] Therefore, each strategy requires 2 x (112 + 112 + 64 + 64) = 704 bits. It is important to note that the unpredictable token fractional digits (i.e., the atomicity characteristic of cryptocurrency tokens) require a relatively large amount of storage allocation, while the constants S and B are relatively insensitive to fluctuations and can be adequately implemented with less storage. Referring to Table 2, an example layout for the storage of these values ​​could be as follows:

[0084] Below is an example layout for the storage of these values: Slot #1: y(source), y(target) Slot #2:y int (Source), S(Source), B(Source) Slot #3:y int (Target), S(Target), B(Target) This gives us the following for each trade in a particular strategy: Exactly 3 slot read operations One or two slot write operations

[0085] Encoding / Decoding Using: L = Minimum order rate H = Highest rate of order M = marginal rate of order Given the following: min=floor(2 32 ×√(L)) max=floor(2 32 ×√(H)) mid=floor(2 32 ×√(M)) An order holds: y=current liquidity · yint = Current Liquidity x (max-min) / (mid-min) S=max-min B=min The order reflects the following: L=(B / 2 32 ) 2 H=((B+S) / 2 32 ) 2 M=((B+S×y / y int ) / 2 32 ) 2

[0086] Transaction Calculation [Table 3]

[0087] The function mulDiv(m,n,d) returns the value of m×n÷d, allowing intermediate values ​​of m×n to exceed 256 bits. This function overflows (reverts) only if the final result exceeds 256 bits.

[0088] The following can be observed: In the function getTradeTargetAmount, - Overflows can cause transaction reverts - Possible loss of precision due to two division operations. In the function getTradeSourceAmount, - Transaction reverts can occur due to overflows or underflows - A single division operation can cause precision loss.

[0089] However, overflow and underflow occur depending on the input value (Δx) and the system state (y and y int) combinations. Also, because the number of division operations performed in each function is very small, loss of precision is expected to be minimal.

[0090] Here are some comparisons with industry standards:

[0091] There are two similar examples in the industry that are comparable to the implementation considerations presented herein. One example is Uniswap V3, which is described in the white paper "Uniswap v3 Core (Adams, H.; Zinsmeister, N.; Salem, M.; Keefer, R.; Robinson, D., 2021)." These authors introduce an immutable function of the form S3, which is essentially redundant with the amplified token reserve described in connection with the '896 patent. For clarity, we will refer to the constant P as a constant P, consistent with the meaning herein. a and P b However, the meanings of these two parameters are reversed in the white paper. The constant L can be expressed in terms of x0, y0, and n, as shown in equation S4. This derivation is not given in Adams et al.'s paper, but is presented here for explanatory purposes.

number

[0092] The constant L is redundant with x0, y0, and n, and so has the same drawbacks as the implementation using these constants mentioned above.

[0093] As another example, the Kyber DMM whitepaper, Dynamic Automated Market Making (Nguyen, A.; Luu, L.; Ng, M., 2021) presents a rudimentary derivation of the constants x0 and y0 and introduces an amplification term a, which corresponds to the inverse of n (i.e., the term u herein) and is redundant with the essentially amplified token reserve described in the '896 patent. Unlike the Uniswap paper, Nguyen et al.'s paper does not include a new immutable function. Instead, it refers to a hypothetical token balance that simulates a larger bonding curve (Excerpt S1).

[0094] [Table 4]

[0095] In the Kyber DMM implementation, four token balances are managed: two real and two virtual. While the total number of parameters required to describe a centralized liquidity profile is the same, this approach of using both real and virtual token balances requires that all four parameters be read from and written to storage for every transaction. It is not clear how this approach would apply to asymmetric systems, but it is certain that at least two additional virtual balances would be required. As mentioned above, token balances require very large integers for accurate calculations, which consumes a significant amount of storage, posing a significant problem in terms of gas consumption and overall network load. Furthermore, the size of the curve (e.g., y intAdjusting the S value (equivalent to S) typically requires updating three or more token balances simultaneously, which is complex and expensive. Because of the extremely large integers required to support such an implementation, each of the three balance updates likely involves reading and writing to separate memory slots on the Ethereum Virtual Machine. This can result in unrealistic virtual token balances in the case of high amplification factors. For example, the implementation described here can easily handle a zero S value, whereas Nguyen et al.'s scheme would require infinite virtual token balances in the same situation.

[0096] It should be emphasized that neither Uniswap V3 nor Kyber DMM address asymmetric liquidity, and both of these systems are redundant with the hypothetically amplified token reserves described in the '896 patent, which must address additional implementation challenges unrelated to the embodiments described herein. Aspects of the handling of immutable functions described herein improve the computational performance of computers and / or processors running smart contracts, blockchains, and other decentralized applications, enabled by over-parameterization, relative to existing approaches.

[0097] Before describing at least one embodiment of the present invention in detail, it is to be understood that the invention is not necessarily limited in its application to the details of construction and arrangement of components set forth in the following description and / or drawings and / or examples. The invention is capable of other embodiments and of being practiced or carried out in various ways.

[0098] The present invention may be a system, a method, and / or a computer program product. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions stored thereon for causing a processor to execute each of the components of the present invention.

[0099] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. Computer-readable storage media include, but are not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or suitable combinations of the above. More specific examples of computer-readable storage media include, but are not limited to, portable computer diskettes, hard disks, random access memories (RAMs), read-only memories (ROMs), erasable programmable read-only memories (EPROMs or flash memories), static random access memories (SRAMs), portable compact disk read-only memories (CD-ROMs), digital versatile disks (DVDs), memory sticks, floppy disks, and suitable combinations of the above. As used herein, the term "computer-readable storage medium" should not be construed as a mobile signal per se, such as radio waves or other electromagnetic waves propagating through free space, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted through wires.

[0100] The computer-readable program instructions described herein may be downloaded to a respective computing / processing device from a computer-readable storage medium or to an external computer or storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, fiber optic transmission cables, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to a computer-readable storage medium within the respective computing / processing device for storage.

[0101] Computer-readable program instructions for carrying out the operations of the present invention may be any combination of assembly language instructions, instruction set architecture (ISA) instructions, machine language instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or source or object code written in one or more programming languages, including, but not limited to, object-oriented programming languages ​​such as Smalltalk and C++, as well as traditional procedural programming languages ​​such as the "C" programming language. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on both the user's computer and a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, such as a local area network (LAN) or a wide area network (WAN), or the connection to the external computer may be via the Internet using an Internet service provider. In some embodiments, electronic circuitry, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), can utilize state information from computer-readable program instructions to personalize the electronic circuitry to perform aspects of the present invention.

[0102] Aspects of the present invention are described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0103] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, and when these instructions are executed by the processor of the computer or other programmable data processing apparatus, they produce means for implementing the functions / acts specified in the flowchart and / or block diagram blocks. These computer-readable program instructions may also be stored on a computer-readable storage medium that can cause a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the instructions stored on the storage medium constitute an article of manufacture containing instructions that implement the functions / acts specified in the flowchart and / or block diagram blocks.

[0104] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process, where the instructions executing on the computer, other programmable apparatus, or other device implement the functions / operations specified in the flowchart and / or block diagram blocks.

[0105] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In alternative embodiments, the functions depicted in the blocks may be performed out of the order depicted in the figures. For example, two blocks shown in succession may actually be executed substantially concurrently or may be executed in the reverse order, depending on the functionality. It should also be noted that each block of the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations or executes a combination of special-purpose hardware and computer instructions.

[0106] Referring now to FIGS. 1a-c, these are schematic diagrams illustrating an invariant function characterized by a point with coordinates x=x0, y=y0 on its contour curve (which coincides with the graph of Equations 1a-c), according to some embodiments of the present invention. Also referring to FIGS. 2a-c, these are schematic diagrams illustrating the case where the negative slope (-dy / dx) of the tangent at the point is P and is equal in both the contour curve of the customizable function and the contour curve of Equations 1d-e, according to some embodiments of the present invention. Also referring to FIGS. 3a-g, these are schematic diagrams illustrating the case where the parameter k is a hyperbolic constant in Equations 1a-c (i.e., xy=k) and indicates the magnitude of the contour curve of a constant volume that shares coordinates x=x0, y=y0 with the contour curve of the novel invariant function, according to some embodiments of the present invention. Also referring to FIGS. 4a-l, these are schematic diagrams illustrating the case where the parameter x is a hyperbolic constant in Equations 1a-c (i.e., xy=k) and indicates the magnitude of the contour curve of a constant volume that shares coordinates x=x0, y=y0 with the contour curve of the novel invariant function, according to some embodiments of the present invention. asym and y asym 5a-g are schematic diagrams showing the "vertical" and "horizontal" asymptotes of the decay curve of the novel function, respectively. Also, referring to Figures 5a-g, these figures show the "vertical" and "horizontal" asymptotes of the decay curve of the novel function, respectively, as a function of the parameter xint and y int 6a-f are schematic diagrams showing the x- and y-intercepts of the new function's y-intercept curve, y=y, in accordance with some embodiments of the present invention. int and x-intercept x=x int The slope of the tangent at a and P b , y, y). Also, referring to FIGS. 7a-b, these are schematic diagrams illustrating exemplary methods for detecting parameters n and u, which indicate the relative sizes of two rectangles, according to some embodiments of the present invention. Also, referring to FIGS. 7c-d, these are schematic diagrams illustrating exemplary methods for detecting parameter Q, which indicates the relative sizes of two rectangles, according to some embodiments of the present invention. Also, referring to FIGS. 8a-c, these are schematic diagrams illustrating the case where Equation 22 uses n instead of f(x), according to some embodiments of the present invention. Also, referring to FIGS. 9a-c, these are schematic diagrams illustrating the case where Equation 23a-c uses n instead of f(a, x, x0, y, y0), according to some embodiments of the present invention. Also, referring to FIG. 10, these are schematic diagrams illustrating the state of Alice's original strategy before any exchanges are performed, according to some embodiments of the present invention. Also, referring to FIG. 11, these are schematic diagrams illustrating the difference in relative changes in either half of Alice's strategy, according to some embodiments of the present invention. Also, reference is made to Figure 12, which is a schematic diagram illustrating the difference in relative changes in either half of Alice's strategy, according to some embodiments of the present invention. Also, reference is made to Figure 13a, which is a schematic diagram illustrating the difference in relative changes in either half of Alice's strategy, according to some embodiments of the present invention, according to some embodiments of the present invention. TKN 13b, which is a schematic diagram showing Alice's USD accumulation in accordance with some embodiments of the present invention. TKN The balance of y on its own curve int14 is a diagram including a graph showing the first case where the value of the bonding curve exceeds the threshold. Also, reference is made to FIG. 14, which illustrates components of a system for executing virtual currency transactions using one or more bonding curves having values ​​of tunable parameters of a function, in accordance with some embodiments of the present invention. Also, reference is made to FIG. 15, which is a flowchart illustrating a method for executing virtual currency transactions using one or more bonding curves having values ​​of tunable parameters of a function, in accordance with some embodiments of the present invention. Also, reference is made to FIG. 16, which is a sequence diagram illustrating the creation of a strategy of two or more bonding curves for converting virtual currency, in accordance with some embodiments of the present invention. Also, reference is made to FIG. 17, which is a sequence diagram illustrating the deposit of funds using the strategy, in accordance with some embodiments of the present invention. Also, reference is made to FIG. 18, which is a sequence diagram illustrating the withdrawal of funds using the strategy, in accordance with some embodiments of the present invention. Also, reference is made to FIG. 19, which is a sequence diagram illustrating a transaction using the strategy, in accordance with some embodiments of the present invention.

[0107] Referring again to FIG. 14, the system 100 may implement the methods described with reference to FIGS. 1-13 and 15-19.

[0108] The system 100 includes multiple computing devices 102, each functioning as a respective network node (for clarity and brevity, an example is illustrated in which one computing device 102 functions as a network node). The computing devices 102 may be geographically distributed. Examples of computing devices 102 include servers, computing clouds, virtual machines, virtual servers, client terminals, desktop computers, kiosks, mobile devices, smartphones, tablet computers, laptop computers, wearable computers, augmented reality glasses, eyeglass computers, watch computers, etc.

[0109] Each computing device 102 includes one or more hardware processors 104, such as a central processing unit (CPU), a graphics processing unit (GPU), a field programmable gate array (FPGA), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), etc. Processor 104 may include one or more homogeneous or heterogeneous processors, which may be configured as a cluster for parallel processing or as one or more multi-core processing units.

[0110] Each computing device 102 includes memory 106 for storing code instructions executable by the hardware processor 104, including, for example, random access memory (RAM), read-only memory (ROM), and / or storage devices such as non-volatile memory, magnetic media, semiconductor memory devices, hard drives, removable storage, optical media (e.g., DVD, CD-ROM), etc.

[0111] The memory 106 stores smart contract code 108 (also referred to as distributed smart contract code) that runs on the blockchain 110.

[0112] It should be noted that the blockchain described herein is one example of a distributed application environment and / or a distributed ledger. Other implementations of a distributed application environment and / or a distributed ledger may use a directed acyclic graph.

[0113] When executed by the hardware processor 104, the smart contract code 108 implements one or more functions and / or operations of the methods described with reference to Figures 1-13 and 15-19. The smart contract code 108 manages one or more cryptocurrency reserves 108A as described herein. The smart contract code 108 provides exchange services between primary and secondary tokens using a bonding curve defined by values ​​of tunable parameters of a function. The values ​​of the tunable parameters may be stored in a tunable parameter repository 108B, which may be included in the blockchain 110 or stored in another storage device, such as offline. Transactions performed on the reserves 108A by the smart contract code 108 may be recorded in a distributed ledger 108C, which may be stored in the blockchain 110.

[0114] It should be noted that different smart contracts 108 executing on the same computing device 102 and / or different computing devices 102 may provide exchange and / or deposit and / or withdrawal services for different combinations of virtual currencies using different bonding curves. Optionally, each smart contract 108 manages a reserve 108A that holds at least one type of virtual currency and performs exchanges between tokens in the reserve and other tokens according to bonding curves defined by values ​​of tunable parameters of a function. The values ​​of these tunable parameters may be stored in a tunable parameter repository 108B. The values ​​of the tunable parameters may be selected by a user.

[0115] Optionally, the reserve and bonding curve may be implemented as components of a single smart contract 108. Alternatively, the reserve and bonding curve may be implemented as components of a set of smart contracts 108. Furthermore, each reserve and bonding curve may be implemented in its own dedicated smart contract. Multiple reserves and their associated bonding curves may be managed using a set of smart contracts.

[0116] A single decentralized smart contract running on the blockchain may implement different sets of values ​​for the tunable parameters for each separate instance of the function. A single decentralized smart contract may implement each reserve of a token, and the corresponding bonding curve defined by the function with different sets of values ​​for the tunable parameters may define a primitive for one-way exchange between an external token and a token in the reserve. Multiple primitives may be connected together to define one-way routes for token exchange.

[0117] The computing device 102 includes a data storage device 112 for storing data. The data storage device 112 may be implemented, for example, as memory, a local hard drive, virtual memory, a removable storage unit, an optical disk, a storage device, and / or a remote server and / or computing cloud (e.g., accessed using a network connection). One or more of the blockchain 110, smart contract code 108, reserve 108A, tunable parameter repository 108B, and / or ledger 108C, or portions thereof, may be stored in the data storage device 112 and loaded from the data storage device 112 into memory 106 for execution by the processor 104.

[0118] The computing devices 102 may act as network nodes and communicate with each other to update their respective copies of the blockchain 110 and / or distributed transaction ledger 108C.

[0119] Each computing device 102 provides token exchange services and / or token deposit services and / or token withdrawal services to a plurality of client terminals 114 via the network 116 .

[0120] The computing device 102 may include a network interface 118, such as a network interface card, a wireless interface for connecting to a wireless network, a physical interface for connecting to a cable for network connection, a virtual interface implemented in software, network communications software that provides a higher layer of network connectivity, and / or combinations thereof.

[0121] The network 116 may be implemented as, for example, the Internet, a local area network, a virtual network, a wireless network, a cellular network, a local bus, a point-to-point link (eg, wired), and / or combinations thereof.

[0122] The client terminal 114 may be implemented as, for example, a server, a computing cloud, a virtual machine, a virtual server, a desktop computer, a kiosk, a mobile device, a smartphone, a tablet computer, a laptop computer, a wearable computer, augmented reality glasses, a glasses-type computer, and a watch-type computer.

[0123] The client terminal 114 may access and / or communicate with the smart contract code 108 to execute transactions (e.g., exchanges, deposits, withdrawals), for example, using an accessible software interface of the smart contract function code 108, such as through a graphical user interface (GUI), an application programming interface (API), a software development kit (SDK), and / or the transmission of messages specifying the performance of predetermined functions. The smart contract code 108 may be accessed directly or indirectly via other applications, such as a wallet management application, that access the smart contract code 108 and execute transactions.

[0124] Optionally, the client terminal 114 that provides the adjustable parameters (e.g., stored in repository 108B) for defining a bonding curve is different from other client terminals that perform exchanges using that bonding curve.

[0125] The computing device 102 and / or client terminal 114 include and / or are in communication with one or more physical user interfaces 122, which include mechanisms for a user to input data (e.g., data for conducting a transaction involving the primary token and / or secondary token) or display data (e.g., data for displaying the results of such a transaction). The user interface 122 may present a GUI that includes mechanisms for inputting and / or displaying data. Examples of user interfaces 122 include, for example, one or more of a touchscreen, a display, a gesture sensing device, a keyboard, a mouse, voice recognition software using a speaker, and a microphone.

[0126] Referring again to FIG. 15, at 202, one or more hardware processors of a networked server execute code of a distributed smart contract of the blockchain to manage a primary reserve of tokens of a primary virtual currency.

[0127] Note that the term "primary" is used for clarity to describe the exchange of primary tokens with secondary tokens, but is not intended to necessarily limit and / or define the primary token. For example, there may be multiple primary reserves, each of which may trade between external tokens, which may be referred to as secondary tokens, and the reserve's corresponding primary token.

[0128] Optionally, each primary reserve is managed independently without necessarily managing a secondary reserve of the secondary token of the secondary virtual currency. The secondary reserve may be managed independently of the primary reserve, and a link may be defined between the primary reserve and the secondary reserve for processing transactions, as described herein. This contrasts with conventional approaches that manage a pair of reserves together, where transactions between the two reserves are symmetric, i.e., use the same exchange rate.

[0129] At 204, values ​​of one or more adjustable parameters that define a function for calculating an exchange rate between the primary virtual currency and the secondary virtual currency are obtained.

[0130] Optionally, a subset of tunable parameters is selected from the candidate set of tunable parameters, which may be based on specified values, such that tunable parameters with a given value are selected and those with no specified value are not selected (or their value is treated as zero or undefined).

[0131] In this specification, the terms selecting a value for a tunable parameter and selecting a tunable parameter may be used interchangeably depending on the context.

[0132] Optionally, multiple decentralized smart contracts may be configured to run on the blockchain. Each decentralized smart contract may manage a different token reserve. Each decentralized smart contract corresponding to each reserve may be configured as a different function instance with its own set of tunable parameters to define its own bonding curve. Note that while the tunable parameters used are common to all bonding curves, the values ​​set for each bonding curve may be different.

[0133] Optionally, each reserve of a token and its corresponding bonding curve (i.e., defined by a function based on a different set of adjustable parameters) constitutes a primitive for unidirectional exchange between an external token and the tokens in that reserve. Combining and connecting multiple such primitives defines a unidirectional exchange route for a token exchange. In this manner, multiple bonding curves (i.e., corresponding to multiple primitives) linked to realize exchanges between multiple virtual currencies are referred to herein as a strategy.

[0134] For example, in an exchange between two tokens (A and B), two bonding curves would be set up, one in each direction, to indicate a sale to exchange for the other token in the pair, as shown below: A → B B → A

[0135] For three tokens (A, B, C), up to six bonding curves can be configured, although the number configured by the user can be less than six. A → B B → A A → C C → A B → C C → B

[0136] With four tokens (A, B, C, D), a maximum of 12 curves can be set, although the user may set fewer than 12. A → B B → A A → C C → A A → D D → A B → C C → B B → D D → B C → D D → C

[0137] And so on. The maximum number of discrete bonding curves for any number of tokens is: n = number of tokens m = number of bonding curves m=(2×n!) / (2×(n-2)!)

[0138] Choosing different values ​​for the same tunable parameters allows customization of the function for each user, or using defined primitives allows each user to define their own one-way token translation path.

[0139] For example, two different users can use different instances of the same smart contract, using the same token, but with different sets of tunable parameters for the same function. These tunable parameters allow two different users to define different bonding curves, even when trading the same token. This contrasts with traditional approaches, where two users are limited to the same bonding curve and cannot customize the tunable parameters.

[0140] These values ​​may be obtained, for example, from a client terminal (e.g., a user's) in communication with a networked server, for example via a user interface, optionally a graphical user interface (GUI), a file stored in a data storage device, and / or by automatically calculated means.

[0141] Alternatively or additionally, these values ​​may be calculated automatically by the running process. For example, if the parameters are for meeting hardware and / or software resource requirements for the execution of a smart contract, the running process may automatically determine the resource requirements and automatically select values ​​for the tunable parameters according to the determined resource requirements. The running process may dynamically monitor the performance of the running smart contract (e.g., relative to a target performance level) and dynamically adapt the values ​​of the tunable parameters so that the running process meets and / or maintains the target performance level and / or hardware and / or software resource requirements. Such dynamic monitoring and / or dynamic adaptation may be performed, for example, after each transaction, after multiple transactions, after a period of time (e.g., an hour, a day, a week, a month, etc.), and / or after an event occurs (e.g., detection of software and / or hardware installation and / or detection of other events that may affect performance).

[0142] The term hardware and / or software resource requirements may refer to target performance, e.g., values ​​of tunable parameters are calculated to meet target performance (e.g., of hardware and / or software resources).

[0143] Optionally, the tunable parameters are selected to meet hardware and / or software resource requirements (e.g., performance requirements) for the execution of the code of the distributed smart contract. Examples of resource requirements include one or more of: computational precision in the absence of floating-point arithmetic, overflow, underflow, unsigned integers, computational complexity, storage requirements, and memory requirements.

[0144] Optionally, each parameter is assigned to a set of sets, and each parameter in each set is mathematically related to other parameters in the set, and / or each parameter is also mathematically related to other parameters among other sets, sufficient to unambiguously describe a unique invariant function-implicit curve pair.

[0145] This function may represent (eg, all) exchange rates for combinations of primary and secondary tokens and one-way conversions of primary tokens to secondary tokens.

[0146] One of the x-axis and y-axis may represent the balance of the first reserve, while the other may be undefined (e.g., meaningless, arbitrary). The other axis is not necessarily required because the limit exchange rate for conversion between the first virtual currency and the second virtual currency is calculated according to the first derivative of the associated bonding curve. In calculating the first derivative and determining the limit exchange rate, the other axis is not necessarily required. The bonding curve may represent (e.g., all) exchange rates for conversion between the first token and the secondary token.

[0147] The function may be defined based on a hyperbola having asymptotes at x=0 and y=0. The hyperbola may be expressed as xy=k, where x represents a primary token and y represents a secondary token. The function may include one or more adjustable asymptotes. A graph of the function may have at least one common point with a constant-volume bonding curve expressed as xy=k. The slope of the bonding curve at this common point may coincide with the first derivative of xy=k. Each bonding curve may be defined to have a point on its curve at coordinates x=x0 and y=y0 whose first derivative is equal to the first derivative of the constant-volume bonding curve at the same coordinates.

[0148] A bonding curve may be defined as a curve of a constant function and used to enumerate a continuous exchange rate between a primary virtual currency and a secondary virtual currency. Alternatively or additionally, the bonding curve may be defined as a secant connecting two points of the function, which may be separated by a continuous midpoint. The bonding curve may be defined as the slope of the secant. The bonding curve may define multiple exchange rates for conversion between the primary virtual currency and the secondary virtual currency. Each exchange rate for conversion between the primary virtual currency and the secondary virtual currency may be represented as a secant between two points of the function. The first point represents the balance of the primary reserve before the exchange occurs, and the second point represents the balance of the primary reserve after the exchange occurs.

[0149] The adjustable parameters may be, for example: n P, which indicates the start of the range of exchange rates for converting the primary virtual currency to the secondary virtual currency a P, which indicates the end value of the range of exchange rates for converting the primary virtual currency to the secondary virtual currency. b P, which indicates the slope at x=x0, y=y0, which indicates the geometric mean price Q R S, which indicates the difference in the square root of the intercept and slope The limit exchange rate is P a y, which denotes the balance of the primary tokens equal to int y=y int x indicates the secondary token balance that will be obtained if the primary token balance becomes zero, where the range starts at int x0 indicates the x-coordinate of the geometric mean price y0 indicates the y coordinate of the geometric mean price x indicating the x-asymptote or vertical asymptote asym y indicating the y-asymptote or horizontal asymptote asym Geometric and / or algebraic reconstruction of the above The parameter set may include a base set of adjustable parameters selected from the group consisting of:

[0150] Adjustable parameters are discussed in more detail herein.

[0151] For different bonding curves implicitly defined by the function, different values ​​are assigned to the same base set of parameters.

[0152] At 206, two or more bonding curves may be defined according to the function.

[0153] For brevity and clarity of explanation, two bonding curves will be described, although more than two bonding curves may be defined.

[0154] In the case of two bonding curves, the first bonding curve and the second bonding curve have a common adjustable parameter with different values. The first bonding curve is defined by a first set of values ​​for the adjustable parameter. The second bonding curve is defined by a second set of values ​​for the adjustable parameter that is different from the first set of values. Each bonding curve defines a one-way conversion. The first bonding curve may define a conversion from a primary virtual currency to a secondary virtual currency. The second bonding curve may define a conversion from a secondary virtual currency to the primary virtual currency.

[0155] Once a bonding curve is defined according to the values ​​of the tunable parameters, the bonding curve may be used to perform a transaction.

[0156] At 208, a transaction request for conversion between the primary token and a secondary token of the secondary virtual currency may be obtained from another client terminal (e.g., from another user) different from the client terminal that provided the value of the adjustable parameter. The secondary token may be received through passive interaction with an external market. The other client terminal may be used by another user who wishes to exchange tokens.

[0157] A transaction request for an exchange using a function with applied parameters may be executed on the blockchain using basic mathematical operations, such as addition, subtraction, multiplication, and division. Other more complex mathematical operations, such as Taylor series, polynomial approximations, and numerical methods for generating function outputs, may be excluded. Two or more of the adjustable parameters may be calculated off-blockchain. Using basic mathematical operations and not using more complex mathematical operations and / or performing calculations off-blockchain may improve processor computational efficiency. For example, reduced processing resource usage, reduced memory usage, and / or faster processing time may be achieved.

[0158] At 210, the transaction request is executed using a bonding curve defined by a function using the values ​​of the adjustable parameters. Two bonding curves may be used to execute the complete transaction request, and each bonding curve may be used independently, optionally based on feedback from the other bonding curve.

[0159] The execution of the transaction request may be performed in two stages, which may be performed sequentially in any order or in parallel.

[0160] Consider an example of a transaction request that includes an amount of secondary tokens to be converted into primary tokens. In a first stage, the primary tokens may be automatically withdrawn from a primary reserve. The amount of primary tokens withdrawn in response to the amount of provided secondary tokens is calculated based on a first exchange rate calculated according to a first bonding curve. The primary tokens may be provided, for example, to a client terminal of a user who submitted the transaction request and deposited in the user's wallet. In a second stage, the secondary tokens may be automatically added to the secondary reserve according to a second bonding curve. The addition of the secondary tokens may affect a second exchange rate for the conversion of the secondary virtual currency to the primary virtual currency, which is calculated according to the second bonding curve. As described above, the first and second stages may be performed in different orders (e.g., the first stage after the second stage) or may be performed substantially in parallel.

[0161] Optionally, a transaction executed using a first bonding curve deterministically affects another transaction executed using a second bonding curve, the transaction executed using the first bonding curve including a second stage in which secondary tokens are automatically added to a secondary reserve according to the second bonding curve, and changes in the amount of secondary tokens in the secondary reserve may affect a second exchange rate for future exchanges.

[0162] Secondary tokens received via the first bonding curve are added substantially immediately and automatically to the secondary reserve according to the second bonding curve.

[0163] As another example, consider a transaction request that includes an amount of primary tokens to be converted into secondary tokens. Because the bonding curve corresponds to a specific conversion direction, a second bonding curve is used to determine the amount of secondary tokens. In a first stage, the secondary tokens may be automatically withdrawn from a secondary reserve. The amount of secondary tokens withdrawn in response to the amount of provided primary tokens is calculated based on a second exchange rate calculated according to the second bonding curve. The secondary tokens may be provided to a client terminal of a user who submitted the transaction request and deposited in the user's wallet. In a second stage, the primary tokens may be automatically added to the primary reserve according to the first bonding curve. This addition of the primary tokens may affect the primary exchange rate for the conversion of the primary virtual currency to the secondary virtual currency. This effect is calculated according to the first bonding curve. As described above, the first and second stages may be performed in different orders (e.g., the second stage followed by the first stage) or may be performed substantially in parallel.

[0164] Optionally, the marginal exchange rate for conversion between the first virtual currency and the second virtual currency is calculated according to the first derivative of an associated bonding curve.

[0165] At 212, the blockchain records may be updated to indicate the transactions and / or updated balances of the different tokens.

[0166] Figures 16 to 19 are sequence diagrams for implementing the embodiments described herein. Figure 16 is a sequence diagram showing the creation of a strategy. Figure 17 is a sequence diagram showing the deposit of funds using a strategy. Figure 18 is a sequence diagram showing the withdrawal of funds using a strategy. Figure 19 is a sequence diagram showing a transaction using a strategy.

[0167] The sequence diagrams described in conjunction with Figures 16-19 may be based on, for example, the method described in conjunction with Figure 15, the method implemented by the components of the system described in conjunction with Figure 14, and / or other features described herein. Note that each sequence diagram is an example and includes optional data flows. The data flows may be adapted depending on the particular implementation.

[0168] FIG. 16 shows data flow (e.g., interactions) between a user 1602 (using a client terminal), a web application 1604 (e.g., running on a server), a pool collection 1606 (a smart contract), a strategy 1608, an order 1610, a strategy NFT (non-fungible token) 1612, and an NFT 1614.

[0169] Strategy creation may begin at 1620 when a user uses the web application to select to create a (trading) strategy with a particular set of parameters. As described herein, a trading strategy includes values ​​for different adjustable parameters for different functions, each function defining a unidirectional exchange of one token for another.

[0170] At 1622, the application may be configured to compare the strategy parameters to existing market conditions, including existing strategies and existing market prices, to identify anomalies that the user should consider when creating the strategy, and present these anomalies to the user, who may then decide whether to continue.

[0171] If the user decides to continue at 1624, the user may confirm the creation of the strategy via the web application.

[0172] At 1626, the main entry point on the blockchain for strategy creation may be the pool collection smart contract. In response to receiving a strategy creation request for a particular user, the pool collection smart contract may validate the data and initiate the strategy creation process as follows:

[0173] Orders defined by the strategy parameters may be created at 1628. Each order is defined by a corresponding bonding curve, which defines transactions in a particular direction.

[0174] At 1630, the owner of the strategy may be marked as the user who sent the request.

[0175] At 1632, a unique identifier for the particular strategy may be created.

[0176] At 1634, an NFT may be created that represents the strategy and associates the strategy's unique identifier with the new NFT. This new NFT may be transferred to the user who owns the new strategy.

[0177] At 1636, a notification may be provided confirming that the operation is complete.

[0178] FIG. 17 illustrates data flow (e.g., interactions) between a user 1602 (using a client terminal), a web application 1604 (e.g., running on a server), a pool collection 1606 (a smart contract), a strategy 1608, and a vault 1702 regarding the deposit of funds according to a strategy.

[0179] At 1703, the user may view a page of existing strategies on the web application.

[0180] At 1704, the web application may provide a list of existing strategies created by the user.

[0181] At 1706, the user may select a particular strategy.

[0182] Once the user selects a strategy, the web application may open a page where the user can manage the strategy at 1708. One of the options on the page may be to deposit funds into the strategy.

[0183] At 1710, the user may select the deposit funds option, enter the tokens / amount to deposit, and confirm the action.

[0184] At 1712, the primary entry point on the blockchain for depositing funds for a strategy may be the pool collection smart contract. In response to receiving a request to deposit funds for a strategy for a particular user, the pool collection smart contract may validate the data and initiate the deposit process as follows:

[0185] At 1714, the pool collection smart contract may verify that the user requesting the deposit is the actual owner of the strategy.

[0186] At 1716, the pool collection smart contract may withdraw the specified token amount from the user.

[0187] At 1718, the pool collection smart contract may deposit the token balance into a vault that holds all funds.

[0188] At 1720, the pool collection smart contract may increase the balance of the specified strategy by the provided token amount.

[0189] At 1722, the pool collection smart contract may confirm that the operation is complete.

[0190] FIG. 18 shows data flow (e.g., interactions) between a user 1602 (using a client terminal), a web application 1604 (e.g., running on a server), a pool collection 1606 (a smart contract), a strategy 1608, and a vault 1702 regarding the withdrawal of funds according to a strategy.

[0191] At 1802, a user may view a page of existing strategies on a web application.

[0192] At 1804, the web application may provide a list of existing strategies created by the user.

[0193] At 1806, the user may select a particular strategy.

[0194] Once the user selects a strategy, the web application may open a page where the user can manage the strategy, at 1808. One of the options on the page may be to withdraw existing funds from the strategy.

[0195] At 1810, the user may select the withdraw option, enter the tokens / amount to withdraw, and confirm the action.

[0196] At 1812, the primary entry point on the blockchain for withdrawing funds from a strategy may be the pool collection smart contract. In response to receiving a request to withdraw funds from a strategy for a particular user, the pool collection smart contract may validate the data and initiate the withdrawal process as follows:

[0197] At 1814, the pool collection smart contract may verify that the user requesting the withdrawal is the actual owner of the strategy.

[0198] At 1816, the pool collection smart contract may decrease the balance of the strategy by the provided token amount.

[0199] At 1818, the pool collection smart contract may instruct the vault that holds all user funds to send the specified token amount to the user.

[0200] At 1820, the pool collection smart contract may confirm that the operation is complete.

[0201] FIG. 19 shows data flow (e.g., interactions) between a user 1602 (using a client terminal), a software development kit (SDK) 1902, a trade router 1904, a pool collection 1606 (smart contract), a strategy 1608, a vault 1702, and a protocol 1906 for a funds transaction according to a strategy.

[0202] At 1950, the user may browse the open strategies within the protocol to assess whether they are available for trading for the desired amount, where existing open strategies associated with the particular token pair the user wishes to trade may be requested.

[0203] At 1952, the user may submit a list of strategies to the SDK. The user may request that the SDK attempt to match the trade requirements (e.g., source token, destination token, amount) with the list of strategies. The SDK may attempt to identify a list of strategies predicted to be available for the trade and predicted to provide the best trading results for the user.

[0204] Once the list is generated, the user may request the trade router to execute the trade at 1954. The user may provide the list of strategies received from the SDK as input for the trade, which initiates the trading process, which proceeds as follows:

[0205] At 1956, the trade router may withdraw tokens from the user to be used in the transaction.

[0206] At 1958, the trade router may deposit the tokens into a vault that holds all funds.

[0207] At 1960, the trade router may request the pool collection to execute the trade and provide a list of matching strategies.

[0208] At 1962, the pool collection may iterate through the list of strategies. For each strategy in a given list of strategies, the following may be performed: calculate the trade result for that particular strategy, verify that the strategy has a sufficient balance to accommodate the trade, update the new balance in the strategy, and return the trade result amount.

[0209] At 1964, once the trades have been executed for all the strategies provided, the pool collection may notify the trade router with the results of the trades.

[0210] At 1966, the trade router may request that the user send target tokens in an amount equal to the trade result to the vault that holds all funds.

[0211] At 1968, the vault may send the target token to the user.

[0212] At 1970, the vault may notify the trade router that the token has been sent.

[0213] At 1972, the trade router may confirm that the transaction is complete.

[0214] An additional example of the adjustable parameters that define the functions described herein is detailed below.

[0215] The terms x and y in the following equations represent the balances of two assets between which an exchange is or can be effected. The balances x and y may be virtual, hypothetical, or real and may represent any fungible tokenized form of value on a distributed ledger, including but not limited to blockchains and directed acyclic graphs. The following equations and the customizable functions described herein are necessarily defined based on constant product functions, i.e., hyperbolic curves with asymptote at x=0 and y=0.

[0216] The implicit curve of a constant product function, described, for example, with reference to Patent Document '923, can be written as xy = k (Equation 1a) or as a variant thereof (Equations 1b-c). In the context of token balances within the relevant smart contract where this function is used to effect an exchange, its first derivative (Equations 1d-e) can be used to evaluate the instantaneous rate, i.e., exchange value, between any two affected tokens. A secant line connecting two points on the implicit curve, separated by a continuous midpoint, determines the absolute change in holdings within the smart contract for tokens represented by x and y (Equations 1f-g). Thus, the realized exchange rate between any two tokens by users of the system can be derived (Equations 1h-i).

[0217]

number

[0218] At least some embodiments described herein are based on the concepts defined by the above formula. In the following sections, the properties of customizable immutable functions are disclosed in detail, and it may be appropriate to treat each term entirely abstractly. Additional and more specific details regarding embodiments related to the exchange of tokens are discussed herein.

[0219] Below is a complete mathematical development of the customizable invariant function, its bonding curves, and its properties. A list of terms used to describe the function is provided in Table 1, followed by the equations in which these terms are used. These equations define each term in the context of the customizable function and its associated set of curves. Graphical representations of these same mathematical concepts are shown in the example diagrams that follow.

[0220] [Table 5]

[0221] The customizable function described herein may be an improvement of the general liquidity amplification described in connection with "SMART CONTRACT OF A BLOCKCHAIN ​​FOR MANAGEMENT OF CRYPTOCURRENCIES" (Patent Document '896). This document describes a hypothetical amplified token reserve amount obtained by multiplying the initial staking value (x0, y0) by an amplification value (1 / n or u) in the specific case where there are only two token reserves and their reserve ratio is 1 / 2. Therefore, functions that satisfy the following conditions are of interest. 1) Having arbitrary or adjustable asymptote 2) The graph has at least one common point with Equations 1a-c. 3) The slope of the curve at the common point matches Equations 1d to 1e.

[0222] This definition is further elaborated below. The relationship between x and y is governed by an invariant function, which can be written in many equivalent forms. The content described here is representative and not limiting. The explicit forms shown below are included as examples, but do not limit the scope of the described embodiments. A representative set of novel invariant functions is shown in Equations 2a-p, and examples of equivalent forms obtained by algebraically transforming these functions are also shown in the following description. The functions can be written in terms of variables x and y, as well as n, u, k, P, Q, x0, y0, xasym , y asym , x int , y int It is well defined based on at least three parameters from the above. a and P b or other forms of these parameters, as will be discussed in more detail below.

[0223]

number

[0224] Other forms of the invariant function include various modifications thereof, particularly forms that force either the y-coordinate or the x-coordinate to be the dependent variable (Equations 3a-n and 4a-n, respectively).

[0225]

number

number

[0226] Alternatively or additionally, the new invariant function may be defined in terms of an arbitrary tangent to the curve, measured from either the x- or y-coordinate (Equations 5a-n and 6a-n, respectively).

[0227]

number

number

[0228] Alternatively or additionally, the novel invariant function may be defined based on a secant connecting any two points on the curve, where Δy and Δx represent the absolute displacements in the Cartesian plane between any two points connected by successive intermediate points on the graph. The secant may be defined based on either the x- or y-coordinate (Equations 7a-n and 8a-n, respectively).

[0229]

number

number

[0230] Alternatively or additionally, the new invariant function may be defined based on the slope of the secant (here represented as Δy / Δx), or based on either the x- or y-coordinate (Equations 9a-n and 10a-n, respectively). As Δx approaches zero, Δy / Δx approaches the instantaneous rate of change at any point on the descent curve, equivalent to Equations 5a-n and 6a-n.

[0231]

number

number

[0232] The equations shown above are not exhaustive and are not necessarily limiting. Each parameter belongs to a set and may have explicit relationships with other parameters within that set, as well as with other sets of parameters. These relationships include significant equivalence relationships between fundamental parameters and explicit pairwise relationships between other parameters, including, but not limited to, those defined in Equations 11a-11 and 12.

[0233]

number

[0234] The parameter n is redundant with the parameter u, and the two are inversely related to each other (Equation 12).

number

[0235] Based on existing theory, we can define an extended network of algebraic identities. The entire picture of geometric relationships is too broad to comprehensively enumerate, but representative relationships are shown in Equations 13a-s.

[0236]

number

[0237] The equations shown above are summarized in Equations 14a-c, which are based on the fundamental parameters n, P, Q, k, and x asym , y asym , x int , and y int gives the exact identity for the interrelationship of

[0238]

number

[0239] The parameters defined algebraically above will now be further elaborated upon in the context of their geometric meaning. The explanations provided herein are for illustrative and explanatory purposes to aid the reader's understanding and should not be confused with any particular use case, nor should they be construed as a restriction, limitation, or bound to the generality of the embodiments described herein.

[0240] Referring back to FIGS. 1a-c, they are schematic diagrams illustrating an invariant function characterized by a point with coordinates x=x0, y=y0 on its contour curve (which coincides with the graph of Equations 1a-c), according to some embodiments of the present invention. Referring back to FIGS. 2a-c, they are schematic diagrams illustrating a case where the negative slope (-dy / dx) of the tangent at the point is P and is equal in both the contour curve of the customizable function and the contour curve of Equations 1d-e, according to some embodiments of the present invention. Referring back to FIGS. 3a-g, they are schematic diagrams illustrating a case where the parameter k is a hyperbolic constant in Equations 1a-c (i.e., xy=k) and indicates the magnitude of the contour curve of a constant volume that shares coordinates x=x0, y=y0 with the contour curve of the novel invariant function, according to some embodiments of the present invention. Referring back to FIGS. 4a-l, they are schematic diagrams illustrating a case where the parameter x is a hyperbolic constant in Equations 1a-c (i.e., xy=k) and indicates the magnitude of the contour curve of a constant volume that shares coordinates x=x0, y=y0 with the contour curve of the novel invariant function, according to some embodiments of the present invention. asym and y asym 5a-g are schematic diagrams showing the "vertical" and "horizontal" asymptotes of the decay curve of the novel function, respectively. Note that the terms "vertical" and / or "horizontal" should not be misconstrued as meaning orthogonal and / or straight lines in the embodiments described herein. These terms are used for convenience of explanation, and where their meaning differs from conventional understanding, it will be explained separately. Referring back to FIGS. 5a-g, these figures illustrate the use of a parameter x in accordance with some embodiments of the present invention. int and y int 6a-f are schematic diagrams showing the x- and y-intercepts of the new function's y-intercept curve, y=y, in accordance with some embodiments of the present invention. int and x-intercept x=x int The slope of the tangent at a and P b7a-b, which are schematic diagrams illustrating exemplary methods for detecting parameters n and u that indicate the relative sizes of two rectangles, according to some embodiments of the present invention. One exemplary method will now be described. Assume that each side of both rectangles is parallel to the x-axis and y-axis. The first of the two rectangles has one vertex at the origin (x=0, y=0) and one vertex at the x-intercept (y=0, x=x int ), one vertex is the y-intercept (x=0, y=y int ), and the remaining vertex is the intersection of the line segments that extend from the x-intercept and y-intercept points and intersect at right angles (x=x int , y=y int ) As shown in Figures 7a and 7b, the second rectangle has one vertex at a point on the curve of the equations 1a to 1c, where the tangent at this point is P b A point parallel to (x=√k / √P b , y=√kP b ) one vertex is a point on the curve of the equation 1a-c, and the tangent at this point is P a A point parallel to (x=√k / √P a , y=√kP a ) and the remaining vertex at the intersection of line segments extending from these other two points at right angles. The square root of the ratio of the areas of these rectangles, or the ratio of the lengths of the rectangles, or the ratio of the heights of the rectangles can be used to calculate n and its reciprocal u.

[0241] Referring back to Figures 7c-d, these are schematic diagrams illustrating an exemplary method for finding a parameter Q that indicates the relative size of two rectangles, according to some embodiments of the present invention. Assume that each side of both rectangles is parallel to the x-axis and y-axis. Both rectangles are located at the intersection of the horizontal and vertical asymptotes of the implicit curve of the new invariant function (x = x asym , y=y asym ) and the first of the two rectangles has one vertex at the intersection of the lines extending from the x-intercept and y-intercept (x=x int , y=y int) and the remaining vertices at the intersections of line segments extending from these other two points at right angles. The second rectangle has one vertex at the origin (x=0, y=0) and the remaining vertices at the intersections of line segments extending from these other two points at right angles, as shown in Figures 7c-d. The ratio of the square root of the area of ​​one rectangle to the square root of the sum of the areas of both rectangles, or the ratio of the length of one rectangle to the sum of the lengths of both rectangles, or the ratio of the height of one rectangle to the sum of the heights of both rectangles can be used to calculate Q. The parameters n, u, and Q indicate the relative scaling of the transformation between the implicit curve of the new invariant function and the constant-volume implicit curve.

[0242] The dimensions of the graphs in the relevant figures described herein are not of any particular significance and have been chosen for illustrative purposes. The disclosed functions are effectively infinite and can be applied to any plane or hyperplane, regardless of its size.

[0243] Many further variations of the formulas shown above can be generated based on geometric identities within the scope of the embodiments described herein, and these curves encompass a specific set of exchange operations. For all positive values ​​of x and y, which may represent token balances in a smart contract or a similar structure on a distributed ledger, application of an invariant function provides a mapping of the exchange rate. For example, this encompasses novel DEX technologies.

[0244] The over-parameterization described herein allows for the creation of new subsets of parameters that reference the above parameters, from which specific forms of invariant functions can be explicitly derived. This concept is illustrated below with several specific examples, which are only a small subset of the many possible combinations of curve parameters and variations on the general formula. This flexibility allows for application-specific constraints to be accommodated, including, but not limited to, computational precision in the absence of floating-point arithmetic, overflow, underflow, unsigned integers, computational complexity, storage and memory requirements, and other constraints imposed directly or indirectly by the underlying hardware or software that determine the function's output. This aspect is technically important or provides technical advantages, and is demonstrated by the following specific examples.

[0245] The overall theory can be understood empirically. One set of implicit curves encompassed by the embodiments described herein consists of curves that can be selected with reference to the coordinates of the implicit curves in Equations 1a-c and some scaling factor. The parameters n, u, and Q naturally represent the scaling factor, but it is also possible to construct forms of invariant functions that do not rely on any of these. For example, the invariant functions described in Equations 15, 16a-c, and 17a-c are fully useful despite the lack of direct reference to n, u, or Q. This is demonstrated by their expansion into marginal exchange equations (Equations 16d-e and 17d-e), swap equations (Equations 16f-g and 17f-g), and overall exchange rate equations (Equations 16h-i and 17h-i). Such construction is possible because only three parameters (x0, y0, and y int or x int , or ) provide partial position and scaling information relative to each other.

[0246]

number

number

number

[0247] Thus, from the algebraic and geometric identities for the invariant functions described herein, it is possible to define new fundamental scaling constants. This is an important development from a technical point of view, allowing individual forms of the overall theory to be constructed to suit specific implementation constraints. For the two cases considered on the set derived by the expansion of Equation 15, it is straightforward to define a new scaling term R and show its consistency with the overall theory (Equations 18a-b). The explicit form of this simplification is shown in Equations 19a-i.

[0248] Invariant functions of this kind can be easily shown to belong to the same superset and are included within the scope of the embodiments described herein.

[0249]

number

number

[0250] Obvious combinations of the parameters described herein are also within the scope of the embodiments described herein. For example, in some embodiments, the parameter S is defined as the difference between the square roots of the slopes at the y-intercept and x-intercept, and can be shown through algebraic manipulation to have equivalence with the other basic parameters P, Q, and n (Equations 20a-b). Then, P b B 2 (Equation 20c), a new set of equations (Equations 21a-i) can be constructed.

[0251]

number

number

[0252] This equation set is included to emphasize its simplicity and computational tractability, and in particular, the swap equation (Equation 21g) and marginal price equation (Equation 21e) demonstrate the technical advantages afforded by certain algebraic and / or geometric developments of the over-parameterization and / or general theory described herein. This equation set is employed to explain another aspect described herein, referred to as asymmetric liquidity pools.

[0253] While the examples provided so far concern the discrete case in which the fundamental parameters of the immutable functions are assumed to be fixed, this is not a requirement. Any function parameters may be functions of internal variables, including, but not limited to, x- or y-coordinates, any combination of x- and y-coordinates or combinations with other parameters, or external variables, including, but not limited to, data provided by other smart contracts, application programmable interfaces (APIs), and / or oracle systems or networks.

[0254] Referring back to Figures 8a-c, which are schematic diagrams of Equation 22 using n instead of f(x), according to some embodiments of the present invention. As shown in Figures 8a-c, the invariant function has a point on its graph with coordinates (x0, y0), which coincides with the implicit curve of Equation 1, and the slopes of the tangents at this point are the same in both cases.

number

[0255] Returning to Figures 9a-c, which are schematic diagrams of Equations 23a-c using n instead of f(a, x, x0, y, y0), according to some embodiments of the present invention. As illustrated in Figures 9a-c, consistent with its definition and as observed in the examples discussed herein, the new function retains a point on its graph with coordinates x=x0, y=y0 that coincides with the graph of Equation 1, and the slope at this point is equal to P in both graphs. While the demonstration of Equation 22 has no purpose other than illustrating the scope of the immutable function disclosed herein, Equations 23a-c have special significance. It is a unique variant of, and a close relative of, the "stable swap" function currently used in several DeFi protocols. The term a in Equation 23a determines how flat the function is near the point x=x0, y=y0. The larger the value of a, the larger the flattened region; when a=0, the graph of the function coincides with the graph of Equation 1.

[0256]

number

[0257] Additional details related to asymmetric liquidity pools are described below, where each bonding curve defines a unidirectional transaction from a first cryptocurrency to a second cryptocurrency.

[0258] The application of the novel immutable function in the context of AMMs and DEXs is detailed below. The fundamental objective of a DEX is to exchange tokens according to a predetermined pricing process, with the x and y balances being coordinates on the graph of the immutable function, representing all possible configurations of tokens and exchange rates. Thus, an exchange can be represented as a secant line between two coordinates in the positive domain, which describe the x and y balances at two points in time before and after the exchange is executed. Typically, the numeraire asset is assigned to the y-axis and the risk asset to the x-axis, and this setting will be adopted herein.

[0259] In some embodiments, the customizable functions described herein may be used to generate a price range for a single user to programmatically exchange their token for other selected tokens in a decentralized marketplace. In general terms, an AMM position where tokens are exchanged within a predetermined exchange rate range is referred to as centralized liquidity. In such a centralized liquidity model, the graph of the invariant function in the positive domain necessarily intersects the x-axis and y-axis, and the slope of the graph at these intersections defines the upper and lower bounds of the exchange rate. x asym < 0 and y asym < 0, x = 0 (i.e., y-intercept y int ) defines the maximum exchange rate of the numeraire for the risky asset, and the slope of the graph at y=0 (i.e., x-intercept x int ) defines the minimum exchange rate of the numeraire for the risky asset. asym and y asym In the graph of any new invariant function where is a constant, if n<1, then x asym < 0 and y asym <0.

[0260] The following discussion expands on the application of invariant functions under this premise, which constitutes part of a broader range of possible uses of the embodiments described herein. The slope of the y-intercept of the graph of the customizable function is defined as -P a Let the slope of the x-intercept of the graph of the new function be -P b As with any permutation of an invariant function, the slope at the point where Equation 1 coincides (i.e., x=x0, y=y0) is defined as -P. In one embodiment, P a , P b , y int and x int Any three of the four parameters are provided by the user, where P a and P b is the exchange rate range selected by the user, y intrepresents the liquidity of the numeraire provided by the user for this same range, and x int represents the total amount of risk assets that the user has expressed an intention to acquire by exchanging the numeraire.

[0261] While the following discussion refers to Equations 21a-i, please note that this is an example implementation. For completeness, Equations 24a-l are examples where any of the parameters discussed so far are implemented using P a , P b and y int The remainder of the illustration shows how B, S and y int A subset of is required.

[0262]

number

[0263] A user strategy includes a set of two or more token balances, including a zero token balance, and two or more instances of the invariant functions described herein. For clarity, the following description is limited to a case where a two-token strategy is defined by a user and includes two asymmetric bonding curves that determine the exchange rates. However, the embodiments described herein are not necessarily limited to such a case.

[0264] To illustrate the emergent behavior of user strategies as a function of the two asymmetric liquidity pools, we use USD as the cryptocurrency token. TKN and RSK TKN Using USD as a general example. TKNis used as a proxy for so-called "stablecoins," i.e., cryptocurrency tokens that maintain roughly a 1:1 exchange value with the U.S. dollar. Stable tokens were chosen because of their intuitive properties and for the purposes of the following discussion, but the embodiments described herein are not limited to such tokens and may work with other tokens as well. Similarly, the fictional character Alice is used as a general proxy to represent any user interacting with the protocol.

[0265] RSK TKN is currently trading at a value of US$1.00, therefore TKN USD Let's assume that Alice is a blockchain user and has an exact 1:1 exchange value between her and 100 RSK. TKN and 5000 USD TKN She holds RSK and hopes to increase her total holdings of both tokens over time by trading them on the open market. TKN The exchange rate for USD TKN Additional RSK when low against TKN and then again in USD when the exchange rate is higher. TKN Depending on her beliefs, skills, knowledge, biases, preferences, and other factors, Alice may choose to exchange USD TKN Part of RSK TKN However, in a traditional AMM, Alice's ability to exercise this most fundamental economic activity is limited. This problem stems from the fact that traditional AMM systems are symmetric in their ability to facilitate exchange. That is, if USD TKN A certain amount of RSK TKN If Alice exchanges Ethereum with Ethereum, the reverse exchange can be performed as well, regardless of Alice's liquidity provider settings.

[0266] In at least some embodiments described herein, USD TKN from RSK TKN Exchange to RSK TKN from USD TKN The exchange rate for each is defined by Alice herself, not by the protocol. The exchange rate for each direction is determined by a separate instance of an immutable function, which generates a pair of bonding curves where both tokens are exchangeable with marketplace participants, independent of the system's state. In one respect, Alice's liquidity position can represent a formal limit order, which, unlike limit orders in traditional finance, is continuously executable within a pre-defined range of exchange rates, rather than an "all-or-nothing" execution only at a specific target rate. The tokens Alice uses to execute her strategy automatically become available on the corresponding curve at a different exchange rate than when she acquired them. Alice's intent is realized automatically, without her manual intervention or active management, which is a fundamental improvement over existing DEX technology.

[0267] We now consider the characteristic behavior of Alice's liquidity position (i.e., user strategy) in the context of at least some embodiments described herein, based on the customizable immutable functions described herein. First, as an instance of the general formula, TKN , as the exchange rate fluctuates towards Alice's target, USD TKN Let's say you want to exchange for 1 RSK, which is the current market rate. TKN 1 USD per TKN (i.e., $1.00 USD), Alice will receive 1 RSK TKN 1.5 USD per TKN The exchange will start at an exchange rate of 1 RSK, with a target of TKN 3.5 USD per TKN A total of 100 RSK TKNBy configuration, Alice's bonding curve corresponding to half of this strategy is plotted on the y-axis against the RSK remaining in that position. TKN At the time of creating this strategy, the initial small amount of RSK TKN is 1RSK TKN 1.5 USD per TKN In one embodiment, the exchange rate of RSK at the time of position creation is TKN The balance is the parameter y of the immutable function instance corresponding to Alice's strategy. int Therefore, y int P, defined as the negative value of the slope (-dy / dx) of the tangent at a defines the initial exchange rate. P a represents the change in y with respect to x, where y is the RSK TKN To represent the true quantity of TKN Assuming that it is a building, P a is the reciprocal of the initial exchange rate chosen by Alice. In other words, the first small change in y relative to x according to Alice's intention is -dy / dx=1RSK. TKN / 1.5USD TKN Therefore, USD at the initial exchange TKN The value of RSK TKN Since it is 2 / 3 of P a = 2 / 3. Therefore, two of the required input parameters by Alice are P a = 2 / 3 and y int =100.

[0268] The final input in the first half of Alice's strategy is P b is P a As Alice intended, the last tiny bit of RSK TKN is 1RSK TKN 3.5 USD per TKN In this case, her bonding curve in that range is x=x int, y=0, which completes the order. P b Note that represents the slope of the tangent at this very point on the curve, and represents the change in y with respect to x. Therefore, its value is -dy / dx=1RSK TKN / 3.5USD TKN and P b With this third and final input, Alice's bonding curve, i.e., RSK TKN in USD on the external market TKN From an implementation point of view, these three parameters alone are sufficient to define this half of the strategy, but for redundancy reasons, all previously mentioned parameters are calculated, as shown in Table 2.

[0269] [Table 6]

[0270] RSK TKN The closer the exchange rate of to her desired value, the more Alice will be able to use her USD TKN Let us consider the second half of Alice's strategy, assuming she is willing to exchange with other market participants.

[0271] Current market position: 1RSK TKN 1 USD per TKN (i.e., $1.00), Alice will receive 1 RSK TKN 2 / 3 USD per TKN exchange rate of 1 RSK TKN 1 / 5 USD per TKN Within the range of the target of USD TKN RSK TKN We want to start exchanging to 5000 USD for this range. TKN The same settings are applied to this bonding curve. The y-axis of the bonding curve for this half of Alice's strategy is the remaining USD she holds in the position. TKNNote that in both bonding curves, true liquidity is on the y-axis. The x-axis is simply a coordinate in both cases, not a token balance. At the time Alice creates her strategy, the initial tiny USD TKN But, 1RSK against the market TKN 1 USD per TKN As mentioned above, the exchange rate is USD at the time the position is created. TKN The balance of y in the immutable function instance associated with this half of Alice's strategy int Suppose we define the parameters P in this half of the strategy. a The parameters are the same as for the other curve: y int is the slope of the tangent at , which defines the initial exchange rate in the corresponding direction. The same logic applies to the calculation of the curve parameters. However, the USD TKN Note that in the half case, the numerical benchmark asset is inverted, which gives a more intuitive result. In this case, there is no need to take the reciprocal. P a represents the change in y relative to x, where y is the true USD TKN Since it shows the amount of P a is the exchange rate Alice has chosen. The first small change in y relative to x is -dy / dx=2 / 3USD TKN / 1RSK TKN Therefore, P a = 2 / 3 and RSK TKN is 2 / 3 USD when first exchanged against Alice's liquidity TKN Therefore, two of Alice's required inputs are P a = 2 / 3 and y int = 5000. Here, both curves have the same P a Note that the two curves have the same value, but their essential meanings are reversed. For the first curve, P a is RSK TKN is USD TKN The first curve shows the initial exchange rate at whicha is USD TKN RSK TKN In cash terms, the initial exchange rate is P a is RSK TKN In the second curve, the initial valuation of P a The value is RSK TKN Assume the initial valuation of is $0.66. In one embodiment, these and other subtle differences are hidden from the user via a front-end interface, and input is collected in terms that more closely match the user's intuitive understanding. What is described here is a detailed description of the application of the immutable functions described above, and is not an actual user experience.

[0272] The final input value for the second half of Alice's strategy is P b is P a The final tiny USD can be derived in the same way. TKN is 1RSK TKN 1 / 5 USD per TKN Therefore, P b The value of is -dy / dx=1 / 5USD TKN / 1RSK TKN and P b = 1 / 5. For both curves, P a P b Note that the size of Alice's strategy is larger than the size of her previous strategy, but this is only an assumption and not a requirement. This completes the collection of user input and defines the second half of Alice's strategy, completing the creation of the overall strategy, as shown in Table 3.

[0273] [Table 7]

[0274] Depending on the circumstances, any subset or the entire set of values ​​shown in Tables 2 and 3 can be stored in the smart contract. In some embodiments, for a simple deployment, only (optionally) three parameters and one x or y coordinate are used. With reference to the examples described herein and to Equations 21a-i, (optionally only) y int Assume that only B, S, and the y coordinate are used. Note that these choices reflect a low computational burden compared to the other parameters (Equations 24a-l). Furthermore, the initial calculation of B and S during strategy creation can be performed with the assistance of off-chain resources, and all subsequent calculations performed on-chain during the swap use only basic mathematical operations: addition, subtraction, multiplication, and division (optionally only). This also holds true for the equations described herein for the calculation of the marginal exchange rate and swap, eliminating the need for Taylor expansions and / or other polynomial approximations and / or numerical methods for obtaining function outputs. The freedom to select appropriate parameters and / or a customized set of equations to fit the virtual machine on which the decentralized application runs addresses the technical challenge of reducing the use of computational resources for executing smart contracts.

[0275] Here, Alice's strategy is represented by two separate bonding curves. In one embodiment, and in contrast to conventional interpretations, only the y-axis of these curves has intrinsic meaning (and only optionally). That is, the x-axis does not represent any real token balance (even if virtual). At the most abstract level, the x-coordinate is a remnant of taking the indefinite integral of the desired exchange rate profile as a function of Alice's true token balance (represented by y), which is implicit in the swap equation (Equation 21e). While the projection onto the x-axis introduces an additional dimension and produces a bonding curve with a familiar shape, note that for the purposes of the following discussion, the x-axis is effectively meaningless. In this example, Alice is trading USD TKN and RSK TKNThe x-coordinate on both curves is zero, even though the user has offered non-zero amounts of both tokens and has effective non-zero balances in both tokens at this point in the diagram. Note also that other equations described herein, such as the marginal and effective exchange rates, as well as the swap equation itself, do not refer to an x-coordinate. However, this is not a requirement, but rather merely a nuance in some embodiments, as explained in the current context. In other embodiments, both axes may represent real or virtual balances. In any case, treating both axes as representing real token balances in smart contracts associated with users' positions has heuristic value, and despite its practical irrelevance, it is still useful for conveying the more important concepts. For convenience, in subsequent diagrams, the x-axis will be referred to simply as x.

[0276] Returning to reference to Figure 10, this figure is a schematic diagram illustrating the state of Alice's primitive strategy before any exchanges have been performed, according to some embodiments of the present invention. The upper and lower sets of curves are identical, except that in the latter the axes have been rescaled from a square arrangement to allow for a more careful observation of structural changes during the exchange. In the following discussion, the change in scale is necessary to clarify how aspects of the strategy unfold under the asymmetric liquidity paradigm. At this point in the discussion, the intercepts and y-coordinates of the curves are the most important features. In the absence of any activity, both y-coordinates are at their respective starting points, i.e., y int The x-intercept is not accidental, but represents the number of tokens that would be acquired if the liquidity on the y-axis were completely depleted. The exchange rate of the entire position, i.e., the exchange rate of the entire y balance to and from the target token, is equal to the geometric mean of the curve, which is the parameter P.

[0277] RSK TKN The market rate for USD TKNAssume that the price falls as Alice predicted against USD and market participants begin trading against her strategy. TKN She has an active strategy in RSK, which provides a liquidity source to support market activity. TKN A component will be unattractive as long as it offers a higher exchange rate than the exchange rate actually traded in the market. To simplify this part of the explanation, this example simulates a single large transaction and a sudden and rapid change in the market-accepted rate. However, this blurs the dimension of time, and in reality, many different participants may have interacted with Alice's strategy.

[0278] RSK TKN In a situation where the market value of the TKN Assume that Alice's USD TKN We can assume that liquidity in the USD Bond Curve dries up until the market-wide rate and the USD Bond Curve are roughly aligned. To simulate this condition, we use TKN The exact y coordinate on the curve can be calculated from the marginal rate (Equation 21e). The x coordinate can also be calculated and is used in the diagram below to show overall progress towards full fulfillment of the order. USD TKN For the curves, the only (optionally) obvious change is a shift in the y coordinate, as shown in Table 4.

[0279] [Table 8]

[0280] Considering the results above, the overall Δx is 454.4058, which is the RSK for Alice's strategy. TKN The increase in -Δy is 294.8574, which is the USDTKN This corresponds to the loss of RSK TKN The average acquisition cost per token is approximately $0.64. TKN Before considering the impact, note that this exchange is permanent. In a standard AMM, if market sentiment recovers after a sharp drop, Alice's liquidity position will be rebalanced, and thus her opportunity to acquire her target tokens at an attractive rate will be lost (unless she responds quickly, carefully, and appropriately). This is a significant change from the status quo. Alice's USD TKN The curve is (only optionally) exchanged in the forward direction, but not in the reverse direction. Therefore, the obtained RSK TKN The outcome of this is of natural interest.

[0281] RSK TKN is absorbed into the strategy in its dedicated liquidity curve. More importantly, it is added to the y-axis. TKN Since the balance of was already equal to the y-intercept, the y-intercept is shifted to accommodate the newly acquired liquidity. The parameterization of the novel invariant function that constitutes the first half of this disclosure is y int The values ​​can be used as a kind of container size, which can be moved without affecting the exchange profile selected by the user, i.e., the slopes of the x- and y-intercepts can be kept constant, so that the RSK obtained at a lower exchange rate in the same price interval defined when the strategy was created is TKN In the implementation considered in this description, this effect is (optionally only) limited to a single variable, namely y int This can be achieved by simply updating the values, and does not impose a significant computational burden. Depending on the environment, if it is economical to maintain a dictionary of all parameters that describe the pair of liquidity curves that make up Alice's strategy, such a dictionary can be implemented. In this example, Alice's RSK TKN The accumulation results are shown in Table 5. TKNIn contrast to the curves, significant changes are observed, especially with regard to the natural scaling parameters, while the curvature parameters remain unchanged.

[0282] [Table 9]

[0283] Referring back to FIG. 11, it is a schematic diagram illustrating the difference in the relative changes in either half of Alice's strategy, according to some embodiments of the present invention. As shown in FIG. 11, the difference is dramatic. This is because Alice's strategy is very top-heavy, resulting in what is often referred to as a "buy wall" in traditional order books. However, unlike traditional order books, tokens received by passively interacting with the external market through one bonding curve are immediately and automatically added to its mating curve. In this way, a fully automated system for accurately executing a pre-defined trading strategy is realized.

[0284] RSK TKN The exchange rate for USD TKN If RSK continues to fall further against TKN Instead of receiving USD TKN The decline continues, and RSK TKN Assume that the exchange rate approaches 9 / 25, or $0.36. This value remains within Alice's target range. The effect of the market change is that the USD TKN This can be easily reproduced by modeling the y-coordinate of the side as stopping at a point where the slope of the tangent is exactly -9 / 25. This point can be calculated from either the x-coordinate or the y-coordinate using one of the limit rate formulas presented herein. As previously mentioned, the USD TKNThe curve (optionally only) changes relative to the y coordinate, dragging the x coordinate along with it. This simulated drawdown is much more severe than the one considered in the previous example, consuming a larger percentage of Alice's active limit orders. The results are shown in Table 6.

[0285] RSK with corresponding curves TKN Note the large change in scale that occurs with the additional accumulation of RSK. This is easily achieved because the parameter k has the same essential meaning as in Equations 1a-c. TKN Comparing the √k of the curve from its creation to the present shows a 5.5x, then 11.0x increase, resulting in a final relative increase of 60.8x. Arbitrary changes in size are easy and, for the particular parameterization considered in this hypothetical example, do not pose performance or accuracy problems. One reason for this flexibility is that the curve can (only optionally) be exactly y=y as it expands to accommodate additional fluidity. int The value of k can be extended relatively to infinity by allowing users (optionally only) to initiate a strategy that includes only a single token balance, thus configuring it to have an empty curve at the time of creation. int =0), the strategy created in the exchange interval, √P a and √P b The empty curve must contain information about Alice's RSK. TKN In a similar manner as indicated by the curves, the user may begin filling with the liquidity of the corresponding curve. Additionally, a user may wish to adjust the token balance on a strategy over time, including completely emptying one or both curves. Neither of these considerations poses a problem in the currently contemplated embodiment of the invention. Alice's RSK in this example TKN The accumulation results are shown in Table 7.

[0286] Referring back to FIG. 12, this is a schematic diagram illustrating the difference in relative changes in either half of Alice's strategy, according to some embodiments of the present invention.

[0287] [Table 10]

[0288] [Table 11]

[0289] Continuing our exploration of asymmetric liquidity pools, RSK TKN from USD TKN Let's assume that the local bottom of the exchange rate for RSK was on September 25th ($0.36), and that its valuation then began to improve. After an arbitrary period, the market rebounded, and TKN The rating of reaches Alice's target range. First, the exchange rate is 1RSK. TKN 14 / 5 USD per TKN , or 1 USD TKN Winning 5 / 9RSK TKN (i.e., $1.80). Alice's RSK TKN The point on the curve that corresponds to 2 / 5 can be calculated from the limiting rate (Equation 21e). TKN Curve has traded with market participants at least once and they are trading USD TKN Alice's RSK TKN This means that it has been exchanged for

[0290] As expected, Alice's RSK TKN The y-coordinate of the curve (i.e., the true token balance) is decreasing. The results are shown in Table 8. Meanwhile, USD TKN The results are shown in Table 9. However, Alice's USD TKN For curves, use y coordinates int There is enough room to move it without exceeding , so its capacity parameter has not been changed. Instead, the newly added USDTKN The y-coordinate is simply adjusted to reflect Alice's liquidity balance. This change will affect the instantaneous exchange rate offered for the first tradable tiniest unit on the curve. This is the expected behavior. The exchange rate is (only optionally) allowed to fluctuate within a range defined by Alice.

[0291] Referring back to FIG. 13a, it illustrates the potential for additional USD at current prices to initially fill its homogeneous bonding curve and gradually return to the upper end of the re-accumulation target, in accordance with some embodiments of the present invention. TKN FIG. 1 is a schematic diagram showing accumulation of

[0292] [Table 12]

[0293] [Table 13]

[0294] Finally, RSK TKN At the local high, 1RSK TKN 2.5 USD per TKN , or 1 USD TKN Winning 2 / 5RSK TKN (i.e., $2.50), and then fall back outside (i.e., between) both price ranges specified by Alice. This completes a market cycle for Alice. For ease of analysis, let us assume that the final RSK TKN and USD TKN Assume the exchange rate is 1:1 and we are back to the state in which this hypothetical example began.

[0295] RSK TKN While Alice's RSK is at a local high, TKN The point on the curve that corresponds to 2 / 5 can be calculated using the method shown above. TKNAs the price of RSK rises further into Alice's expected price range, her RSK TKN The balance (y coordinate) further decreased. Meanwhile, as shown in Table 11, the counterpart USD TKN The curve will see new liquidity in USD TKN The feature of this case is that Alice's USD TKN The balance is the y int , thus expanding the capacity of the curve to accommodate the new liquidity, as shown in Figure 13B.

[0296] [Table 14]

[0297] [Table 15]

[0298] Alice starts with 100 RSK TKN and 5000 USD TKN Consider that Alice held RSK, with a total value of $5100 at a time when both tokens were valued at exactly $1. Despite not receiving any fee income of any kind and not performing any operations after initiating the position, TKN and USD TKN Holdings increased to 2,112.88 and 9,757.79 respectively, for a total value of $11,870.67.

[0299] The description of each embodiment of the present invention is provided for illustrative purposes and is not intended to be limited to the disclosed embodiments, nor is it intended to be exhaustive. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the disclosed embodiments. The terms used in this specification have been selected to best explain the principles, practical applications, or technical improvements of the embodiments over existing technology in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0300] It is anticipated that many related smart contracts and virtual currencies will be developed during the life of any patent granted under this application, and the scope of the terms "smart contract" and "virtual currency" is intended to encompass all such new technologies a priori.

[0301] As used herein, the term "about" refers to ±10%.

[0302] The words "comprises," "comprising," "includes," "including," "having," and conjugations thereof, mean "including but not limited to." This term encompasses the terms "consisting of" and "consisting essentially of."

[0303] The term "consisting essentially of" means that a composition or method may include additional ingredients and / or steps, provided that the additional ingredients and / or steps do not materially alter the basic and novel characteristics of the claimed composition or method.

[0304] As used herein, the singular forms "a," "an," and "the" include the plural referent unless the context clearly dictates otherwise. For example, "a compound" or "at least one compound" includes a plurality of compounds, and can also include mixtures thereof.

[0305] "Exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment described as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments and / or to exclude the incorporation of features from other embodiments.

[0306] "Optionally" is used herein to mean "is provided in some embodiments and not provided in other embodiments." Any particular embodiment of the present invention may include multiple "optional" features unless such features contradict each other.

[0307] Throughout this application, various embodiments of the present invention may be presented in a range format. It should be understood that the description in range format is for convenience and brevity and should not be construed as an inflexible limitation on the scope of the present invention. Accordingly, the description of a range should be considered to specifically disclose all possible subranges and individual numerical values ​​within that range. For example, a description of a range of "1 to 6" should be considered to specifically disclose subranges such as "1 to 3," "1 to 4," "1 to 5," "2 to 4," "2 to 6," "3 to 6," etc., as well as individual numerical values ​​within that range, i.e., 1, 2, 3, 4, 5, and 6. This applies regardless of the breadth or narrowness of the range.

[0308] When numerical ranges are given herein, they are intended to include all recited numbers (both fractional and integer) within that range. The phrases "ranging / ranges between" and "ranging / ranges from" are used interchangeably herein and mean to include the first and second numerical values ​​and all fractional and integer numbers therebetween.

[0309] Although certain features of the invention are described in separate embodiments for clarity, it will be understood that they may also be provided in combination in a single embodiment. Conversely, various features of the invention, while described in a single embodiment for brevity, may also be provided separately or in any suitable subcombination or other suitable embodiment of the invention. Certain features described in the context of various embodiments should not be considered essential features of such embodiments, unless the embodiment is inoperable without those elements.

[0310] While the present invention has been described in conjunction with specific embodiments, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications, and variations that fall within the spirit and broad scope of the appended claims.

[0311] It is the intention of the applicants of this application to incorporate all publications, patents, and patent applications referenced herein in their entirety at the time each publication, patent, or patent application is referenced. In addition, citation or identification of any document in this application should not be construed as an admission that the document is available as prior art to the present invention. Headings, if used, should not be construed as necessarily limiting. Furthermore, the priority documents of this application are hereby incorporated in their entirety into this specification.

Claims

1. 1. A computing device for exchanging tokens via a distributed smart contract running on a blockchain, comprising: at least one hardware processor in a networked server that executes code for the distributed smart contract that runs on the blockchain; The code Manage the primary reserve of multiple tokens of the primary virtual currency; obtaining, from a client terminal in communication with the network-connected server, a plurality of values ​​of a plurality of adjustable parameters that define a function for calculating an exchange rate for converting between the primary virtual currency and the secondary virtual currency; in response to a transaction request to convert between the primary token and a secondary token of the secondary virtual currency, executing the transaction request using a bonding curve defined by the function having the plurality of values ​​of the plurality of adjustable parameters; It is for the purpose of computing device.

2. The computing device of claim 1 , wherein the primary reserve is managed without managing a secondary reserve of secondary tokens of the secondary virtual currency.

3. 2. The computing device of claim 1, wherein the plurality of tunable parameters are selected to meet hardware and / or software resource requirements for execution of the distributed smart contract code.

4. 4. The computing device of claim 3, further comprising code for dynamically monitoring execution of the code of the distributed smart contract and dynamically adapting the plurality of tunable parameters to meet resource requirements of the hardware and / or software.

5. 4. The computing device of claim 3, wherein the resource requirements are selected from the group consisting of computational precision without floating point arithmetic, overflow, underflow, unsigned integers, computational complexity, storage requirements, and memory requirements.

6. The computing device of claim 1 , wherein the plurality of values ​​of the tunable parameters are obtained from a user via a user interface running on the client terminal in communication with the networked server.

7. 2. The computing device of claim 1, wherein one of the x-axis and y-axis represents the balance of the primary reserve, the other axis is undefined, and the function represents all possible exchange rates for converting the primary tokens and the secondary tokens.

8. 10. The computing device of claim 1, wherein the transaction request for an exchange using the function with the applied parameters is executed on a blockchain using basic mathematical operations selected from addition, subtraction, multiplication, and division, and excludes all Taylor series, polynomial approximations, and numerical methods of generating function outputs.

9. The computing device of claim 8 , wherein at least two of the plurality of tunable parameters are computed outside of a blockchain.

10. 2. The computing device of claim 1, wherein the bonding curves include a first bonding curve and further include a second bonding curve defined by the function, the first bonding curve being defined by a first set of values ​​for the adjustable parameters and the second bonding curve being defined by a second set of values ​​for the adjustable parameters, the first bonding curve being for conversions from the primary virtual currency to the secondary virtual currency and the second bonding curve being for conversions from the secondary virtual currency to the primary virtual currency, and the first bonding curve and the second bonding curve having a common adjustable parameter with different values.

11. 11. The computing device of claim 10, wherein a first exchange rate for converting the primary virtual currency to the secondary virtual currency is calculated according to the first bonding curve, and a second exchange rate for converting the secondary virtual currency to the primary virtual currency is calculated according to the second bonding curve, the first bonding curve being different from the second bonding curve, and the first exchange rate being different from the second exchange rate.

12. 12. The computing device of claim 11, wherein the transaction includes receiving the secondary token, automatically adding the secondary token to a secondary reserve according to the second bonding curve, and automatically withdrawing a primary token from the primary reserve according to the first bonding curve.

13. 12. The computing device of claim 11, wherein a transaction performed using the first bonding curve deterministically affects another transaction performed using the second bonding curve.

14. The computing device of claim 11 , further comprising: obtaining a strategy from the client terminal, the strategy defining values ​​of the parameters for the first bonding curve and the second bonding curve.

15. The plurality of adjustable parameters are: n, P indicating the starting value of the range of exchange rates for converting the primary virtual currency to the secondary virtual currency ａ , P indicating the end value of the range of exchange rates for converting the primary virtual currency to the secondary virtual currency ｂ , The geometric mean price is x = x ０ , y=y ０ P, which indicates the slope at Q. R, S, which indicates the difference in the square root of the intercept slope, The limit exchange rate is P ａ y, which indicates the balance of the primary tokens, ｉｎｔ , The range is y=y ｉｎｔ x, which indicates the balance of secondary tokens obtained when the balance of the primary token becomes zero, ｉｎｔ , x indicates the x coordinate of the geometric mean price ０ , y indicates the y coordinate of the geometric mean price ０ , x indicating the x asymptote or vertical asymptote ａｓｙｍ , y indicates the y-asymptote or horizontal asymptote ａｓｙｍ , Geometric and / or algebraic reconstruction of the above; 10. The computing device of claim 1, further comprising a base set of adjustable parameters selected from the group consisting of:

16. 16. The computing device of claim 15, wherein different values ​​are assigned to the same set of basic parameters for different bonding curves implicitly defined by the function.

17. 2. The computing device of claim 1, wherein a single distributed smart contract running on the blockchain implements different sets of values ​​for the tunable parameters for different instances of the function, the single distributed smart contract implementing each reserve of a particular token, corresponding bonding curves defined by the function having the different sets of values ​​for the plurality of tunable parameters defining primitives for one-way exchanges between an external token and the particular token of each reserve, and a plurality of the primitives being linked together to define one-way routes for token exchanges.

18. 2. The computing device of claim 1, wherein the function is defined according to a hyperbola having an asymptote at x=0 and y=0 expressed as xy=k, where x denotes the primary token and y denotes the secondary token.

19. 20. The computing device of claim 18, wherein the function includes at least one adjustable asymptote, and a graph of the function has at least one common point with a constant volume bonding curve expressed as xy=k.

20. The slope of each of the at least one bonding curve at the at least one common point is equal to the first derivative of xy=k, and each of the at least one bonding curves has a coordinate x=x on the corresponding bonding curve. ０ and y = y ０ 20. The computing device of claim 19, wherein .times. ...

21. The computing device of claim 1 , wherein the bonding curve is defined as the implicit curve of the invariant function and is used to enumerate a set of exchange rates between a primary virtual currency and a secondary virtual currency.

22. 2. The computing device of claim 1, wherein each exchange rate of a plurality of exchange rates for converting between the primary virtual currency and the secondary virtual currency is represented as a secant between two points of the function, a first point representing the balance of the primary reserve before the exchange occurs and a second point representing the balance of the primary reserve after the exchange occurs.

23. 10. The computing device of claim 1, wherein each parameter is assigned to one of a plurality of sets, each parameter of each set being mathematically related to other parameters in the set, and each parameter being mathematically related among other sets of parameters sufficient to unambiguously describe a unique invariant function-implied curve pair.

24. 2. The computing device of claim 1, wherein a limit exchange rate for conversion between the primary virtual currency and the secondary virtual currency is calculated according to a first derivative of the bonding curve implicitly defined by the function having an adjustable parameter applied.

25. 1. A computing device for exchanging tokens via a distributed smart contract running on a blockchain, comprising: at least one hardware processor in a networked server that executes code for the distributed smart contract that runs on the blockchain; The code Manage a primary reserve of a plurality of primary tokens of the primary virtual currency and a secondary reserve of a plurality of secondary tokens of the secondary virtual currency; obtaining a transaction request for converting the primary token to a secondary token of a secondary virtual currency; in response to a transaction request where the transaction request involves converting the primary token to the secondary token, execute the transaction request using a first bonding curve implicitly defined by a function and a first set of values ​​for a plurality of tunable parameters; in response to the transaction request where the transaction request effects a conversion of the secondary token to the primary token, executing the transaction request using a second bonding curve that is implicitly defined by the function and a second set of the plurality of values ​​of tunable parameters that differ from the first set, the second bonding curve being different from the first bonding curve. It is for the purpose of computing device.

26. 26. The computing device of claim 25, wherein the primary reserve and the secondary reserve are linked, and when the transaction request includes an amount of secondary tokens, the amount of primary tokens is taken from the primary reserve according to the first bonding curve and the secondary tokens are deposited into the secondary reserve according to the second bonding curve.

27. 1. A method of exchanging tokens via a distributed smart contract executed on a blockchain, comprising: Managing a primary reserve of multiple tokens of a primary virtual currency; obtaining, from a client terminal in communication with the network-connected server, a plurality of values ​​of a plurality of adjustable parameters that define a function for calculating an exchange rate for converting between the primary virtual currency and the secondary virtual currency; In response to a transaction request to convert between the primary token and a secondary token of a secondary virtual currency, executing the transaction request using a bonding curve defined by the function having the plurality of values ​​of the plurality of adjustable parameters; A method comprising:

Images