Remove and Secure the Stablecoin Terra Market Swap

Governance & Proposals
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:

Buyback and burn ustc minting by Terra Rebels mistakes