The Math

This section explains the technical-mathematical terms and concepts behind ElasticSwap v1.

Technical Terms

Note: The usage of dash notation (') & delta notation (Δ) is explained in subsequent examples in the following sections.

  • X - The internal balance of, baseToken for accounting purposes.

  • DeltaX (ΔX) - The (incoming or outgoing) change in the quantity of X

  • XDash (X') -> X' = ΔX + X - The new quantity of X post the occurrence of a trade or a liquidity event

  • Y - The internal balance of quoteToken, for accounting purposes.

  • DeltaY (ΔY) - The (incoming or outgoing) change in the quantity of Y

  • YDash (Y') -> Y' = ΔY + Y - The new quantity of Y post the occurrence of a trade or a liquidity event

  • Alpha (α) - The ERC20 balance of baseToken currently in the Exchange.

  • Beta (β) - The ERC20 balance of quoteToken currently in the Exchange.

  • Omega (ω) - X/Y - The ratio of the internal balance of baseToken to the internal balance of quoteToken.

  • iOmega (iω) - Y/X - The ratio of the internal balance of quoteToken to the internal balance of baseToken.

  • K - X*Y - The product of the internal balance of baseToken and the internal balance of quoteToken. It is used to price trades between baseToken and quoteToken.

  • Sigma (σ) - α/β - The ratio of the balance of baseToken currently in the Exchange to the balance of quoteToken currently in the Exchange.

  • AlphaDecay (α^) - α-X - The amount of Alpha(α) not contributing to the liquidity due to an imbalance in the tokens caused by elastic supply (a rebase).

  • BetaDecay (β^) - β-Y - The amount of Beta(β) not contributing to the liquidity due to an imbalance in the tokens caused by elastic supply (a rebase).

  • Ro (ρ) - The total supply of the liquidityToken.

  • Gamma - Gamma is a multiplier term that is used to issue the correct amounts of liquidityToken when alphaDecay(α^) or BetaDecay (β^) exists in the system.

Further explained: Presence of AlphaDecay(α^) and BetaDecay(β^)

The presence of the terms X, Y, Alpha(α), Beta(β) Allows the ElasticSwap v1 to support stable pricing on rebasing events for an elastic-non elastic supply token pair. This is done with the concept of AlphaDecay(α^) and BetaDecay(β^). Whenever a rebase event occurs, which results in the increase or decrease in the supply of the baseToken decay is introduced. The presence (or absence) of which determines how much Ro(ρ) is issued to liquidity providers.

  • When there is an increase in the supply of the baseToken, essentially the quantity of Alpha(α) has increased, considering the situation where there was no decay prior to the rebase event, i.e., initially α = X (and β = Y), implying α^ = 0 (and β^ = 0). Post the rebase event: α^ = α' - X ( and β^ = 0, as there has been no change in β or Y)

    Note: In the above scenario, initially ω = σ, post the rebase event, ω' != σ'

  • When there is a contraction in the supply of the baseToken, essentially the quantity of Alpha(α) has now decreased, considering the situation where there was no decay prior to the rebase event, i.e., initially α = X (and β = Y), due to the contraction in supply, the BetaDecay (β^) is given by β^ = (X - α') * iω.

    Note: In the above scenario, initially ω = σ, post the rebase event, ω' != σ'

Issuance of liquidity Tokens ΔRo

Liquidity Tokens, Ro, are provided to liquidity providers. There are multiple ways to provide liquidity: creating an Elastic AMM pool, singleAssetEntry, doubleAssetEntry and a partialSingleAndDoubleAssetEntry.

  1. Creation of an Elastic AMM pool: This case refers to the creation of an ELastic AMM pool( a pool that consists of both baseToken and quoteToken) on ElasticSwap, this differs from doubleAssetEntry because here there is no Omega, Sigma Until the pool has been created. The first batch of LP tokens Ro is also minted to the liquidity provider who bootstraps the pool.

    The amount of liquidityTokens - (ΔRo) issued to the liquidity provider, in this case, is given by:

  2. Double Asset Entry: Double asset entry occurs when the liquidity provider provides both baseToken and quoteToken (in equivalent amounts, such that Omega stays constant) to the AMM. Double asset entry is only possible when there is NO AlphaDecay (α^) or BetaDecay (β^) present in the system. Double asset entry maintains the values of Omega and Sigma.

    The amount of liquidityTokens - (ΔRo) issued to the liquidity provider, in this case, is given by:

    Note: To understand the usage of Delta(Δ) and Dash(') notation, the above scenario initially(prior to Double Asset Entry) was:

    The "change" that the system is introduced to the AMM by the liquidity provider, providing baseToken and quoteToken is given by:

    As a result of which a certain amount ΔRo(DeltaRo) is issued to the liquidity provider (refer above). Which results in the final state being:

    The function that does this is addLiquidity in Exchange.sol

  3. Single Asset Entry: Single asset entry is only possible when there exists decay (alpha or beta) in the system. When there is decay in the system it means that Omega != Sigma. With Single Asset Entry, the liquidity provider is "correcting" this with their liquidity, i.e bringing Sigma in line with Omega.

    The amount of liquidityTokens - (ΔRo) issued to the liquidity provider, in this case, is given by: When there is alphaDecay:

    When there is betaDecay:

    The respective solidity functions can be found at Exchange.sol

  4. PartialSingleAndDoubleAssetEntry: When the liquidity provider wants to provide both baseToken and quoteToken when decay is present, it is called a PartialSingleAndDoubleAssetEntry. This is because firstly, a singleAssetEntry occurs, and then a doubleAssetEntry occurs. The liquidity provider receives ΔRo(liquidity tokens) that takes into account both the entires.

    The amount of liquidityTokens - (ΔRo) issued to the liquidity provider, in this case, is given by:

    Note: In PartialSingleAndDoubleAssetEntry it is possible that the user might end up with a certain amount of unused baseToken or quoteToken, This is because in the presence of AlphaDecay (α^) the SingleAssetEntry uses up a certain amount of quoteToken and then the remaining amount of which is used along with an equivalent amount of baseToken for the DoubleAssetEntry, the quantity of which could be lower than the amount the liquidity provider wanted to provide.

Redemption of liquidity Tokens ΔRo

The underlying redemption value of liquidity tokens increases due to the accrual of trading fees. At any time, they can be redeemed for equivalent amounts of baseToken and quoteToken. The amount of baseToken and quoteToken received is given by:

The function that handles this is removeLiquidity in Exchange.sol.

Note: It is possible to redeem Ro when there is decay (alpha or beta) present in the system.

Fees:

As with any other AMM, the incentive to provide liquidity is such that the LP tokens issued accrue fees.

There is a 30 basis points (BPS) fee for swap occurrences(this is at par with other AMM's at the moment, this can be changed via vote if the ElasticSwap DAO votes to do so ), 5 BPS of which goes to the feeAddress (an address which is ElasticDAO initially, this can be changed via vote if the ElasticSwap DAO votes to do so). The remaining 25 BPS is realized by the LP holders pro-rata.

The fees are accrued on swap occurrences, the portion of the fees (5 BPS) that the feeAddress receives is sent to it when liquidity events occur.

Tokens supported by ElasticSwap:

For the rebasing token - baseToken, any ERC20 token which is Elastic in nature, i.e its supply contracts and expands due to external factors can be used to create a pool with a standard ERC20 non-elastic token - quoteToken.

Note: Support for tokens that have Fee on transfer behaviour will not supported in V1.

Examples:

Example 1:

Example 2: Rebase down -> SAE + DAE -> exit

Last updated