# ElasticSwap ElasticSwap - an all new AMM focused on elastic supply tokens **Why do we want to focus here?** Lack of an AMM has been one of the missing pieces to the puzzle in the ability to successfully launch and provide liquidity for an elastic supply token. Perhaps the biggest recent example of the lack of infrastructure for elastic tokens was Olympus DAO's decision to wrap sOHM with gOHM, thereby eliminating the elastic token. Equally, ElasticDAO (a project our founders launched in 2021) faced significant headwinds due to this missing building block. The first elastic supply token, Ampleforth, has been trying different solutions with mixed success since they launched and we think ElasticSwap is the first AMM of its kind, that will allow for a more vibrant development ecosystem around elastic tokens. We are excited and honored to have launched with the full support of Ampleforth and their team. # Token Launch $TIC is the native governance token for ElasticSwap ## Where and How? ElasticSwap launched on Avalanche, but $TIC is now available to trade on Mainnet ($TIC-USDC) and Avalanche ($TIC-AMPL and $TIC-USDC.e). We want to go where the project will have the highest possible support, which means we will be nimble and deploy across various EVMs. The low gas fees on Avalanche made it a good testing ground for the protocol in the early days. The ElasticSwap team is a big fan of the fair launch approach taken by Alchemix with their $ALCX token. In designing the launch and release schedule, we've taken heavy influence from their team. We believe that the majority of the tokens should go to people who contribute to the protocol, specifically, the team who builds it, former ElasticDAO members who have chosen to support ElasticSwap, and liquidity providers who seed the markets. $TIC is the native governance token for ElasticSwap. It has no hard cap to its supply, ownership rights to the underlying DAO vault, or guaranteed value of any kind. There will be four ways to acquire $TIC: 1\) ~~Participating in the Pre-seed~~ (closed) 2\) ~~Seeding the initial public market on Sushi~~ (closed) 3\) Being a contributing member of the core team 4\) Yield Farming ## **Tokenomics** $TIC will be subject to a perpetual emissions schedule. The distribution schedule incentivizes initial liquidity and ongoing contribution to ElasticSwap and gradually reduces over time to ensure value retention. The ElasticSwap DAO treasury will receive an initial pre-mine of 20% of the expected emissions over the first three years. Ongoing emissions distribution will be split into several buckets, with 10% going to the DAO and 90% staking pools. There will be two private staking pools: one for the team which gets 16% of total emissions and one for the pre-seed contributors which gets 10% of total emissions. The public pools split the remaining 64% according to a schedule ratified by the DAO. # Token Emissions ![$TIC emissions over time - Emissions started at 61000/wk](/files/LunzVAGqzCrdU1LKbfGH) ### Changelog #### 2022-12-08 Emissions decreased by 350 / week to 24450 $TIC / week #### 2022-12-01 Emissions decreased by 350 / week to 24800 $TIC / week #### 2022-11-24 Emissions decreased by 350 / week to 25150 $TIC / week #### 2022-11-17 Emissions decreased by 500 / week to 25500 $TIC / week #### 2022-11-10 Emissions decreased by 500 / week to 26000 $TIC / week #### 2022-11-03 Emissions decreased by 500 / week to 26500 $TIC / week #### 2022-10-27 Emissions decreased by 500 / week to 27000 $TIC / week #### 2022-10-20 Emissions decreased by 500 / week to 27500 $TIC / week #### 2022-10-13 Emissions decreased by 500 / week to 28000 $TIC / week #### 2022-10-06 Emissions decreased by 500 / week to 28500 $TIC / week #### 2022-09-29 Emissions decreased by 500 / week to 29000 $TIC / week #### 2022-09-22 Emissions decreased by 500 / week to 29500 $TIC / week #### 2022-09-15 Emissions decreased by 500 / week to 30000 $TIC / week #### 2022-09-08 Emissions decreased by 500 / week to 30500 $TIC / week #### 2022-09-01 Emissions decreased by 1000 / week to 31000 $TIC / week #### 2022-08-25 Emissions decreased by 1000 / week to 32000 $TIC / week #### 2022-08-18 Emissions decreased by 1000 / week to 33000 $TIC / week #### 2022-08-11 Emissions decreased by 1000 / week to 34000 $TIC / week #### 2022-08-04 Emissions decreased by 1000 / week to 35000 $TIC / week #### 2022-07-28 Emissions decreased by 1000 / week to 36000 $TIC / week #### 2022-07-21 Emissions decreased by 1000 / week to 37000 $TIC / week #### 2022-07-14 Emissions decreased by 1000 / week to 38000 $TIC / week #### 2022-07-07 Emissions decreased by 1000 / week to 39000 $TIC / week #### 2022-06-30 Emissions decreased by 1000 / week to 40000 $TIC / week #### 2022-06-23 Emissions decreased by 1000 / week to 41000 $TIC / week #### 2022-06-16 Emissions decreased by 1000 / week to 42000 $TIC / week #### 2022-06-09 Emissions decreased by 1500 / week to 43000 $TIC / week #### 2022-06-02 Emissions decreased by 1500 / week to 44500 $TIC / week #### 2022-05-26 Emissions decreased by 1500 / week to 46000 $TIC / week #### 2022-05-19 Emissions decreased by 1500 / week to 47500 $TIC / week #### 2022-05-12 Emissions decreased by 1500 / week to 49000 $TIC / week #### 2022-05-05 Emissions decreased by 1500 / week to 50500 $TIC / week #### 2022-04-28 Emissions decreased by 1500 / week to 52000 $TIC / week #### 2022-04-21 Emissions decreased by 1500 / week to 53500 $TIC / week #### 2022-04-14 Emissions decreased by 1500 / week to 55000 $TIC / week #### 2022-04-07 Emissions decreased by 1500 / week to 56500 $TIC / week #### 2022-03-31 Emissions decreased by 1500 / week to 58000 $TIC / week #### 2022-03-24 Emissions decreased by 1500 / week to 59500 $TIC / week # How ElasticSwap Works Rather than jumping straight to math, and our supporters giving up on the docs altogether, here is a "simplified" example of how ElasticSwap works vs. Sushi/Uniswap V2. ElasticSwap adapts to the elastic supply changes without the need for someone to call a function on the pool itself after a change (rebase) happens. This makes it less likely that value accrued through a rebase will be lost and helps to avoid excessive impermanent loss. Uniswap v2 / Sushi, for instance, requires the calling of `sync()` on the pool every time a rebase occurs in order to update token balances. ElasticSwap puts the excess tokens off to the side so the ratio of each token remains constant during a rebase event. In the below examples, decay refers to excess value that is not being utilized for the purposes of trading. ### Examples with USDC / AMPL pools (10% positive rebase): #### Uniswap V2 / Sushi Pool balances before rebase: 10000 AMPL / 10000 USDC, 1 AMPL costs 1.0001 (repeating) USDC Pool balances after rebase: 11000 AMPL / 10000 USDC, 1 AMPL costs \~0.90917356 USDC #### ElasticSwap Pool balances before rebase: 10000 (0 decay) AMPL / 10000 (0 decay) USDC, 1 AMPL costs 1.0001 (repeating) USDC Pool balances after rebase: 10000 (1000 decay) AMPL / 10000 (0 decay) USDC, 1 AMPL costs 1.0001 (repeating) USDC ### Examples with USDC / AMPL pools (10% negative rebase): #### Uniswap V2 / Sushi Pool balances before rebase: 10000 AMPL / 10000 USDC, 1 AMPL costs 1.0001 (repeating) USDC Pool balances after rebase: 9000 AMPL / 10000 USDC, 1 AMPL costs \~1.11123458 USDC #### ElasticSwap Pool balances before rebase: 10000 (0 decay) AMPL / 10000 (0 decay) USDC, 1 AMPL costs 1.0001 (repeating) USDC Pool balances after rebase: 9000 (0 decay) AMPL / 10000 (1000 decay) USDC, 1 AMPL costs 1,0001111235 USDC With ElasticSwap the decay is settled when the next LP enters. Let's say the LP is willing to enter with 2000 AMPL and 2000 USDC. In the first (10% positive rebase) example, the LP would actually enter with 1000 AMPL and 2000 USDC, resolving the decay. In the second example (10% negative rebase) they would enter with 2000 AMPL and 1000 USDC. When LP tokens are redeemed, the LP receives their share of the entire balances including decay. In the first example, redeeming 10% of the total LP tokens would result in 1100 AMPL and 1000 USDC. In the second, 900 AMPL and 1000 USDC. These redemption amounts would be the same as with Uniswap V2 / Sushi. # 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: ``` ΔRo = sqrt(ΔY * ΔX) where, # sqrt - Stands for the square root of the numbers provided, ex: sqrt(4) = 2 # ΔY - The amount of quoteTokens the liquidity provider wants to provide. # ΔX - The amount of baseTokens the liquidity provider wants to provide. Note: Initially, Ro = 0, hence after creation of the pool, Ro' = ΔRo + Ro => Ro' = ΔRo + 0 (this becomes the Ro for other liquidity events, the dash and delta notation (Ro', ΔX, ΔY) is further explained in the Double Aset entry section) ``` 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: ``` ΔRo = (ΔY/Y) * Ro where, # ΔRo - The amount of tokens the liquidity provider receives. # ΔY - The amount of quoteTokens the liquidity provider wants to provide. # Y - The internal balance of quoteToken. # Ro - The current total supply of the liquidityToken ``` > Note: To understand the usage of Delta(`Δ`) and Dash(`'`) notation, the above scenario initially(prior to Double Asset Entry) was: ``` Y - The internal balance of the quoteToken, Ro - The current total supply of the liquidityToken, ``` > The "change" that the system is introduced to the AMM by the liquidity provider, providing baseToken and quoteToken is given by: ``` ΔY - The amount of quoteTokens the liquidity provider wants to provide. ΔX - The amount of baseTokens the liquidity provider has to provide. Given by ΔX = K / ΔY Note: The vice versa also holds true, If the liquidity provider wanted to provide a specific amount of baseTokens(ΔX), then the amount of quoteTokens(ΔY) to be provided would be given by ΔY = K / ΔX ``` > 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: ``` Y' = Y + ΔY - The (new) internal balance of quoteToken after this liquidity event X' = Y + ΔX - The (new) internal balance of baseToken after this liquidity event Ro' = Ro + ΔRo - The (new) current total of the liquidity tokens Note: Y', X', Ro' become Y, X, Ro respectively for the next following liquidity event(regardless of it being single or double asset entry). ``` The function that does this is `addLiquidity` in [Exchange.sol](https://github.com/elasticdao/elasticswap/blob/develop/src/contracts/Exchange.sol#L87) 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`: ``` ΔRo = (Ro/(1 - γ)) * γ where, # ΔRo - The amount of tokens the liquidity provider receives. # γ = ΔY / ( (Alpha/Omega) + Y' ) # ΔY = α^ / ω - The amount of quoteTokens required to completely offset alphaDecay. ``` When there is `betaDecay`: ``` ΔRo = (Ro/(1 - γ)) * γ where, # ΔRo - The amount of tokens the liquidity provider receives. # γ = ΔX / ( X + (Alpha + ΔX) ) # ΔX = α - X - The amount of baseTokens required to completely offset betaDecay(and by extension alphaDecay). # β^ = ΔX / ω ``` The respective solidity functions can be found at [Exchange.sol](https://github.com/elasticdao/elasticswap/blob/develop/src/contracts/Exchange.sol#L87) 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: ``` ΔRo = ΔRo(SAE) + ΔRo(DAE) where, # ΔRo(SAE) - The liquidity tokens received due to the SingleAssetEntry # ΔRo(SAE) - The liquidity tokens received due to the DoubleAssetEntry ``` > 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: ``` ΔX = α * ΔRo / Ro ΔY = β * ΔRo / Ro where, # ΔRo - The amount of liquidity tokens the liquidity provider wants to exchange # ΔX - The amount of baseToken the liquidity provider receives # ΔY - The amount of quoteTokens the liquidity provider receives # α - The balance of baseToken currently in the exchange # β - The balance of quoteToken currently in the exchange ``` The function that handles this is `removeLiquidity` in [Exchange.sol](https://github.com/elasticdao/elasticswap/blob/develop/src/contracts/Exchange.sol#L87). > 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: ``` Liquidity provider #1 provides 1000000 baseTokens and 1000000 quoteTokens. Therefore, X = 1000000 Alpha = 1000000 Y = 1000000 Beta = 1000000 K = 1000000000000 Omega = 1000000/1000000 = 1 Sigma = 1000000/1000000 = 1 AlphaDecay = 1000000 - 1000000 = 0 BetaDecay = 1000000 - 1000000 = 0 deltaRo = -1000000 (because sqrt(1000000*1000000) = 1000000, Negative sign indicates that it is going out of the system) Ro = 1000000 Liquidity provider #1 has now received 1000000 Ro. ---------------------------------------------------------------------------------------------------------------- Now a participant(Swapper #1)comes along and wants to swap 10000 quote tokens for baseTokens. Swapper #1 receives deltaX baseTokens, where: deltaY = 10000 X' = K / (Y + deltaY - (deltaY*liquidityFee)) (Assuming liquidity fee is 30 Basis points) X' = 1000000000000 /(1000000 + 10000 -(10000*0.003)) = 990128.419656029387 deltaX = 990128.419656029387 - 1000000 = -9871.580343970613 (The negative sign simply indicates that the baseTokens are going to the swapper ) Y' = Y + deltaY = 1000000 + 10000 = 1010000 alpha' = alpha + deltaAlpha = 1000000 + (-9871.580343970613) = 990128.419656029387 ( Note: deltaX = deltaAlpha for swap events) beta' = beta + deltaBeta = 1000000 + 10000 = 1010000 ( Note: deltaY = deltaBeta for swap events) alphaDecay' = alpha' - X' = 990128.419656029387 - 990128.419656029387 = 0 betaDecay' = beta' - Y' = 1010000 - 1010000 = 0 K' = X' * Y' = 990128.419656029387 * 1010000 = 1000029703852.58968 feeAddress(ElasticDAO) recieves: ((deltaY/Y)*(liquidityFee/6)*Ro) = (10000*0.003*1000000)/(6 * 1000000) Therefore, post 1st swap, the state of the AMM is: X = 990128.419656029387 Alpha = 990128.419656029387 Y = 1010000 Beta = 1010000 Omega = 990128.419656029387/1010000 = 0.98032516797626672 Sigma = 990128.419656029387/1010000 = 0.98032516797626672 AlphaDecay = 990128.419656029387 - 990128.419656029387 = 0 BetaDecay = 1010000 - 1010000 = 0 K = X*Y = 990128.419656029387 * 1010000 = 1000029703852.58968 Ro = 1000000 feeAddress(ElasticDAO) recieves: 5 Ro hence total Ro the feeAddress has 5 Ro (Note: Omega is equal to Sigma) ---------------------------------------------------------------------------------------------------------------- Now let's assume a positive rebase occurs such that there are now 25% more `baseTokens`, as a result of which: Alpha = 1.25 * 990128.419656029387 = 1237660.52457003673 X = 990128.419656029387 alphaDecay = alpha - X = 1237660.52457003673 - 990128.4196560293874 = 247532.104914007343 Beta = 1010000 Y = 1010000 K = X*Y = 990128.419656029387 * 1010000 = 1000029703852.58968 betaDecay = beta - Y = 1010000 - 1010000 = 0 Omega = X/Y = 990128.419656029387/1010000 = 0.98032516797626672 Sigma = Alpha/Beta = 1237660.52457003673 / 1010000 = 1.2254064599703334 Ro = 1000000 (Note: Non zero alphaDecay and Omega is no longer equal to Sigma) ---------------------------------------------------------------------------------------------------------------- Now a another participant (Swapper #2) comes along and wants to swap 10000 quote tokens for baseTokens. Swapper #2 receives deltaX baseTokens, where: deltaY = 10000 X' = K / (Y + deltaY - (deltaY*liquidityFee)) (Assuming liquidity fee is 30 Basis points) X' = 1000029703852.58968 / (1010000 + 10000 - (10000*0.003)) = 980450.115054942479 deltaX = 980450.115054942479 - 990128.419656029387 = -9678.304601086908 Y' = Y + deltaY = 1010000 + 10000 = 1020000 alpha' = alpha + deltaAlpha = 1237660.52457003673 + (-9678.304601086908) = 1227982.21996894982 alphaDecay' = alpha' - x' = 1227982.21996894982 - 980450.115054942479 = 247532.104914007341 beta' = 1010000 + 10000 = 1020000 betaDecay' = 1020000 - 1020000 = 0 K' = X' * Y' = 980450.115054942479 * 1020000 = 1000059117356.04133 feeAddress(ElasticDAO) recieves: ((deltaY/Y)*(liquidityFee/6)*Ro): (10000 * 0.003 * 1000000)/(6 * 1010000) Therefore, post 2nd swap, the state of the AMM is: X = 980450.115054942479 Alpha = 1227982.21996894982 Y = 1020000 Beta = 1020000 K = X * Y = 980450.115054942479 * 1020000 = 1000059117356.04133 Omega = 980450.1150549424796 / 1020000 = 0.961225602995041647 Sigma = 1227982.21996894982 / 1020000 = 1.20390413722446061 AlphaDecay = 247532.104914007341 BetaDecay = 0 Ro = 1000000 feeAddress(ElasticDAO) recieves: 4.9504950495049505 Ro, hence total Ro the feeAddress has 4.9504950495049505 + 5 = 9.9504950495049505 Ro (Note: The swap was unaffected by the occurrence of a rebase event prior to the trade(resulting in the presence of non-zero decay)) ------------------------------------------------------------------------------------------------------------------- Now liquidity provider #2 comes along and wants to do a SingleAssetEntry(this is now possible due to the presence of alphaDecay), in this case the amount of quoteTokens required to be supplied to the AMM are deltaY, where: deltaY = alphaDecay / Omega = 247532.104914007341 / 0.961225602995041647 = 257517.178217821776 For which the liquidity tokens issued to liquidity provider #2 (deltaRo) are given by: deltaRo = (Ro/(1 - gamma)) * gamma where Gamma is given by, gamma = deltaY / ( (Alpha/Omega) + Y' ) where Y' = Y + deltaY = 1020000 + 257517.178217821776 = 1277517.17821782178 Therefore, gamma = 257517.178217821776 / ((1227982.21996894982 / 0.961225602995041647 ) + 1277517.17821782178) = 0.100788146965298211 deltaRo = (1000000 / ( 1- 0.100788146965298211) * 0.100788146965298211 = 112084.984895554598 X' = X + deltaX = 980450.115054942479 + 247532.104914007341 = 1227982.21996894982 Y' = Y + deltaY = 1020000 + 257517.178217821776 = 1277517.17821782178 deltaAlpha = 0 alpha' = alpha + deltaAlpha = 1227982.21996894982 + 0 deltaBeta = deltaY = 257517.178217821776 alphaDecay' = alpha' - X' = 1227982.21996894982 - 1227982.21996894982 = 0 betaDecay = 0 beta' = beta + deltaBeta = 1020000 + 257517.178217821776 = 1277517.17821782178 Sigma' = alpha' / beta' = 1227982.21996894982/1277517.17821782178 = 0.961225602995041643 K' = X' * Y' = 1227982.21996894982 * 1277517.17821782178 = 1568768380556.38929 Omega' = X' / Y' = 1227982.21996894982/1277517.17821782178 = 0.961225602995041643 Ro' = Ro + deltaRo = 1000000 + 112084.984895554598 = 1112084.9848955546 Therefore at the end of the SingleAssetEntry the state of the AMM is: X = 1227982.21996894982 Y = 1277517.17821782178 K = 1568768380556.38929 Alpha = 1227982.21996894982 Beta = 1277517.17821782178 Omega = 0.961225602995041643 Sigma = 0.961225602995041643 alphaDecay = 0 betaDecay = 0 Ro = 1112084.9848955546 (Note: Omega = Sigma, which is expected behaviour) ------------------------------------------------------------------------------------------------------------------- Now, liquidity provider #2 decides to withdraw all of his liquidity, he receives a certain amount of baseTokens and quoteTokens, given by: deltaX = alpha * deltaRo / Ro deltaY = beta * deltaRo / Ro Where, deltaX - The amount of baseTokens received deltaY - The amount of quoteTokens received deltaRo - The number of liquidity tokens to be redeemed - here it is all that he had initially received Hence we get, deltaRo = (-1) * 112084.984895554598 = -112084.984895554598 deltaX = 1227982.21996894982 * (-112084.984895554598) / 1112084.984895554598 = -123766.05245700367 deltaY = 1277517.17821782178 * (-112084.984895554598) / 1112084.984895554598 = -128758.589108910888 (Note: (-1) is because the deltaRo is being redeemed for underlying quantities of deltaX and deltaY) deltaX = deltaAlpha deltaY = deltaBeta X' = X + deltaX = 1227982.21996894982 + (-123766.05245700367) = 1104216.16751194615 Y' = Y + deltaY = 1277517.17821782178 + (-128758.589108910888) = 1148758.58910891089 K' = X'* Y' = 1104216.16751194615 * 1148758.58910891089 = 1268477806662.27207 Ro' = Ro + deltaRo = 1112084.9848955546 + (-112084.984895554598) = 1000000 alpha' = alpha + deltaAlpha = 1227982.21996894982 + (-123766.05245700367) = 1104216.16751194615 beta' = beta + deltaBeta = 1277517.17821782178 + (-128758.589108910888) = 1148758.58910891089 Sigma' = alpha'/ beta' = 1104216.16751194615 / 1148758.58910891089 = 0.961225602995041645 Omega' = X'/Y' = 1104216.16751194615 / 1148758.58910891089 = 0.961225602995041645 alphaDecay' = alpha' - X' = 1104216.16751194615 - 1104216.16751194615 = 0 betaDecay = beta' - Y' = 1148758.58910891089 - 1148758.58910891089 = 0 //(Note: Omega' = Omega = Sigma' = Sigma , this is expected behaviour) Therefore at the end of the redemption of liquidity tokens event the state of the AMM is: X = 1104216.16751194615 Y = 1148758.58910891089 K = 1268477806662.27207 alpha = 1104216.16751194615 beta = 1148758.58910891089 Omega = 0.961225602995041645 Sigma = 0.961225602995041645 alphaDecay = 0 betaDecay = 0 Ro = 1000000 And LP #2 has received, baseTokens = 123766.05245700367 quoteTokens = 128758.589108910888 ------------------------------------------------------------------------------------------------------------------- Now, liquidity provider #1 decides to withdraw all of his liquidity, he receives a certain amount of baseTokens and quoteTokens, given by: deltaX = alpha * deltaRo / Ro deltaY = beta * deltaRo / Ro Where, deltaX - The amount of baseTokens received deltaY - The amount of quoteTokens received deltaRo - The number of liquidity tokens to be redeemed - here it is all that he had initially received Hence we get, deltaRo = (-1) * 1000000 = -1000000 deltaX = 1104216.16751194615 * (-1000000)/1000000 = -1104216.16751194615 deltaY = 1148758.58910891089 * (-1000000)/1000000 = -1148758.58910891089 (Note: (-1) is because the deltaRo is being redeemed for underlying quantities of deltaX and deltaY) Hence LP#1 receives 1104216.16751194615 amount of base tokens and 1148758.58910891089 amount of quoteTokens, he has benefitted from the trades(accrual of fees) and the rebase event. LP#1 initial v final state: baseTokens -> final - initial = 1104216.16751194615 - 1000000 = 104216.16751194615 quoteTokens -> final - initial = 1148758.58910891089 - 1000000 = 148758.58910891089 ``` Example 2: Rebase down -> SAE + DAE -> exit ``` LP #1 sets the pool with 10k baseTokens, 10k quoteToken, hence 10k Ro for LP1 Omega = 1 Rebase down of 5k happens X = 10,000 Alpha = 5000 Y = 10,000 Beta = 10,000 Ro = 10,000 (all LP#1 owned ) LP#2 comes along and wants to do SAE+DAE baseTokenAmountProvided = ((iOmega)*5000 + 10000 = 15,000 quoteTokenAmount provided = 10k LP token LP#2 recieves: For SAE: (5000 baseTokens) -> 3333 LP tokens At this stage: X, Y, Alpha, Beta = 10k Now DAE (10k basetokens + 10k quoteTokens) => (10000/10000) * 13333 = 13333 LP tokens Hence, the LP#2 gets = 3333 + 13333 = 16666 tokens State of the pool: X: 20k Alpha: 20k Y: 20k Beta 20k LP outstanding = 26666 (10,000 -> LP#1, 16666 -> LP#2) LP#1 exits their LP position: Basetokens recieved = (10000/26666) * 20000 = ~7500.18750468761719 (had put in 10k) quoteToken recieved = (10000/26666) * 20000 = ~7500.18750468761719 (had put in 10k) State of the pool: X, Alpha, Beta, Y: ~12500 LP#2 exits their LP position: BaseToken receieved = 16666 / 16666 * 12500 = ~12500 (had put in 15k) QuoteToken receieved = 16666 / 16666 * 12500 = ~12500 (had put in 10k) ``` # Ampleforth Partnership ElasticSwap started with an $AMPL pool at the launch of the platform. Given that Ampleforth founded this space, we can think of no better partnership from day 1. As of now, there are 3 Ampleforth pools being supported by ElasticSwap including $AMPL-USDC on Mainnet, $AMPL-USDC.e on Avalanche, and $AMPL-TIC on Avalanche. We are also having conversations with several other elastic supply token projects and will be focusing heavily on onboarding these projects once the platform is launched and proven. Feel free to join the Ampleforth [discord](https://discord.com/invite/mptQ49m) and make yourselves known. Cross-community activity is the primary way you can help to make ElasticSwap a success. **We are excited about partnerships with any and all protocols that could utilize ElasticSwap, so** [**please get in touch**](https://discord.gg/elasticswap) **with the team if you want to discuss working with us!** # ShapeShift Partnership ElasticSwap is now supporting $FOXy-FOX on Mainnet With the launch of ElasticSwap on Mainnet, ElasticSwap was thrilled to announce a strategic partnerhsip with the ShapeShift DAO via their sub-DAO, vFOX. vFOX is taking a strategic position in ElasticSwap and for that ElasticSwap is getting USDC earmarked for hiring Developer help, and treasury diversification in the form of FOX Tokens. Furthermore, ElasticSwap will be the AMM of choice for a newly launched $FOX-FOXy pair, providing swap capabilities for the new FOXy Token (a yield-bearing elastic supply token). ShapeShift has seeded that pool with $1M in liquidity and is live for trading right now\.. FOXy is the first yield bearing elastic supply token launched by the ShapeShift community, but the opportunity for cooperation on future innovative token pairs and innovation in the broader elastic supply space are endless. Not to mention, ElasticSwap will be fully integrating with the [ShapeShift trading platform](https://shapeshift.com/). # Staking {% hint style="info" %} The individual emissions weight of each contract will be subject to DAO governance and is likely to change as the ElasticSwap product launches and markets mature. {% endhint %} Emissions began after deployment of the staking contracts and public Sushi pool. The following public staking pools were deployed with the public market: $TIC Single Staking (25% of public emissions) $TIC/$USDC SLP Staking (75% of public emissions) ### Changelog #### 2022-05-11 *Avalanche: $TIC:* 25%, *$TIC/$USDC.e ELP:* 12.5%, *$AMPL/$TIC ELP:* 12.5%, *$AMPL/$USDC.e ELP:* 12.5%\ Ethereum: $TIC/USDC ELP: 12.5%, $AMPL/USDC ELP: 12.5%, $FOXy/$FOX: 12.5% #### 2022-04-21 *$TIC:* 62.50%, *$TIC/$USDC ELP:* 12.5%, *$AMPL/$TIC ELP:* 12.5%, *$AMPL/$USDC ELP:* 12.5% #### 2022-03-24 *$TIC:* 40%, *$TIC/$USDC SLP:* 60% # New Staking Pools TL;DR - Yield farmers' assets are unlocked, but staking for longer periods of time results in higher yield. Everyone's earnings are tied to collected protocol fees. ## ELP Staking Pools The ElasticSwap LP (ELP) Staking Pools work like a hybrid between a -ve and -x staking contract, with the added benefit of also growing protocol-owned liquidity. They are designed to allow stakers to accrue $TIC, the native token of the ElasticSwap protocol, every second, while receiving rewards in the form of an $ELP position as the platform accrues fees. ### How does it work? When eligible tokens are staked in the Staking Pools, they are not locked. Rewards start to accrue instantly, but in an unrealized way, meaning stakers are entitled to a reward distribution as fees are collected by the treasury. Those staking rewards come in the form of $TIC-$USDC.e $ELP tokens. ElasticSwap charges a 50 bps fee as swaps occur (25 bps to LPs, 20bps to public stakers, and 5 bps for protocol operations). The public staker fees (the 20 bps due to the stakers) are converted by the treasury into $USDC.e, and then deposited into the Staking Pools contract, creating $ELP which represents a liquidity position in the $TIC-USDC.e pool. Stakers can claim their $ELP tokens and then restake them, or they can exit the $ELP position for the underlying $TIC and $USDC.e tokens. ![The elasTIC way](/files/lxpSSzdKkEfrs6V1WRos) ### Why did we choose this model? This yield farming approach is designed to align the incentives of staking liquidity providers and the protocol itself. By tying staking reward distribution to fee generation, we ensure that the community is rewarded for promoting the platform, double the rewards the staker receives, and eliminate the incentive to sell their rewards to enter a $TIC/$USDC.e LP position. Stakers can also choose to take profit in the form of $USDC.e without creating $TIC sell pressure. ### Why not -ve? With the -ve model, stakers are rewarded based on how long they are willing to lock their tokens. This prevents stakers from withdrawing and liquidating their original deposit in an emergency situation. It also encourages the forming of cartels who gather the token to be staked, stake it receiving the veToken in return, and then wrap that veToken to make it liquid again, defeating the entire purpose of the locking period. Some newer iterations of the -ve token model include losing all -ve rewards if you unstake early, applying boosted APY to certain staking farms, and providing additional rewards the more -ve tokens you accumulate. Innovation around locking up tokens will likely continue, as projects look for creative ways to keep people locked into their ecosystem. ### What kind of APR can I expect? APR is the wrong metric to look at, but it will be effectively double what it was in the previous contracts. Instead, unrealized and claimable rewards should be considered. Unrealized rewards are $TIC waiting for protocol fees to be generated. These fees are realized when an LP in any ElasticSwap exchange exits their position. The treasury regularly pairs collected fees with unrealized $TIC, minting new claimable $ELP rewards. ### What happens if I exit the position before the protocol generates fees? There is no penalty for exiting the staking pool before the protocol generates fees, however, the staker will forfeit any unrealized rewards. Those rewards are then transferred to the DAO to be used as $TIC/$USDC.e LP in the future, guaranteeing protocol-owned liquidity, which benefits all token holders and the protocol itself. ### How long will I have to stake to receive all of my rewards? The duration between when a staker stakes their tokens and can withdraw their rewards is dependent on how quickly the protocol is generating fees. The more fees ElasticSwap generates, the faster a staker will be able to claim their rewards. Rewarded $ELP will be claimable in a pro-rata fashion by stakers who had unclaimed reward balance at the time the fees were deposited. #### For example: A staker has 40 $TIC of unrealized rewards, and there are 4000 $TIC total unrealized rewards in the staking contract. The staker would be able to claim 40/4000 (or 1%) of any $ELP rewards generated at this exact moment. ### How will rewards be tracked and calculated? Unrealized $TIC rewards are accrued every second in the staking contracts. Stakers begin to earn unrealized rewards instantly as soon as they deposit eligible tokens. If they deposit more, the rewards accrued per second increases. The total rewards generated by all staking contracts can be found [here](https://docs.elasticswap.org/readme/token-emissions#changelog). Claimable rewards are generated when the treasury deposits USDC.e into the staking pools contract. Due to the complexity of on-chain calculations, the treasury also generates a merkle tree, allowing for these rewards to be claimed. The full trees will be available to be inspected by the public on IPFS at any time. As it is updated, a new tree will be published and a new merkle root will be added to the staking pools contract. This hybrid solution will allow full transparency while also ensuring that gas costs remain reasonable. #### Example: At time t=0, we have 10 stakers who have 10 unclaimed $TIC each. For the sake of this example, they are all of equal stake size. At time t=1, we generate 1000 $USDC in fees and the are deposited into the staking pools contract. Assuming 1 $TIC = 10 $USDC, 100 $TIC are minted and subtracted from the unrealized balances of each staker. $ELP is minted, the merkle tree is updated, and each staker is now able to claim $ELP worth 10 TIC and 100 USDC. At time t=2, a new whale staker comes along, and doubles the amount of tokens staked. At time t=3, whale staker 1 now has as much unclaimed $TIC as all of the other stakers combined, but is not able to claim any of the $ELP minted at t=1. ### How are staking rewards distributed when they become claimable? Step 1) Convert all fees on all chains to USDC to get a total amount of USDC. Step 2) Look at the total unrealized $TIC across all chains to get a percentage of USDC due to each chain. Step 3) Bridge the correct amount of USDC to the correct chains. Step 4) Deposit USDC into the staking contracts, minting ELP. Step 5) Everyone can withdraw a percentage of the ELP created based on their percentage of the unrealized TIC. # Treasury Management The DAO treasury will hold half of its pre-mined $TIC and 25% of its $TIC emissions in reserve for bug bounty payments. ETH that was raised during the pre-seed has been allocated for operational use (audits, services, LPing, etc.) Ethereum Treasury Multisig: Ethereum Fee Multisig: Avalanche Treasury Multisig: Avalanche Fee Multisig: [https://gnosis-safe.io/app/avax:0x8AA16c21a8b529a655711c62BdEf27456b1E8Fe3](https://gnosis-safe.io/app/avax:0x8AA16c21a8b529a655711c62BdEf27456b1E8Fe3/balances) Avalanche Cross Chain Multisig: [https://gnosis-safe.io/app/avax:0x1E0c87fc6ee83f775436f58D9B3E74367a484C42](https://gnosis-safe.io/app/avax:0x1E0c87fc6ee83f775436f58D9B3E74367a484C42/balances) Avalanche Bug Bounty Multisig: [https://gnosis-safe.io/app/avax:0xF330C11D23787577b404341646626dFd5BfdC622](https://gnosis-safe.io/app/avax:0xF330C11D23787577b404341646626dFd5BfdC622/balances) Avalanche Rebalancing Wallet: # Avalanche A quick how-to guide To bridge assets from another network to Avalanche, we suggest visiting this site that was put together by the team over at Avalanche Setting up the Avalanche network on your Metamask or Frame wallet is very easy. You can add the Avalanche network by visiting [chainlist](https://chainlist.org/), connecting your wallet, and adding Avalance Mainnet C-Chain. If you prefer to interact with native AVAX tokens rather than bridging assets, you can purchase AVAX on most centralized exchanges and transfer them to your wallet. So that you are sure you send them to the correct address, we advise adding Avalanche to your preferred wallet interface before transferring the tokens off exchange. # Timeline ![](/files/7bKaCyrTbZ1rw38FHmsA) # Resources Discord: Twitter: [@elasticswap ](https://twitter.com/elasticswap) Website: [ elasticswap.org ](https://elasticswap.org) Audit Report: GitHub: [ https://github.com/ElasticSwap](https://github.com/ElasticSwap) # Tutorials **Buying $TIC on ElasticSwap using 1inch** {% embed url="" %} **Buying $AMPL on ElasticSwap using 1inch** {% embed url="" %} **Opening a new $TIC-USDC.e ELP position on ElasticSwap** {% embed url="" %} **Buying $TIC on SushiSwap** {% embed url="" %} {% hint style="info" %} NOTE: The Sushi UI displays USDC.e as USDC. {% endhint %} **SushiSwap LP Staking Tutorial -** *This pool is not longer generating rewards* {% embed url="" %} {% hint style="info" %} NOTE: The Sushi UI displays USDC.e as USDC. {% endhint %} **How to Pre-seed Tutorial** {% embed url="" %} **How to add Avalanche C-Chain to Metamask via chainlist.org** {% embed url="" %} # Deployed Addresses ## Avalanche #### TIC and Staking * [StakingPools](https://snowtrace.io/address/0x416494bD4FbEe227313b76a07A1e859928D7bA47) (legacy) - 0x416494bD4FbEe227313b76a07A1e859928D7bA47 * [StakingPools](https://snowtrace.io/address/0x9B7B70F65eA5266EBd0a0F8435BE832d39e71280) (merkle) - 0x9B7B70F65eA5266EBd0a0F8435BE832d39e71280 * [TIC Token](https://snowtrace.io/address/0x75739a693459f33B1FBcC02099eea3eBCF150cBe) - 0x75739a693459f33B1FBcC02099eea3eBCF150cBe * [TIME Token DAO](https://snowtrace.io/address/0xBA41c2A2744e3749ab3E76FdFe6FCa5875D97660) - 0xBA41c2A2744e3749ab3E76FdFe6FCa5875D97660 * [TIME Token Team](https://snowtrace.io/address/0x31fa86c83aE739220CE4fa93391BB321cC77670E) - 0x31fa86c83aE739220CE4fa93391BB321cC77670E * [TIME Token PreSeed](https://snowtrace.io/address/0x65C8CB3AFF7021c9A1579787e29B1c3D24c5cA59) - 0x65C8CB3AFF7021c9A1579787e29B1c3D24c5cA59 #### Protocol * [Exchange Factory](https://snowtrace.io/address/0x8B3D780Db8842593d8b61632A2F76c4D4f31D7C3) - 0x8B3D780Db8842593d8b61632A2F76c4D4f31D7C3 * [AMPL/USDC.e Exchange](https://snowtrace.io/address/0x1b80e501e397dbf8b7d86d06bd42679d61cac756) - 0x1b80e501e397dbf8b7d86d06bd42679d61cac756 * [TIC/USDC.e Exchange](https://snowtrace.io/address/0x4ae1da57f2d6b2e9a23d07e264aa2b3bbcaed19a) - 0x4ae1da57f2d6b2e9a23d07e264aa2b3bbcaed19a * [AMPL/TIC Exchange](https://snowtrace.io/address/0xa0c5aa50ce3cc69b1c478d8235597bc0c51dfdab) - 0xa0c5aa50ce3cc69b1c478d8235597bc0c51dfdab ## Ethereum * [StakingPools](https://etherscan.io/address/0xc8d00c0a8d2ec4ec538a82461a7a7f5c3ac99d95) - 0xc8D00C0a8d2ec4EC538a82461A7a7F5C3aC99d95 * [TIC Token](https://etherscan.io/address/0x2163383c1f4e74fe36c50e6154c7f18d9fd06d6f) - 0x2163383C1F4E74fE36c50E6154C7F18d9Fd06d6f #### Protocol * [Exchange Factory](https://etherscan.io/address/0x8b3d780db8842593d8b61632a2f76c4d4f31d7c3) - 0x8B3D780Db8842593d8b61632A2F76c4D4f31D7C3 * [TIC/USDC Exchange](https://etherscan.io/address/0x79274bf95e05f0e858ab78411f3ebe85909e4f76)- 0x79274BF95e05f0e858ab78411f3eBe85909E4F76 * [AMPL/USDC Exchange](https://etherscan.io/address/0xa0c5aa50ce3cc69b1c478d8235597bc0c51dfdab)- 0xa0c5aA50cE3cc69b1c478d8235597bC0c51DfDAb * [FOXy/FOX Exchange](https://etherscan.io/token/0x1b80e501e397dbf8b7d86d06bd42679d61cac756) - 0x1b80e501e397dBf8B7d86d06bD42679d61CAC756 # ElasticSwap Token Suggestions If you have any tokens you think we should support, you can now add them to these lists via PR. {% embed url="" %} You can add tokens from any EVM network. The combination of an elastic supply token and a stablecoin on an EVM network will be a reason for us to launch on that network ASAP. # Software ElasticSwap has open sourced it's SDK and Solidity contracts. In the following pages you will find documentation for this code. Our Github can be viewed at # @elasticswap/elasticswap {% embed url="" %} NPMJS publish version, includes addresses of deployment locations {% endembed %} {% embed url="" %} Github Source {% endembed %} {% embed url="" %} Audit Report {% endembed %} # @elasticswap/sdk JSDoc generated documentation coming soon {% embed url="" %} NPMJS published location {% endembed %} {% embed url="" %} Github Source {% endembed %} # Developer Collaboration On this page, we want to document our collaboration workflow within the ElasticSwap organization. We are a small, distributed team and don't rely on daily standups or constant meetings; nonetheless, it's crucial to know what fellow teammates are working on and what's next on the priority list. We use a form of agile project management, though some areas might diverge from its rules. If you want to learn more about agile, follow this link: {% embed url="" %} Agile Project Management {% endembed %} # Scoping & Breakdowns ## Why Are We Doing This? * Breaking down complex topics into epics and user stories helps us tackle work in the proper order and avoid losing an overview or goal. Additionally, breaking down bigger tasks early on makes writing and reviewing code more manageable. * Ensuring transparency by enabling all team members to see what everyone is working on, which issues are blocking/blocked, and how much workload we currently have. * Creating user stories helps us build features from the user's perspective and ensures that we tailor the experience toward them. It's an easy way to cover all bases and think about edge cases before starting the implementation. ## Getting Started Before working on a task, we first need to document it in GitHub. This also means breaking down complex topics into smaller subtasks with dependencies between each other. As a rule of thumb, if you need more than one day to work on an issue or cover many different aspects (e.g., creating a design, writing front-end code, and updating the SDK), it should be broken up into smaller tasks. The main advantage here is smaller PRs, making for easier code reviews. Nobody wants to review 5,000 line changes in a single PR, as this can become cumbersome quickly and lead to overseen bugs eventually landing in production. So before you start writing code, think about the task as a whole and how you could potentially break it up into smaller subtasks. Then, please create a new issue in the appropriate repository for each task and link them to make dependencies clear. If a task is small enough or it doesn't make sense to break it up, then create just one issue. The next section will cover best practices for creating new issues and epics. # Issues We offer different templates for these issue types when creating a new issue. Below is an explanation. ## Issue Types We have three types of issues: epics, user stories, and bug reports. Generally speaking, whenever you create a new issue, it should fit in one of these categories. However, it's also okay to diverge from the structure if it doesn't fit. ### Epics An epic is a collection of user stories used for more complex features or tasks. An epic should contain a user story describing what it is about, e.g., building a new page for the app or improving the SDK to be more performant. Below the user story, you should list all dependencies. These are other tasks or epics inside the same or another repository required for the epic to be considered done. Using GitHub's To-Do list feature, it's easy to tick off any done task. ### User Stories A user story can be standalone or part of an epic. Either way, its structure is always the same: write a user story at the beginning, explaining what should be built and how it affects the user. Write a user story from a user's perspective and mention the user's role (developer, trader, liquidity provider, etc.). Try to be as specific as possible but keep the language simple: > As a trader, I want to swap elastic tokens while being aware of token decay after a rebase so that I can make the right decisions. > As a developer, I want to have the same GraphQL API endpoints as Uniswap offers so that I can compare the total volume of a pool. User stories are accompanied by a checklist of acceptance criteria, which is easy to do, thanks to GitHub's To-Do list feature. Below the user story, list all tasks that need to be done to achieve the stated goal. If you feel like too many items are on the acceptance criteria list, breaking up the task into more issues might make sense. #### Dependencies Most of the time, issues depend on each other. Say you want to implement a new page on the app: 1. First, a design needs to be created 2. Eventually, the SDK or a back end must deliver some data for you to consume 3. With the above two done, you can start working on the front end. It's essential to make it transparent that issue 3 depends on 1 and 2, but 1 and 2 can both be started independently. Inside issue 3, write > requires #1 requires #2 to make that clear. Inside issues 1 and 2, write > required by #3 ### Bug Reports Bug reports usually don't contain user stories (though they can), but it's still important to provide as many details as possible. A bad example of a bug report would be: > Pages sometimes don't load. With such little information, it's hard to debug what's going on. Usually, the bug reporter has more information on hand, so it's crucial to be as descriptive as possible. We have a template for bug reports, asking for detailed information such as a description, steps to reproduce, expected behavior, and screenshots to show the bug even better. Whenever possible, try to be as specific as possible. ## Labels We use labels to categorize issues further and make it more obvious whether an issue is a user story, bug report, or epic. So please make sure to give your issues the appropriate labels. ### Categories * **epic:** a collection of user stories or issues towards a more extensive feature or change. Examples are a new analytics page, adding a new token, or migrating the app to another framework. * **enhancement:** a user story or code change that improves the product. Examples are design changes, new functionality, or performance improvements. * **bug:** a bug that a user or we have discovered. Usually, bug tickets shouldn't be too big, and if they are, there might be the need for fundamental refactoring, which leads to an epic. Examples are incorrect responsive styling, a button not doing anything upon interaction, or the back button not working. * **documentation:** improvements or additions to our documentation. Examples are changes to markdown docs for developers (like style guides) or text changes on the website explaining the product. ### Progress * **backlog:** use this label whenever you create a new issue and don't immediately start working on it. * **in progress:** add this label while actively working on it. If you take a break for a couple of days, you can still leave the label, but make sure to remove it once those days turn into weeks. * **waiting:** an issue that depends on another issue and can't be started unless all dependencies are resolved. This will happen mostly when working with epics. * **needs review:** this issue is done and awaits a code review. Remove the label once the code review has been conducted and the PR is merged or closed. Feel free to create more labels if the existing ones don't fit your case. # Project Board We utilize a GitHub [project board](https://github.com/orgs/ElasticSwap/projects/1) to better visualize our current workload and open issues. Therefore, whenever you create a new issue, make sure to link it to this board. The board is semi-automated, meaning that issues are moved into the correct columns whenever certain criteria match the conditions. * **Backlog:** an issue that has been newly opened or re-opened. * **Done:** an issue that has been closed, either manually or through a PR. Unfortunately, we can't yet automate the board through GitHub labels, which means that we sometimes have to move issues manually. Remember to move issues into the correct column whenever you change their status, e.g., from *backlog* to *in progress*, once you start working on them. The project board bundles issues from the following repositories: * [elasticswap-sdk](https://github.com/ElasticSwap/elasticswap-sdk) * [elasticswap-app](https://github.com/ElasticSwap/elasticswap-app) * [elasticswap-avalanche](https://github.com/ElasticSwap/elasticswap-avalanche) # Branches & Commits ## Branch Rules Create a new branch whenever you start working on something. **Don't commit to `main` or `development`, as these branches are used for the production and staging environments and need to be stable.** Branch names are up to you, but we recommend including the issue number and a brief title. You can also prefix branch names with `feature/`, `fix/`, or other categories. ``` 123-fix-router-navigation fix/router-navigation ``` ### The `main` Branch The `main` branch reflects our currently deployed production state. Most PRs should never be merged directly into `main`, but rather `development`. We will create a new PR to merge the delta between staging and production regularly. ### The `development` Branch Once you finish a task and create a PR for it, it should merge into development, the equivalent of a staging environment. Don't merge work that isn't done yet. Instead, if more PRs are about to follow, combine them into a feature branch. ### Feature Branches Working on more significant issues means that a couple of PRs need to be merged first before releasing the feature to development. That's what you can use feature branches for. Please prefix feature branches with `feature/` to make it transparent, e.g.: ``` feature/add-analytics-page ``` ## Commits We use [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/#summary) across all repositories. This means that our commit messages have a certain structure: ``` [optional scope]: [optional body] [optional footer(s)] ``` The commit type can include the following: * **feat:** a new feature is introduced with the changes * **fix:** a bug fix has occurred * **chore:** changes that do not relate to a fix or feature and don't modify src or test files (for example, updating dependencies) * **refactor:** refactored code that neither fixes a bug nor adds a feature * **docs:** updates to documentation such as a README or other markdown files * **style:** changes that do not affect the meaning of the code, likely related to code formatting such as white space, missing semi-colons, and so on * **test:** including new or correcting previous tests * **perf:** performance improvements * **ci:** continuous integration-related * **build:** changes that affect the build system or external dependencies * **revert:** reverts a previous commit The commit-type subject line should be lowercase with a character limit to encourage succinct descriptions. The optional commit body should be used to provide further detail that cannot fit within the character limitations of the subject line description. Below is an example of a conventional commit: ``` fix: remove duplicate entry in router This fixes the problem of the navigation not working properly and instead putting the new page at the bottom. Closes #123 ``` # Pull Requests As a rule of thumb, every PR should relate to an issue. Opening PRs without issues should be the absolute exception. ## Creating a New PR When creating a new PR, make sure to follow these rules: * Provide a descriptive **title**, like "*Update homepage design"*. Don't write something like "*linting issues*" as it's unclear what this PR will change. * Connect the PR to an **issue**, either by mentioning it in the PR's description (*closes #123*) or via GitHub's UI (under the Development section in the right sidebar). The goal is to have an issue closed automatically once the PR is merged. * Provide a brief **description** of what this PR tries to achieve. You don't have to be too explicit since the linked issue will contain user stories and descriptions. Instead, focus on how you achieved the changes, which steps you took, and what needs to be considered for review. * Assign one or more **reviewers**. A PR should only be merged if at least one other team member approves the changes. If you need more reviewers, add them to the PR. * If the PR is still incomplete and you plan to continue making changes, open it as a **draft** and mark it as ready for review once you're done. ## Closing a PR Once a PR has been reviewed and approved, feel free to merge it. Remember to delete the branch if it's no longer needed. # Legal & Disclaimers By accessing any website related to ElasticSwap, you are agreeing to these terms. ***TL;DR: if you use the Interface you state that you (a) are at least 18; (b) don’t break any laws of your jurisdiction by using the Interface; (c) are not located, established or registered in any of the jurisdictions enlisted below titled “Prohibited Localities”.*** ### General You may not use the Interface if you are otherwise barred from using the Interface under applicable law. ### Legality You are solely responsible for adhering to all laws and regulations applicable to you and your use or access to the Interface. Your use of the Interface is prohibited by and otherwise violate or facilitate the violation of any applicable laws or regulations, or contribute to or facilitate any illegal activity. By using or accessing the Interface, you represent to us that you are not subject to the Sanction Lists and you are not a Restricted Person, as defined below. “Sanction Lists” means any sanctions designations listed on economic/trade embargo lists and/or specially designated persons/blocked persons lists published by the international organisations, as well as any state and governmental authorities of any jurisdiction, including, but not limited to the lists of United Nations, European Union and its Member States, United States and United Kingdom sanctions lists. You are not permitted to access or use our Interface in any jurisdiction or country if it would be contrary to the law or regulation of that jurisdiction or if it would subject us to the laws of, or any registration requirement with, such jurisdiction. We reserve the right to limit the availability of our Interface to any person, geographic area, or jurisdiction, at any time and at our sole and absolute discretion. ### Prohibited Localities ElasticSwap does not interact with digital wallets located in, established in, or a resident of Myanmar (Burma), Cote D'Ivoire (Ivory Coast), Cuba, Crimea and Sevastopol, Democratic Republic of Congo, Iran, Iraq, Libya, Mali, Nicaragua, Democratic People’s Republic of Korea (North Korea), Somalia, Sudan, Syria, Yemen, Zimbabwe or any other state, country or region that is included in the Sanction Lists. ### Restricted Persons ElasticSwap does not interact with digital wallets, which have been previously classified or otherwise identified by international organizations or any state and governmental authorities of any jurisdiction, as belonging or affiliated with the persons specially designated or otherwise included in the Sanction Lists (“Restricted Persons”). For the purposes of these Terms, Restricted Persons shall also include all persons or entities who reside in, are citizens of, are incorporated in, or have a registered office in the Prohibited Localities. ### [Further Disclaimers](https://termify.io/disclaimer/1659827824)