WO2024084480A1

WO2024084480A1 - Customizable cryptocurrency trading

Info

Publication number: WO2024084480A1
Application number: PCT/IL2023/051079
Authority: WO
Inventors: Mark Bentley RICHARDSON; Stefan Loesch; Barak Manos; Asaf Shachaf
Original assignee: Bprotocol Foundation; Localcoin Ltd.
Priority date: 2022-10-20
Filing date: 2023-10-16
Publication date: 2024-04-25

Abstract

A computing device for exchanging tokens by a distributed smart contract executing on a blockchain, comprising: at least one hardware processor of a network connected server executing a code of the distributed smart contract executing on the blockchain, the code for: managing a primary reserve of a plurality of tokens of a primary cryptocurrency, 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 computing an exchange rate for converting between the primary cryptocurrency and a secondary cryptocurrency, and in response to a transaction request for converting between the primary tokens and a secondary token of a secondary cryptocurrency, executing the transaction request using a bonding curve defined by the function with the plurality of values of the plurality of adjustable parameters.

Description

CUSTOMIZABLE CRYPTOCURRENCY TRADING

RELATED APPLICATION

This application claims the benefit of priority of U.S. Provisional Patent Application No. 63/417,723 filed on October 20, 2022, the contents of which are incorporated herein by reference in their entirety.

BACKGROUND

The present invention, in some embodiments thereof, relates to distributed applications for management of cryptocurrencies and, more specifically, but not exclusively, to systems and methods for distributed applications for customizable cryptocurrency trading.

Advances in blockchain technology provide distributed (i.e., non-centralized approaches) to enable almost any entity to create their own custom cryptocurrencies and/or create their own smart contract that provides cryptocurrency exchange services. Some smart contracts executing on the blockchain are designed to enable users to convert between different types of cryptocurrencies.

SUMMARY

According to a first aspect, a computing device for exchanging tokens by a distributed smart contract executing on a blockchain, comprises: at least one hardware processor of a network connected server executing a code of the distributed smart contract executing on the blockchain, the code for: managing a primary reserve of a plurality of tokens of a primary cryptocurrency, 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 computing an exchange rate for converting between the primary cryptocurrency and a secondary cryptocurrency, and in response to a transaction request for converting between the primary tokens and a secondary token of a secondary cryptocurrency, executing the transaction request using a bonding curve defined by the function with the plurality of values of the plurality of adjustable parameters.

According to a second aspect, a method of exchanging tokens by a distributed smart contract executing on a blockchain, comprises: managing a primary reserve of a plurality of tokens of a primary cryptocurrency, 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 computing an exchange rate for converting between the primary cryptocurrency and a secondary cryptocurrency, and in response to a transaction request for converting between the primary tokens and a secondary token of a secondary cryptocurrency, executing the transaction request using a bonding curve defined by the function with the plurality of values of the plurality of adjustable parameters.

According to a third aspect, a computing device for exchanging tokens by a distributed smart contract executing on a blockchain, comprises: at least one hardware processor of a network connected server executing a code of the distributed smart contract executing on the blockchain, the code for: managing a primary reserve of a plurality of primary tokens of a primary cryptocurrency and managing a secondary reserve of a plurality of secondary tokens of a secondary cryptocurrency, obtaining a transaction request for converting between the primary token and a secondary token of a secondary cryptocurrency, in response to the transaction request being for converting from the primary token to the secondary token, executing the transaction request using a first bonding curve implicitly defined by a function and a first set of a plurality of values of a plurality of adjustable parameters, and in response to the transaction request being for converting from the secondary token to the primary token, executing the transaction request using a second bonding curve different from the first bonding curve, the second bonding curve implicitly defined by the function and a second set the plurality of values of adjustable parameters that is different from the first set.

In a further implementation form of the first, second, and third aspects, the primary reserve is managed without managing a secondary reserve of secondary tokens of the secondary cryptocurrency.

In a further implementation form of the first, second, and third aspects, the plurality of adjustable parameters are selected for meeting hardware and/or software resource requirements for execution of code of the distributed smart contract.

In a further implementation form of the first, second, and third aspects, further comprising code for dynamically monitoring the execution of the code of the distributed smart contract, and dynamically adapting the plurality of adjustable parameters for meeting the hardware and/or software resource requirements.

In a further implementation form of the first, second, and third aspects, the resource requirements are selected from a group comprising: calculation accuracy in the absence of floating-point arithmetic, overflow, underflow, unsigned integers, computational complexity, storage requirements, and memory requirements. In a further implementation form 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 network connected server.

In a further implementation form of the first, second, and third aspects, one of the x-axis and the y-axis represents a balances of the primary reserve, and the other axis is non-defined, and the function represents all possible exchange rates for converting between the primary token and the second token.

In a further implementation form of the first, second, and third aspects, the transaction request for exchange using the function with applied parameters is executed on blockchain using fundamental math operations selected from: addition, subtraction, multiplication, and division, and excludes all of: Taylor series, polynomial approximation, and numeric methods of producing a function output.

In a further implementation form of the first, second, and third aspects, at least two of the plurality of adjustable parameters are computed off-blockchain.

In a further implementation form of the first, second, and third aspects, the bonding curve comprises a first bonding curve and further comprising a second bonding curve defined by the function, the first bonding curve defined by a first set of values of the adjustable parameters, the second bonding curve defined by a second set of values of the adjustable parameters, the first bonding curve for converting from the primary cryptocurrency to the secondary cryptocurrency, and the second bonding curve for converting from the secondary cryptocurrency to the primary cryptocurrency, wherein the first bonding curve and the second bonding curve have common adjustable parameters with different values.

In a further implementation form of the first, second, and third aspects, a first exchange rate for converting from the primary cryptocurrency to the secondary cryptocurrency is computed according to the first bonding curve, a second exchange rate for converting from the secondary cryptocurrency to the primary cryptocurrency is computed according to the second bonding curve, wherein the first bonding curve is different than the second bonding curve and the first exchange rate is different than the second exchange rate.

In a further implementation form of the first, second, and third aspects, the transaction comprises receiving secondary tokens, and automatically adding the secondary tokens to a secondary reserve according to the second bonding curve, and automatically withdrawing primary tokens from the primary reserve according to the first bonding curve. In a further implementation form 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.

In a further implementation form of the first, second, and third aspects, further comprising obtaining a strategy from the client terminal, the strategy defining the values of the parameters for the first bonding curve and the second bonding curve.

In a further implementation form of the first, second, and third aspects, the plurality of adjustable parameters include a base set of adjustable parameters, selected from the group comprising: n,

Pa denoting a start value of a range of exchange rates for converting from the primary cryptocurrency to the secondary cryptocurrency,

Pb denoting an end value of a range of exchange rates for converting from the primary cryptocurrency to the secondary cryptocurrency,

P denoting a gradient at x=xo, y=yo indicating a geometric mean price, Q

R,

S denoting a difference of square roots of the gradients of the intercepts, yint denoting a balance of the primary tokens where the marginal exchange rate is equal to Pa, xint denoting, when the range commences with y=yint, a balance of secondary tokens that is obtainable if the balance of the primary tokens is driven to zero x0 denoting an x-coordinate at the geometric mean price, yo denoting a y-coordinate at the geometric mean price, x_asym denoting an x-asymptote or vertical asymptote, y_asym denoting a y-asymptote or horizontal asymptote, and geometric and/or algebraic reconstruction of the aforementioned.

In a further implementation form of the first, second, and third aspects, different values are assigned to a same set of the base parameters for different bonding curves implicitly defined by the function.

In a further implementation form of the first, second, and third aspects, a single distributed smart contract executing on the blockchain implements a different set of values for the adjustable parameters for a different instance of the function, and the single distributed contract implements each respective reserve of a certain token and a corresponding bonding curve defined by the function with the different set of values for the adjustable parameter defines a primitive for unidirectional exchange between an external token and the certain token of the respective reserve, wherein multiple primitives are linked to one another for defining unidirectional routes for token exchanges.

In a further implementation form of the first, second, and third aspects, the function is defined with reference to a hyperbola with asymptotes at x=Q and =0 represented as xy=k where x denotes the primary token and y denotes the secondary token.

In a further implementation form of the first, second, and third aspects, the function includes at least one adjustable asymptote, and a graph of the function shares at least one common point with a constant product bonding curve denoted as xy=k.

In a further implementation form of the first, second, and third aspects, a slope of each at least one bonding curve at the at least one common point is identical with a first derivative of xy=k, wherein each at least one bonding curve is defined to have a point on its implicit curve at coordinates x=x0 and = 0 where a first derivative is equal to that of the constant product bonding curve at the same coordinates.

In a further implementation form of the first, second, and third aspects, the bonding curve is defined as the implicit curve of the invariant function, which is used to enumerate a continuum of exchange rates between a primary cryptocurrency and a secondary cryptocurrency.

In a further implementation form of the first, second, and third aspects, each exchange rate of a plurality of exchange rates for converting between the primary cryptocurrency and the secondary cryptocurrency is represented as a secant line between two points of the function, wherein a first point represents the balance of the primary reserve before the exchange occurred, and a second point represents the balance of the primary reserve after the exchange occurred.

In a further implementation form of the first, second, and third aspects, each parameter is assigned to a set of a plurality of sets, each parameter of each set is mathematically related to other parameters within the set and each parameter is mathematically related between sets of other parameters, sufficient to unambiguously describe a unique invariant function - implicit curve pair.

In a further implementation form of the first, second, and third aspects, a marginal exchange rate for converting between the primary cryptocurrency and the secondary cryptocurrency is computed according to a first derivative of the bonding curve implicitly defined by the function with applied adjustable parameters.

In a further implementation form of the third aspect, the primary reserve and the secondary reserve are linked, wherein when the transaction request includes an amount of secondary tokens, an amount of primary tokens are obtained from the primary reserve according to the first bonding curves, and the secondary tokens are deposited into the secondary reserve according to the second bonding curve.

Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention pertains. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the invention, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

Some embodiments of the invention are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments of the invention. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments of the invention may be practiced.

In the drawings:

Figures la-c are schematics depicting the invariant function characterized as having a point on its implicit curve with coordinates x = xo, y = yo, which coincide with the graph of eqns. la-c, in accordance with some embodiments of the present invention;

Figures 2a-c are schematics where the negated slope of the tangent line (-dy/dx) at this point is P and is equal in both implicit curves of the customizable function and eqns. Id-e, in accordance with some embodiments of the present invention;

Figures 3a-g are schematics where the parameter k is the hyperbola constant of eqns. la- c, (i.e. xy = k), and denotes the magnitude of the constant product’s implicit curve with which the implicit curve of the novel invariant function shares the coordinates x = xo, y = yo, in accordance with some embodiments of the present invention;

Figures 4a-l are schematics where the parameters x_asym and y_asym denote the “vertical” and “horizontal” asymptotes, respectively, of the novel function’s implicit curve, in accordance with some embodiments of the present invention; Figures 5a-g are schematics where the parameters xint and yint denote the x- and y- intercepts the novel function’s implicit curve, in accordance with some embodiments of the present invention;

Figures 6a-f are schematics where the slope of the tangent lines at the y- and x-intercepts of the novel implicit curve, y = yint and x = xim, respectively, are denoted by the parameters P_a and Pb, respectively, in accordance with some embodiments of the present invention;

Figures 7a-b are schematics depicting exemplary methods of discovery of the parameters n, u that denote the relative size of two rectangles, in accordance with some embodiments of the present invention;

Figures 7c-d are schematics depicting an exemplary method for discovering the parameter Q, which denotes the relative size of two rectangles, in accordance with some embodiments of the present invention;

Figures 8a-c are schematics in which eqn. 22 substitutes n for f(x), in accordance with some embodiments of the present invention;

Figures 9a-c are schematics in which eqns. 23a-c substitute n for f(a, x, xo, y, yo), in accordance with some embodiments of the present invention;

Figure 10 is a schematic depicting a state before any exchanges are performed, of Alice’s pristine strategy, in accordance with some embodiments of the present invention;

Figure 11 is a schematic depicting the difference in the relative changes to either half of Alice’s strategy, in accordance with some embodiments of the present invention;

Figure 12 is a schematic depicting the difference in the relative changes to either half of Alice’s strategy, in accordance with some embodiments of the present invention;

Figure 13a is a schematic depicting accumulation of additional USDTKN at the current price point that fills its cognate bonding curve from the bottom-up, slowly moving the reaccumulation target back towards the upper boundary, in accordance with some embodiments of the present invention;

Figure 13b includes graphs indicating the first case where Alice’s balance of USDTKN exceeds the yint on its own curve, in accordance with some embodiments of the present invention;

Figure 14, which is a diagram of components of a system for performing transactions of cryptocurrencies using one or more bonding curves with values for adjustable parameters of a function, in accordance with some embodiments of the present invention; Figure 15, which is a flowchart of a method for performing transactions of cryptocurrencies using one or more bonding curves with values for adjustable parameters of a function, in accordance with some embodiments of the present invention

Figure 16, which is a sequence diagram for creation of a strategy of two or more bonding curves for converting cryptocurrencies, in accordance with some embodiments of the present invention;

Figure 17 is a sequence diagram for depositing funds using the strategy, in accordance with some embodiments of the present invention;

Figure 18 is a sequence diagram for withdrawing funds using the strategy, in accordance with some embodiments of the present invention; and

Figure 19 is a sequence diagram for trading using the strategy, in accordance with some embodiments of the present invention.

DETAILED DESCRIPTION

As used herein, the terms bonding curve, function, invariant function, novel invariant function, customizable function, and customizable invariant function, and the like, are used interchangeably. The bonding curve may refer to the function with values for the adjustable parameters, as described herein. For example, a first bonding curve and a second bonding curve may refer to the same function with same adjustable parameters, having different sets of values assigned to the adjustable parameters. The first bonding curve may be defined by a first set of values assigned to the adjustable parameters of the function. The second bonding curve may be defined by a second set of values assigned to the adjustable parameters of the function.

The terms primary token and secondary token are sometimes used interchangeably. The terms primary and secondary token may be used arbitrarily, as any one of two tokens and/or reserves and/or pool tokens may be referred to as primary, with the other referred to as secondary. The terms primary and secondary are used for convention and clarity of explanation. In most cases, the terms primary and secondary refer to tokens of which the smart contract is unable to mint and/or burn, since both tokens are controlled by another external unrelated smart contract, for example, cryptocurrencies that are bought and sold on the open market, for example, bitcoin, ethereum, and the like. As used herein, the term cryptocurrency and token are interchangeable. A token may be created for different purposes and/or uses, for example, representing money, club member points, frequent flyer points, reward points, as part of a game, and the like. Tokens may be customized cryptocurrencies issued and based upon another cryptocurrency such as provided by the Ethereum Network, Lisk, RootStock, and other Networks.

An aspect of some embodiments of the present invention relates to systems, methods, computing devices, and/or code instructions (stored on a data storage device and executable by one or more processors) for exchanging tokens by a distributed smart contract executing on a blockchain using a bonding curve, optionally an asymmetrical curve, with selectable and/or adaptable values of adjustable parameters. A processor manages a primary reserve of tokens of a primary cryptocurrency. Values of the adjustable parameters that define a function for computing an exchange rate for converting between the primary cryptocurrency and a secondary cryptocurrency are obtained, optionally from a client terminal (e.g., used by a user). The values may be customizable, for example, selected and/or adapted by the client terminal. In response to a transaction request for converting between the primary tokens and a secondary token of a secondary cryptocurrency, the processor executes the transaction request using a bonding curve defined by the function with the values of the plurality of adjustable parameters.

The bonding curve may be asymmetrical. The first bonding curve may provide primary tokens in response to receiving secondary tokens, thereby converting from the secondary tokens to the primary tokens. A second bonding curve with different values for the adjustable parameters may be defined for providing secondary tokens in response to receiving primary tokens, thereby converting from the primary tokens to the secondary tokens. Different exchange rates may apply for different directions (i.e. TO, FROM), even for the same amounts being exchanges, according to the first and second bonding curves.

Optionally, multiple reserves of different types of cryptocurrencies are managed. Each reserve may be associated with one or more bonding curves, that define the exchange between another cryptocurrency and the respective cryptocurrency being managed. Each reserve and bonding curve may be considered as a primitive defining a specific exchange in a unilateral direction between two types of cryptocurrencies. The multiple primitives may be used to define a set of customizable unilateral token exchanges. For exchange, to exchange from a token A to a token C, the following may be defined token A

token B

token C, i.e., no direct exchange from token A to token C exists. To exchange token A to token C, token A must first be exchanged for token B, and then token B is exchanged for token C. In another example, a single primitive may be used on its own, for example, to define a specific directional conversion from one type of cryptocurrency to another type of cryptocurrency, such as token A - B. When the single primitive is used on its own, no trade can be done from token B to token A.

At least some implementations of the systems, methods, apparatus, and/or code instructions described herein address technical problems related to smart contracts managing cryptocurrencies executing on a blockchain, and/or improve the technology of smart contracts managing cryptocurrencies executing on a blockchain, and/or improve on prior approaches of smart contracts managing cryptocurrencies executing on a blockchain.

At least some implementations described herein address the technical problem of improving utilization of computational and/or processing resources executing the smart contract managing cryptocurrencies on the blockchain, for example, reducing processor utilization, reducing processing time, reducing the amount of used memory, and/or reducing the amount of storage space. Using standard approaches, in which smart contracts managing cryptocurrencies are bound by fixed rules, does not differentiate between smart contracts that require additional processing and/or computational resources and smart contracts that require fewer processing and/or computational resources. At least some implementations described herein address the aforementioned technical problem by enabling customization of the smart contract according to target processing and/or computational resources. The customization provided by some embodiments enables smart contracts that require additional processing and/or computational resources to obtain the additional resources, while in contrast using standard approaches those smart contracts would not be allocated additional resources and/or would experience increased costs for obtaining the additional resources. The customization provided by some embodiments enables smart contracts that are able to operate with fewer processing and/or computational resources to be allocated less processing resources. This frees up those resources which would have been unnecessarily tied up, for use by other smart contracts.

At least some implementations of the systems, methods, apparatus, and/or code instructions described herein improve computational efficiency of a computing device executing the smart code on the blockchain, by reducing computational resources that would otherwise be required for executing the smart code, for example, reduced processor utilization, reduced processing time, and/or reduced allocated memory. The customizable parameters of the function seed by the smart contract may be selected for using reduced computational resources, for example, in comparison to the resources that would be used by standard smart contracts operating under standard fixed non-customizable rules.

At least some implementations described herein address the technical problem of fixed rules of the smart contract managing cryptocurrencies. Users are bound by the rules defined by the smart contracts. All users are bound by the same rules. The fixed rules apply to all users limit the user experience. At least some implementations described herein address the aforementioned technical problem by enabling customization of the smart contract by each user. Different users may define different customizations for their respective smart contracts. The ability to customize the smart contract provides an enhanced user experience to users of the smart contracts. Different users may define primitives using different values for the adjustable parameters of the function to create different bonding curves, where each bonding curve defines a specific conversion is a specific direction, from a first cryptocurrency to a second cryptocurrency. A set of primitives may be defined to provide conversions amongst different cryptocurrencies, for example, according to the user’s selection. The option to define a single primitive on its own, for unidirectional trade and no trade in the other direction, is in contrast to prior approaches that provide symmetrical trading between two cryptocurrencies. The option to link multiple primitives to provide a set of unidirectional trades of cryptocurrencies, each with its own bonding curve, is in contrast to prior approaches that provide symmetrical trading between two cryptocurrencies.

At least some implementations described herein address the technical problem of the same rules applied to the buying and to the selling of cryptocurrencies. Users are bound by the same exchange rates, which are equally applied to the buying and to the selling. At least some implementations described herein address the aforementioned technical problem by enabling different rules for the buying and selling. Users may define a first set of rules for buying, and a second set of rules for selling. The ability to define different rules for the buying and for the selling provides an enhanced user experience to users of the smart contracts.

Examples of prior approaches for smart contracts managing cryptocurrencies executing on a blockchain are described, for example, with reference to United States Patent No. 11,188,896 "SMART CONTRACT OF A BLOCKCHAIN FOR MANAGEMENT OF CRYPTOCURRENCIES" (referred to herein as Patent ‘896), and/or United States Patent No. 11,574,291 “Methods for Exchanging and Evaluating Virtual Currency”, (referred to herein as Patent ‘923) filed on January 8, 2018, incorporated herein by reference in their entirety, which includes at least one common inventor as the instant application.

At least some implementations described herein improve the technology of exchange of tokens between different participants within a distributed application environment, such as a blockchain, and/or improve a smart contract implementation thereof.

At least some embodiments described herein improve the technology of Decentralized finance (DeFi) applications, which are a distributed system of applications built on public blockchains that fulfill the need for economic and/or financial primitives for cryptocurrency. Decentralized exchanges (DEXes) are protocols that allow for cryptocurrency tokens to be exchanged between users in a permissionless manner. The prototypical example is a smart contract (“liquidity pool”) that collects crowd-sourced capital from users (“liquidity providers”) and issues a receipt token (“pool token”) in return. The pool token represents the liquidity provider’s pro-rata share of the liquidity pool as a whole; therefore, any proportion of the pool token supply is redeemable for the same proportion of the liquidity pool. The composition of the liquidity pool may change over time as users (“traders”) exchange their own tokens for those inside the liquidity pool. DeFi applications use an invariant function DEX, where exchange rates are determined by equations which force the composition of the liquidity pool to adhere to a predefined profile (termed “bonding curve”). Preeminent examples are constant product, and constant sum; however, more elaborate variations of these concepts have appeared which have fine-tuned the behavior of their protocols and cognate liquidity pools. The “value” function, and the “stableswap” function are noteworthy modifications of common archetypes.

At least some embodiments described herein address the technical problem experienced by liquidity providers on DEXes, which are beholden to parameters of the liquidity pool to which they contribute their tokens. Thus, the agency of an individual liquidity provider to decide their own exchange rates and execute precise trading strategies is suppressed in favor of a prescribed, generic interpretation of their intentions. At least some embodiments described herein address the aforementioned technical problem, and/or improve the aforementioned technology, by providing a mechanism of liquidity provision whereby users can exercise their personal trading preferences. This is made possible by a customizable invariant function that encompasses an infinite set of bonding curves, the elements of which may include constant sum and/or constant product models. Each liquidity provider therefore owns their own liquidity pool, for which they may be the only participant. Moreover, each liquidity pool may be governed by a set of bonding curves, instead of just one, which allows for the tokens to be deployed asymmetrically. In contrast to existing approaches where tokens sold by a liquidity pool are assumed to be purchased back by the pool at the same exchange rate, the asymmetry paradigm described herein allows for the sale and repurchase rates, as well as their relative acceleration, to be independent of each other.

In the common vernacular, some embodiments caters to a “buy low, sell high” trading mentality, and allow its 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 can variably be the sole property of its creator, or, alternatively, be open for community participation through the issuance of its own pool tokens. The latter describes a novel type of subscriber trading product and represents a decentralized counterpart to copy trading on conventional, centralized exchanges.

Taken together, the improvements offered by at least one embodiments described herein address technical challenges that have greatly limited the scope of application for DEX protocols.

At least some embodiments described herein address the aforementioned technical problem, and/or improve the aforementioned technology, by an invariant function and/or infinite set of associated bonding curves, and/or an asymmetric liquidity pool design employing one or more instances of these bonding curves supporting arbitrary trading strategies across any number of cryptocurrency tokens within the same pool.

At least some embodiments described herein address the aforementioned technical problem, and/or improve the aforementioned technology, by the invariant function that is employed with adjustable parameters that allow for users to determine the behavior of its associated liquidity pool with respect to exchange rates and price acceleration for all liquidity contained therein. In contrast to prior approaches, the function described herein is customizable (optionally infinitely). The customizable function may be limited in scope, accuracy, and/or resolution by the virtual machine of the distributed ledger system it is deployed on.

At least some embodiments described herein address the aforementioned technical problem, and/or improve the aforementioned technology, by the asymmetric liquidity pool described herein, which is designed to use a plethora of bonding curves simultaneously to achieve an explicit trading profile, concordant with the objectives and bias of its creator. In contrast to prior approaches, asymmetric liquidity pools allow for decisive actions by liquidity providers. The asymmetric liquidity pools enable executing premeditated plans, while maintaining liquidity for the cryptocurrency token economy.

Different subsets of adjustable parameters may be defined (e.g., over-parameterization), from which specific forms of the invariant function can be explicitly derived. The subsets are of a much larger collection of possible groupings of curve parameters and associated rearrangements of the general formula. Such flexibility allows for application-specific considerations to be addressed, including but not necessarily limited to: calculation accuracy in the absence of floating-point arithmetic, overflow and underflow, unsigned integers, computational complexity, storage and memory requirements, or other limitation imposed either directly or indirectly by the hardware or software on which the outputs of the function are determined. At least some embodiments described herein improve upon prior approaches. For example, the status quo in DeFi protocols employing concentrated liquidity models is that exchanges are reversible; users who have contributed tokens to the smart contract system exchange tokens in both directions concordant with the system state. This manifests as a symmetric exchange profile, save for a nominal fee, whereby users of these protocols are forced to accept the reverse exchange at the same rate as the forwards direction. In contrast, at least some embodiments described herein, improve upon such prior approaches by designating the forwards and reverse exchange rates as separate, and optionally entirely under the control of the user. Therefore, and in contrast to conventional AMMs, users’ positions are described by two or more bonding curves, simultaneously. From this arrangement a technical capability of DeFi smart contract systems can emerge, which is a technical improvement over existing approaches. The asymmetric liquidity pool construction, in addition to a formal limit order functionality, offers what may best be described as support for automated trading strategies. The term “user strategy” is used herein to refer to a specific analogue of liquidity provision. It is helpful to interpret each strategy as its own unique liquidity pool vis-a-vis the entrenched meaning of the term. However, apart from both being smart contract systems that contain cryptocurrency tokens for the explicit purpose of performing exchange, the behavior of the strategies described herein are a profound shift from the standard DeFi archetypes.

Moreover, after the initial calculations of B and S, as described herein, during the creation of a strategy, which can be performed with the assistance of off-chain resources, all on- chain calculations performed during swaps use (optionally only) the fundamental math operations addition, subtraction, multiplication, and division. This is true of equations described herein relating to the computation of marginal exchange rates and swaps, thus precluding the need for Taylor series and/or other polynomial approximations, and/or numeric methods of producing a function output. The freedom of choice to select appropriate parameters, and/or customized equation sets to fit the virtual machine on which the decentralized application is running addresses the technical problem of reducing use of computation resources for executing the smart contract.

Additional details of using embodiments described herein for improving computational efficiency of a computing device (e.g., processor) running a smart contract on a blockchain, and/or other distributed application, are now described.

Mathematical computations over a size-limited fixed-point infrastructure, bare a fundamental trade-off between Accuracy and Valid Input Range. Within any computation, the only type of operation which can reduce the accuracy of the output is division. The typical solution is to rearrange the computation such that division takes place only as the very last step. Subsequently, intermediate results of the computation become more likely to overflow and revert the entire transaction. This means that rearranging the computation will effectively reduce the range of input which can be handled successfully. For example, consider the following expression:

where a = 100, & = 51, c = 1, d = 25, and a size-limit of 8 bits (maximum value being 255). The true value of this expression is 100 / 51 + 1 / 25 = 2.00078..., so ideally on a fixed- point infrastructure, we would want our implementation to yield 2. The straightforward implementation a / b + c / d is very inaccurate. It yields the output 100 / 51 + 1 / 25 = 1 + 0 = 1, which reflects an inaccuracy of more than 50% compared with the true value. However, rearranging it such that division takes place as the very last step using:

reverts the transaction. It yields the intermediate computation of a * d = 100 * 25, which overflows the given size-limit.

In the following, these concepts are elaborated with a view to distinguish between mathematically redundant, but computationally distinct, versions of the invariant function described in the disclosure. First, two different implementations of the invariant function, one using the constants x0, 0 and n, and the other using the constants S, B, and yint, are discussed relative to each other. Then, a short discussion is provided comparing the implementation flexibility of implementations described herein versus other concentrated liquidity industry standards, Uniswap V3 and Kyber DMM, which are based on embodiments described with reference to Patents ‘896 and/or ‘923.

Some embodiments of the disclosure relate to an asymmetric liquidity system that includes (so-called concentrated liquidity) bonding curves. Each bonding curve may be described with respect to a collection of parameters which define its characteristic pricing behaviour. As each parameter may be expressed in terms of other parameters, it is possible to present to the user an intuitive selection and then process their input so as to preserve its meaning, while affording a more computationally tractable translation of the same data. From a product perspective, the user may need only make decisions as to the specific price intervals through which their liquidity will be available to the market, and the quantity of tokens they wish to include in said interval. It is noted that the user choices presented here are accurate but simplified. The local discussion herein is not to explore the full scope of possible applications, but rather to demonstrate the flexibility of implementations of some embodiments with respect to constraints of the computer environment that the implementation will run on. These user-facing parameters are defined in more detail herein; a truncated version appears below and features just the parameters a user would be presented with, prior to further processing.

Consider that with these inputs, any of the terms discussed herein can be accessed using the formulae contained therein. For example, the parameters n, yo and xo can be computed using eqns. 11b, lid, and 13n described herein. eqn. lid eqn. 11b eqn. 13n

Such processing would allow for the invariant functions eqns. 2d-h described herein to be used by the protocol. For clarity, each of these forms may be redundant with each other; they may be different algebraic representations of the same fundamental relationships between the constants n, yo and xo and the points (x, y) that satisfy these relationships.

eqn. 2h The x and y coordinates may be defined in terms of each other using eqns. 3-4e described herein. The marginal price formulae are defined by eqns. 5-6e described herein. The token swap formulae, and swap-dependent pricing formulae are defined by eqns 7-10e described herein. To further assist with the present discussion, a rearrangement of eqn. 8e to make Δx the subject is included as eqn. SI. Equation 8e is a generic swap equation, where -Δy denotes the quantity of target tokens received by the trader in exchange for Δx source tokens, appropriate for when the trader nominates Δx and measures -Δy. Equation SI is the reverse swap equation, appropriate for when the trader requests to receive -Δy of the target token and measures the trade amount Δx required to achieve such a result

Note that Pa and Pb may be expected to remain constant until the user changes their values, whereas yint may change as a result of normal protocol activity. Some information may be pre-calculated before runtime (i.e., in advance). The precalculated information may be found during runtime to:

• Improve accuracy (reduce precision loss)

• Improve performance (reduce the gas cost)

For example, the following may be pre-calculated:

In a fixed-point infrastructure such as Ethereum (and other blockchains), each of the constants must be subjected to a scaling factor to remove the fractional component, and then use just the integer part of each one of the results. The runtime computation itself will need to account for each one of these scaling factors, and possibly descale intermediate results accordingly. The scaling of each constant value needs to be high enough to make precision-loss negligible, but at the same time, it should not be high to the point of bringing the size of valid input range (where certain inputs lead to arithmetic overflow) below system requirements.

An alternative approach based on at least some embodiments described herein is now described. Parameters S and B (eqns 20a-c) described herein, may also be computed directly from the user inputs listed in Table SI.

Processing via this method grants access to the invariant function eqn. 21a described herein. The x and y coordinates can be defined in terms of each other using eqns. 21b-c described herein. The marginal price formulae are defined by eqns. 21d-e described herein. The token swap formulae, and swap-dependent pricing formulae are defined by eqns. 21f-i described herein. To further assist with the present discussion, a rearrangement of eqn. 21g¹ to make Δx the subject is included as eqn. S2. Equation 21g is a generic swap equation, where - Δy denotes the quantity of target tokens received by the trader in exchange for Δx source tokens, appropriate for when the trader nominates Δx and measures -Δy. Equation S2 is the reverse swap equation, appropriate for when the trader requests to receive -Δy of the target token and measures the trade amount Δx required to achieve such a result.

A comparison of two different implementations of the theory elaborated herein, derived from representations of the invariant function eqn. 2h (which uses the constants xo, yo, and n) and 21a (which uses the constants S, B, and yint). In both cases there is a need to maintain three constant values in addition to the token balance, y. However, the latter implementation benefits from a reduction in:

The overall number of operations (e.g., gas cost). • The overall number of division operations (e.g., precision-loss).

• The overall magnitude of intermediate results (e.g., potential overflows).

Since yint is used directly as its own constant in the implementation employing S and B, there is no precision loss associated with its processing after receiving it as an input from the user. It is noted that yint is adjusted dynamically by the protocol during regular operation as required to maintain the user’s liquidity within their nominated price bounds Pa and Pb. This aspect of the disclosure is described herein; examples of updates to this parameter are described, for example, in Table 5, Table 7, and Table 11. Using yint directly also has ongoing operational advantages. During certain conditions, it is necessary to update the size of the user’s curve, as depicted in Figure 11 and described herein.

During such an event, both constants xo and yo would require an update, whereas the implementation using yint as its own constant requires that it be updated. Moreover, direct update of yint requires no mathematical operations whatsoever. These updates occur when the token balance y surpasses the value of yint, at which point yint is updated to be equal to y. The Boolean operations required to compare two numbers, and update one to be equal to the other, is computationally trivial. Whereas the implementation involving xo and yo is rather complex. First, this conditional statement requires yint to be reconstituted from the stored constants yo and n, prior to the Boolean operation. Then, if an update is required, the new yint value is then be decomposed back into xo and yo, further burdening the computational overhead and introducing additional precision issues. Addressing optimal scaling factors for the values of S and B, as alluded to previously:

• Each scaling factor is to be high enough to make precision-loss negligible.

• Each scaling factor is not be high to the point of causing runtime overflows.

An additional consideration is the overall size required for storing these values in the contract on a blockchain for example, Ethereum. As on-chain storage read/write operations are typically amongst the most gas-consuming ones, it is preferable to maintain all 4 values (y, yint, S, B) using as little storage as possible.

At least some implementations based on embodiments described include entities referred to herein as Strategies. Each strategy may include two or more entities sometimes referred to herein as Orders. Each order may include the 4 values described above. Hence each strategy includes 2 sets of these 4 values. Strategies may be created, for example, by market makers (i.e., liquidity providers) and/or traded against by market takers (i.e. traders). Each strategy may be traded independently of all other strategies. When traded against, the following storage-access operations may be executed:

The source order may refer to the component of the maker’s (e.g., liquidity provider’s) strategy that has a token balance with the same identity as that which the taker (e.g., trader) is sending into the protocol. For example, if the trader is sending TKN1 into the protocol and receiving TKN2, then the maker’s order with a balance of TKN1 is the source order.

The target order may refer to the opposite of the source order. Using the example above, the maker’s order with a balance of TKN2 is the target order.

In an exemplary implementation, the value of y (e.g., current token balance/liquidity) typically requires no more than 112 bits, allowing for an amount of approximately 5* 10³³ (i.e., the number 5 followed by 33 zeros), which is more than enough for representing any reasonable token-decimal value, including high token decimal contracts. For example:

• A token with 18 decimals, it allows for up to 5* 10¹⁵ (5 million billion) tokens.

• A token with 22 decimals, it allows for up to 5* 10¹¹ (500 billion) tokens.

• A token with 24 decimals, it allows for up to 5* 10⁹ (5 billion) tokens.

The same number of bits is required for the value of yint, since it is derived directly from the value of y. The value of B, which stores the square root of the lowest exchange rate, may need to be scaled up to some integer value large enough to maintain most of the information. Allocating 64 bits for it and scaling it up by a factor of 2³² may allow it to attain values between 1/2³² and 2³², at a resolution of 1/2³². This may yield effective rates between 1/2⁶⁴ and 2⁶⁴, at an average resolution of 1/2¹⁶.

Similarly for the value of S, which stores the difference between the square root of the highest exchange rate and the square root of the lowest exchange rate, allocating 64 bits for it and scaling it up by a factor of 2³² may allow it to attain values between 1/2³² and 2³², at a resolution of 1/2³². This may yield effective rates between 1/2⁶⁴ and 2⁶⁴, at an average resolution of 1/2¹⁶.

Therefore, each strategy requires 2 x (112 + 112 + 64 + 64) = 704 bits. It is important to note here that unpredictable token decimality (a property of a cryptocurrency token that refers to its smallest, indivisible unit) necessitates relatively high storage allocation, whereas the rate constants S and B are relatively insensitive and can be satisfactorily implemented with lower storage requirements. With reference to Table 2, the following exemplary layout of these values in storage may be:

The following exemplary layout of these values in storage may be:

• Slot #1 : y (source), y (target)

• Slot #2: yint (source), S (source), B (source)

• Slot #3 : yint (target), S (target), B (target)

Will yield for every trade on a given strategy:

• Exactly 3 slot-read operations.

• Either 1 or 2 slot-write operations.

Encoding/Decoding

With:

• L = order’s lowest rate

• H = order’ s highest rate

• M = order’s marginal rate Given:

• min = floor(2³² x sqrt(L))

• max = floor(2³² x sqrt(H))

• mid = floor(2³² x sqrt(M))

The order maintains:

• y = current liquidity

• yint = current liquidity * (max - min) / (mid - min)

• S = max - min • B = min

The order reflects:

• L = (B / 2³²)²

• H = ((B + S) / 2³²)² • M = ((B + 5 * y / yint) / 2³²)²

Trade Computation

Function mulDiv(m, n, d) returns the value of m x n / d, while allowing the intermediate value of m x n to exceed 256 bits; the function overflows (reverts) only if the final result exceeds 256 bits.

It may be observed that:

• In function getTradeTargetAmount: o Transaction-revert may occur due to overflow. o Precision-loss may occur due to two division operations.

• In function getTradeSourceAmount: o Transaction-revert may occur due to overflow or underflow. o Precision-loss may occur due to one division operation.

Nevertheless, overflows and underflows are expected to be extremely rare, occurring under highly unlikely combinations of input value (Ax) and system state (y and yint). And due to the very small number of division operations executed in each function, the loss of precision is also expected to remain minimal.

Some examples of industry Standard comparisons are now provided.

Two close industry analogues exist, to which the implementation considerations discussed here may be compared. One example is Uniswap V3, which is described in its whitepaper, Uniswap v3 Core (Adams, H.; Zinsmeister, N.; Salem, M.; Keefer, R.; Robinson, D. 2021). The authors introduce an invariant function of the form eqn. S3, which is redundant with the virtually amplified token reserves described with reference to Patent ‘896. For clarity of explanation, here, the constants Pa and Pb are displayed for consistency with their meaning in the disclosure; the meaning of these two parameters is reversed in the whitepaper. The constant L can be expressed in terms of xo, yo, and n, as shown in eqn. S4. This deduction is not featured in the article by Adams et al, but provided herein for explanatory purposes.

Since L is redundant with xo, yo and n, it suffers from the same drawbacks as the implementation using these constants, discussed above. In another example, The Kyber DMM whitepaper, Dynamic Automated Market Making (Nguyen, A.; Luu, L.; Ng, M. 2021), presents a rudimentary derivation of the constants .to and o, and introduces an amplification term a, which is equivalent to the reciprocal of n (i.e. the term u of the present disclosure), which is redundant with the virtually amplified token reserves described in Patent ‘896. Unlike the Uniswap paper, the paper by Nguyen et al. does not contain a new invariant function; rather, it invokes virtualized token balances belonging to a simulated, larger bonding curve (Excerpt SI).

The Kyber DMM implementation manages four token balances, two real and two virtual. While the total number of parameters required to describe a concentrated liquidity profile is identical, this method of using both real and virtual token balances requires that all four parameters are read from and written to storage with every trade. How to apply this method to an asymmetric system is not entirely clear; however, it is certain that at least two additional virtual balances would be required. As alluded to in earlier discussion, token balances can require significant storage allocation to account for the long integers necessary to achieve reasonable accuracy, making this a formidable challenge vis-a-vis gas consumption and overall network overhead. Adjusting the size of the curve (i.e. the equivalent of yint) would entail changes to at least three of these token balances simultaneously. Given the prohibitively large integers required to support such an implementation, it is likely that all three updates could require individual read/write actions to discrete memory slots in the Ethereum Virtual Machine. Lastly, high amplification values will result in ostensibly absurd virtualized token balances. For example, implementation described herein an S value of zero - which is easily supported - would require an infinite virtual token balance in the system described by Nguyen et al.

It should be stressed that neither Uniswap V3 or Kyber DMM discuss asymmetric liquidity, and both systems are redundant with the virtually amplified token reserves described in Patent ‘896, and their systems must contend with additional implementation challenges, unrelated to the embodiments described herein. The aspect of handling of the invariant function described herein improves computational performance of a computer and/or processor executing the smart contract, blockchain, and/or other distributed application, afforded by its overparameterization, over existing approaches.

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

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 thereon for causing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference to flowchart illustrations 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 flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

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, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

Reference is now made to Figures la-c, which are schematics depicting the invariant function characterized as having a point on its implicit curve with coordinates x = xo, y = o, which coincide with the graph of eqns. la-c, in accordance with some embodiments of the present invention. Reference is also made to Figures 2a-c, which are schematics where the negated slope of the tangent line (-dyldx) at this point is P and is equal in both implicit curves of the customizable function and eqns. Id-e, in accordance with some embodiments of the present invention. Reference is also made to Figures 3a-g, which are schematics where the parameter k is the hyperbola constant of eqns. la-c, (i.e. xy = k), and denotes the magnitude of the constant product’s implicit curve with which the implicit curve of the novel invariant function shares the coordinates x = xo, y = yo, in accordance with some embodiments of the present invention. Reference is also made to Figures 4a-l, which are schematics where the parameters x_asym and a_sym denote the “vertical” and “horizontal” asymptotes, respectively, of the novel function’s implicit curve, in accordance with some embodiments of the present invention. Reference is also made to Figures 5a-g, which are schematics where the parameters xint and yint denote the x- and y- intercepts the novel function’s implicit curve, in accordance with some embodiments of the present invention. Reference is also made to Figures 6a-f, which are schematics where the slope of the tangent lines at the y- and x-intercepts of the novel implicit curve, y = yint and x = xim, respectively, are denoted by the parameters P_a and Pb, respectively, in accordance with some embodiments of the present invention. Reference is also made to Figures 7a-b, which are schematics depicting exemplary methods of discovery of the parameters n, u that denote the relative size of two rectangles, in accordance with some embodiments of the present invention. Reference is also made to Figures 7c-d, which are schematics depicting an exemplary method for discovering the parameter Q, which denotes the relative size of two rectangles, in accordance with some embodiments of the present invention. Reference is also made to Figures 8a-c, which are schematics in which eqn. 22 substitutes n for/(x), in accordance with some embodiments of the present invention. Reference is also made to Figures 9a-c, which are schematics in which eqns. 23a-c substitute n for

x, xo, y, yo), in accordance with some embodiments of the present invention. Reference is also made to Figure 10, which is a schematic depicting a state before any exchanges are performed, of Alice’s pristine strategy, in accordance with some embodiments of the present invention. Reference is also made to Figure 11, which is a schematic depicting the difference in the relative changes to either half of Alice’s strategy, in accordance with some embodiments of the present invention. Reference is also made to Figure 12, which is a schematic depicting the difference in the relative changes to either half of Alice’s strategy, in accordance with some embodiments of the present invention. Reference is also made to Figure 13 A, which is a schematic depicting accumulation of additional USDTKN at the current price point that fills its cognate bonding curve from the bottom-up, slowly moving the reaccumulation target back towards the upper boundary, in accordance with some embodiments of the present invention. Reference is also made to Figure 13B, which depicts graphs indicating the first case where Alice’s balance of USDTKN exceeds the yint on its own curve, in accordance with some embodiments of the present invention. Reference is also made to Figure 14, which is a diagram of components of a system for performing transactions of cryptocurrencies using one or more bonding curves with values for adjustable parameters of a function, in accordance with some embodiments of the present invention. Reference is also made to Figure 15, which is a flowchart of a method for performing transactions of cryptocurrencies using one or more bonding curves with values for adjustable parameters of a function, in accordance with some embodiments of the present invention. Reference is also made to Figure 16, which is a sequence diagram for creation of a strategy of two or more bonding curves for converting cryptocurrencies, in accordance with some embodiments of the present invention. Reference is also made to Figure 17 is a sequence diagram for depositing funds using the strategy, in accordance with some embodiments of the present invention. Reference is also made to Figure 18 is a sequence diagram for withdrawing funds using the strategy, in accordance with some embodiments of the present invention. Reference is also made to Figure 19 is a sequence diagram for trading using the strategy, in accordance with some embodiments of the present invention.

Referring now back to Figure 14, system 100 may implement the methods described with reference to FIGs. 1-13 and 15-19.

System 100 includes multiple computing devices 102 each acting as a respective network node (one computing device 102 acting as one network node shown for clarity and simplicity). Computing devices 102 may be geographically distributed. Exemplary implementations of computing devices 102 include, for example, a server, a computing cloud, a virtual machine, a virtual server, a client terminal, a desk top computer, a kiosk, a mobile device, a Smartphone, a Tablet computer, a laptop computer, a wearable computer, augmented reality glasses, a glasses computer, and a watch computer.

Each computing devices 102 includes one or more hardware processors 104, for example, a central processing unit(s) (CPU), a graphics processing unit(s) (GPU), field programmable gate array(s) (FPGA), digital signal processor(s) (DSP), and application specific integrated circuit(s) (ASIC). Processor(s) 104 may include one or more processors (homogenous or heterogeneous), which may be arranged for parallel processing, as clusters and/or as one or more multi core processing units.

Each computing devices 102 includes a memory 106 that stores code instructions executable by hardware processor(s) 102, for example, a random access memory (RAM), readonly memory (ROM), and/or a storage device, for example, non-volatile memory, magnetic media, semiconductor memory devices, hard drive, removable storage, and optical media (e.g., DVD, CD-ROM).

Memory 106 stores smart contract code 108 (also referred to as distributed smart contract code) that executes on a blockchain 110. It is to be understood that the blockchain described herein in one example of a distributed application environment and/or distributed ledger, and other implementations of the distributed application environment and/or distributed ledger may be used as a directed acyclic graph.

Smart contract code 108 implements one or more features and/or acts of the method described with reference to FIGs. 1-13 and 15-19 when executed by hardware processor(s) 104. Smart contract code 108 manages one or more cryptocurrency reserves 108 A, as described herein. Smart contract code 108 provides services for exchanging between the primary token and a secondary token, using a bonding curve defined by values of adjustable parameters of a function. The values for the adjustable parameters may be stored in an adjustable parameter repository 108B, which may be included in blockchain 110 and/or stored on another storage device such as off-line. Transactions executed by smart contract code 108 on reserve(s) 108 A may be recorded in a distributed ledger 108C which may be stored on blockchain 110.

It is noted that different smart contracts 108 executing on the same computing device 102 and/or on different computing devices 102 may provide manage exchange services and/or deposit services and/or withdrawal services for different combinations of cryptocurrencies using different bonding curves. Optionally, each smart contract 108 manages at least a single reserve 108 A that holds a single type of cryptocurrency, and exchanges between the tokens in the reserve and other tokens according to a bonding curve defined by values of adjustable parameters of a function, which may be stored in adjustable parameter repository 108B. The user may select the values of the adjustable parameters.

Optionally, a single smart contract 108 is implemented, where the reserves and bonding curves are components of the single contract. Alternatively, a set of smart contracts 108 is implemented, where the reserves and bonding curves are components of the set of smart contracts. Alternatively, each reserve and bonding curve are implemented using their own smart contract. A set of smart contracts is used for multiple reserves and related bonding curves.

The single distributed smart contract executing on the blockchain may implement a different set of values for the adjustable parameters for a different instance of the function. The single distributed contract may implement each respective reserve of a certain token and a corresponding bonding curve defined by the function with the different set of values for the adjustable parameter defines a primitive for unidirectional exchange between an external token and the certain token of the respective reserve. Multiple primitives are linked to one another for defining unidirectional routes for token exchanges.

Computing devices 102 includes a data storage device 112 for storing data. Data storage device 112 may be implemented as, for example, a memory, a local hard-drive, virtual storage, a removable storage unit, an optical disk, a storage device, and/or as a remote server and/or computing cloud (e.g., accessed using a network connection). It is noted that one or more of blockchain 110, smart contract code 108, reserve 108A, adjustable parameter repository 108B, and/or ledger 108C, or portions thereof, may be stored in data storage device 112, and loaded from data storage device 112 into memory 106 for execution by processor(s) 104.

Computing devices 102 may act as network nodes which communicate with each other for updating their respective copies of blockchain 110 and/or distributed transaction ledger 108C.

Each computing device 102 provides token exchanges services, and/or token deposit services, and/or token withdrawal services to multiple client terminals 114 over a network 116.

Computing device 102 may include a network interface 118, for example, a network interface card, a wireless interface to connect to a wireless network, a physical interface for connecting to a cable for network connectivity, a virtual interface implemented in software, network communication software providing higher layers of network connectivity, and/or combinations of the aforementioned.

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 (e.g., wired), and/or combinations of the aforementioned.

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 computer, and a watch computer.

Client terminal 114, may access smart contract code 108 and/or interact with smart contract code 108 for performing transactions (e.g., exchange, deposit, withdrawal), for example, by accessible software interfaces of the smart contract function code 108, for example, using a graphical user interface (GUI), application programming interface (API), software development kit (SDK), and/or transmission of messages specifying certain functions for execution. Smart contract code 108 may be accessed directly, and/or indirectly via another application that accesses smart contract code 108 to perform transactions, for example, a wallet managing application.

Optionally, the client terminal 114 that provides the values for the adjustable parameters (e.g., stored in repository 108B) for defining the bonding curve, is different than other client terminals that use the bonding curve to perform exchanges. Computing device 102 and/or client terminal(s) 114 include and/or are in communication with one or more physical user interfaces 122 that include a mechanism for a user to enter data (e.g., for performing a transaction with the primary and/or secondary tokens) and/or view data (e.g., view the results of the transaction). User interface 122 may present a GUI that includes the mechanism for entering data and/or viewing data. Exemplary user interfaces 122 include, for example, one or more of, a touchscreen, a display, gesture activation devices, a keyboard, a mouse, and voice activated software using speakers and microphone.

Referring now back to Figure 15, at 202, one or more hardware processors of one or more network connected serves execute code of a distributed smart contract of a blockchain, for managing a primary reserve of tokens of a primary cryptocurrency.

It is noted that the term primary is used for clarity of explanation, for exchange between the primary tokens and secondary tokens, but is not meant to necessarily limit and/or define the primary tokens. For example, there may be multiple primary reserves, each of which may trade between an external token that may be referred to as secondary token and the respective primary token of the reserve.

Optionally, each primary reserve is managed independently without necessarily managing a secondary reserve of secondary tokens of a secondary cryptocurrency. The secondary reserve may be managed independently of the primary reserve, with a link defined between the primary reserve and the secondary reserve, for handing the transactions, as described herein. This is in contrast to standard approaches in which pairs of reserves are managed together, where trades between the two reserves are symmetrical, i.e., using the same exchange rates.

At 204, values of one or more adjustable parameters that define a function for computing an exchange rate for converting between the primary cryptocurrency and a secondary cryptocurrency, are obtained.

Optionally, a sub-set of adjustable parameters are selected from a candidate set of adjustable parameters. The selection may be done by the provided values, where adjustable parameters for which values are provided are selected, and/or adjustable parameters for which no values are provided are not selected (and/or the value may be set to zero or undefined).

As used herein, the phrases (selection of) values of the adjustable parameters and (selection of) the adjustable parameters are sometimes used interchangeably.

Optionally, multiple distributed smart contracts are executing on the blockchain. Each distributed smart contract may manage a different reserve of tokens. Each distributed smart contracts of each reserve may be associated with its own values for the adjustable parameters for defining its own bonding curves as a different instance of the function. The same adjustable parameters may be used for all related bonding curves, with different values for the different adjustable parameters.

Optionally, each respective reserve of a certain token and a corresponding bonding curve (i.e., defined by the function with the different set of values for the adjustable parameter) defines a primitive for unidirectional exchange between an external token and the certain token of the respective reserve. Multiple primitives are linked to one another for defining unidirectional routes for token exchanges. The multiple bonding curves (i.e., of multiple primitives) that are linked to one another for defining exchanges between multiple cryptocurrencies are referred to herein as a strategy.

For example, exchange between two tokens (A and B) is defined by two bonding curves - one for each token, each representing the sale of that token for the other in the pair. Essentially:

A -> B

B -> A

For a strategy of three different tokens (A, B and C), up to six bonding curves may be defined, where the user may define fewer than six bonding curves:

A -> B

B -> A

A -> C

C -> A

B -> C

C -> B

For a strategy of four different tokens (A, B, C, and D), up to twelve curves may be defined, where the user may define fewer than twelve bonding curves:

A -> B

B -> A

A -> C

C -> A

A -> D D -> A

B -> C

C -> B

B -> D

D -> B

C -> D

D -> C

And so on. The maximal number of discrete bonding curves for any number of tokens is: n = number of tokens m = number of bonding curves m = (2xn!)/(2x(n-2)!)

Selection of different values for the same adjustable parameters provides customization of the function for different users, and/or enables each user to define their own unilateral token conversion paths using the defined primitives.

For example, two different users may use different instances of the same smart contract, with the same types of tokens with different sets of adjustable parameters for the same function(s). The adjustable parameters enable the two different users to define different bonding curves, even when the same tokens are being traded. This is in contrast to prior approaches, where the two different users were restricted to using the same bonding curve, without the ability to customize adjustable parameters.

The values may be obtained, for example, from a client terminal (e.g. of a user) in communication with the network connected server, for example, via a user interface, optionally a graphical user interface (GUI), a file stored on a data storage device, and/or automatically computed.

Alternatively or additionally, the values may be automatically computed by an executing process. For example, when the parameters are for meeting hardware and/or software resource requirements, for execution of the smart contract, an executing process may automatically determine the resource requirements, and may automatically select the values for the adjustable parameters according to the determined resource requirements. The executing process may dynamically monitor performance of the executing smart contract (e.g., relative to a target performance level), and may dynamically adapt the values of the adjustable parameters in order for the executing process to meet and/or maintain the target performance level and/or the hardware and/or software resource requirements. The dynamic monitoring and/or dynamic adaptation may be performed, for example, after each transaction, after multiple transactions, after a time interval has elapsed (e.g., 1 hour, 1 day, 1 week, 1 month, and the like), and/or after an event (e.g., detecting an installation of software and/or hardware and/or other events that may affect performance).

The terms hardware and/or software resource requirements may refer to a target performance. For example the value for the adjustable parameters are computed for meeting a target performance (e.g., of the hardware and/or software resources).

Optionally, the adjustable parameters are selected for meeting hardware and/or software resource requirements (e.g., performance requirements) for execution of code of the distributed smart contract. Exemplary resource requirements include one or more of: calculation accuracy in the absence of floating-point arithmetic, overflow, underflow, unsigned integers, computational complexity, storage requirements, and memory requirements.

Optionally, each parameter is assigned to a set selected from multiple candidate sets. Each parameter of each set may be mathematically related to other parameters within the set and/or each parameter is mathematically related between sets of other parameters, which may be sufficient to unambiguously describe a unique invariant function - implicit curve pair.

The function may represent the (e.g., all) possible combinations of primary tokens and secondary tokens and exchange rates for converting between the primary token and the second token, in a single direction.

One of the x-axis and the y-axis represents a balance of the first reserve, and the other axis may be non-defined (e.g., meaningless, arbitrary). The other axis is not necessarily needed, since a marginal exchange rate for converting between the first cryptocurrency and the second cryptocurrency is computed according to a first derivative of the relevant bonding curve. The other axis is not necessarily needed for computation of the first derivative, and not necessarily needed to determine the marginal exchange rate. The bonding curve may represent (e.g., all) possible exchange rates for converting between the primary token and the second token.

The function may be defined with reference to a hyperbola with asymptotes at x=Q and =0. The hyperbola may be represented as xy=k, where x denotes the primary token and y denotes the secondary token. The function may include one or more adjustable asymptotes. A graph of the function may shares at least one common point with a constant product bonding curve denoted as xy=k. A slope of the bonding curve at the one common point(s) may be identical with a first derivative of xy=k. Each bonding curve may be defined to have a point on its implicit curve at coordinates x=xo and y=yo, where a first derivative is equal to that of the constant product bonding curve at the same coordinates.

The bonding curve may be defined as the implicit curve of the invariant function, which is used to enumerate a continuum of exchange rates between a primary cryptocurrency and a secondary cryptocurrency. Alternatively or additionally, the bonding curve may be defined as a secant line connecting two points of the function separated by a continuum of intermediate points. The bonding curve may be defined as a gradient of the secant line. The bonding curve may define multiple exchange rates for converting between the primary cryptocurrency and the secondary cryptocurrency. Each exchange rate for converting between the primary cryptocurrency and the secondary cryptocurrency may be represented as a secant line between two points of the function. A first point represents balance of the first reserve before the exchange occurred, and a second point represents balance of the first reserve after the exchange occurred.

The adjustable parameters may include a base set of adjustable parameters, for example:

• n

• Pa denoting a start value of a range of exchange rates for converting from the primary cryptocurrency to the secondary cryptocurrency.

• Pb denoting an end value of a range of exchange rates for converting from the primary cryptocurrency to the secondary cryptocurrency.

• P denoting a gradient at x=xo, y=yo indicating a geometric mean price.

• Q

• R

• S denoting a difference of square roots of the gradients of the intercepts.

• int denoting a balance of the primary tokens where the marginal exchange rate is equal to Pa.

• Xint denoting, when the range commences with y=y_int, a balance of secondary tokens that is obtainable if the balance of the primary tokens is driven to zero.

• xo denoting an x-coordinate at the geometric mean price.

• yo denoting a y-coordinate at the geometric mean price.

• Xasym denoting an x-asymptote or vertical asymptote.

• yasym denoting a y-asymptote or horizontal asymptote.

• Geometric and/or algebraic reconstruction of the aforementioned.

The adjustable parameters are discussed herein in more detail. Different values are assigned to the same set of the base parameters for different bonding curves implicitly defined by the function.

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

For simplicity and clarity of explanation, two bonding curves are described. However, it is to be understood that three or more bonding curves may be defined.

In the case of two bonding curves, the first bonding curve and the second bonding curve have common adjustable parameters with different values. The first bonding curve is defined by a first set of values of the adjustable parameters. The second bonding curve is defined by a second set of values of the adjustable parameters, which is different than the first set of values. Each bonding curve defines unidirectional conversion. The first bonding curve may define conversion from the primary cryptocurrency to the secondary cryptocurrency. The second bonding curve may define conversion from the secondary cryptocurrency to the primary cryptocurrency.

Once the bonding curves have been defined according to the values of the adjustable parameters, the bonding curves may be used to execute transactions.

At 208, a transaction request for converting between the primary tokens and secondary tokens of a secondary cryptocurrency is obtained, for example, from another client terminal (e.g., of another user) which may be different from the client terminal that provided the values of the adjustable parameters. The secondary tokens may be received by passive interaction with an outside market. The other client terminal may be used by another user looking to exchange tokens.

The transaction request for exchange using the function with applied parameters may be executed on the blockchain using fundamental math operations, for example: addition, subtraction, multiplication, and division. Other more complex math operations may be excluded, for example: Taylor series, polynomial approximation, and numeric methods of producing a function output. Two or more of the adjustable parameters may be computed off-blockchain. Using fundamental math rather than more complex math operations, and/or performing computations off-blockchain may improve computational efficiency of the processor, for example, reduced utilization of the processing resources, reduced memory utilization, and/or lower processing times.

At 210, the transaction request is executed using the bonding curve defined by the function with the values of the adjustable parameters. Two bonding curves may be used for execution of the full transaction request, where each bonding curve may be used independently, optionally based on feedback from the other bonding curve.

Execution of the transaction request may be performed in two stages, which may occur sequentially optionally in any order, and/or in parallel.

A case of the transaction request including an amount of secondary tokens which are to be converted to primary tokens is now considered. In a first stage, primary tokens may be automatically withdrawn from the primary reserve. The amount of primary tokens that are withdrawn in response to the provided amount of secondary tokens is computed according to the first exchange rate computed according to the first bonding curve. The primary tokens are provided, for example, to the client terminal of the user that sent the transaction request, deposited into a wallet of a user that sent the transaction request, and the like. In a second stage, the secondary tokens are automatically added to a secondary reserve according to the second bonding curve. The addition of the secondary tokens may impact a second exchange rate for converting from the secondary cryptocurrency to the primary cryptocurrency. The impact is computed according to the second bonding curve. As mentioned, the first stage and the second stage may be performed in a different order, such as the second stage followed by the first stage, and/or substantially in parallel.

Optionally, the transaction performed using the first bonding curve deterministically affects another transaction performed using the second bonding curve. The transaction performed using the first bonding curve includes the second stage, where the secondary tokens are automatically added to the secondary reserve according to the second bonding curve. The change in the amount of secondary tokens in the secondary reserve may impact the second exchange rate for future exchanges.

The secondary tokens received through via the first bonding curve are substantially immediately and automatically added to the secondary reserve according to the second bonding curve.

In another example, a case of the transaction request including an amount of primary tokens which are to be converted to secondary tokens is now considered. Since the bonding curves are directed to a specific conversion direction, the second bonding curve is used to determine the amount of secondary tokens. In the first stage, secondary tokens may be automatically withdrawn from the secondary reserve. The amount of secondary tokens that are withdrawn in response to the provided amount of primary tokens is computed according to the second exchange rate computed according to the second bonding curve. The secondary tokens are provided, for example, to the client terminal of the user that sent the transaction request, deposited into a wallet of a user that sent the transaction request, and the like. In the second stage, the primary tokens are automatically added to the primary reserve according to the primary bonding curve. The addition of the primary tokens may impact the primary exchange rate for converting from the primary cryptocurrency to the secondary cryptocurrency. The impact is computed according to the primary bonding curve. As mentioned, the first stage and the second stage may be performed in a different order, such as the second stage followed by the first stage, and/or substantially in parallel.

Optionally, the marginal exchange rate for converting between the first cryptocurrency and the second cryptocurrency is computed according to a first derivative of the relevant bonding curve.

At 212, records of the blockchain may be updated, to indicate the transaction and/or updated balances of the different tokens.

Referring now back to Figures 16-19, sequence diagrams for implementing embodiments described herein are depicted. Figure 16 is a sequence diagram for creation of a strategy. Figure 17 is a sequence diagram for depositing funds using the strategy. Figure 18 is a sequence diagram for withdrawing funds using the strategy. Figure 19 is a sequence diagram for trading using the strategy.

The sequence diagrams described with reference to Figures 16-19 may be based on methods described herein, for example, described with reference to Figure 15 and/or implemented by components of the system described with reference to Figure 14, and/or other features described herein. It is noted that each sequence diagram is exemplary, with optional data flows. Data flows may be adapted according to specific implementations.

With reference to Figure 16, data flows (e.g., interactions) between a user 1602 (using a client terminal), a web application 1604 (e.g., running on a server(s)), a pool collection 1606 (smart contract), a strategy 1608, orders 1610, a strategy NFT (non-fungible token) 1612, and a NFT 1614, are described.

At 1620, strategy creation may begin with the user visiting the web application and choosing to create a (trading) strategy with a specific set of parameters. The trading strategy includes different values for the different adjustable parameters, for the different functions, where each function defines a unilateral exchange from one token to another token, as described herein.

At 1622, the application may compare the strategy parameters with existing market state that includes the existing strategies and existing market prices and attempts to identify anomalies that the user should consider when creating the strategy and presents these anomalies to the user. The user may then decide whether to proceed or not.

At 1624, once the user decides to proceed, the user may confirm the strategy creation through the web application.

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

At 1628, the orders defined by the strategy parameters may be created. Each order is defined with its own bonding curve, which defines a transaction in a certain direction.

At 1630, the strategy owner may be marked as the user who sent the request.

At 1632, a unique identifier for the specific strategy may be created.

At 1634, an NFT that represents the strategy and associates the strategy unique identifier with the new NFT, may be created. The new NFT may be transferred to the user who owns the new strategy.

At 1636, a confirmation that the action is complete may be provided.

With reference to Figure 17, data flows (e.g., interactions) between user 1602 (using a client terminal), web application 1604 (e.g., running on a server(s)), pool collection 1606 (smart contract), strategy 1608, and vault 1702, are described for depositing funds according to the strategy.

At 1703, the user may view the existing strategies page on the web application.

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

At 1706, the user may select a specific strategy.

At 1708, once the user selects the strategy, the web application may open a page that allows the user to manage the strategy. One of the options on that page may be to deposit funds into the strategy.

At 1710, the user may select the deposit funds option, input the tokens/amounts to deposit, and may confirm the action.

At 1712, the main entry point on the blockchain for depositing funds into a strategy is the pool collection smart contract. In response to receiving a request to deposit funds into a strategy for a specific user, the pool collection smart contract may validate the data and may begin the depositing process as follows: At 1714, the pool collection smart contract may verify that the user who requested the deposit is the actual owner of the strategy.

At 1716, the pool collection smart contract may withdraw the given token amounts from the user.

At 1718, the pool collection smart contract may deposit the token balances into the vault that holds all funds.

At 1720, the pool collection smart contract may increase the balances of the specific given strategy by the token amounts provided.

At 1722, pool collection smart contract may confirm that the action is complete.

With reference to Figure 18, data flows (e.g., interactions) between user 1602 (using a client terminal), web application 1604 (e.g., running on a server(s)), pool collection 1606 (smart contract), strategy 1608, and vault 1702, are described for depositing funds according to the strategy.

At 1802, the user may view the existing strategies page on the web application.

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

At 1806, the user may select a specific strategy.

At 1808, once the user selects that strategy, the web application may open a page that allows the user to manage the strategy. One of the options on that page may be to withdraw existing funds from the strategy.

At 1810, the user may select the withdrawal option, input the tokens/amounts to withdraw, and may confirms the action.

At 1812, the main entry point on the blockchain for withdrawing funds from a strategy is the pool collection smart contract. In response to receiving a request to withdraw funds from a strategy for a specific user, the pool collection smart contract may validate the data and may begin the withdrawal process as follows:

At 1814, the pool collection smart contract may verify that the user who requested the withdrawal is the actual owner of the strategy.

At 1816, the pool collection smart contract may reduce the balances of the specific given strategy by the token amounts provided.

At 1818, the pool collection smart contract may instruct the vault, which holds all user funds, to transfer the given amounts of tokens to the user.

At 1820, the pool collection smart contract may confirm that the action is complete. With reference to Figure 19, data flows (e.g., interactions) between user 1602 (using a client terminal), a software develop kit (SDK) 1902, a trade router 1904, pool collection 1606 (smart contract), strategy 1608, vault 1702, and protocol 1906 are described for trading funds according to the strategy.

At 1950, the user may view the open strategies in the protocol and/or evaluate whether a trade for the required amount is possible. Existing open strategies that are relevant to the specific pair of tokens the user would like to trade may be requested.

At 1952, the user may send the list of strategies to the SDK. The user may request that the SDK attempts to match the trade requirements (e.g., source token, target token, amount) against the list of strategies. The SDK may attempt to find the ideal list of strategies that the trade can use, i.e., the list of strategies that are predicted to provide the user with the best trade outcome.

At 1954, once the list is generated, the user may request from the trade router to execute the trade. The user may provide the list of strategies received from the SDK as an input for the trade. This begins the trade process which may proceed as follows:

At 1956, the trade router may withdraw tokens used for the trade from the user.

At 1958, the trade router may deposit the tokens into the vault which holds all funds.

At 1960, the trade router may request the pool collection to execute the trade and provides the list of matched strategies.

At 1962, the pool collection may iterate through the list of strategies. For each strategy in the list of given strategies, the following may be performed: calculating the result of a trade for the specific strategy, verifying that the strategy has enough balance to accommodate the trade, updating the new balances in the strategy, and returning the trade result amount.

At 1964, once the trade is performed against all the provided strategies, the pool collection may notify the trade router with the trade result.

At 1966, the trade router may request from the vault (which holds all funds) to send the target tokens to the user, with an amount equal to the trade result.

At 1968, the vault may send the target tokens to the user.

At 1970, the vault may notify the trade router that the tokens were sent.

At 1972, the trade router may confirms that the trade is complete.

Additional exemplary details of the adjustable parameter(s) that define the function(s) described herein are now described.

The x and y terms in equations below denote balances of two assets with which an exchange will, or can, be performed. The x and y balances may be hypothetical, virtual, or real, and may represent any fungible, tokenized form of value on a distributed ledger, including but not necessarily limited to blockchains and directed acyclic graphs. The customizable function described in the following equations, and herein, is necessarily defined with reference to the constant product function - a hyperbola with asymptotes at x = 0 and y = 0. The implicit curve of the constant product function, described for example with reference to Patent ‘923, may be written as xy = k (eqn. la), or via its rearrangements (eqns. Ib-c). In the context of token balances in an associated smart contract, where this function is employed to perform exchange, its first derivative (eqns. Id-e) can be used to evaluate the instantaneous rate, or exchange value, between any two tokens under its influence. A secant line connecting two points of the implicit curve, separated by a continuum of intermediate points, determines the absolute change in the smart contract holdings of the tokens represented by x and y (eqns. If-g). Therefore, the realized rate of exchange between any two tokens by a user of the system may be derived (eqns. Ih-i).

At least some embodiments described herein are based on the concepts defined by the equations above. In the following sections, where the properties of the customizable invariant function are disclosed in detail, it may be appropriate to let each term be handled entirely in abstraction. Additional and more specific details with respect to the embodiments related to exchange of tokens are discussed herein.

What follows is a full mathematical elaboration of the customizable invariant function, its bonding curves, and properties. The list of terms used to describe the function appears in Table 1; the equations wherein these terms are used are presented thereafter. The equations define each of these terms in the context of the customizable function and its associated curves set; the graphical representations of these same mathematical concepts are depicted in example figures thereafter.

The customizable function described herein may be an improvement of the general liquidity amplification described with reference to “SMART CONTRACT OF A BLOCKCHAIN FOR MANAGEMENT OF CRYPTOCURRENCIES” (Patent ‘896), which describes a virtually amplified amount of token reserves obtained by multiplying the initial staked values (xo, yo) by an amplification value (1/n, or w), for the specific case where there are only two token reserves with reserve ratios of one-half. Therefore:

1) A function with arbitrary, or adjustable asymptotes, and

2) Where the graph of the function shares at least one common point with eqns. la-c., and

3) Where the slope of the curve at the common point is identical with eqns. Id-e.

This definition is now elaborated. The relationship between x and y is under the influence of the invariant function, which can be written in many equivalent forms. The content provided herein is submitted as a representative sample that is not necessarily limiting. Therefore, the explicit forms that appear below include, but do not limit the scope of the described embodiments. A representative set of novel invariant functions appears in eqns. 2a-p, and examples of its algebraic manipulation into equivalent forms appear later in the disclosure. In addition to the two variables, x and y, the function is adequately defined with respect to a minimum of three parameters from the set The

function may also be defined with respect to the parameters P_a and Pb, in addition to other rearrangements of these parameters, which is subject to further discussion herein.

Other forms of the invariant function include its various rearrangements, including and especially those which force either the y- or x- coordinates to be the subject (eqns. 3a-n and 4a- n, respectively).

Alternatively or additionally, the novel invariant function may be defined with respect to any line tangent to its implicit curve, measured from either the x- or y-coordinates (eqns. 5a-n and 6a-n, respectively).

Alternatively or additionally, the novel invariant function may be defined with respect to any secant line connecting any two points on its implicit curve, where Δy and Δv denotes the absolute translocation in the Cartesian plane between any two points on its graph connected by a continuum of intermediate points. The secant line may be defined with respect to either the x- or y-coordinate (eqns. 7a-n and 8a-n, respectively).

Alternatively or additionally, the novel invariant function may be defined with respect to the gradient of said secant lines, denoted here as Δy /Δx, and can be defined with respect to either the x- or y-coordinate (eqns. 9a-n and lOa-n). As Δx approaches zero, Δy/ Δx approaches the instantaneous rate of change at any point on its implicit curve and forms an equality with eqns. 5a-n and 6a-n.

The equations depicted above are non-exhaustive, and/or not necessarily limiting. Each parameter belongs to a set and may have an explicit relationship to other parameters within its own set, and between sets of other parameters. These relationships include important equivalences between fundamental parameters, and explicit pairs of other parameters, including but are not necessarily limited to those defined in eqns. lla-d and 12.

The parameter n is redundant with the parameter u; the two are the reciprocal of each other (eqn. 12).

eqn. 12

From the established theory, an expanded network of algebraic identities can be defined.

The totality of the geometric relationships is too vast to list in its entirety; however, a representative set is provided with eqns. 13a-s.

The equalities presented above are summarized in eqns. 14a-c and give precise identities for the fundamental parameters n, P, Q, k, x_asym, j_asym, xint, and yint with respect to each other.

The parameters algebraically defined above are now elaborated in the context of their geometric meaning. The descriptions provided here are for illustrative and explanatory purposes to aid the reader’s understanding and should not be conflated with any specific use case, and/or be considered a constraint, and/or necessarily limiting, and/or boundary in any manner to the generality of the embodiments described herein. Reference is now made back to Figures la-c, which are schematics depicting the invariant function characterized as having a point on its implicit curve with coordinates x = xo, y = yo, which coincide with the graph of eqns. la-c, in accordance with some embodiments of the present invention. Reference is now made back to Figures 2a-c, which are schematics where the negated slope of the tangent line (-dyldx) at this point is P and is equal in both implicit curves of the customizable function and eqns. Id-e, in accordance with some embodiments of the present invention. Reference is now made back to Figures 3a-g, which are schematics where the parameter k is the hyperbola constant of eqns. la-c, (i.e. xy = k), and denotes the magnitude of the constant product’s implicit curve with which the implicit curve of the novel invariant function shares the coordinates x = xo, y = o, in accordance with some embodiments of the present invention. Reference is now made back to Figures 4a-l, which are schematics where the parameters x_asym and _asym denote the “vertical” and “horizontal” asymptotes, respectively, of the novel function’s implicit curve, in accordance with some embodiments of the present invention. It is noted that the designations “vertical” and/or “horizontal” should not be misconstrued as perpendicular lines, and/or straight lines in embodiments described herein; these terms are used for ease of communication, and/or the divergence of their meaning from the status quo is discussed elsewhere. Reference is now made back to Figures 5a-g, which are schematics where the parameters xint and yint denote the x- and y-intercepts the novel function’s implicit curve, in accordance with some embodiments of the present invention. Reference is now made back to Figures 6a-f, which are schematics where the slope of the tangent lines at the y- and x-intercepts of the novel implicit curve, y = yint and x = xint, respectively, are denoted by the parameters P_a and Pb, respectively, in accordance with some embodiments of the present invention. Reference is now made back to Figures 7a-b, which are schematics depicting exemplary methods of discovery of the parameters n, u that denote the relative size of two rectangles, in accordance with some embodiments of the present invention. One exemplary method is described herein. Assume both rectangles have edges parallel to the x- and y-axis. Let the first of the two rectangles have one corner at the origin (x = 0, y = 0), one corner at the x-intercept (y = 0, x = xint), one comer at the y-intercept (x = 0, y = yint), and one corner at the junction of the lines emanating from both intercepts (x = xint, y = yint) and converging at a right angle. The second rectangle has one corner at the point on the implicit curve of eqns. la-c where a tangent line at this point is parallel to and ^one corner at the point on the

implicit curve of eqns. la-c where a tangent line at this point is parallel to

d the other corners at the junctions of the lines emanating from both

other points and converging at right angles, as depicted in Figures 7a-b. The square root of the quotient of the rectangles’ areas, or the quotient of the rectangles’ lengths, or the quotient of the rectangles’ heights, can be used to calculate to n and its reciprocal, u.

Reference is now made back to Figures 7c-d, which are schematics depicting an exemplary method for discovering the parameter 2, which denotes the relative size of two rectangles, in accordance with some embodiments of the present invention. Assume both rectangles have edges parallel to the x- and y-axis. Let both rectangles have one corner at junction of the horizontal and vertical asymptotes of the implicit curve of the novel invariant function (x = x_asym, y = _asym). Then, let the first of the two rectangles have a comer at the convergence of the lines emanating from the x- and y-intercepts (x = xint, y = yint), and the other comers at the junctions of the lines emanating from both other points and converging at right angles. The second rectangle has one comer at the origin (x = 0, y = 0), and the other comers at the junctions of the lines emanating from both other points and converging at right angles, as depicted in Figures 7c-d. The quotient of the square root of the area of the one rectangle to the square root of the sum of the areas of both rectangles, or the quotient of the length of one rectangle to the sum of the lengths of both rectangles, or the quotient 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 report the relative scaling of the transformation of the novel invariant function’s implicit curve with respect to the constant product implicit curve, and vice versa.

The dimensions of the graphs in relevant Figures described herein hold no special significance and are chosen for the sake of demonstration; the disclosed function is effectively unbounded and can be applied to any plane or hyperplane, regardless of its size.

A vast expanse of additional rearrangements of the equations presented above can be generated from the geometric identities contained within the scope of embodiments described herein, and their implicit curves comprise a specific set of possible exchange processes. For all positive values of x and y, which may represent the balances of tokens in a smart contract, or any similar arrangement on a distributed ledger, the application of the invariant function provides a map of exchange rates, for example, that encompasses a novel DEX technology.

The overparameterization described herein enables the creation of subsets of new parameters that reference those defined above, from which specific forms of the invariant function can be explicitly derived. This concept is exemplified as follows with reference to specific examples, which represent a subset of a much larger collection of possible groupings of curve parameters and associated rearrangements of the general formula. Such flexibility allows for application-specific considerations to be addressed, including but not necessarily limited to: calculation accuracy in the absence of floating-point arithmetic, overflow and underflow, unsigned integers, computational complexity, storage and memory requirements, or other limitation imposed either directly or indirectly by the hardware or software on which the outputs of the function are determined. This aspect is technically significant and/or provides technical advantages, and is demonstrated with specific examples below. The general theory can be understood heuristically. One set of implicit curves encompassed by embodiments described herein is comprised of those which can be selected with reference to a coordinate of the implicit curve of eqns. la-c, and some scaling factor. While the parameters n, u and Q are the natural expression of the scaling factor, it is possible to construct forms of the invariant function that feature none of these. For example, the invariant functions described by eqn. 15, 16a-c, and 17a-c are perfectly serviceable despite their lack of direct reference to n, u or Q, as demonstrated by their elaboration into the marginal exchange formulas (eqns. 16d-e and 17d-e), their swap formulas (eqns. 16f-g and 17f-g), and gross exchange rate formulas (eqns. 16h-i and 17h-i). Such a construction is possible because the three parameters (xo, o, and either int or xint) each contribute partial positional and scaling information with respect to each other.

Therefore, it is possible to define new fundamental scaling constants from the algebraic and geometric identities described herein for the invariant function. This is an important advance from a technological perspective, as it allows for discrete forms of the general theory to be created to suit specific implementation constraints. For the two cases considered for the set resulting from the elaboration of eqn. 15, it is trivial to define the new scaling term, R, and demonstrate its congruence with the general theory (eqns. 18a-b). The explicit forms of this simplification are presented in eqns. 19a-i. Invariant functions of this kind may be easily demonstrated as belonging to the same superset and are contained within the scope of embodiments described herein.

Trivial combinations of the parameters described herein are also within the scope of embodiments described herein. For example, in some embodiments, let the parameter S be defined as the difference between the square roots of the gradients at the y- and x-intercepts, which through algebraic manipulation is shown to have equivalence with other fundamental parameters P, Q, and n (eqn. 20a-b). Then, redefinition of Pb as B² (eqns. 20c) allows for the construction of a new equation set (eqns. 21a-i).

This set is included to emphasize the brevity and computational tractability of its forms, especially its swap formula, eqn. 21g, and its marginal price formula eqn. 21e, which showcases the technical advantages afforded by the overparameterization described herein and/or specific algebraic, and/or geometric elaboration of the general theory. This set is adopted to illustrate another aspect described herein, referred to as, asymmetric liquidity pools.

The examples provided hitherto are for a discrete case where fundamental parameters of the invariant function are assumed to be fixed values, which is not a necessary requirement. Any function parameter may also be functions of internal variables including but not necessarily limited to the x- or y-coordinates, and/or any combination of the x- and y- coordinates and/or other parameters, and/or functions of external variables including but not necessarily limited to data delivered by another smart contract, application programmable interface (API), and/or a system or network of oracles.

Reference is now made back to Figures 8a-c, which are schematics in which eqn. 22 substitutes n for f(x), in accordance with some embodiments of the present invention. The invariant function maintains a point on its graph with coordinates (xo, yo) coincident with the implicit curve of eqn. 1, and the slope of the tangent line at this point is equal in both, as depicted with reference to Figures 8a-c.

Reference is now made to back Figures 9a-c, which are schematics in which eqns. 23a-c substitute n for f(a, x, xo, y, yo), in accordance with some embodiments of the present invention. Consistent with its definition, and as has been observed for examples examined herein, the novel function maintains a point on its graph with coordinates x = xo, y = yo coincident with the graph of eqn. 1, and where the slope at this point is equal to P in both graphs, as depicted in Figures 9a-c. Whereas the demonstration via eqn. 22 is included for no other reason than to demonstrate the scope of the invariant function disclosed herein, eqns. 23a-c have special significance. It is a unique variation, and close homologue of the “stableswap” function currently in use by several DeFi protocols. The a term of eqn. 23a determines the degree to which the function is flattened around the point x = xo, y = yo. Higher values of a extend the flattened region, and at a = 0 the graph of the function is identical to that of eqn. 1.

Additional details related to the asymmetric liquidity pools are now described, where each bonding curve defines a unidirectional trade from a first cryptocurrency to a second cryptocurrency.

The application of the novel invariant function in the context of AMMs and DEXes is now elaborated. The fundamental purpose of a DEX is to exchange tokens according to a preset pricing process; the balances x and y are coordinates on the graph of the invariant function and represent all possible compositions of tokens and exchange rates. Therefore, an exchange may be represented as a secant line between two coordinates in the positive domain, that describe the balance of x and y at two points in time, before and after the exchange occurred. Typically, the numeraire asset is assigned the y-axis, and the risk asset is assigned the x-axis, and this convention will be observed herein.

In some embodiments, the customizable function described herein may be used to create a price range through which one user can programmatically exchange their tokens for another of their choosing in a decentralized marketplace. In the common vernacular, an AMM position whereby tokens are exchanged within predefined bounds of exchange rates is termed concentrated liquidity. In such a concentrated liquidity model, the graph of the invariant function in the positive domain necessarily intersects the x- and y-axis, and the slope of the graph at these intercepts defines the bounds of exchange rates. For any graph of the novel invariant function with asymptotes X_asym < 0 and y_asym < 0, the slope of the graph at x = 0, (i.e. the y-intercept, yint) defines the highest exchange rate of the risk asset relative to its numeraire, and the slope of the graph at y = 0, (i.e. the x-intercept, xint) defines the lowest exchange rate of the risk asset relative to its numeraire. For any graph of the novel invariant function where n, X_asym and y_asym are constant values, X_asym < 0 and y_asym < 0 if n < 1. The following discussion expands on the application of the invariant function under this pretense; however, this comprises a subset of a wider scope of possible utilizations of embodiments described herein. Let the slope of the graph of the customizable function at the y- intercept be -Pa and the slope at the slope of the graph of the novel function at the x-intercept be - Pb. As with any permutation of the invariant function, the slope at the point coincident with eqn.

1, (i.e. x = xo, y = yo) is defined as -P. In some embodiments, any three of the parameters Pa, Pb, yint and xint can be user-provided, where Pa and Pb are the user’s chosen range of exchange rates, yint represents the numeraire liquidity the user is committing to this same range, and xint represents the sum total of the risk asset the user has announced their intention to obtain via exchange with said numeraire.

The following illustrations refer to eqns. 21a-i; however they should be considered as an example implementation. For completeness, eqns. 24a-l demonstrate how any parameter discussed thus far can be computed from the example user inputs, Pa, Pb, and yint, although a subset, P, S, and yint, are required for the remainder of this illustration.

A user strategy includes two or more sets of token balances, including token balances of zero, and two or more instances of the invariant function described herein. For clarity of communication, the present discussion will be restricted to circumstances where a user has defined a strategy comprised of two tokens, and with two asymmetric bonding curves which determine their rate of exchange. However, embodiments described herein are not necessarily limited as such.

To illustrate the emergent behavior of a user’s strategy as a function of two asymmetric liquidity pools, cryptocurrency tokens designated as USDTKN and RSKTKN are used as a generic case. USDTKN is used a stand-in for a “stablecoin”, a cryptocurrency token that maintains an approximate 1 : 1 exchange value with the United States Dollar. The choice of a stable token was made for its intuitive properties which assist with the forthcoming explanations; however, embodiments described herein are not necessarily limited to such tokens to operate. Similarly, the fictional characters Alice is used as a generic placeholder for any user with whom the protocol is interacting.

Assume that RSKTKN is currently trading at a value of $1.00, and therefore a precise 1 : 1 exchange value with TKNUSD. Alice is a blockchain user who owns 100 RSKTKN and 5000 USDTKN and has ambitions to improve her overall quantity of both tokens over time by trading them against each other in an open marketplace. In its most elemental articulation, Alice is seeking to obtain additional RSKTKN when its exchange rate versus USDTKN is low, and then exchange it back for USDTKN when its exchange rate is high. Depending on her confidence, skills, knowledge, biases, predilections and other factors, Alice may have precise target rates of exchange with which she is comfortable replacing some quantity of USDTKN with RSKTKN, and vice versa. In a conventional AMM, Alice has limited agency to exercise this most fundamental of economic activities. The issue arises from the fact that traditional AMM systems are symmetrical in their ability to facilitate exchange; if USDTKN is exchanged for some quantity of RSKTKN, then the opposite exchange can also occur, regardless of Alice’s pretension as a liquidity provider.

In at least some embodiments described herein, the exchange of USDTKN for RSKTKN, and RSKTKN for USDTKN, is prescribed by Alice, rather than the protocol. The exchange rate in each direction is determined by discrete instances of the invariant function, giving rise to a pair of bonding curves that allow for both tokens to be exchanged with participants in the marketplace at rates entirely independent of system state. In one aspect, Alice’s liquidity position can represent a formal limit order, which in contrast to its counterpart in traditional finance, can be executed continuously over a premeditated range of exchange rates, as opposed to “all or nothing” given a single target rate at which the order executes. The tokens with which Alice is executing her strategy are automatically available on its companion curve, at a different exchange rate to that with which they were acquired. The expression of Alice’s objective occurs without her intervention or active management and represents a substantive improvement over existing DEX technologies.

The characteristic behavior of Alice’s liquidity position (aka her user strategy) in the context of at least some embodiments described herein is now explored with reference to the customizable invariant function described herein. First, consider the instance of the general formula where Alice is seeking to exchange her RSKTKN for USDTKN as its exchange rate moves towards Alice’s targets. From the current market position of 1 USDTKN per RSKTKN (i.e. $1.00), Alice wishes to begin exchanging her RSKTKN for USDTKN starting at a rate of U/2 USDTKN per RSKTKN, up to a target of 31 USDTKN per RSKTKN, for which she is willing to contribute 100 RSKTKN to this range. By convention, let the y-axis of Alice’s bonding curve for this half of her strategy be represented by the quantity of RSKTKN she has remaining in said position. At the time she creates it, the first infinitesimal of RSKTKN is available to the market at an exchange rate of 116 USDTKN per RSKTKN. In some embodiments, the balance of RSKTKN at the time the position is created may define the int parameter of the instance of the invariant function associated with Alice’s strategy. Therefore, Pa, the negated gradient of the tangent line (-dy/dx) at int, defines the initial exchange rate. Since Pa represents a change in y relative to x, where y denotes a true quantity of RSKTKN, then P_a is the reciprocal of Alice’s chosen starting rate, assuming it was denominated in USDTKN as in the present example. In other words, the first infinitesimal change in y with respect to x, concordant with Alice’s mandate, is -dyldx = 1 RSKTKN / 116 USDTKN. Therefore P_a = ²/ as USDTKN is worth ²/s of RSKTKN at the first instance of exchange against Alice’s liquidity. Thus, two of Alice’s required inputs are P_a = ²/s and int = 100.

The final input for the first half of Alice’s strategy, Pb, can be deduced via the same method as for P_a. The last infinitesimal amount of RSKTKN, concordant with Alice’s mandate, is to be exchanged at a rate of 3 ’A USDTKN per RSKTKN, as her bonding curve for this range comes to rest at x = xint, y = 0, thus fulfilling her order. Recall that Pb is the gradient of the tangent line at this exact point on the curve, and represents a change in y with respect to x. Therefore, its value is -dyldx = 1 RSKTKN / 3% USDTKN, or Pb = ² . With the third and final input in hand, Alice’s bonding curve where RSKTKN is exchanged with the external market for USDTKN can be defined completely. From an implementation perspective, these three parameters are sufficient to define this half of the strategy; however, all previously discussed parameters have been calculated and are presented here for redundancy’s sake, as presented in Table 2.

For the second half of Alice’s strategy, assume she is motivated to exchange her USDTKN with the rest of the market for RSKTKN as its exchange rate approaches a value where she believes there is an opportunity.

From the current market position of 1 USDTKN per RSKTKN (i.e. $1.00), Alice wishes to begin exchanging her USDTKN for RSKTKN starting at a rate of ²/s USDTKN per RSKTKN, down to a target of Vs USDTKN per RSKTKN, for which she is willing to contribute 5000 USDTKN to this range. The same convention applies to this bonding curve; let the y-axis of Alice’s bonding curve for this half of her strategy be represented by the quantity of USDTKN she has remaining in said position. Note that both bonding curves have the true liquidity on the y-axis; the x-axis in both cases is just a coordinate, and not a token balance. At the time she creates her strategy, the first infinitesimal of USDTKN is available to the market at an exchange rate of 1 USDTKN per RSKTKN. As before, assume the balance of USDTKN at the time the position is created defines the yint parameter for the instance of the invariant function associated with this half of Alice’s strategy. The P_a parameter of this half of the strategy, as was the case for the other curve, is the gradient of the tangent line at yint, which defines the initial exchange rate in its cognate direction. Identical logic applies to the calculation of the curve parameters; however, note the flipped numeraire results in a more intuitive result in the case of USDTKN half of the strategy; there is no need to take a reciprocal in this case. Since Pa represents a change in y relative to x, where y denotes a true quantity of USDTKN, then P_a is Alice’s chosen rate as-is. The first infinitesimal change in y with respect to x is -dyldx = ²/s USDTKN / 1 RSKTKN. Therefore Pa = ²/ as RSKTKN is worth ²/s of USDTKN at the first instance of exchange against Alice’s liquidity. Thus, two of Alice’s required inputs are Pa = ²/s and yint = 5000. As an aside, it is worth acknowledging that both curves now have identical Pa values. However, their intrinsic meaning is reversed. In the first curve, Pa denotes the initial rate at which RSKTKN is exchanged for USDTKN; in the second curve, Pa denotes the initial rate at which USDTKN is exchanged for RSKTKN. In cash basis, Pa on the first curve give rise to an initial valuation of RSKTKN $1.50, whereas on the second curve the same Pa value gives rise to an initial valuation of RSKTKN of $0.66. In one embodiment, these and other impish nuances are hidden from the user through a front end interface, where inputs are collected in terms more aligned with their visceral understanding. The full description provided here should not be conflated with the user experience, but rather a detailed exploration of the application of the invariant function described previously.

The final input for the second half of Alice’s strategy, Pb, can be deduced via the same method as for P_a. The last infinitesimal amount of USDTKN is to be exchanged at a rate of Vs USDTKN per RSKTKN. Therefore, the Pb value is -dy/dx = Vs USDTKN / 1 RSKTKN, and Pb = Vs. It is also worth observing that P_a > P on both curves, which is expected, but not necessarily a requirement. This concludes the collection of the user inputs and allows the second half of Alice’s strategy to be defined, completing the creation of the strategy overall, as presented in

Table 3

Depending on the environment, any subset or the complete set of values in Tables 2 and 3 can be stored in a smart contract. In some embodiments, a frugal deployment makes use of (optionally only) three parameters and a single x or y coordinate. For the example described here, and with reference to eqns. 21a-i, assume that (optionally only) int, B, S, and the y-coordinate are used. Note that these choices reflect modest computational burden compared with the other parameters (eqns. 24a-l). Moreover, after the initial calculations of B and S during the creation of the strategy, which can be performed with the assistance of off-chain resources, all on-chain calculations performed during swaps use (optionally only) the fundamental math operations addition, subtraction, multiplication, and division. This is true of equations described herein relating to the computation of marginal exchange rates and swaps, thus precluding the need for Taylor series and/or other polynomial approximations, and/or numeric methods of producing a function output. The freedom of choice to select appropriate parameters, and/or customized equation sets to fit the virtual machine on which the decentralized application is running addresses the technical problem of reducing use of computation resources for executing the smart contract.

Alice’s strategy is now represented by two discrete bonding curves. In one embodiment, and in contrast to the conventional interpretation, (optionally only) only the y-axis of these curves has any intrinsic meaning; i.e., the x-axis does not denote a balance of tokens of any kind, virtual or otherwise. At the highest level of abstraction, the x-coordinate is a remnant of taking the antiderivative of Alice’s desired exchange rate profile as a function of her true token balance, represented by y, implicit in the swap equations (eqn. 21e). The projection onto the x-axis gives rise to an additional dimension and creates the familiar looking bonding curve, but for the remaining demonstrations it should be stressed that the x-axis is effectively meaningless. It is noted that Alice has provided nonzero quantities of both USDTKN and RSKTKN tokens in the present example and has active nonzero balances in both tokens at this stage in the illustration, and yet the x-coordinate on both curves is nil. It is noted that other equations described herein, including marginal exchange and effective exchange rates, and the swap equations themselves, make no reference to the x-coordinate. However, this is not a requirement, but rather a nuance of some embodiments as it is being described in the present context. In other embodiments, both axes may represent actual or virtual balances. Regardless, the familiarity of treating both axes as representing real token balances in a smart contract associated with a user’s position has heuristic value, and despite its implicit irrelevance, still benefits the communication of more important concepts. As a compromise, the x-axis will be named only as x in the forthcoming figures.

Reference is now made back to Figure 10, which is a schematic depicting a state before any exchanges are performed, of Alice’s pristine strategy, in accordance with some embodiments of the present invention. The top and bottom sets of curves are identical, but the axes have been rescaled in the latter from its square arrangement to allow for more prudent observation of changes to their structure during exchange. During the following discussion, changes in scale are necessary to make clear how each side of the strategy evolves under an asymmetric liquidity paradigm. At this stage in the discussion, the most important features of the curves are their intercepts and the y-coordinates. In the absence of any activity, both y-coordinates are at their starting points, their yint values, respectively. The x-intercepts are not incidental; these represent the number of tokens that will be acquired should the liquidity on the y-axis be completely depleted. The overall rate of exchange of the whole position - meaning the entire y-balance for its target, is equal to the geometric mean of the curve, which is the parameter P.

Assume the market rate of RSKTKN declines with respect to USDTKN as Alice predicted, and market participants begin to interact with her strategy. Since Alice has an active strategy in USDTKN, this is the liquidity source that supports market activity; her RSKT N component is simply not attractive while quoting an exchange rate above that which the market is actively trading. To simplify this part of the discussion, the examples simulate a single bulk trade and sudden, violent changes in the accepted market rate; however, this obfuscates the time dimension, where many different actors may have interacted with Alice’s strategy.

During a downturn in the market appraisal of RSKTKN, assume its exchange rate versus USDTKN arrives at ¹²/i9, or $0.63, which is inside of Alice’s target. During this time, through arbitrage and other mechanisms, it can be assumed Alice’s USDTKN liquidity will deplete to such a point where the exchange rate quoted by her bonding curve largely agrees with the rest of the market. To simulate this condition, the precise y-coordinate on the USDTKN curve can be computed from the marginal rate (eqn 21e). The x-coordinate can also be computed and is used in the following figures to indicate the overall progress towards fulfilling the order in its entirety.

For the USDTKN curve, the (optionally only) change that is apparent is the shift in the y- coordinate, as presented in Table 4.

Inspection of the results above reveal an overall Δv of 454.4058, representing a gain of RSKTKN to Alice’s strategy, and -Δy of 294.8574, corresponding to a loss of USDTKN from Alice’s strategy, culminating in a cost base average of approximately $0.64 per RSKTKN acquired. Before examining the effect of the acquired RSKTKN on the state of Alice’s strategy, it is noted that this exchange is permanent. In standard AMMs, if market sentiment recovered after a sudden drawdown, Alice’s liquidity position would rebalance, and thus the opportunity afforded to her by acquiring her target tokens at an attractive rate is rescinded (unless she is fast and attentive enough to respond appropriately). This is a significant change from the status quo. Alice’s USDTKN curve (optionally only) performs exchange in its forwards direction and not in the reverse direction. Thus, the fate of the acquired RSKTKN provokes a justified curiosity.

The RSKTKN is absorbed by the strategy on its dedicated liquidity curve. More importantly, it is added to its y-axis. Since the balance of RSKTKN was already at parity with its y-intercept, the y-intercept is moved to accommodate the newfound liquidity. The parametrization of the novel invariant function comprising the first half of the present disclosure is such that the yint value can be used as a type of container size; it can be moved without affecting the user’s chosen exchange profile. In more explicit terms, the gradients at the x- and y- intercepts can remain constant, thus allowing the RSKTKN acquired at a low exchange rate to accumulate at the same price interval defined when the strategy was created. In the implementation considered for the present discussion, this effect can be achieved while (optionally only) updating a single variable, the yint value, and therefore represents no significant computational overhead. Depending on the environment, if it is economical to maintain a dictionary of all parameters describing the pair of liquidity curves comprising Alice’s strategy then such dictionary may be implemented. The results of Alice’s accumulation of RSKTKN in this example is summarized in Table 5. In contrast to the situation for the USDTKN curve, significant changes are apparent, particularly with respect to the natural scaling parameters, whereas the curvature parameters have remained unchanged.

Reference is now made back to Figure 11, which is a schematic depicting the difference in the relative changes to either half of Alice’s strategy, in accordance with some embodiments of the present invention. As seen in Figure 11, the difference is dramatic. The reason for this is that Alice’s strategy is very top-heavy, culminating in what is often referred to as a “buy wall” on conventional order books. However, unlike a conventional orderbook, the tokens received through passive interaction with the outside market via one bonding curve are immediately and automatically added to its counterpart. Thus, a fully automated system for precise execution of premediated trading strategies is realized. As the exchange rate of RSKTKN continues to fall against USDTKN, Alice’s strategy will continue to part with its USDTKN in return for RSKTKN. Assume the downturn continues to the point where the exchange rate of RSKTKN approaches ⁹/25, or $0.36, which remains inside of Alice’s target range. The effects of the changing market can be easily modelled by assuming the y-coordinate of the USDTKN side of her position comes to rest at the point where the gradient of its tangent line is precisely - ⁹/25. This point can be computed from either the x- or y-coordinate via any of the marginal rate equations presented herein. As before, the USDTKN curve changes (optionally only) with respect to the y-coordinate, which drags the x-coordinate behind it. The simulated drawdown is considerably more severe than what was considered in the previous example, consuming a more significant fraction of Alice’s active limit order, as presented in Table 6

The tremendous change in scale resulting from the accumulation of additional RSKT N by its cognate curve, is noted. This is trivial to achieve, as the parameter k has the same intrinsic meaning as in eqns. la-c. Comparing [k for the RSKT N curve from the instant of its creation up to the present moment reveals a 5.5*, followed by an 11. Ox increase, culminating in an overall 60.8x increase in relative terms. Arbitrary changes in size are trivial, and do not give rise to performance or accuracy problems in the specific parametrization considered in this hypothetical. In part, this resiliency is owed to the fact that when a curve is expanding to accommodate additional liquidity, it can (optionally only) do so such that y = yint, precisely. Infinite relative growth in the value of k can also be achieved by allowing users to commence strategies containing (optionally only) a single token balance, and therefore featuring an empty curve at its creation. Strategies created with an empty curve (i.e. y = yint = 0) must still contain information about the exchange interval, JP^ and

Empty curves can begin to fill via the use of its companion’s liquidity, in a manner identical to that demonstrated by Alice’s RSKTKN curve. Moreover, users may wish to adjust the token balances on their strategies over time, including completely emptying one or both curves. None of these considerations present a problem for the embodiment of the invention presently under examination. The results of Alice’s accumulation of RSKTKN in this example is summarized in Table 7.

Reference is now made back to Figure 12, which is a schematic depicting the difference in the relative changes to either half of Alice’s strategy, in accordance with some embodiments of the present invention.

Continuing with the examination of the asymmetric liquidity pools, assume that the local bottom in the exchange rate of RSKTKN to USDTKN was ⁹/n ($0.36), after which its appraisal begins to improve. After an arbitrary period, a market rally carries the valuation of RSKTKN into Alice’s target range. First, consider a moment in time where the exchange rate approached l⁴/s USDTKN per RSKTKN, or ⁵/9 RSKTKN per USDTKN (i.e. $1.80). The point on Alice’s RSKTKN curve corresponding to ²A can computed from the marginal rate (eqn 21e). For the first time in the present study, the RSKTKN curve has experienced at least one interaction with market participants, who have exchanged their USDTKN for Alice’s RSKTKN.

As anticipated, the y-coordinate (i.e. the true token balance) of Alice’s RSKTKN curve has diminished, as presented in Table 8; while USDTKN has accumulated on its counterpart, as presented in Table 9. However, since Alice’s USDTKN curve has ample space to move its y- coordinate without exceeding yint, no changes are made to its capacity parameters. Rather, the y- coordinate is simply moved to reflect the new USDTKN liquidity balance, which has a subsequent effect on the quoted instantaneous exchange rate for the first available infinitesimal within the curve. This is expected behavior. The exchange rate can (optionally only) move within the bounds determined by Alice.

Reference is now made back to Figure 13 A, which is a schematic depicting accumulation of additional USDTKN at the current price point that fills its cognate bonding curve from the bottom-up, slowly moving the reaccumulation target back towards the upper boundary, in accordance with some embodiments of the present invention.

Finally, assume that at its local high, RSKTKN achieved an exchange rate of 2 ’ USDTKN per RSKTKN, or ²A RSKT N per USDTKN (i.e. $2.50), before capitulating back to a point outside of (i.e. between) both of Alice’s designated price ranges, thus marking the completion of a market cycle from her perspective. For ease of analysis, let the final exchange rate of RSKTKN and USDTKN be 1 : 1, thus having returned to the state whence this hypothetical began.

During the local top for RSKTKN, the point on Alice’s RSKTKN curve corresponding to ²A can be computed as demonstrated previously. As per the routine, the y-coordinate (i.e., the true token balance) of Alice’s RSKTKN curve has further diminished due its valuation against USDTKN climbing farther into her range, as presented in Table 10; while USDTKN has accumulated on its counterpart curve, as presented in Table 11. Notably, this is the first case where Alice’s balance of USDTKN exceeds the yint on its own curve; therefore, the capacity of the curve is increased to accommodate the new liquidity, as shown with reference to Figure 13B.

Consider that Alice began with 100 RSKTKN and 5000 USDTKN, at a price point where both were stated to be worth precisely $1, totaling $5,100 in value. Despite the absence of fee earnings of any kind, and without interacting with her position at all after instantiating it, Alice has improved her holdings of RSKTKN and USDTKN to 2112.88 and 9757.79, respectively, totaling $11,870.67.

The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

It is expected that during the life of a patent maturing from this application many relevant smart contracts and cryptocurrencies will be developed and the scope of the terms smart contract and cryptocurrency is intended to include all such new technologies a priori.

As used herein the term “about” refers to ± 10 %.

The terms "comprises", "comprising", "includes", "including", “having” and their conjugates mean "including but not limited to". This term encompasses the terms "consisting of' and "consisting essentially of .

The phrase "consisting essentially of' means that the composition or method may include additional ingredients and/or steps, but only if the additional ingredients and/or steps do not materially alter the basic and novel characteristics of the claimed composition or method.

As used herein, the singular form "a", "an" and "the" include plural references unless the context clearly dictates otherwise. For example, the term "a compound" or "at least one compound" may include a plurality of compounds, including mixtures thereof.

The word “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.

The word “optionally” is used herein to mean “is provided in some embodiments and not provided in other embodiments”. Any particular embodiment of the invention may include a plurality of “optional” features unless such features conflict.

Throughout this application, various embodiments of this invention may be presented in a range format. It should be understood that the description in range format is merely for convenience and brevity and should not be construed as an inflexible limitation on the scope of the invention. Accordingly, the description of a range should be considered to have specifically disclosed all the possible subranges as well as individual numerical values within that range. For example, description of a range such as from 1 to 6 should be considered to have specifically disclosed subranges such as from 1 to 3, from 1 to 4, from 1 to 5, from 2 to 4, from 2 to 6, from 3 to 6 etc., as well as individual numbers within that range, for example, 1, 2, 3, 4, 5, and 6. This applies regardless of the breadth of the range.

Whenever a numerical range is indicated herein, it is meant to include any cited numeral (fractional or integral) within the indicated range. The phrases “ranging/ranges between” a first indicate number and a second indicate number and “ranging/ranges from” a first indicate number “to” a second indicate number are used herein interchangeably and are meant to include the first and second indicated numbers and all the fractional and integral numerals therebetween.

It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the invention. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.

Although the invention has been described in conjunction with specific embodiments thereof, 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.

It is the intent of the applicant(s) that all publications, patents and patent applications referred to in this specification are to be incorporated in their entirety by reference into the specification, as if each individual publication, patent or patent application was specifically and individually noted when referenced that it is to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present invention. To the extent that section headings are used, they should not be construed as necessarily limiting. In addition, any priority document(s) of this application is/are hereby incorporated herein by reference in its/their entirety.

Claims

WHAT IS CLAIMED IS:

1. A computing device for exchanging tokens by a distributed smart contract executing on a blockchain, comprising: at least one hardware processor of a network connected server executing a code of the distributed smart contract executing on the blockchain, the code for: managing a primary reserve of a plurality of tokens of a primary cryptocurrency; 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 computing an exchange rate for converting between the primary cryptocurrency and a secondary cryptocurrency; and in response to a transaction request for converting between the primary tokens and a secondary token of a secondary cryptocurrency, executing the transaction request using a bonding curve defined by the function with the plurality of values of the plurality of adjustable parameters.

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

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

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

5. The computing device of claim 3, wherein the resource requirements are selected from a group comprising: calculation accuracy in the absence of 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 adjustable parameters are obtained from a user via a user interface running on the client terminal in communication with the network connected server.

7. The computing device of claim 1, wherein one of the x-axis and the y-axis represents a balances of the primary reserve, and the other axis is non-defined, and the function represents all possible exchange rates for converting between the primary token and the second token.

8. The computing device of claim 1, wherein the transaction request for exchange using the function with applied parameters is executed on blockchain using fundamental math operations selected from: addition, subtraction, multiplication, and division, and excludes all of: Taylor series, polynomial approximation, and numeric methods of producing a function output.

9. The computing device of claim 8, wherein at least two of the plurality of adjustable parameters are computed off-blockchain.

10. The computing device of claim 1, wherein the bonding curve comprises a first bonding curve and further comprising a second bonding curve defined by the function, the first bonding curve defined by a first set of values of the adjustable parameters, the second bonding curve defined by a second set of values of the adjustable parameters, the first bonding curve for converting from the primary cryptocurrency to the secondary cryptocurrency, and the second bonding curve for converting from the secondary cryptocurrency to the primary cryptocurrency, wherein the first bonding curve and the second bonding curve have common adjustable parameters with different values.

11. The computer device of claim 10, wherein a first exchange rate for converting from the primary cryptocurrency to the secondary cryptocurrency is computed according to the first bonding curve, a second exchange rate for converting from the secondary cryptocurrency to the primary cryptocurrency is computed according to the second bonding curve, wherein the first bonding curve is different than the second bonding curve and the first exchange rate is different than the second exchange rate.

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

13. 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 the values of the parameters for the first bonding curve and the second bonding curve.

15. The computing device of claim 1, wherein the plurality of adjustable parameters include a base set of adjustable parameters, selected from the group comprising: n,

P denoting a gradient at x=xo, y=yo indicating a geometric mean price, Q

R,

S denoting a difference of square roots of the gradients of the intercepts, yint denoting a balance of the primary tokens where the marginal exchange rate is equal to Pa, xint denoting, when the range commences with y=yint, a balance of secondary tokens that is obtainable if the balance of the primary tokens is driven to zero xo denoting an x-coordinate at the geometric mean price, yo denoting a y-coordinate at the geometric mean price, Xasvm denoting an x-asymptote or vertical asymptote, y_asym denoting a y-asymptote or horizontal asymptote, and geometric and/or algebraic reconstruction of the aforementioned.

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

17. The computing device of claim 1, wherein a single distributed smart contract executing on the blockchain implements a different set of values for the adjustable parameters for a different instance of the function, and the single distributed contract implements each respective reserve of a certain token and a corresponding bonding curve defined by the function with the different set of values for the adjustable parameter defines a primitive for unidirectional exchange between an external token and the certain token of the respective reserve, wherein multiple primitives are linked to one another for defining unidirectional routes for token exchanges.

18. The computing device of claim 1, wherein the function is defined with reference to a hyperbola with asymptotes at x=Q and =0 represented as xy=k where x denotes the primary token and y denotes the secondary token.

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

20. The computing device of claim 19, wherein a slope of each at least one bonding curve at the at least one common point is identical with a first derivative of xy=k, wherein each at least one bonding curve is defined to have a point on its implicit curve at coordinates x=xo and = o where a first derivative is equal to that of the constant product bonding curve at the same coordinates.

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

22. The computer device of claim 1, wherein each exchange rate of a plurality of exchange rates for converting between the primary cryptocurrency and the secondary cryptocurrency is represented as a secant line between two points of the function, wherein a first point represents the balance of the primary reserve before the exchange occurred, and a second point represents the balance of the primary reserve after the exchange occurred.

23. The computer device of claim 1, wherein each parameter is assigned to a set of a plurality of sets, each parameter of each set is mathematically related to other parameters within the set and each parameter is mathematically related between sets of other parameters, sufficient to unambiguously describe a unique invariant function - implicit curve pair.

24. The computing device of claim 1, wherein a marginal exchange rate for converting between the primary cryptocurrency and the secondary cryptocurrency is computed according to a first derivative of the bonding curve implicitly defined by the function with applied adjustable parameters.

25. A computing device for exchanging tokens by a distributed smart contract executing on a blockchain, comprising: at least one hardware processor of a network connected server executing a code of the distributed smart contract executing on the blockchain, the code for: managing a primary reserve of a plurality of primary tokens of a primary cryptocurrency and managing a secondary reserve of a plurality of secondary tokens of a secondary cryptocurrency; obtaining a transaction request for converting between the primary token and a secondary token of a secondary cryptocurrency; in response to the transaction request being for converting from the primary token to the secondary token, executing the transaction request using a first bonding curve implicitly defined by a function and a first set of a plurality of values of a plurality of adjustable parameters; and in response to the transaction request being for converting from the secondary token to the primary token, executing the transaction request using a second bonding curve different from the first bonding curve, the second bonding curve implicitly defined by the function and a second set the plurality of values of adjustable parameters that is different from the first set.

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

27. A method of exchanging tokens by a distributed smart contract executing on a blockchain, comprising: managing a primary reserve of a plurality of tokens of a primary cryptocurrency; 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 computing an exchange rate for converting between the primary cryptocurrency and a secondary cryptocurrency; and in response to a transaction request for converting between the primary tokens and a secondary token of a secondary cryptocurrency, executing the transaction request using a bonding curve defined by the function with the plurality of values of the plurality of adjustable parameters.