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

ETH-DAI / ETH-USDC uniswap LPs mostly fear of a parabolic ETH rally that would erase all fee profits.

Minting DAI against the uniswap liquidity tokens would be a reliable source of liquidity for hedging the risk with leveraged ETH exposure in a bullish environment.


Wanted to cross post this here:

Would love to know what the next steps are and if there is any room for community involvement. Is this just an issue of development work and capacity given the current circumstances? Do we need a separate discussion for how to properly build a uniswap oracle?

Next steps will be waiting for MIPs to be ratified. Once they are, MIP8 states that domain teams need to communicate their opinion of the asset (domain greenlight) and whether they are willing to work on it within two weeks. MIP9 details the process for the community greenlight poll which is run by the governance facilitator on a similar timescale.

Once those have both happened, we wait for the domain teams to do the required work on the asset. Then I believe someone (who?) submits a MIP12c2 subproposal which is then voted on at some point (when?) and may be part of the governance cycle?

Admittedly it gets a bit confusing towards the end there.

It seems to me that the main holdup here at this point (based on the various coms I’ve seen from foundation members) is that we are unsure of how to create an oracle for this asset at either an implementation level or a conceptual level.

I am wondering if the concerns around a proper oracle are mitigated if an open-sourced PoC oracle was created by the community for the oracle team to review. I.E. If the community were to build an example implementation would that be useful to the foundation’s oracle domain team and would that help speed things along here.

@NikKunkel would be the one to ask.

I messaged @NikKunkel and his suggestion was to start a new thread where we could hash out the details of a UNI-V1 oracle. Here’s that thread.

Please leave your comments in that thread if you have ideas about how the DAI:ETH UNI-V1 token might be priced.


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