USM: what type of oracle, and what admin powers if any?

This is a writeup of some analysis I’ve had in the back of my mind about two broad, important questions in USM’s design:

1. ETH/USD oracle: what type of oracle (eg, single oracle or “composite” oracle) should it use, and which specific oracle(s)?
2. Admin powers: should admins have any “governance” powers — eg, to set a “voluntary upgrade” v2 contract, as described in my original post?

Overview of this post:

• A: Why is the choice of oracle so sensitive?
• B: Ways oracles can fail, and how well different oracles handle them
• C: Admin powers or not?
• D: Tradeoffs of specific oracles
• E: Conclusion: my (tentative) takeaways

But probably the most important takeaway here is the table in part B.

A: Why is the choice of oracle so sensitive?

We recognized from the start that, general smart contract snafus aside, inaccuracies/slowness of the price oracle was the most delicate part of the design. The system is essentially a market maker. If it will sell you 1 USM for 0.003 ETH, when the current market price is closer to 0.004 ETH, there is a risk that arbitrageurs will repeatedly “pick off” such inaccuracies, draining the ETH pool over time. There are reasons to think we can prevent such exploits (it’s an experiment!), but clearly the more accurate the oracle, the better our chances.

Unlike in-&-out systems like Tornado.cash or Uniswap, USM is a highly stateful system. Once I’ve sold token A for token B on Uniswap, I don’t care about Uniswap any longer: I have my token B. But any holder of USM or FUM is relying on the ability of the system to redeem those tokens for ETH in the future — at a fair price. If I come back later and suddenly the system will only give me $0.01 worth of ETH per USM, my tokens are effectively busted.

If the USM system is successful, the USM/FUM outstanding and the pile of ETH it sits on will grow: once deployed we have no control over this. It could grow for many years, and grow to a huge value.

Meanwhile, oracles — the question of how to make off-chain data available on-chain — remain an open research area. In the best case, over time we’ll develop more accurate, robust ways to import off-chain data like the ETH/USD price. In the worst case, the ways we have now will stop working as trading venues, price sources and oracle infrastructure evolve.

So it’s highly plausible that in a few years, if not sooner:

1. The USM system will still be running, sitting on a large pile of ETH; and,
2. Our initial choice of oracle will no longer be providing good prices.

This doesn’t necessarily mean a complex composite oracle is better, or that an admin-controlled upgrade mechanism is worth it. But it does mean we should think these questions through before deploying.

B: Ways oracles can fail, and how well different oracles handle them

This table summarizes:

1. Ways an oracle could fail (failure cases), that I could think of anyway
2. Types of oracles we could choose
3. How well or badly each type of oracle behaves under each failure scenario

C: Admin powers or not?

The goal with USM was always minimal admin powers/“governance” — ideally, none. But as always, there are tradeoffs. For example, cases 5.b) and 7.b) above represent persistently inaccurate prices, from a min/max-style composite oracle. In these cases, users could be unable to migrate from v1 to a fixed v2 on their own, because v1 is charging unreasonable prices to withdraw. But they might be able to migrate affordably if we had included a special migration function, which performed the migration from v1 to v2 at (corrected) v2 prices.

This is a case where a built-in migration function could prevent user funds from getting lost in v1 with its broken oracle. Note that this would still be an entirely opt-in user migration — admins can’t perform the migration. The only question is whether it’s worth giving admins the power to set the v2 migration contract, and whether it’s worth increasing the complexity of the contract code by adding this migration functionality.

There are other plausible admin powers we could consider. Eg, a one-time “pause” function which halted all token-exchange functions (mint/burn/fund/defund) for say 2 weeks, for cases like 5.a) or 7.a) above where an oracle problem or other bug is causing the pool to get drained, and we want to give ourselves time to set up a fixed v2 and give users time to migrate. Or we could make the migration functionality temporary while we “kick the tires” after deployment, and revoke it once we were comfortable.

But there’s still a strong case for giving ourselves no admin powers at all, especially if we deploy a relatively robust oracle like the median-style composite.

D: Tradeoffs of specific oracles

We’ve discussed this elsewhere at length, but some notes as reminders — edits/additions welcome:

• Chainlink:
  Pros:
  - fast accurate prices
  - great UX
  - reasonably distributed (“decentralized”) sources
  - very low gas costs
  - widely used
  - ready to deploy!
  Cons:
  - off-chain (therefore shutdownable?) price sources
  - incentives rely on LINK token retaining value
  - components of system not trivially inspectable
  - price feed infra (not just price contributors) apparently capable of giving way-off prices due to “human error” (?)
  - decentralization purists will keep asking us suspicious questions
• Uniswap (v2 oracle):
  Pros:
  - ownerless smart contract — truly “unshutdownable”
  - no maintenance risk: “human error” limited to original contract code
  - code is short and open-source
  - good liquidity
  - beloved by decentralization purists
  Cons:
  - forces us to depend on other stablecoins (USDT, DAI, …) and their pegs
  - slower/less accurate prices
  - higher gas costs
  - despite sketch from Keydonix, doesn’t seem 100% ready-to-deploy
• Others…? Maybe MakerDAO’s ETH/USD price feed?

E: Conclusion: my (tentative) takeaways

1. First of all: there are many genuine tradeoffs above. If the answers to any of these questions seem obvious to you, you may not be fully appreciating the counterarguments.
2. Of course when in doubt it’s tempting for a project like USM to just default to the simplest option. But in this case, the simplest option — one oracle, no migration mechanism, no admin powers — seems to me too simple. The risk of our sole oracle misbehaving in a way that leaves user funds unrecoverable — say breaking its peg, or suffering an extended outage — seems too high, especially given that 1. once deployed our contract could accumulate a growing pile of ETH for years, and 2. oracles are still an active research area.
3. Peering at the color-coded table of tradeoffs above, my own first choice is: a median-style composite oracle (3 source oracles), no admin powers — the median-style oracle should make migration user-friendly enough without any extra functionality on our part.
   But the feasibility of the median-style oracle depends on:
   a) how many half-decent source oracles we can find,
   b) how much work it takes to get them running, and
   c) how much they increase user gas costs.
   I hope none of these three obstacles turn out to be severe, but if they do, we may need to consider a single-oracle solution — though then probably with an admin-settable migration function (and maybe even an admin “pause” function), to add some minimal future-proofing.
4. These are only tentative conclusions and I reserve the right to change my mind, or have my mind changed!