Liquidity Parameters - 2

[JumpTrading]

Since our last proposal (and the one Do put forth right after), the Terra ecosystem has continued it’s hockey stick trajectory upwards. The previous proposals have helped increased elasticity to take the UST float from ~$10m to it’s current $2B mark, but the usage of stablecoin and the liquidity and volume in LUNA have continued to increase dramatically. Time for a fresh look at the on chain parameters.

As mentioned on the previous proposal, some of the most heinous attacks on the system can occur when on chain liquidity driven off the oracle price is larger than liquidity off chain. Additionally as the elasticity of the system grows, the profits to be gained from temporary mispricing can also start to get large. Luna validators and holders effectively take the other side of these trades and thus they are important for the ecosystem to protect against. The current oracles update every ~30s, and the 95th percentile price returns on that time horizon are ~30bps. The off chain liquidity curve below is shifted upward by 30bps to reflect this and serve as mitigation against unconstructive arbitrage. As the oracle speeds increase over time, this curve could be shifted down further and allow for more liquidity and a lower min spread for tighter tracking.

We can see below that with a ~3x increase in base pool size and the 30bps buffer, the on chain swap liquidity is still more conservative than the off chain component and offers a margin of safety against oracle attacks.

Off chain trading volumes are up by a factor of 30 since the last proposal. The instantaneous liquidity has increased greatly, as indicated by the plot above, but the increase in volume suggests that the rate at which this liquidity is refreshed has also increased significantly. This brings us to the PoolRecoveryPeriod parameter. Using $350M USD as an estimate of the ADV, setting the recovery time to ~5 minutes would enable roughly as much notional to be traded within 2% of the best on the on chain swap platform.

Additionally, as your favorite IT admin will tell you, for high value systems it’s always worth exploring defense in depth.

One of the scariest attacks on the on chain market goes as follows →

1. Bid off chain reference markets up heavily on not too much size
2. Oracles report high prices
3. Sell a lot of LUNA for UST on chain
4. Sell it back down off chain
5. Buy a lot of LUNA for UST on chain. End up with more LUNA, diluting other holders
6. Repeat

Having higher liquidity off chain vs on chain makes it so that the above attack is unprofitable as it takes more capital to move the price than you can try to exchange on chain. That, of course, is a large part of the analysis above. A further mitigant would be to split out the TerraPoolDelta parameter into TerraPoolDeltaBid and TerraPoolDeltaAsk. In the example above after step 5, TerraPoolDelta is back to being close to zero. This means step 6 - Repeat, can just go again if the conditions are suitable and continue to hemmorage the system.

The on chain trading system is meant to be a means by which to expand and contract the money supply and not as a place of exchange (Terrswap, KuCoin and other exchange platforms that list UST serve that function). Thus there is no reason for the on chain market maker to ‘skew’ back into line once it sees 2 sided flow. This safety hatch is one that should hopefully never need to be hit, but provides another line of defense and some more time for the community to respond in the event on attack.

Summary of the Proposal

• Increase BasePool size to 32,500,000 SDR
• Reduce PoolRecoveryPeriod to 49 blocks
• Split out TerraPoolDelta into TerraPoolDeltaBid and TerraPoolDeltaAsk.

Note: Since we wrote this proposal, the market downturn has destabilized the peg downwards. This proposal is just as necessary for contractions in the other direction to help maintain the peg. Stability of the peg through dramatic movements is necessary (but not sufficient), to the success of UST and the Terra ecosystem in the long run

[DavidCS]

Why not use a liquidity curve that looks like the liquidity curve of aggregated CEX, instead of the hinge like curve? Shouldn’t be difficult to implement and would allow better on chain liquidity irrespective of swap size

[npSharkie]

I 100% support this proposal. Great analysis and recommendations! I love the insights into onchain vs. offchain (oracle driving) liquidity ratio and how these attacks can occur. As they said, if off chain is more liquid than pushing the LUNA oracle print high or low in order to offset the trade on chain doesn’t really work well.

Additionally I believe it would be good to consider reducing fees and increasing on chain liquidity for flow of UST → LUNA during a downside depeg and vice versa. Do had suggested something similar on Mirror where there they are implementing a scaling system of rewards allocated to short minters when the mAsset basis is exaggerated to the upside from Oracle. I think in that case Mirror will be using a reward based incentive (MIR tokens) that scales based off the premium of mAsset to oracle. Here I just think we want some sort of incentives whether it be rewards/lower fees (if the people demand 40bp range, then 50bp is not going to work considering the costs of all the legs of the arb) for on chain flow that is helping the core cause of maintaining a tight peg. I would also say to Jump’s point the chain liquidity could be dynamic. It could also skew to one side-- more liquidity, lower refresh providing liquidity to those burning UST → LUNA in this market (although I know the math might get really funky there, I haven’t looked into that at all with invariant).

Of course UST/LUNA is the life blood of the entire system, so when it depegged at first I don’t think people had much issue. When the depeg of even 1.5 cents persisted I do think that made a lot of people -quite- nervous. “Isn’t stable coin stable”. The psychological standards for stablecoin having low volatility are very, very high. 1.5 cents might as well be 10 cents in the eyes of some nervous investors-- and b/c of the monetary system, here psychology becoming reality through a vicious circle can happen very quickly and unfortunately lead to irreversible damage to LUNA supply diluting earlier investors (beyond the reputational damage). Flash crash, peg goes to .85 or what not, arbs pour in driving Luna bids down further and thus minting more and more shares while arbing it at extreme, artificially low prices (non fundamental prices). It becomes a game theoretic situation that we should stop at all costs as talking to the community for several days that is one of the “fat tails in the back of people’s minds”. If this was far more heavily protected I believe many long term investors would sleep easy at night even during extreme volatility.

One final thought I had that might give the community some peace of mind in the future is similar to what the Fed can do with open market operations. For example, at times in multiple central banks they will simply go in and buy assets that will provide momentary stability (heck even stocks in March 2020) and carry the inventory. In this case I think there could be some backstop at say .95 that people are aware of, where an automated algo could be a hard or semi hard bid that would buy UST from sellers, mint LUNA, store the newly minted LUNA in a reserve. That reserve would then be sold/twapped over some agreed upon interval as to not crash the market. I’m not sure where or how would do these things equivalent to “open market operations” and it of course doesn’t really fit with the nature of DeFi. Let me be clear, I believe relying on third party arbitrageurs is the primary way to go, but you can never be too careful so this is just a thought.

Sorry for rambling and perhaps straying off the proposal topic. As I said, I believe their ideas are on point in the proposal and good security advice, and I hope this might also add some other notes on system stability/adaptation of the onchain liquidity. I agree with Jump in that onchain is not meant to be “just another trading venue”. It really is the lifeblood of Terra providing that much needed stability in exuberance or fear.

Cheers to all of you in this community, only been here a month or two but it’s awesome.

p.s. thank you devs!

[flipside]

I’d appreciate it if anyone could provide a brief, slightly less technical summary of the proposal.

[Ilo_Muoto]

In response to @npSharkie

In short, have an algorithm perform arbitrage functioning using liquidity provided by the protocol’s investors. Investors receive the generated profit in a linear fashion out of the protocol’s treasury. Yeah sounds excellent!

Or have it built into the Terra ecosystem where profits from arbs are distributed to Luna Stakers?

[redkiho]

In response to @Ilo_Muoto

I suspect an automated arbitrage algorithm might incentivize malicious actors to game the system and destabilize the peg in order to maximize arb profit. I think 3rd party arbitrage should remain the primary stabilizing force.

[Ilo_Muoto]

Hey Redhiko,

Wouldn’t the cost required to destabilize the peg be equal to the profit derived from arbitrage?
Or heck, even outpace it since we have to account for routing fees aswell?

In any case, Peg is once again under 0.98. UST keeps leaving Terra for other purposes which tells me two things: DEX on terra is very important and arb right now is not enough.

[thelawenforcer]

Seems this proposed changes would have helped the peg alot during the downturn as well as after. seems the parameters they change werent really adapted to the size of the terra economy anymore. would it be worth considering making these parameters dynamic so that they scale with terra circulation, or otherwise ensuring they are regularly reviewed so as not to be caught on the wrong foot again?

[dokwon]

We could make the base pool sizing some proportion of UST float, but this would be gameable while Luna liquidity is still nacent. The on-chain liquidity must be smaller than overall luna liquidity (or at least comparable) otherwise the on-chain swaps can be arbed against the offchain market.

Vigilience is needed and has been internalized for the future.

[thelawenforcer]

ok thnx Do, i figured there would be a good reason for this. perhaps an option down the line would be to have a recurring vote at X interval (i guess a proposal would first have to be passed to make a recurring proposal) on whether to change or maintain the parameters, assuming it would always be the basepoolsize that would need adjusting. perhaps a proposal could automatically trigger each time the Terra float increases or decreases by some %. this would ensure these important stability parameters are looked at and brought to governance’s attention regularly. I dont know whether this is possible to do however. anyway, questions for another day!

also, happy cake day

[pauldehodl]

How can you get liquidity on CEX @JumpTrading thank in advance