Remove and Secure the Stablecoin Terra Market Swap

Governance & Proposals
107

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.

108

I Support this proposall

109

I support it!

110

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

111

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.

112

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…

113

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
114

Proposal is written by a fool.

115

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.

120

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: