[UNI-V1-DAI] Uniswap Dai Liquidity Token Collateral Application

About price Oracle (12). It can be computed directly from current ETH price. So no oracle is needed. If uniswap pool is not in balance it is subject to arbitrage anyways, so it will be balanced back quickly by anybody.

Idea to include uniswap pool tokens like DAI-ETH is fantastic. It has half of a volatility of ETH and actually better liquidity than ETH (since half of it’s value is DAI which You redeem right away)

1 Like

From the discussion on a UNI-V1 oracle, here is how you can avoid the issue of the pool not being balanced:

BAL_DAI = SQRT(INVARIANT / (1 / ETHUSD))          // (USDETH === 1 / ETHUSD)
SHARE_VALUE = (BAL_ETH * ETHUSD) + (BAL_DAI * 1)  // Value in USD

Huge fan of the idea of having Uniswap liquidity tokens as collateral on makerDAO :slight_smile:

However, Uniswap V2 is coming out in ~2 weeks. I think it would be better to wait and use Uniswap V2 liquidity tokens as collateral.

1 Like

We did discuss this briefly. What are the advantages and disadvantages of using only v2 over both v1 and v2?

1 Like

Similar to the benefit of having one DAI and not two - it encourages less liquidity fragmentation and is better for interoperability

1 Like

There is no reason to believe v2 would overtake or replace v1. Several reasons to prefer v1 over v2:

  • v1 uses ~50% less gas
  • v1 does not have “governance” that could steal revenue from liquidity providers. Governance should generally be viewed as a risk. WETH and Uniswap v1 have no governance, for example.
  • v2 splits token liquidity pairwise.

For the same reason, we should not expect Uniswap v2 to do better than Uniswap v1. Token liquidity is fragmented so slippage is higher and volume/returns are lower.

We know that v1 has high-yield and is secure, so we should use it, independent of whether or not v2 would succeed. If v2 also succeeds we can support it as well, but that is not a reason to delay v1 support.


Governance should generally be viewed as a risk.

Have you read the contracts? Please explain where there is governance risk introduced.

v2 splits token liquidity pairwise.

I understand where you’re coming from on this since I used to feel this way too. But liquidity that goes in an DAI/USDC pair is not liquidity that would otherwise go into a DAI/ETH pair - its a completely different position. I’m expecting most liquidity to be in WETH pairs and maybe 2-3 other common pairs.

1 Like

Maybe a quick poll to get the temperature of the room regarding UNIV1 vs UNIV2.

  • Uni-V1 liquidity Tokens
  • Uni-V2 liquidity Tokens

0 voters


Actually the Gaz* is not really gaz, it’s just a tag added to the transaction in order to keep 1 more value to the on-chain process.

We can adjust these parameters, even set them to 0 if we want.

I wouldn’t call it a risk in the traditional sense of loss of funds, but given the higher gas costs and the potential for fees to be diverted from LPs to the protocol, it seems possible that liquidity may be better on v1 than on v2.

With that being said, the ability to incentivize liquidity for non-ETH pairs could be beneficial (e.g. better liquidity for BAT/DAI or WBTC/DAI). Personally I am on board for v1 and v2!


Oracle Team Collateral Onboarding Evaluation

Author: Niklas Kunkel (Oracle Team)
Date: 05/13/20

Explanation of the Oracle Team Collateral Onboarding Methodology

Economic Impact

How much Dai can be expected to be generated against UNI-V1-DAI?

Concrete Data:
Token Contract Address: 0x2a1530C4C41db0B0b2bB646CB5Eb1A67b7158667
Circulating Token Supply: 22,791.80 UNI-V1-DAI
Token Market Cap of Circulating Token Supply ( TMC ): $10,067,385.90

  • Current ETH Balance of Pool = 25,340.52 ETH
  • Current DAI Balance of Pool = 5,020,821.36 DAI

Total Number of Holders: 841
Token Distribution: Top 20 holders hold 86.02% of Circulating Token Supply
Avg Collateralization Ratio of Maker Protocol ( avgCR ): 361.38%


  1. Assume a reasonable minimum collateralization ratio ( minCR ) based off empirical values in collateral portfolio. Since this token has exposure to ETH which has a collateralization ratio of 150%, let’s assume minCR = 150%.
  2. Market Cap Utilization ( MCU ), the amount of the TMC that can reasonably expect to be deposited in the Maker Protocol, is bounded by empirical values in collateral portfolio (e.g. [0.55%, 2.74%] )
    Currently the lowest and highest MCU in the Maker Protocol are [0.73%, 3.73%]


Estimated Lower Economic Impact = TMC * MIN(MCU) / avgCR 
Estimated Lower Economic Impact  = $10,067,385.90 * .0073 / 3.6138 = 20,336.47 DAI

Estimated Upper Economic Impact = TMC * MAX(MCU) / minCR
Estimated Upper Economic Impact  = $10,067,385.90 * .0373 / 1.5 = 250,342.33 DAI

Due to the limited amount of Dai that is estimated to be minted for UNI-V1-DAI the Oracle team is labeling this as Low Economic Impact

Given the distribution of token holders relative to the total number of token holders, how many users with significant sums of the proposed collateral are we reasonably targeting with this integration?
~20 people

Technical Complexity

Determine how complex integrating Oracles for this collateral type would be and how long it would take to implement such a solution.

Is a solution currently not possible because of a key missing component?
The Oracle stack doesn’t currently support Feeds querying data from the blockchain.

Are there enough high quality data sources available to construct a reliable, resilient, and secure Oracle for the proposed collateral asset?
No. Using the Uniswap API would be completely centralized and allow complete manipulation of the Oracle. The better alternative of using on-chain data is not currently supported.

Can the current tooling support the types of data sources that are needed?
No, see above.

Can the current tooling support the types of data modeling that are needed?
There is an active discussion in the Oracle section discussing the potential Data Model for UNI-V1-DAI. This model is not currently implemented in the Oracle tooling.

Does adding these features interfere with ongoing or planned development of new tooling on the Oracle Team roadmap?
This feature is already on the roadmap.

What dependencies (both technical and system), risks, costs, and latency are added to the Oracle Protocol as a function of these added features?
Getting blockchain data would require Feeds to run their own Ethereum node or subscribe to external services. Running a node adds complexity to the Oracle stack and introduces a new point of failure. It also would significantly increase the costs of running a Feed. Increasing costs while keeping compensation the same would negatively impact the security incentives for Feeds. Subsriving to an Ethereum node service like Infura would work but now has a centralized trust-dependency on Infura who could censor data intentionally (or unintenionally if the service goes down which it has in the past). All of these problems are solvable, but require extensive R&D.

Does adding these features require work from other stakeholders such as the Smart Contracts Team(s)?

How long would it take to design, implement, test, and deploy such a solution?
About 2 months to develop and test.

Given the R&D work involved to add support for blockchain data in a secure and reliable manner the Oracle Team considers this a high technical complexity project.


The combination of Economic Impact mapped against the Technical Complexity of onboarding a new collateral type can paint a picture of whether an Oracle Team ought to accept, decline, or defer a collateral onboarding application.

Low Technical Complexity High Technical Complexity
Low Economic Impact maybe decline
High Economic Impact accept maybe

Low Economic Impact x High Technical Complexity => decline


UNI-V1-DAI looks like a very interesting token in that it enables market-makers of Uniswap V1 to generate extra yield. That being said, given the current supply of UNI-V1-DAI tokens, the amount of Dai that could be expected to be generated is exceedingly low.

Due to the current limitations of the Oracle tooling, creating an Oracle that meets our quality standards for reliability and security is fairly difficult. These limitations are not unique to UNI-V1-DAI but extend to all classes of tokens that require verifiable on-chain data. Advanced tooling which can support this functionality is on the roadmap for the Oracles.

The combination of low economic impact and high technical complexity to implement an Oracle inclines the Oracle Team to decline this collateral type at the present time. Once the supply of UNI-V1-DAI has grown and the Oracle stack has been updated to include the necessary functionality, the Oracle Team will consider revising the reccommendation.


I don’t love the outcome, but accept the outcome based on the methodical approach. Hopefully factors will change to allow for its inclusion sometime soon.

Unfortunate. I hope we consider it again if the market cap for uniswap token pairs increases. Uniswap token pairs have much lower volatility than ether and are fully decentralized, so they would make a very good collateral if the economic impact was there.

1 Like

It seems that v2 is now launched


Total liquidity in Uniswap V2 is over half Uniswap V1 in less than 1 week! ETH is the most common pair still, but there are already over 40 DAI based pairs :heart_eyes:

Check this link to track DAI pairs: https://uniswap.info/token/0x6b175474e89094c44da98b954eedeac495271d0f

With DAI as the second most common pair after ETH, DAI/ETH becomes a common route when swapping between two arbitrary tokens (ABC -> ETH -> DAI -> XYZ)

B/c of this, I’m guessing DAI/ETH in Uniswap V2 will be a lot bigger than V1.

Also, I think there is a pretty good way to do this oracle stuff - will write up a proposal when I get the time.


Some other factors to consider regarding Nik’s post,

  • Instead of assuming minCR = 150%, a 130% CR or lower is reasonable. Uniswap LP tokens have less volatility than the underlying. A 130% CR is similar to a CR of 169% on ETH-A.
  • Market Cap Utilization could be higher than 3.73%, Uniswap LP holders would generally be more aware of the Maker ecosystem and vaults.
  • ETH-DAI LP tokens should have a SF discount, partially crediting the DSR to DAI held as collateral. It makes sense for LP tokens to use DAI vs CHAI/cDAI/aDAI because there’s more trading volume on DAI, and less fees to unwrap. Now by adding the SF discount this is another economic incentive for LP tokens to be used as collateral when in a high DSR environment. And you don’t lose on-chain liquidity in a high DSR environment.
    • ETH-DAI SF = SF - 0.5*DSR = (Base Rate + Risk Premium) - 0.5*DSR
  • The Economic Impact of adding LP tokens is not just from increased DAI minting. DAI LP tokens also have a big impact on the DAI Stablecoin Ecosystem. LPs add DAI liquidity to the ecosystem, adding a lot of utility to DAI. There’s a possible snowball effect, with more liquidity (less slippage), more adoption, more trading volume, more liquidity. Also some network effects with Uniswap V2, more ETH-DAI liquidity, possibly more pairs using DAI as a spoke. This is also a governance decision, whether the economic impact is high enough.

Some explanations on the 130% CR and SF discount.


I can’t wait to see what you come up with on this front. I had also took a stab at this as well. My implementation is linked from this forum post here if you want to take a look.

Looks like this was approved?

A bit confused since the last message I saw was the oracle team declining adding it - what happens in these situations?

The combination of low economic impact and high technical complexity to implement an Oracle inclines the Oracle Team to decline this collateral type at the present time. Once the supply of UNI-V1-DAI has grown and the Oracle stack has been updated to include the necessary functionality, the Oracle Team will consider revising the reccommendation.

Also Uniswap V2 DAI/ETH is now over $5M (basically tied with V1)


The greenlight poll vote passing just means that the community is interested in onboarding the asset. The domain teams are the group that has to actually do the work required to make that happen, so we we are waiting on the domain team’s workload.

If you would prefer to see V2 DAI/ETH, you are welcome to create an application under MIP6 to do so (details here)


Thanks for the explanation!

Will write up a V2 DAI/ETH proposal soon