UNI should become an oracle token

Requests for Comment
1

One of the most important ingredients for a successful defi ecosystem is a highly secure price oracle. Algorithmic stablecoins (eg. DAI, RAI, LQTY) depend on a price oracle, synthetic assets of any type depend on a price oracle, collateralized loans depend on a price oracle, as do many other types of projects. Uniswap does provide an “oracle” for the price of ERC20s traded on the exchange, but this is not a true oracle as it does not provide the price of anything in the outside world. This is a problem: algorithmic stablecoins need an oracle for the price of ETH/USD to be able to function, and they specifically need an oracle for USD the off-chain fiat asset, and not any specific on-chain instantiation of USD. Similarly, synthetic assets need an oracle for the price of ETH denominated in whatever asset they are mirroring.

I recommend that Uniswap and the UNI token step in and provide such an oracle (eg. modeled after the Augur or UMA design), specialized to providing price data that’s robust and extremely costly to manipulate and attack.

Outline of this post

  • Stablecoins need an oracle for the price of ETH/USD (see above)
  • Workarounds like taking the ETH/USDC price are NOT sufficient
  • Chainlink is great, but there’s room for a simple alternative specialized for high-value, okay-with-high-latency use cases
  • UNI is in an excellent position to be a token for such an oracle
  • More broadly, Ethereum L1 needs to remain governance-minimalist, but L2 should be more ambitious, and UNI can be part of that

Workarounds like taking the ETH/USDC price are NOT sufficient

The goal of algorithmic stablecoins is to try to be maximally censorship-resistant and robust by being free of dependencies to the “fiat world”. If this goal is not important to a stablecoin user, then they can avoid algorithmic stablecoins’ technical risks by just using USDC directly. If this goal is important to a stablecoin user, then it’s important to avoid not just direct dependencies on the fiat markets but also indirect dependencies. Using the ETH/USDC price as a proxy for ETH/USD does not achieve that goal, because such system is still ultimately dependent on USDC continuing to exist and being freely tradeable.

Taking the median of multiple ETH/stablecoin rates (eg. USDC, GUSD and USDT) is at best a small improvement, because the traditional financial system is quite coordinated and can easily become less friendly to all asset-backed stablecoins simultaneously. Hence, if we want to have algorithmic stablecoins that fulfill the raison d’être of their category, an oracle that provides the price between ETH and the USD in the fiat world is needed.

Chainlink is great, but there’s room for a simple alternative specialized for high-value, okay-with-high-latency use cases

Currently, most “governance-minimized stablecoins” are using Chainlink as their oracle. Chainlink is really valuable for many oracle use cases, but it is also a complex system with many features. Incentives are not as clean as they are in eg. Augur; in particular, there is not an automated mechanism by which participants who provide wrong answers get penalized.

Much like it’s desirable to complement MakerDAO with more minimalist stablecoin alternatives like RAI (disclosure: I hold both MKR and Rai’s FLX) so that the ecosystem can be more resilient through the diversity of different approaches, it also seems desirable to complement Chainlink with a more minimalist alternative that’s more laser-focused on optimizing incentives and maximizing cost of attack. A robustness-favoring oracle should target these properties even at the cost of being okay with tradeoffs like long resolution times and being limited to one specific type of data (price indices for highly liquid assets).

UNI is in an excellent position to be a token for such an oracle

Decentralized price oracles (at least, if they want to avoid dependence on an identity layer) need to have a token for sybil-resistance. Holders of the token are asked what the price is, and typically an economic mechanism is introduced where those who provide the majority answer are rewarded and those who provide the minority answer are penalized.

If the majority of token holders are corrupted, they can successfully impose an incorrect answer, and at that point it’s up to the minority holders to create a fork of the system where the attackers’ coins are zeroed out and convince the community to prefer the fork from that point forward. The cost of such an attack is thus half the market cap of the token, minus some amount to account for very lazy holders who are not willing to participate in a vote even in an extreme emergency that could cost them their coins.

For this reason, a robust token-based decentralized oracle for a defi project must first and foremost be based on a token with large market cap. Efficiency of an oracle is not important: an inefficient oracle can always be augmented with a game where one party claims a value and only if another party disagrees is the oracle actually called. Cost of attack, on the other hand, is absolutely essential to maximize, and thus market cap is key. And the two Ethereum project coins out there with the highest market caps are… LINK and UNI.

Supporting oracles would not just be an act of altruism for Uniswap; in fact, Uniswap heavily benefits from the existence of a more robust stablecoin ecosystem. Uniswap v3 is heavily optimized toward ultra-high capital efficiency for stablecoin <-> stablecoin trades, and is likely to earn very high amounts of fee revenue from these trades. If we start to also see high-volume and robust synthetic assets emerge on-chain, then this is even more valuable for Uniswap.

More broadly, Ethereum L1 needs to remain governance-minimalist, but L2 should be more ambitious, and UNI can be part of that

The Ethereum ecosystem aims to be the base layer of a fundamentally broader set of applications than preceding blockchain platforms attempted to cover. The goal is not just supporting holding and transfer of a basic asset, but also a decentralized finance (DeFi) ecosystem and also increasingly a decentralized governance (DeGov) ecosystem. There’s also a large need for public goods funding in the Ethereum ecosystem.

Supporting this broader vision requires something more expansive than “just a blockchain”. Arguably, it requires taking a few steps in the direction of the “crypto state” vision, expanding the services that the blockchain ecosystem provides to not just security but also oracles, dispute resolution, public goods funding, identity, etc. But in order for Ethereum to be a stable platform, there is a need for the blockchain base layer to be governance-minimalist. The governance minimalism gives users confidence that applications that they care about will not be interfered with, and that the base layer will not be ripped apart by political conflicts over addition of controversial features.

Hence, these services need to somehow be provided at layer 2. MEV auctions on rollups to fund ecosystem-wide public goods, as being implemented by Optimism, are one example of this. And Uniswap, as a decentralized exchange that is core to the Ethereum ecosystem also taking on more responsibilities (including price oracle provision) is another natural potential step in this direction.

82 Likes
2

Uniswap as a highly secure oracle system is much needed; and is a great idea. I am trying to grasp how UNI will be used in the model. My hope is it does not require extensive hardware requirements like running a full node. To be an oracle reporter is to be a holder of UNI, or does it require also being a Liquidity Pooler (with locked up funds) to gain UNI incentives or potential slashing in the case of maliciousness?

Is being an oracle a passive or active experience? I.e is the oracle in the center (like the treasury) passively running and token holders vote as a whole occasionally during a price dispute, or is each UNI token holder or LP’er actively reporting specific paired pricing constantly. How is off-chain currency data aggregated with UNI oracles?

I am in support of an improvement that allows token holders to become more engaged in the Ethereum ecosystem.

2 Likes
3

Uniswap has already seen some difficulty enacting governance with the token, I wonder if spreading token utility out further would make governance even harder.

Meanwhile the full market cap of the LINK token can be dedicated to purchasing data and securing it when the staking mechanism outlined in their 2.0 model is deployed. No cross-utility to worry about spreading the cryptoeconomics around, it’s fully oracle focused.

May edit this with more thoughts as I further process the proposal.

Edit: As I outlined further below, my conclusion here is this both solves the issue in a lesser manner than Chainlink and also burdens Uniswap development with a specialized use not core to their product. This Augur arbitration model is not exactly a simple extension of Uniswap’s current oracle model, it’s a whole new economic system tacked on for one specific case.

Furthermore Chainlink is already solving this in the same way with their proposed two tier arbitration system that lets latency tolerant contracts (like what’s proposed here) go into an Augur style resolution (also like what’s proposed here) but the difference is that the security of Chainlink’s model has n^2 scaling with the value of LINK whereas the Augur/UMA model has 1/2n scaling.

So basically this seems like extra work for the Uniswap team just to result in something similar to Chainlink 2.0 but less effective.

9 Likes
5

I agree with everything Vitalik stated, get a proposal up asap :+1:

8 Likes
6

Hm but I’m not sure how “low latency” a stablecoin can handle. Maker requires an hourly price. How does this actually function? You can’t have a quorum of UNI holders voting every hour. Also doesn’t delegation introduce a potential centralization risk?

Like the idea, curious about implementation.

1 Like
7

I love it! This is a killer feature to propel Uniswap further as an overall product.
:unicorn: :clap:

5 Likes
8

Account created 1 day ago. Proof this is the real Vitalik?

LINK’s superlinear staking which is already mostly built solves for the need outlined here in its entirety. I have a hard time believing real Vitalik is not aware of this, but willing to be proven wrong.

2 Likes
9

+1 on this! i think the accessibility of uniswap’s TWAP oracle has been great but curious of the implementation for the UNI governance token to double up as an oracle token…

if anyone has ideas on implementation - would love to see them discussed and of course, apply to the UNI Grants Program - unigrants.org!

7 Likes
10

I can confirm this is the real Vitalik, he reached out before posting because the username vbuterin was reserved

22 Likes
11

Technically you only need price feeds in two occasions:

  1. CDP liquidation
  2. Once every interest rate adjustment period

You don’t need a quorum of UNI holders voting once every time one of the above things happens, you can use an escalation mechanism: whoever first takes an action that requires providing a price provides a price along with a deposit, then anyone else can challenge them with a 2x deposit, and then the deposits escalate until only past some threshold you do a global vote. This is how the Augur oracle works, and IMO it works quite well!

5 Likes
12

But how would you know to trigger a liquidation without the hourly price feed? You also need the price for stablecoin generation in the first place.

I’m also not following the escalation procedure as by time the issue is resolved the entire system could have collapsed. Unless I’m missing something? Is the escalation period prior to the submission of the price?

1 Like
13

From my perspective, this proposal suggests that Uniswap should launch an Augur/UMA style human voting oracle in addition to their existing decentralized exchange infrastructure. In my opinion, a token-weighted human voting based oracle mechanism is not ideal for providing decentralized stablecoins the price data they require. Collateralized stablecoins like DAI/RAI (which are backed by ETH and other on-chain tokens) need to be able to liquidate undercollateralized positions in a timely manner for the protocol to stay solvent, otherwise the peg of the stablecoin can break when collateral is less than the debt/stablecoins minted. Augur-style disputes can take days to weeks to resolve, by which point it may be far too late to do anything about the situation, leading to the loss of user funds and a loss of confidence in the stablecoin.

We can imagine a flash crash scenario where the price of a collateral asset drastically falls during a period of extreme Ethereum network congestion. Will UNI holders be incentivized to put the collateral price on-chain in a timely manner when gas fees are 1000+ gwei during a flash crash? What would be the consequences of price data not being posted on-chain within the timeframe required for viable liquidations? A dedicated decentralized oracle network consisting of nodes whose sole business is to provide reliable data even during the worst of network conditions are highly incentivized to post data during these conditions as their long term revenue depends on their personal reputation/performance history and the value of the token they hold and are paid in depend on the reputation/performance history of the network as a whole.

Creating an oracle system requires a lot of resources for development, monitoring, upkeep, and support. Creating an oracle as a side project would siphon resources away from development of the Uniswap DEX, the primary product offering from Uniswap. There are also open questions here such as where the data would be sourced from, how often the price feed should update, how much each token holder should be paid, how much they should be slashed, how forks would be handled from a user’s perspective, how long disputes should last, how a network of voters would be bootstrapped, how users will be onboarded and supported during integration, etc.

In my opinion, using Chainlink as an oracle and using Uniswap as a DEX is the best possible equilibrium where resources aren’t wasted and users are provided the highest quality infrastructure at the lowest cost (economies of scale provided by the Chainlink network through the shared cost model of the reference contracts). If interested, I can provide additional context on the existing cryptoeconomics of the Chainlink network today as there are indeed financial penalties for posting incorrect data.

7 Likes
14

But how would you know to trigger a liquidation without the hourly price feed?

The liquidators would be watching the price, and if they see that the price is low enough that a CDP is undercollateralized, they would start the liquidation process. But the liquidation process would be challengeable and could be challenged many times, so the final result would not be known for some time (and this is okay! the liquidator’s extra collateral would cover any extra price movements that happen while the CDP is in the “liquidation pending” state)

3 Likes
15

I would say that a stablecoin that depends on timeliness for its security is not stable at all. There’s always the chance of a blockchain attack at the same time as a market crash; indeed, a period of high market volatility is the best time to attack the chain! There’s a reason optimistic rollups have a 1 week finality period, and stablecoins need to start thinking in those terms as well. A 1.5x liquidation margin is a good start; perhaps that needs to even be pushed slightly higher. Obviously you can have more security during those periods when the network is doing well, but you can’t rely on acceptable network latency absolutely.

Also, I should repeat when I said in an earlier reply: the oracle does not go immediately to “everyone votes”. You only need a single liquidator to kick off the process, and that is something that can happen quickly at least during non-attack periods.

10 Likes
16

I don’t think a long “liquidation pending” state is feasible, unfortunately. If the price of the asset is dropping quickly, the solvency of the system is at risk for every hour you wait. The only potential solution to this would be very high levels of over-collateralization, which would render the system uncompetitive.

4 Likes
17

An escalating oracle can take a very long time to resolve. For things like CDP liquidations and interest rate adjustments which need to be done quickly, this cane be problematic.

Also, it can be very dangerous if the assets under management of the oracle (how much can be stolen by the oracle lying) exceeds the market cap of the oracle token (UNI in this case) by 2x since it becomes profitable to rob the system via governance attack.

3 Likes
18

Most liquidation bots require instant arbitrage or they won’t play. Requiring they take on a liquidation position and then hold it for an undefined amount of time results in the bots refusing to participate until the asset slips way down. For a volatile asset, this threshold for where the bots will start participating can end up being below the collateralize ratio.

1 Like
19

For things like CDP liquidations and interest rate adjustments which need to be done quickly, this cane be problematic.

Interest rate adjustments definitely do not need to be done quickly; once a week is fine imo.

For CDP liquidations, the idea is that you only need the process to start to put the CDP in limbo. The first liquidator would have to provide a lot of collateral to make sure the outcome resolves safely no matter which way it goes.

Also, it can be very dangerous if the assets under management of the oracle (how much can be stolen by the oracle lying) exceeds the market cap of the oracle token (UNI in this case) by 2x since it becomes profitable to rob the system via governance attack.

And this is exactly why I am proposing that the absolutely-massive-market-cap UNI takes on this task!

3 Likes
20

Sure, it’s possible that this would require the liquidation threshold to be significantly higher! I actually wonder what the UMA people would say to this; the “use some kind of escalation mechanism as an oracle” is an idea that as I remember they were the most focused on.

Another alternative is that Uniswap itself could make it easy for a large class of participants to be liquidators for free, and make escalation be part of the oracle (and expose the level of escalation in an API that stablecoins could use). UNI holders, Uniswap liquidity providers, etc…

3 Likes
21

The market cap of UNI is absolutely massive today, but it may not be absolutely massive tomorrow. If you don’t have a mechanism to ensure that the market cap remains higher than the assets at risk you can very easily end up in a dangerous situation. The only reason Augur works is because it has mechanisms in place to guarantee that the REP market cap always exceeds the market cap of the assets at risk (and even this is not perfect as parasitic open interest cannot be accounted for).

4 Likes