Automated Market Maker

Every liquidity pool is based on an automatic market making (AMM) algorithm that determines the prices and amounts of tokens in each trade. Geminon's GLPs use a proprietary algorithm derived from the constant product AMM that gives them the liquidity creation capabilities of an LBP.

Constant product AMM

Practically all of the decentralized exchange (DEX) protocols that exist today use the so-called constant product formula for their liquidity pools:

xy=kx \cdot y = k

Where xx and yy are the amounts of the pair of tokens in the pool and kk is a constant that is fixed when the initial liquidity is added during its creation. The liquidity pool creates an automatic market for the token pair simply by imposing the condition that, after every trade, the product of the amounts of both tokens cannot be less than the liquidity constant:

(x+Δx)(y+Δy)k(x + \Delta x)(y + \Delta y ) \nless k

Given an amount of tokens Δx\Delta x that you want to exchange using the liquidity pool, the amount of the exchanged token to receive Δy- \Delta y is calculated as:

Δy=ykx+Δx- \Delta y = y - \frac {k}{x + \Delta x}

Generalized constant product AMM

The constant product AMM formula can be generalized for a pool consisting of n tokens with weights wnw_n such that nwn=1\sum_n w_n = 1:

nBnwn=k\prod_n B_n^{w_n} = k

Where BnB_n is the balance of the nth token in the pool. Developing the previous formula, it is obtained that for an exchange of any pair of tokens in the pool, given the input amount of one token Δx\Delta x, the received amount of the second token is given by:

Δy=y(1(xx+Δx)wxwy)-\Delta y = y \Bigg(1 - \bigg(\frac {x} {x + \Delta x}\bigg)^{\frac{w_x}{w_y}}\Bigg)

From the previous equations it is derived that the quote or relative price of one token based on another in the pool depends exclusively on the balances and relative weights of both tokens in the pool:

Pxy=xwxywyP_x^y = \frac {\frac {x}{w_x}} {\frac {y}{w_y}}

It can be easily shown that these equations are transformed into the equations for a pool of two tokens seen in the previous point by doing wx=wyw_x = w_y.

Geminon AMM

The generalized AMM equations from the previous point are the ones used by the Balancer protocol for its pools. In Balancer LBPs it is possible to alter the relative weights of the tokens in the pool, which changes the relative price of both tokens and also the value of the pool's liquidity constant kk.

The AMM algorithm developed for the Geminon GLPs also alters the value of the pool invariant, although it employs a completely different mechanism. The main differences are:

  • The variation of the liquidity constant is completely automatic in GLP: it is not possible to manually alter the weights of the tokens in the pool, and therefore the prices.

  • The parameterization of liquidity in a GLP varies depending on the operations carried out, not depending on time as it happens in LBPs.

  • The GLP algorithm does not vary the weights of the tokens in the pool, but rather the balance of the GEX token.

Algorithm description

The Geminon AMM works in two steps:

  1. The amount of the output token is calculated using the constant product AMM formula with the liquidity available at that moment in the pool, that is, in this step the LPG behaves exactly the same as a Uniswap-type liquidity pool.

  2. In the second step, the balance of the GEX token in the pool is modified by minting or burning tokens. The variation of the supply of the GEX token is calculated from the number of tokens that the user has received or delivered to the pool, depending on the operation carried out.

To help reduce trade slippage, which negatively impacts user output, the pool automatically splits the input amount in half and runs the above steps twice, so that on the second iteration the user benefits from the increase in liquidity that he himself has generated. This mechanism is especially effective when the liquidity of the pool is very low.

Mint GEX tokens (mintSwap)

For a GEX token purchase (mint) operation, the amount of GEX tokens to be received is initially calculated as if it were a Uniswap-type liquidity pool. If c0c_0 is the balance of collateral in the pool, and g0g_0 the balance of GEX tokens in the pool, the pool invariant is:

k0=c0g0=(c0+cin)(g0gout)k_0 = c_0 \cdot g_0 = (c_0 + c_{in})(g_0 - g_{out})

And the amount of tokens received by the user, goutg_{out}, when he delivers an amount of collateral, cinc_{in}, is calculated by isolating the invariant in the previous equation:

gout=g0(1c0c0+cin)g_{out} = g_0 \bigg( 1 - \frac {c_0}{c_0 + c_{in}} \bigg)

After calculating the number of output GEX tokens, the mint coefficient μ\mu is applied, which increases the balance of GEX tokens in the pool:

g1=g0gout(1μ)g_1 = g_0 - g_{out}(1 - \mu)
c1=c0+cinc_1 = c_0 + c_{in}
k1=c1g1k_1 = c_1 \cdot g_1

Finally, the commissions for minting the protocol are deducted from the number of GEX tokens to be sent to the user.

The minting coefficient takes its values in the interval [1,2][1,2], which makes it possible to deduce the behavior of GLP in GEX token mint operations:

1. In a minting operation, liquidity always increases: since the values of the minting coefficient are restricted (μ[1,2]\mu \in [1,2]) the difference 1μ1-\mu is always less than or equal to 0, which implies that g1g0g_1 \ge g_0, the final balance of GEX in the pool will always be equal to or greater than the initial. Also, since c1>c0c_1 > c_0 because it is a minting operation, k1>k0k_1 > k_0, then the liquidity product of the pool after the operation will always be strictly greater than the initial one.

2. The result of an operation in GLP is closer to that obtained in a Uniswap-type liquidity pool, the lower the amount of the operation. If the k1k_1 invariant equation is developed to express it solely as a function of the input quantity, we have:

k1=(c0+cin)g0(1(1μ)(1c0c0+cin))k_1 = (c_0 + c_{in}) \cdot g_0 \Bigg(1 - (1-\mu) \bigg(1- \frac {c_0}{c_0 + c_{in}} \bigg) \Bigg)

It's easy to see that the above expression converges to the value of the initial invariant k0=c0g0k_0 = c_0 \cdot g_0 the lower the input value cinc_{in} is, or more formally:

limcin0k1=k0\lim_{c_{in} \rarr 0} k_1 = k_0

3. The final price of the GEX token in the pool after the transaction is lower than the price that would be obtained in a pool of pure constant product. It is easy to intuitively see that by increasing the balance of GEX tokens in the pool, the relative price of this token against the other token should decrease:

P1g=c1g1=c0+cing0gout+μgout<c0+cing0goutP_1^g = \frac{c_1}{g_1} = \frac{c_0 + c_{in}}{g_0 - g_{out} + \mu g_{out}} < \frac{c_0 + c_{in}}{g_0 - g_{out}}

This means that transactions in a GLP are not reversible even without taking into account the protocol commissions: if a mint operation is done and immediately after the opposite is carried out, redeeming the tokens in the pool, a lower amount will be obtained depending on how far the liquidity product k1k_1 is from the initial one k0k_0. As seen in the second property, the invariants coincide at zero and separate as the amount of the trade cinc_{in} increases, or more specifically the ratio c0/cinc_0/c_{in} that determines the slippage that the trade produces in the pool price. The greater the slippage (entropy) generated by an operation in the pool, the more irreversible that operation is. Said entropy is captured by the GLP by increasing the value of the GEX token, which is why GLPs are called entropy capturing machines.

The irreversibility of the operations presents important advantages for the security of the Geminon protocol, since it implies that flash loan attacks cannot be carried out on a GLP: since the amount lent cannot be repaid in its entirety, the transaction will revert. In general, any attack that involves price manipulation in a GLP using large transactions that must be undone in a short period of time, will mean a financial loss for the attacker in favor of the protocol.

Redeem GEX tokens (redeemSwap)

The equations for GEX token redemption are very similar to those for minting. The main difference between both processes is that during the exchange, the protocol commission is deducted from the amount of GEX tokens entered. The amount of exit collateral coutc_{out}, given an input amount ging_{in}' (minus the commission) is worth:

cout=c0(1g0g0+gin)c_{out} = c_0 \bigg( 1 - \frac {g_0}{g_0 + g_{in}'} \bigg)

And the new balances that determine the liquidity product of the pool:

c1=c0coutc_1 = c_0 - c_{out}
g1=g0+gin(1ρ)g_1 = g_0 + g_{in}'(1 - \rho)

Price curve

In a constant product liquidity pool, the price of a token with respect to its peer is the quotient of the reserves of both. Using the constant product ratio xy=kx \cdot y = k we get:

Py=x2kP_y = \frac{x^2}{k}

The price of one token in a liquidity pool is a parabolic function of the amount of the second token in the pool. In a GLP, on the other hand, the value of kk is not constant, but rather its value varies with the amount of collateral in the pool. The GEX token price function in a GLP can be written as:

Pg=c2k(c)P_g = \frac{c^2}{k(c)}

Where k(c)k(c) is a function that varies linearly with the amount of collateral tokens. As a consequence, the GLP price function for the GEX token does not vary quadratically with the amount of collateral as it happens in a Uniswap-type pool, but rather linearly. The goal of this design is to reduce the volatility of the GEX token.

For a detailed discussion on the influence of the mint ratio on the value of kk, see the next page "Supply Control".

Last updated