Liquidity Parameters - 3

SUMMARY: Given the rapid changes in the UST ecosystem, the on-chain liquidity parameters should be updated to preserve stability, in the following ways:

  • Increase BasePool size to 50,000,000 SDR
  • Reduce PoolRecoveryPeriod to 36 blocks

The Terra ecosystem continues to scale at rapid clips. At the same time, it has also encountered new stresses. On one hand, the average daily volume is $1.25 billion — as compared to $350 million in a similar analysis conducted eight months ago (link)! Moreover, the total UST float has grown from $2 billion to $10 billion. But at the same time, strong liquidation pressure spilling over from Wonderland, MIM, and others have put the peg under stress in the last few days. It’s time for a fresh look at the on-chain parameters.

Despite the changing circumstances, the primary attack vector has always been the oracle attack, as covered in more depth in our previous proposal. This is where on-chain liquidity derived from the oracle price exceeds the off-chain liquidity used to generate that oracle price. A careful analysis is thus needed to ensure that the additional liquidity meant to stabilize the ecosystem is not drained at the expense of stakers or the broader Terra ecosystem.

We have done such an analysis, and believe that the optimal solution is to increase the base pool size from 32 million SDR to 50 million SDR, and to decrease the refresh period for the pool from 49 blocks to 36 blocks. This will increase the ability to mint or burn LUNA on-chain by 116% (i.e. more than double the status quo), based on our simulations. In particular, we estimate the total capacity for mint/burns to be $293 million, up from $135 million today, per day under this change. Moreover, this does not greatly change the risks arising from oracle attacks, as compared to the status quo.

At the same time, we recommend leaving other parameters untouched — namely the minimum spread should remain fifty basis points and the oracle voting period should remain five blocks. Indeed, we estimate the 99th percentile of the absolute return over a five-block voting period to be almost exactly fifty basis points. This is depicted on the plot below, in which the x-axis is approximately Terra blocks, and the y-axis is the absolute return in the LUNA/UST pair (in basis points).

This proposal should enhance the liquidity of the on-chain mechanism for now, but there are further solutions under development. For instance, we could adjust those other two parameters — the minimum spread and oracle voting period — in tandem. Moreover, we could make the on-chain liquidity a more complex function of off-chain liquidity, rather than utilizing static parameters. But note that this and all other solutions under development continue to view the on-chain mechanism as the means to expand and contract the money supply, and not as a means to facilitate ordinary exchanges. Those latter functions are better served by Terraswap and other venues that provide UST liquidity.


In your last proposal, you also suggested splitting out the TerraPoolDelta parameter into TerraPoolDeltaBid and TerraPoolDeltaAsk. This would enable us to allow UST to contract faster than it can expand. In other words, we can increase the protection of the peg when UST <$1 while simultaneously preventing oracle attacks.

Are you still considering this idea?

1 Like

2 questions on my end

  • The ecosystem has grown significantly since Liquidity Parameter 2 (x10 for Luna, x5 for UST). Is the 116% increase in daily mint/burn capacity commensurate ? - I would like to better understand the analysis you conducted.
  • Could you please expand on “we estimate the 99th percentile of the absolute return over a five-block voting period to be almost exactly fifty basis points” - this is more for my own education.

Many thanks in advance for your time

Thanks for raising this, we continue to explore the parameter split and aim to provide a proposal along with other suggestions once we settle on understanding all potential downside risks.

1 Like
  • While there are some nuances, they are necessarily proportional. We did take a look at the order book, we’d be happy to share the order book data.

  • While a faster replenish rate, under modeled simulations, yields a greater hypothetical arbitrage opportunity for an adversary during an oracle attack - there still remains significant timing risks around realizing those profits since it assumes perfect execution between a centralized exchange and the on-chain mechanism. As such, a relevant time scale is to model the potential arbitrage profits over a selected period to examine the associated downside risks of such changes.

  • Absolute return here is: Untitled plotted for different time intervals (roughly corresponding to Terra blocks)


Thought I would mention this is already done: [Feature] Separate mint and burn swap pool by YunSuk-Yeo · Pull Request #467 · terra-money/core · GitHub


@JumpTrading hey team, great to see you back here.

This is a great reminder and a massive success for the network:

A 5x growth, there is new strain - and consequence - put on the UST peg. I am curious about your chart included above. It seems to mirror a similar EMA included in your last post.

Is there any significance to this or strictly a coincidence, indicative of normal volatility?

2nd - it is my understanding the SDR is a factor of mint/burns.

By making the SDR greater than 50mm does it increase this daily mint/burn number? Are there any additional effects or risks which prevent you from making this number higher?

1 Like

Thank you @somethingelse, it seems like the split of the two parameters was made but then it was rolled back to one parameter only. I could not find an explanation for why it was rolled back. I wonder if @Yun_Yeo could explain what happened here:

I think it is just simpler with one base pool.

There should be parity in costs on mints and burns - having a singular pool reflects the intention to create this cost symmetry


I heard the other day at the Do and Kanav AMA that the max amount of UST is being minted currently and still amounted to ~$130m/day.

Is the parameter change undergoing more simulations before changing to $300m/day? I know we voted on this and passed it a month ago.


1 Like