ARC-10: Scale Amplification for the bLUNA-LUNA Pool

[tatyana]

References

SoK: Decentralized Exchanges (DEX) with Automated Market Maker (AMM) Protocols

https://alvarofeito.com/articles/curve/#Making-a-Curve-trade

A Parameter Research [Demo and Code]

2003.10001.pdf

Summary

In this post, we propose a methodology for determining the optimal value of the amplification parameter that is used in Astroport’s stableswap pools.

Based on this methodology we propose to increase the amplification parameter for the bLUNA/LUNA pool from 10 to 30.

Abstract

The Amplification coefficient (A) is a hyperparameter of the stableswap formula that defines the tradeoff between constant sum and constant product functions. In this way, the stableswap formula tries to achieve a compromise between low slippage and a balanced pool.

In Astroport, the A parameter is defined by the pool creators, and can be changed through a governance vote. Here we propose a methodology to determine an optimal value for the A parameter based on historical swap transactions, the corresponding token prices, and their effect on pool balances.

Motivation

The stableswap formula used in the Astroport is a combination of constant sum and constant-product functions:

where x, y are the token amounts, C is the total number of tokens when they have an equal price and A is the amplification parameter that establishes the trade-off between the two functions.

When A→inf, the stableswap formula is a constant-sum one with constant exchange rate equal to 1. When A → 0, the stableswap formula boils down to a constant-product one.

The exchange rate of the pair of tokens can be defined as a gradient of the stableswap formula or, in the limit of small trades, the derivative:

The constant sum (linear-invariant) function implies no slippage but can lead to running out of tokens. The product invariant function leads to greater slippage, but makes it expensive to bring the pool out of balance. Lastly, the curve allows the exchange rate to deviate from 1 to reflect supply-demand dynamics while simultaneously keeping the slippage low.

In that way the curve tries to achieve a balance between low slippage and a balanced pool. For that to be the case, though, an adequate amplification parameter needs to be determined for the pool. In the next section we propose a methodology for doing this that intends to promote the aforementioned balance for stableswap pools within Astroport.

Specification

The price in AMM-based pools usually fluctuates around the fair market price. If the price in the pool differs significantly from the market price, arbitrage opportunities arise that in an efficient market are quickly discovered and eliminated by market participants.

Therefore, it is reasonable to assume that whatever parameter A is set, the price in the pool is likely to tend towards its average market value.

Since the price in an AMM-based pool can be calculated as the tangent to the curve at a given point, for a given market price and A parameter we can determine which point of the curve it corresponds to using the stableswap formula and its derivative

Specifically, for bLUNA/LUNA the average market price is about 0.98. The figure below shows, for different values of A, the pool balance (x, y) that correspond to that average market price. As can be seen, the higher the A, the more unbalanced the pool is at the 0.98 price.

As was mentioned before, the A parameter should be set to achieve a balance between low slippage and a balanced pool. The previous figure showed that the lower the A, the more balanced the pool. However, the lower the A the more slippage traders will experience, as will be shown in the analysis below.

Using historical data for the bLUNA/LUNA pool on Terraswap, we calculate, for different values of A, the swap amounts required under a stableswap pool that would achieve the same prices as in the constant product Terraswap pool. The following figure summarizes the results and basically shows that, the higher the A, the lower the slippage or, in other words, the larger the trade size required to achieve the same price levels as in the constant product Terraswap pool.

Lastly, the pool balance was calculated over the time as follows:

According to this formula the perfect balance is 1 and complete imbalance (all coins held in one token) is 0.

The pool balance under different A is provided in the figure below.

The relationship between the average and the minimum pool balances and the A parameter is shown in the figure below.

The above analysis further confirms that increases in A can lead to high pool imbalances.

Thus, to achieve the right balance between low slippage and balanced pools we propose to set the parameter A at the level that corresponds to a given average and minimum balance in the pool.

Particularly for the bLUNA/LUNA pool we consider an acceptable average balance to be 80% (which corresponds to minimum balance of 60%), which leads to an amplification coefficient of 30.

Proposed Code

A Jupyter notebook is provided with the calculations mentioned above.

Test Cases

None, as there is no new smart contract code to add.

Security Considerations

The methodology proposed above should be reviewed by the community for several weeks before the bLUNA-LUNA amplification can be scaled.

Licensing

GNU General Public License v3.0

[TopHatOnURHead]

I like this a lot. As of late, this pool has been quite out of balance but only a couple days ago did it finally rebalance to be closer to 1:1. Since the bLuna-Luna pool resembles a constant sum pool atm, the pool ratio more closely mirrors the tastes of the market yet the bLuna/Luna price ratio seemingly never changed significantly. In the bLuna-Luna pool’s current state, the arb opportunity would eventually come but how imbalanced would the pool have to be for this to happen?

Increasing slippage a bit while providing arb opportunities for rebalancing would be good, imo.

[tatyana]

Thanks for your comment. The higher the parameter A, the closer we are to a constant sum (that corresponds to zero slippage). Increasing A reduces slippage, thereby attracting market participants. However, as the analysis shows, an increase in the parameter can lead the pool into imbalance. The higher A, the more unbalanced the pool can be due to the increase in transaction sizes. We have limited A so that at sufficiently low slippage, the average and minimum balance of the pool remains within acceptable values.

Thus, answering your question, my understanding is that by setting a relatively high value of the parameter (A=30) in the pool, we reduce slippage, thereby attracting market participants. They will be able to make larger swaps, thereby creating arbitrage opportunities in the pool. At the same time the pool balance (under the proposed A=30) can drop to min 60%.

[stefan]

In order to scale the bLUNA-LUNA pool amplification, the on-chain proposal will need an executable message. Assuming this proposal will go on-chain next week, a message like the following can be used.

First, a sub-message that starts the scaling process:

{"start_changing_amp": {"next_amp": 30,"next_amp_time": 1651593600}}

// base63 encoded value
eyJzdGFydF9jaGFuZ2luZ19hbXAiOiB7Im5leHRfYW1wIjogMzAsIm5leHRfYW1wX3RpbWUiOiAxNjUxNTkzNjAwfX0=

This sub-message says that scaling will start when the proposal executes and it will end at 3rd of May 2022 at 4pm UTC. next_amp_time may need to change depending on when the proposal is posted on-chain and it should take into account the fact that it takes about 6-7 days for an on-chain proposal to go through voting and through the queueing period. The current value of 1651593600 assumes that scaling the amplification value from 10 to 30 will take about one week if the proposal is submitted by 19th of April.

Then, the sub-message needs to be wrapped:

{"update_config": {"params": "eyJzdGFydF9jaGFuZ2luZ19hbXAiOiB7Im5leHRfYW1wIjogMzAsIm5leHRfYW1wX3RpbWUiOiAxNjUxNTkzNjAwfX0="}}

// base64 encoded value
eyJ1cGRhdGVfY29uZmlnIjogeyJwYXJhbXMiOiAiZXlKemRHRnlkRjlqYUdGdVoybHVaMTloYlhBaU9pQjdJbTVsZUhSZllXMXdJam9nTXpBc0ltNWxlSFJmWVcxd1gzUnBiV1VpT2lBeE5qVXhOVGt6TmpBd2ZYMD0ifX0=

And finally, the message that should be submitted on-chain looks like this:

[
   {
      "order":"1",
      "msg":{
         "wasm":{
            "execute":{
               "contract_addr":"terra1j66jatn3k50hjtg2xemnjm8s7y8dws9xqa5y8w",
               "msg":"eyJ1cGRhdGVfY29uZmlnIjogeyJwYXJhbXMiOiAiZXlKemRHRnlkRjlqYUdGdVoybHVaMTloYlhBaU9pQjdJbTVsZUhSZllXMXdJam9nTXpBc0ltNWxlSFJmWVcxd1gzUnBiV1VpT2lBeE5qVXhOVGt6TmpBd2ZYMD0ifX0=",
               "funds":[
                  
               ]
            }
         }
      }
   }
]

[sech]

Hi all, this is my first foray into the math behind Astro so I’m going to be learning as I go. Please bear with me. @TopHatOnURHead, you mention the pool has been out of balance. Where does one get the historical data? I saw reference to Terraswap data in the Jupyter notebook but may have missed how to get the Astro pool historical balance.

@tatyana, what would you consider to be a successful outcome of this proposal? Increasing A seems to increase imbalance so is the desire here to increase the overall pool size (i.e. more market participants)? Is there a point where the market participation becomes large enough that A should be decreased?

Apologies if these are rookie questions. As mentioned, I’m new to this conversation and want to learn .

[tatyana]

Hi! Firstly, thanks for asking the right questions! Please see my thoughts below.

Question #1. The higher the Amp the lower the slippage. So, you’re right, the purpose of increasing the Amp is to attract users to the pool by offering them lower slippage and creating more earning opportunities. However, a large Amp is associated with the risk that the pool will be unbalanced (it becomes cheaper to drain the pool). In this analysis, we tried to find a tradeoff (a specific A value) between the low slippage and pool balance.

When conducting the simulation, we made an assumption that whatever the Amp the prices in the pool will still tend to fair market prices due effective market hypothesis. By fixing prices movements, we considered what transactions could be made. When the parameter A is increased, in order to shift the price by the same amount, it is necessary to make transactions of a larger volume (due to lower slippage).

Question #2. Mathematically as the pool approaches a state of imbalance, the curve inverts, preventing further pool draining. That is, algorithmically, a kind of self-regulation algorithm is embedded in the pool. However, in practice of course the pool balance should be monitored. In particular, if the balance falls below 60%, then it is worth considering reducing A.

General remark. Currently there are no specific recommendations for choosing the optimal Amp value. Any ideas are welcome!

[unsinn]

I think this might be a bit overkill. In a small test I made with the compute swap function, if we had 4m bluna and 2m luna at the pool (double amount of bluna in the pool), with AMP = 10 the return amount for 1 bluna would be 0.928377 luna. If I change the amp parameter to 30 the return changes to 0.978377 luna.

Part of the traffic this pools gets comes from users doing the so called “bluna arb” which are looking to get cheap bluna. This strategy would become much less profitable and which might lead to less traffic in the pool.

[sech]

@tatyana

General remark. Currently there are no specific recommendations for choosing the optimal Amp value. Any ideas are welcome!

Building off this comment and @unsinn, perhaps there’s a case to be made for on ongoing review and incremental adjustments to be made. Maybe like a weekly or monthly review and adjust by a 5-10 at a time?

This current thread seems specifically targeted to bLuna/Luna but I suspect the same can be said for any Luna variant (b, x, y/p, etc.) esp. if Arbie covers it.

[tatyana]

That’s a good point. Could you please provide your cacluations in Excel or smth like that to have a look?

[FullYeti]

Thanks for this in depth analysis and effort on researching this, I find the math is really interesting and I learned a lot!

My initial thoughts are this would hurt the usage of the pool. And for LP’ers, it increases the risk and decreases profits.

In my view, market participants primarily use this pool for two reasons… arb opportunities to increase their LUNA, and to escape the 21-day lockup on bLUNA so they can sell/use LUNA in a hurry. Both of these have proven to be incredibly valuable to users, that’s why it’s the #2 pool by volume. I believe Danku_R said in one of his videos the ARB opportunities alone amounted to 46% APY.

It sounds like increasing the value of this hyperparameter would decrease slippage and benefit market participants who have large trades (whales), but at the expense of reducing arb opportunities… which could decrease trade volume coming from smaller wallets.

Increasing the pool imbalance would also hurt LP’ers who need to withdraw, as they’d get more bLuna than Luna, and be forced to swap a larger % of their investment to LUNA. Or wait 21-days and suffer the price actions.

Long-term, this reduces profits to LP’ers on a pool that already has a very low APR… CoinHall shows 0.77% APR in the last 7 days. Yes, the APY is augmented by astro emissions, but that’s not the same as accumulating more LUNA/BLUNA.

If LP’s take on more risk, they should make more profits to augment the risk/reward. Personally, I always felt this pool should have the normal 0.3% swap fee, since users do accumulate huge benefits.