Remove and Secure the Stablecoin Terra Market Swap

If this will help repeg ustc : yes.
what is the proposal id ?

i never recieve that option how can i ensure to activate that?

It’s completely understandable to disable the swaps while they can be exploited. I was just concerned they’d be disabled permanently, but it sounds like we’re on the same page.

As for the capital controls, I think the basic theory behind the algorithm to control the market though - minting, burning, spread fees, and the Tobin Tax is correct. But its implementation and the equations that power it are very weak/insufficient. Looking at the maths in Terra Docs it’s clear they were a vulnerability and prioritised movement of capital over stability, but with some modification you could have a bulletproof system.

2 Likes

No exchange uses those tokens. So its usefulness is negligible. I myself want to get rid of the ones I have because I don’t see any use for them and I always have to convert them to USTC

Currently that may be the case, but with the huge global push towards digital currencies and crypto. Having this base of stables is a huge asset, and would make our blockchain more globally accessible and much more enticing to build on for those selling products/services.

3 Likes

Doesn’t matter. You were always able to exchange your, say, EUT to Luna on terraswap and then sell on an exchange. I was okay with bearing that risk in that short period of time. And the fact that your staking rewards consist of these tokens shows clearly, that they are being used as store of value.

Yep…and if the proposal get approved…the swap feeds to this coins should be 0

I support this proposal!

Hello. I wrote and translated me proposal from other language so there may be mistakes

and Also I cannot understand how to post on Agora because I am new registered that’s why I post it here

We all know that the LUNC blockchain was a blockchain of stablecoins, the main one of which is UST. And that was his peculiarity. Therefore, the community should preserve this feature and this functionality. This means to revive and restore the binding of UST and other stablecoins to their fiat counterparts. Without this, the Lunc blockchain will lose its peculiarity. Also , we should not mint new analogues like USTN , this will undermine the credibility of the blockchain . We need to show future investors and developers that we can recover.

The first thing to be done is to RESTORE the binding USTC=1$

How to do it?

At the moment, I often see posts on Twitter addressed to CZ Binance. Unfortunately, the community wants someone to solve their problems. I propose such a solution. It is up to the community to do this. How?

It is necessary to restore the work of the blockchain in the form it worked before the crash and, PLUS, add here the function of maintaining the USTC rate not by minting new LUNCS, but by withdrawing them from the remuneration of miners.

I’ll give you an example. Approximate calculations if the idea is interesting, let the mathematicians do the calculations.

Let’s assume the rate of 1 USTC = 0.9 $, taking 10% of the reward from the miners

1 USTC = 0.8 $ taking 20% of the reward from the miners and so on until full recovery.

— miners are not happy (but they will earn on the growth of the exchange rate and also when the binding is restored 1 USTC = 1 $ everything will be as usual

— – We will get rid of the spiral of death, Restore trust in the blockchain, and it will also serve as a protective mechanism against the fall of USTC, because if everyone knows that there is such a mechanism, then people themselves will buy USTC when falling in the hope of making money on the difference knowing that there is such a protective mechanism

With best wishes Incognito trader

2 Likes

I support

Hi @aeuser999 , you have many concerns and I am overwhelmed in all aspects of the word. I have done my DD and written a paper about my recommended paths forward. I encourage you to take some time to address your own concerns. When you are satisfied, please report your results back to the community and put forth a governance proposal.

I Support this proposall

I support it!

@ek826 Try this… Much better plan than USTN etc. and also possible

They just need to disable one side here temporarily. Like disable USTC to LUNC. But enable LUNC to USTC. This way LUNC will lessen the total supply. It’s like we are doing repegging in a more control manner. And lower this tax. So more people will be active using terra station. The crash happened because they have swap on both side. But if they disable one side then it is impossible to have a crash. Once we lower the LUNC supply we can mint new coin and completely whitelist USTC. And upgrade the arbitrage. This coin is not moving now because of that tax.

Adding an appropriately tuned circuit breaker, to curb abrupt price changes, sounds great for risk free on-chain swaps… Sounds like progress toward fixing lunc…

I think that minting tokens out of thin air is useless if it has no real value. If things are not done well we could go back to the same as before. With trillions of tokens that have no value.

1 Like

Proposal is written by a fool.

This proposes a rigged swap tool in terra station that would fleece people of their swapped ust and lunc as opposed to doing what the token swap does, which is to swap tokens.

Downgrading the product does not serve the user in any way and only enriches one party.

Proposal is written by a selfish fool.

Hi @ek826 ,

I just received a request from you in discord on this proposal. To be honest, I was not sure how to take your response.

Since you have asked for feedback, here is what I would suggest to validators:

  • Vary the sources for the price server in the config/default.js to be different from the sample (at least for about 2/3’s of the validators)(ie. the default being fiatProvider: { fallbackPriority: [‘currencylayer’, ‘alphavantage’, ‘fixer’, ‘exchangerate’, ‘bandprotocol’] } maybe one of three fallback Priorities (mainly since TFL had commented out fixer and alphavantage for some reason - but I am taking a guess that since both currencylayer and fixer are now products of https://apilayer.com, they may have commented out fixer since most likely ApiLayer would use similar data for both products - you can confirm both products are owned by ApiLayer by going to their sites https://fixer.io and https://currencylayer.com/ and looking at the legal documentation in the footer links). Suggestions could be:

    • { fallbackPriority: [‘exchangerate’, ‘bandprotocol’, ‘currencylayer’, ‘fixer’, ‘alphavantage’] }
    • { fallbackPriority: [‘bandprotocol’, ‘currencylayer’, ‘exchangerate’, ‘alphavantage’, ‘fixer’] }
    • { fallbackPriority: [‘currencylayer’, ‘exchangerate’, ‘bandprotocol’, ‘alphavantage’, ‘fixer’] }
      • I have created a tool that validators can use to determine if they are using a source that is too much of a majority source, or if they are reporting back information that is missing certain sources but containing others: I will direct message you the link to that tool.
  • For the keystore issue in the oracle feeder:

    • it appears that it needs a fallback to decrypt to CBC and SHA1 if it errors on decrypting using GCM and SHA512 message digest (or an external tool to be used before the new oracle feeder starts that decrypts using the old method and then re-encrypts using the new method). That is one reason that it may not have worked - but I have not tested it. I would recommend that the keystore file itself should be limited to the root:[limited-user-oracle-should-run-under] and that owner and group be given appropriate rights to the keystore file and that other users and groups be given none.

I think this should mitigate most of these issues in the short run (at least as a personal opinion - and these can happen by working with validators without a proposal). In regards to a potential proposal (at least as a suggestion), I would recommend the oracle price server be adjusted (if it does not already do something similar - but from observation it does not look as if it does, although I have not tracked the code):

  • For Oracle Price Server:
    • Oracle pricing server is updated to pull from 3 sources (not just fallbacks, but it actively checks the top 3), the higher ordered (validator configured) and:
      • submit the price of the higher ordered of two of the three sources where those two sources are within 90% of one another.
      • If no 2 sources are within 90% of one another, then use the one that is closest to the last settled vote price on chain.
    • Add more sources for fiat pairs
  • For Core:
    • If votes being voted for on chain, for the amount of validator voting power that would allow for a settled vote, give pricing that is more than 80% lower than the last settled voted price on chain for that particular coin/denomination, then use last settled vote for that denomination for all validators (keeping last settled vote for that particular denomination for the new settled vote), and do not allow swaps into/out-of that particular denomination until the above condition for “Core” is no longer true, or until an epoch has passed (if an epoch has passed, then allow votes for the particular denomination that was caught in above “Core” condition, even if still 80% lower than the last settled voted price recorded on chain).

This potential solution outlined above for the oracle prioritizes flash crashes over market crashes - since flash crashes in data are more frequent than actual market crashes.

I may have time to contribute toward this in development to some degree (if you feel that would be helpful) since it is actually one portion/point, in one particular plan, of what I have been spending the majority of my available time working on, with others, toward a potential plan regarding the restoration of pegging the stables.

That said, really my concerns were meant to be passed along for discussion (since I did not see answers to my questions or concerns in the discussion so far, nor in the attached publication). I mentioned some concerns that I had as part of this discussion with hopes you would let us know how it worked from what you were seeing in testing. Beyond that, I also mentioned that it appeared to me that most of these had workable mitigations (although that was not meant to stop your proposal, just to add to the discussion).

Thank you so much for your consideration.

I hope you have a great day today :slight_smile: