Yearn Governance Roundup #9

Week Ending November 22, 2020

Nomad

Published in

Yearn Governance Roundup

5 min readNov 20, 2020

Welcome to the Yearn Governance Roundup — a weekly newsletter covering everything in the Yearn Governance pipeline.

📋 Quick Hits

⚖️ Proposals and Discussions

Make sure you join the governance forum if you want to get involved with these discussions! Table of contents:

Proposal: Bancor YFI/BNT Pool

milkyklim shared this proposal on Nov. 18. Here’s the summary:

Bancor has YFI/BNT pool with impermanent loss protection. You can provide liquidity both one-sided and two-sided (50/50). However, the size of the pool is too small. This proposal is check sentiment in the YFI community first and move on with 2 proposals on Bancor forum:
1. Bump YFI/BNT pool size limit.
2. Vote YFI/BNT pair in as large cap pair and earn liquidity mining rewards for staking.
This option is superior to what SushiSwap is offering — similar rewards with impermanent loss protection on top.
Ideally, after passing these 2 proposals we will have more on-chain locked liquidity for YFI treasury buy-backs.

In October Bancor released what they call Bancor v2.1. This new version of Bancor introduced single-asset exposure & impermanent loss protection to AMM pools with support for more than 60 ERC20 tokens—including YFI.

They also have an active proposal to implement a liquidity mining program that only includes the following:

Large-Caps: ETH, WBTC, USDT, USDC, DAI, LINK
Mid-Caps: OCEAN and renBTC

Since YIP-54 passed last week, the Operations Fund now has the authority to buy back YFI. That said: Buying back YFI in this way requires on-chain liquidity — the more the better! Klim’s goal with this proposal is to gauge community interest in encouraging Bancor governance to consider bootstrapping more YFI liquidity on their protocol.

If you have thoughts on this, share them here!

[Proposal] Create yDPI vault

the_anonymous_hash shared this proposal on Nov. 11. Here’s the summary:

Should this proposal be implemented, a yDPI vault will be created and used to deposit DPI into MakerDAO to mint DAI and delegate to yDAI vault, basically cloning the yETH vault functionality. The generated fees would be used to mint new DPI.

Some background: DPI is an ERC20 index fund. It represents 100% asset ownership of the underlying tokens. The intention of the fund is to allow ownership of key governance protocols within the DeFi space.

The functionality of the vault is aptly described in the summary, but it all hinges on two conditions: DPI getting accepted as collateral in the Maker system and Yearn getting whitelisted for the Maker YFIUSD oracle. So, while interesting, it is too early to fully implement or entertain this idea.

However, banteg did provide some alternative thoughts in the thread:

Redeem index token for its components
Put each component into corresponding Vault
Add our wrapper into the rebalancing pipeline

If you’re interested in providing feedback to this proposal or exploring the idea further, hop into the conversation here.

Bonus: Adjust the YFI-A Debt Ceiling on Maker

Shortly after launching as collateral, 1,031 YFI (>3% of supply) was locked in Maker CDPs and the 7 million DAI cap was quickly reached. As a result: There was a vote to raise YFI’s debt ceiling from 7 million DAI to 20 million DAI — which passed with overwhelming support!

This proposal now moves to this week’s Executive Vote in the Maker governance system. If passed, the change will officially be implemented in the protocol. You can get more information here.

Bonus: Subproposal to Whitelist Yearn Finance on YFIUSD Oracle

banteg shared this proposal on the MakerDAO governance forum on Nov. 19.

We’ve been through this process before with Maker’s ETHUSD and BTCUSD oracles. Yearn’s third Maker-based vault is being built, which takes YFI as a base asset and leverages it in a similar manner to our existing yWETH and yWBTC Vaults. It will maintain a Maker Vault and delegate the drawn DAI to the Yearn DAI Vault. To make the strategy able to rebalance and unwind, the vault needs access to the next OSM price.

Remember: The OSM is Maker’s Oracle Security Module. The OSM ensures that new price values propagated from Maker’s oracles are not taken up by the system until a 1 hour delay has passed. This means that in the event of a rapid collateral price cash, the yVaults will have an hour to fix their collateralization ratio to avoid liquidation. The ability to read data from Maker’s OSM requires services to go through a whitelisting process — hence Banteg’s proposal.

I don’t imagine that this proposal will run in to many issues, but you can track the conversation here.