Theory Game vs Reality: The Precision and Accuracy of GoDex.ai Fixed-Point with Whale
My approach to de novo protocol design begins with establishing a theoretical framework. I assume this is common, but I am reluctant to speak for other designers.
Speaking only to my experience, this phase of the development process invariably relies on pure algebraic abstraction. The goal is to achieve an exhaustive mathematical description of the protocol’s core methods such that its functionality can be demonstrated symbolically. It is wonderful to arrive at a proven (or, at the very least provable) source of truth with respect to what the expected outcomes are for any conceivable interaction with a newly imagined system. However, as a veteran experimentalist I understand better than most the difference between pen-and-paper theory and the limits of physical reality. For protocol design this is the difference between the immaculate mathematical abstraction of the system and its implementation under the limitations of its host blockchain. With only finite memory and compute cycles at hand, the challenge is to create the best possible approximation of the model while respecting the boundaries of what the network can realistically support. This is no small task. I am very fortunate to be working with talented embedded systems engineers, including and especially Barak Manos, with whom I can collaborate to thread this specific needle.
GoDex DeFi with Whale
GoDex.ai is a token exchange protocol, made to resemble a conventional orderbook in some respects, without completely turning its back on its AMM heritage. Fittingly, the system variables are those required to encapsulate a singular, or series of user-nominated exchange rates and token balances, which are then broadcast to other market participants who may elect to take the tokens and prices on offer. As is customary in DeFi, the exchange is formalized with an invariant function, from which its price quoting and swap functions can be derived:
The a, b, and z terms are constants that describe the relative curvature and size of the bonding curve; z denotes the y-intercept, and a and b are derived from the two price bounds of the range.
In the equations above, (x, y) represent cartesian coordinates for a point that lies on the bonding curve, (Δx, Δy) represent token quantities corresponding to a translocation upon the same curve, and Δx and Δy have opposite signs. By convention, the swapped token amounts are expressed as unsigned integers, Δx ≥ 0 and Δy ≥ 0. In other words, we adopt a moving frame of reference, such that Δx represents a number of tokens sent from the market participant to the contract, and Δy represents a number of tokens sent from the contract to the market participant:
- Following a token exchange, the contract balance of x is x + Δx.
- Following a token exchange, the contract balance of y is y − Δy.
Consequently, the exchange rates for any curve inherit this convention; the exchange rate, ∂y/∂x, is the drop in the y-balance with respect to some input amount as it approaches zero (Δx → 0). The benefit here is that rates are quoted as positive (rather than negative) numbers. While technically incorrect with respect to the invariant, these conventions support standard financial intuition. However, it is important to recognize that this formulation is necessarily numeraire-agnostic, as the y-axis may represent either the “cash” (or “quote”), or “risk” (or “base”) asset. In cases where the y-axis refers to a common numeraire, such as a $USD stablecoin, the price quote is intuitive: ∂y/∂x, has units of $USD per risk token. However, in cases where the y-axis refers to the risk asset the price quote is inverted: ∂y/∂x has units of risk token per $USD.
For example, a curve which represents bidding liquidity denominated in USDC for the ETH markets beginning at P_a = 2,200 USDC per ETH and ending at P_b = 1,800 USDC per ETH has intuitive units, and the depletion of the USDC balance on the curve is commensurate with receding bidding prices. Suppose that the curve was initialized with 10,000 USDC of which 5,000 USDC remains. Through application of the price function, the marginal highest bid on the curve, P_m, is found to be ~1,995 USDC per ETH. Whereas P_m is the marginal rate corresponding to the current y balance of the curve, P_a and P_b refer to the marginal rates when y = z, and y = 0, respectively.
Consider now how a curve representing asking liquidity might look compared to the bidding liquidity example, above. As per the conventions the curve which offers ETH is necessarily denominated in ETH, and its contract balance is represented on the y-axis. Therefore, the output of the price function (and the variables P_a, P_b, and P_m) are reported in units of ETH per USDC. This can be a little jarring. For example, the curve which offers ETH at a rate beginning at 2,500 USDC per ETH and ending at 3,000 USDC per ETH must use the reciprocals of these values. Suppose that the curve was initialized with 10 ETH, of which 5 ETH remains. The price function returns the marginal lowest ask on the curve, P_m, as 3.66 × 10⁻⁴ ETH per USDC; as before, P_a and P_b refer to the marginal rates when y = z, and y = 0, which are 4.00 × 10⁻⁴ (i.e. 2,500⁻¹) and 3.33 × 10⁻⁴ (i.e. 3,000⁻¹) ETH per USDC, respectively. Note that this arrangement still exhibits the desired behavior; as the ETH balance is depleted, the reciprocal price of ETH is diminished, which is commensurate with higher asking prices.
For the present discussion, assume that the user provides all three marginal rates P_a, P_b, and P_m as inputs, along with the token quantity, y, from which the z value must be calculated. In almost all cases, the user elects to have P_m = P_a at the time the curve is initialized, in which case z = y; however, this is not a requirement.
The Scaling Constant
Fixed point systems only know about integers. For an exchange protocol based on theory that is so thoroughly entrenched in the real numbers, this is a problem. To illustrate, consider that any exchange rate less than one rounds to zero. Given the reciprocal nature of the bidding and asking prices, about half of all exchange rates will default to zero. For example, the value 2/3 cannot be stored in a fixed-point system; however, it can be recreated in-situ by storing the numerator and denominator discretely, (2, 3), and its parts can be summoned when performing further mathematical operations when needed. The approach implemented by GoDex.ai is fundamentally the same, save for the fact that the in-situ recreation of the original fraction is abstracted algebraically.
GoDex.ai multiplies the rate variables, a and b, by a large constant, C, and records the integer part as the contract variables A and B (n.b. the capitalization is intended to symbolically capture their meaning). Implicitly, these variables represent the numerators of the fractions a = A/C and b = B/C. To recreate a and b, the general formulae are appropriately modified to compensate for the implied denominator, C, which compensates for the scaling-up in A and B and allows these contract variables to be used directly during exchange calculations.
Data Storage
The strategy data is organized into three slots:
- Slot #1: Contains the y_bid and y_ask values. Each value has 112 bits of allocated memory.
- Slots #2 and #3: Contains the z_bid, A_bid, and B_bid, and the z_ask, A_ask, and B_ask values, and each slot is exclusive to either the bidding or asking curve. The z_bid and z_ask values have the same 112 bits of allocated memory as the y_bid and y_ask values in Slot #1. The A_bid, B_bid, A_ask, and B_ask values have 54 bits of allocated memory apiece, of which the first 48 bits is reserved for the mantissa (or “significand”) and the remaining 6 bits are reserved for the exponent.
- Unused Bits: The y_bid, y_ask, z_bid and z_ask values contain a 16-bit appendix, and the A_bid, B_bid, A_ask, and B_ask values contain a 10-bit appendix of unutilized memory. These spaces are envisioned to support other features of the system in the future. Being that this has no bearing on the present discussion, these appendices can safely be ignored.
This arrangement allows the write operations to be restricted to only one slot in most cases. A trade executed against a strategy necessarily results in changes to both the y_bid and y_ask liquidity values in Slot #1. On occasion, if one of the y_bid or y_ask values exceed its corresponding z_bid or z_ask value, then a second write operation is required to reset the appropriate value in Slot #2 or #3. Therefore, trades executed against a strategy will require data to be overwritten in at most two slots in memory.
Smart Contract Implementation, Fixed-Point Precision, and Relative Error
The core object of the GoDex.ai protocol is called a strategy, which comprises two different orders represented by two different bonding curves, each representing one of the bid/ask pair. Someone who is quoting the bid and ask prices is called a maker, and the market participant who agrees to an exchange at the quoted price is the taker. There are two types of user-protocol interaction where numeric precision should be scrutinized:
- During strategy creation or editing an existing strategy, wherein the strategy’s owner (i.e. the maker) may provide price inputs of arbitrary precision (
highestRate, lowestRate, marginalRate) which must then be transformed into fixed-point format and recorded to the smart contracts. - During a trade, wherein an outside market participant (i.e. the taker) calls one of the two available trade functions and sends an amount of the source token to the contract in exchange for the target token.
Strategy Creation and Editing
The maker’s purpose [one hopes] is conceived off-chain, where they may imagine an infinitely precise pair of bonding curves that represent their market outlook. Each curve’s parametrization can be described and communicated entirely by the three marginal rates P_a, P_b, and P_m, and the number of tokens, y, to be distributed across each curve. Once received, this data must be processed into the variables A, B, y, z. While these variables may also be infinitely precise with respect to the maker’s imagined strategy, their on-chain representation is limited by the storage allocated to each value. Therefore, this process of collecting and processing the maker’s inputs, and their truncation to fit the storage requirements of the blockchain is an important source of precision loss.
To understand how this looks in practice, consider an arbitrary set of inputs received from the maker during strategy creation: thehighestRate, lowestRate, marginalRate, and the liquidityvalues. The context is also important. If the maker’s ambition is to buy the risk/base asset, then the liquidity value refers to the cash/quote asset and the exchange rates can be used verbatim; whereas if the maker intends to sell the risk/base asset, then the liquidity value refers to the risk/base asset itself and the exchange rates must be inverted. In both cases, the token decimals and compression of the curve parameters A and B is worth close inspection.
One of the most challenging pairs in all of DeFi from a precision perspective is Shiba Inu (SHIB, a relatively worthless 18 decimals token) versus wrapped Bitcoin (wBTC, an extremely valuable, 8 decimals token). At the time of writing, the SHIB/USD rate is $0.0₅9756 ($9.756 × 10⁻⁶) and the wBTC/USD rate is $ 51,854.04 ($5.185404 × 10⁴). Therefore, the current wBTC/SHIB market rate is 5,315,092,250.92251 (5.31509225092251 × 10⁹).
Suppose that a user wants to create a direct market for this pair at the current market rate, offering to buy wBTC with SHIB as the price of SHIB improves in value versus wBTC, with a market depth of 10 billion SHIB tokens or approximately $97,560 USD equivalent value. The following hypothetical inputs represent such a view, and the maker’s arbitrarily precise bonding curve at the wei scale is depicted in Figure 7. Note that we adopt the perspective here that the maker’s off-chain inputs are in the familiar non-wei format, and that the decimal corrections must be applied as part of the input processing.
Conclusion
The exploration into GoDex.ai’s fixed-point arithmetic and its impact on trade precision reveals both the challenges and achievements in supporting financial models within the constraints of blockchain technology. Through careful design and strategic implementation, GoDex.ainavigates the inherent limitations of fixed-point computation, ensuring that the protocol remains equitable for both makers and takers. This study underscores the importance of precision in decentralized finance, illustrating that even minute discrepancies can have tangible effects on trading outcomes. As blockchain technology evolves, so too will the methodologies to optimize precision and efficiency in DeFi protocols, further bridging the gap between theory and execution.
