text:
---
yip: 43
title: Improve YIP categories
status: Rejected
author: sam bacha <sam@freighttrust.com>
discussions-to: https://gov.yearn.finance/t/proposal-add-new-statuses-to-yip-proposals-non-protocol-change/3608

created: 2020-08-24
---

## Simple Summary

<!--"If you can't explain it simply, you don't understand it well enough." Simply describe the outcome the proposed changes intends to achieve. This should be non-technical and accessible to a casual community member.-->

Add new `status`(s) to `YIPs` so that author(s) may better manage their `YIPs` in the context of community collaboration and so that governance is given the proper procedures to foster community cooperation.

## Abstract

<!--A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what *will* be done if the YIP is implemented, not *why* it should be done or *how* it will be done. If the YIP proposes deploying a new contract, write, "we propose to deploy a new contract that will do x".-->

This will _only_ add to the current state of `proposal YIPs` in that it only changes the _potential_ `statuses` available of a `YIP`. It does not add any `protocol` changes: only documentation and governance procedures (off chain only).

I proposal the following changes to reflect a new state of possible 'YIPs':

1. Modifying YIP Templates
2. Modifying YIP Validator Gemfile
3. Modifying YIP README file

## Motivation

<!--This is the problem statement. This is the *why* of the YIP. It should clearly explain *why* the current state of the protocol is inadequate.  It is critical that you explain *why* the change is needed, if the YIP proposes changing how something is calculated, you must address *why* the current calculation is inaccurate or wrong. This is not the place to describe how the YIP will address the issue!-->

> The current state of procedures for `YIPS` is inadequate as it unnecessarily limits the possible outcomes of a proposed `YIP` while not affording both the author(s) nor the governance council flexibility in being able to deal with community driven `YIPs`

This is a _documentation_ and _procedure_ change. In fact there is no explicit description for proposing such changes in governance _(that I could find)._

This change is needed as it better explains the _intent_ of the YIP format to author(s). It also provides for governance additional functionality in their procedures so as to not potentially 'alienate' author(s) by rejecting a YIP when it could have been withdrawn. This ensures that also the author(s) are active in the process of their submitted proposal and in the larger community (in so far as they are knowledgable about other potentially competing YIPS.)

## Specification

_Additions in 'BOLD'_

Proposed - a YIP that is ready to be reviewed in a governance call.
Approved - a YIP that has been accepted for implementation by the Yearn community.
Implemented - a YIP that has been released to mainnet.
Rejected - a YIP that has been rejected.
**Withdrawn - a YIP that has been withdrawn by the author(s).**
**Deferred - a YIP that governance has decided to wait for another YIP/some other change that should be bundled with it together**
**Moribund - a YIP that was once Implemented. It is now Obsolete 'AND' requires no explicit replacement.**

The "Withdrawn" status is similar - it means that the YIP author has decided that the YIP is actually a 'bad' idea, or has accepted that a competing proposal is a better alternative.

### Workflow Specification

```
Proposed -> Approved -> Implemented
  ^                     |
  +----> Rejected       +----> Moribund
  |
  +----> Withdrawn
  v
Deferred
```

#### New Statuses for YIPs

> To be added are the following

- Withdrawn
- Moribund
- Deferred

### Overview

<!--This is a high level overview of *how* the YIP will solve the problem. The overview should clearly describe how the new feature will be implemented.-->

#### New YIP statuses

- Withdrawn
  Means that the YIP author has decided that the YIP is actually a bad idea, or has accepted that a competing proposal is a better alternative.
- Moribund
  Obsolete and requires no explicit replacement, it SHOULD be marked "Moribund"
- Deferred
  Governance placed status upon a YIP that means that they would like to know more information, or that they would like to see if the author(s) can work with another proposed YIP and combine it into a single YIP, etc.

### Rationale

The reasoning behind this is that it is unclear what will happen to a YIP should material facts change during its initial formal proposal and when its actually voted on by governance. Changes may be introduced between then, and the author may want to withdraw the proposal. This also frees up the governance council in that they are no longer obligated to reject every single YIP that may no longer be relevant, instead sharing the responsibility with the actual author(s).

### Technical Specification

<!--
NOTE: NO PROTOCOL CHANGES ARE PROPOSED
THE ONLY TECHNICAL CHANGES ARE IN THE RUBY VALIDATION PROCESS FOR YIPS
-->

Technical implementation involves:

- changes in the validation Gemfile
- changes in the template `.md` file

#### Changes in Template `.md` file

Below is a sample `.yaml` file to illustrate the _new_ header that should be used in the `yip-template.md` file

```yaml
---
YIP: <YIP number>
Title: <YIP title>
Author: < firstName, lastName, @githubUsrName, contact@address.com >
Type: <Informational | Standards Track>
Status: <WIP | Proposed | Approved | Deferred | Withdrawn | Rejected |
           Implemented | Replaced | Moribund>
    Version: <major>[.<minor>]
    Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
    Requires (*optional): <YIP number(s)>
    Implementation (*optional): <Added if YIP passes>

Discussions-to: <Create a new thread on https://gov.yearn.finance/ and drop the link here>

* Requires: <YIP numbers>
* Replaces: <YIP numbers>
* Replaced-By: <YIP number>
---
```

#### YIP Validator (Ruby Gem)

> current version: `1.0.2`, should be bumped to `1.1.0`
> Changes located [github.com/yearn/yip_validator/blob/master/lib/yip_validator/validator.rb#L25](https://github.com/yearn/yip_validator/blob/master/lib/yip_validator/validator.rb#L25)

```ruby
    validates_inclusion_of :status, in: ['WIP', 'Proposed', 'Approved', 'Implemented', 'Rejected']
```

```ruby
    validates_inclusion_of :status, in: ['WIP', 'Proposed', 'Approved', 'Implemented', 'Rejected', 'Withdrawn', 'Deferred', 'Moribund']
```

See Files Changed here [https://github.com/sambacha/yip_validator/tree/YIP-Proposed](https://github.com/sambacha/yip_validator/tree/YIP-Proposed)

### Test Cases

See `travis-ci` logs for the `Rub Gem` update here [https://travis-ci.com/github/sambacha/yip_validator/builds/181226022](https://travis-ci.com/github/sambacha/yip_validator/builds/181226022)

```bash
total:2, valid:2, invalid:0, errors:0
	statuses: [["Withdrawn", 1], ["Implemented", 1]]
  raises exception if it includes invalid yips
spec/fixtures/invalid/yip-7.md is NOT valid:	 {:status=>["is not included in the list"]}

```

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).


text:
---
yip: 65
title: Evolving YFI Tokenomics
status: Approved
author: 0xJiji, banteg, daryllautk, HAtTip3675, onlylarping, vany365, Wot_Is_Goin_On
discussions-to: https://gov.yearn.finance/t/yip-65-evolving-yfi-tokenomics/11994
created: 2021-12-23
---

## Authors

@0xJiji, @banteg, daryllautk, HAtTip3675, @onlylarping, @vany365, @Wot_Is_Goin_On

## Summary

Evolve the role YFI plays in Yearn over four distinct phases, cementing the vision of the token as the fundamental foundation of governance.

### Status

**Voting:** This proposal is currently in the voting phase. [Cast your vote on Snapshot](https://snapshot.org/#/ybaby.eth/proposal/0x8f7417fa5565d9f46e16618503e8808c36d51b2a9e8217a68c632d7c090d69d9).
You can learn about our voting rules in YIP-55[1].

## Abstract

**If adopted**, this proposal seeks to:

1. Direct a portion of YFI that is bought back by the Treasury as a result of BABY [[1]](#References) as rewards to those YFI token holders who actively participate in Yearn Governance.
1. Evolve the role YFI plays in Yearn Governance through four distinct components. These build on top of each other and thus come in a particular order:
   - **1: xYFI.** Distribute YFI that's been bought back with Treasury tokens as rewards in a YFI vault.
   - **2: Vote-locked YFI.** Introduce ve-style locking of YFI (veYFI) for up to four years (exact max duration tbd), where a longer locking duration gives a greater share of voting power and share of YFI rewards. An early exit from the lock is possible by paying a penalty that is rewarded to the other locked token holders.
   - **3: Vault Gauges + Voting.** Introduce _vault gauges_ where vault depositors stake their vault tokens and earn YFI rewards according to their veYFI weight. YFI are allocated to gauges based on weekly governance votes.
   - **4: "Useful work" features.** Expand the duties and responsibilities of veYFI voters, and their locked YFI, in exchange for earning additional protocol rewards. Pending the tbc v3 vault design.
1. Give the mandate to Yearn Developers to roll out the above components at their discretion as and when they become feasible.
1. Restrict the YFI eligible to vote in Yearn Governance as only those staked in xYFI (from Phase 1 and onwards) or vote-locked in Yearn (from Phase 2 and onwards).

## Background

This section covers general information that readers may find useful in order to better understand the motivation and specification of the proposal. Namely the community exploration of various tokenomics ideas, the source and quantity of YFI rewards proposed to be used, some general information about Curve's ve-mechanic, and what was deliberately kept out of scope of this proposal.

### Call for tokenomics ideas

On October 6th 2021 there was a call for tokenomics ideas on Yearn’s governance forum[[2]](#References) that attracted over 5k views. Over 200 people completed a survey aimed to express the preferences of YFI tokenholders, results of which can be found in the References section.[[3]](#References) A discord chat gave those interested an opportunity to express their views. There were also multiple independent groups created with high degree of engagement, culminating in a signalling vote[[4]](#References) which aligns with the components of this proposal. This proposal attempts to bring together the discussions that have occurred over the last 2 months.

### State of Holdings & Buybacks

YIP-56: Buyback and Build (BABY)[[1]](#References) was adopted in early January 2021, instructing Treasury to buy back YFI with excess Yearn treasury tokens. A few weeks later, the yvDAI vault suffered an incident[[5]](#References) where 11m DAI were lost. The Treasury compensated those affected, making vault depositors whole. Since then, the Treasury has been on a path of recovering from this expense while at the same time saving for a potential market downturn and a prolonged bear market where a runway would be required during periods of lower protocol activity. While the details can be found in the quarterly financial reports[[6]](#References) the high level summary is that Yearn has gone from $11m in debt in February to $30m+ in liquid assets in November.[[7]](#References) Despite saving more than $40m, the Treasury has still been able to buy back **~300 YFI year to date** at a cost of ~$10m equivalent.[[8]](#References)

Now that the yvDAI debt has been paid off and the bear market buffer exists, Treasury expects to be able to direct **~$35-$45m** to YFI buy-backs on an annual run-rate basis assuming TVL and margins stay constant.

This would equate to 1,100-1,400 YFI per year at a YFI price of ~$30k, or somewhere around **100 YFI/month**. These bought back YFI could sustainably be used in a reward system, without impacting overall Treasury health negatively.

### Curve's ve-mechanism in a nutshell

An incomplete and very high level description of this mechanism is as follows:

- Users can lock CRV into veCRV for a duration of up to 4 years.
- Depending on the locking duration, users get different weights linearly: 4 years = 100% weight, 1 year = 25% weight, etc. The longer the lock, the more voting power and influence, and the more rewards can be earned.
- CRV rewards are distributed through _gauges_ in which users stake their Curve LP tokens. Each gauge gets allocated a different amount CRV to emit, based on weekly voting amongst veCRV holders.
- Based on their veCRV lock, users can boost their rewards of up to 2.5x when they claim CRV rewards from gauges.
- Unlike typical ERC-20 tokens, veCRV is non-transferable. This can be bypassed via wrapped derivatives such as the Yearn yveCRV vault or Convex's cvxCRV product.
- Each account can only have one single veCRV lock (of a certain duration).
- As the lock duration decays, so does the influence. If a user initially locked for 4 years for 100% weight, once 1 year has passed, their weight will be 75%. Users therefore have to constantly extend their locks (up to the maximum 4 years) in order to maintain their weight.

### Out of scope

The following topics were intentionally left outside of the scope of this proposal. Each one is potentially important and probably would be best served by its own stand alone proposal. They are also independent from what is proposed here, and could be added as extensions that build on top of the concepts covered in this proposal.

- **New YFI Emission.** The current proposal assumes no new YFI emission or minting. Emission could be attached to the components introduced in the phases, but is not an explicit requirement at this point.
- **Liquidity Mining Program.** A new liquidity mining program, whether funded by Treasury YFI assets or by new emission, is somewhat orthogonal to the topics covered in this proposal, and could be introduced with or without the concepts covered here. There are numerous trade offs to consider, better discussed in a dedicated proposal.
- **Unit bias conversions.**
- **Detailed specs of "useful work" features.** The v3 vault specification is still in the design and discovery phase. Whilst ideas such as vault insurance, safety modules, and vault allocations are mentioned in this context, it is premature to discuss specifics as such proposals are far from being ready to go live.

## Motivation

### Benefits

The following are some of the properties where the new tokenomics design is believed to improve over the previous state:

- **Incorporates YFI buybacks.** The mandate of YIP-56 is unchanged, the new design builds on top of and integrates the bought back YFI.
- **Is a sustainable ecosystem.** The new design does not create a drain on Treasury assets. Instead there are reinforcing flywheel effects where tokenomics rewards drive more TVL, that in turn drive more fees, that in turn drive more YFI buybacks, that is then used to reinforce the tokenomics.
- **Incentivizes a long term view on Yearn.** Token holders are motivated to support the protocol over the longer term rather than to speculate in the short term.
- **Disproportionately rewards those most loyal.** Weaker conviction holders effectively become diluted over time by the stronger conviction holders.
- **Limits rent-seeking benefits.** Over time as the components are introduced, the design avoids holders being rewarded for nothing. Or letting the largest holders accumulate more at the expense of the smaller holders.
- **Makes vaults more competitive.** Additional YFI earned from vault gauges are effectively added yield for depositors, in proportion to how dedicated they are in their support.
- **Motivates 3rd party protocols and DAOs to become YFI holders.** Yearn products are used as a yield components of a broader DeFi stack, and integrated in wallets and protocols. With this design, they have incentives to direct rewards to vaults and products they are using.
- **A seamless experience for integrators.** Participation is _optional_. This maintains the simplicity integrators have come to appreciate and makes it easy to reason about vault behavior. Only those who are motivated to do so can participate.

### Future possibilities

The proposal also opens up doors for potential further improvements that extend or build on top of these concepts, including:

- **yOptions program for contributors**, where contributors can acquire YFI at a discount based on how long these are locked into the protocol for.
- **Insurance/Backstop functionality**, where vaults could be insured against loss based on the amount of YFI locked, which in turn could be used to draw up stablecoin CDPs to repay users in catastrophic events.
- **New YFI Emission to veYFI holders**, where new YFI is minted according to some emission schedule and used to reward veYFI holders based on their lock duration.
- **Partnership program adopting veYFI to boost partner performance**, where partners can earn more based on their veYFI size and lock duration.

### Risks

- **Governance attacks,** where one or several actors accumulate sizable positions of YFI and can control rewards and decisions of the protocol. These risks exist today, and are mitigated somewhat by the limited supply of YFI and how the strong demand for YFI amongst Yearn contributors makes such attacks costly.
- **Not enough rewards to make locking attractive,** where vaults may not generate enough tokens to the Treasury to buy back enough YFI to motivate YFI holders to lock into veYFI. This has somewhat of a balancing effect, where as demand for locking decreases, so does the share of the rewards for those who actually do lock. If it's determined that the equilibrium does not lead to enough YFI being locked, additional YFI could be minted and rewarded to veYFI holders as previously mentioned in "Future possibilities".
- **YFI liquidity dries up.** Currently YFI is traded on multiple centralized and decentralized exchanges. As demand for using YFI elsewhere grows, there may be a lack of YFI/ETH LP supply in liquidity pools and lack of interest in general YFI market making, leading to YFI becoming more illiquid. In such an event, additional incentives may be required in order to ensure a healthy liquidity exists for trading in and out of YFI. The Treasury may also explore owning some of this liquidity outright.

### Alternatives considered

- OlympusPRO style designs
- Voters voting on fees
- YFI as a fee discount
- Distribute treasury YFI

## Specification

### 1. Spend bought back YFI in tokenomics rewards

- Use a portion of bought back YFI from BABY to finance a new tokenomics program.
- The 6,666 YFI that were minted as part of YIP-57: Funding Yearn's Future[[9]](#References) are not used for this purpose.

### 2. Evolve YFI through four components

_In required order:_

#### 2.1 xYFI

- A typical Yearn vault with YFI as a want token (potentially repurposing the existing yvYFI vault).
- Receives bought back YFI as rewards.
- Does not have any locking requirement.
- Does not charge fees.

![xYFI diagram](assets/yip-65/01-xYFI.svg)

#### 2.2 Vote-locked YFI

- Locking similar to the ve-style program of Curve.
- YFI can be locked up to 4 years into veYFI, which is non-transferable.
- The maximum lock duration is still tbd, but will be in the range of min 1 year, max 4 years.
- Locking duration gives the same linear weights, so if max duration is 4 years, this is 100%, and 2 years = 50% etc.
- Weights decay as the remaining lock duration decreases, and can be extended up to the max lock duration.
- Replaces xYFI, where a user _must_ have a veYFI lock in order to continue to earn rewards. No lock leads to no rewards. Maximum lock, continuously renewed, maximizes rewards.
- It's possible to exit the lock early, in exchange for paying a penalty that gets allocated to the other veYFI holders.
- Penalty size may be fixed (i.e. 50%), or may be depending on the remaining lock duration.

![veYFI diagram](assets/yip-65/02-veYFI.svg)

#### 2.3 Vault gauges + Voting

- Vault gauges allow vault depositors to stake their vault tokens and earn YFI rewards according to their veYFI weight.
- YFI are allocated to gauges based on weekly governance votes. Each gauge can get a different amount of bought back YFI to emit.
- Based on their veYFI lock, users can boost their rewards of up to 2.5x proportional to the amount of vault tokens deposited, when they claim YFI rewards from gauges. The greater the amount of veYFI, the more vault deposits can be boosted for the user.
- Inspired by Andre Cronje's initial design of Fixed Forex[[10]](#References), in order for gauge rewards to be claimed, the user must have a veYFI lock. Depending on their lock duration, they are entitled to a different share of gauge rewards: if max lock = 4 years, and user is locked for 4 years, they are entitled to 100% of their rewards, if user is locked for 2 years = 50% of rewards, if user has no lock = 0% of their rewards. The difference is paid as penalty to veYFI holders, as an additional source of yield.

![gauges diagram](assets/yip-65/03-gauges.svg)

#### 2.4 "Useful work" features

- This is driven by requirements of the yearn v3 vault design (still tbd).
- veYFI holders would be able to do useful work for the protocol and earn greater rewards as a result.
- Examples of useful work could be, but does not necessarily have to be: Configuring vault parameters, vault fees, strategy allocations, providing vault insurance, protocol backstop, and many other additional functionality.
- No useful work will be introduced without consulting YFI voters beforehand through YIPs.

### 3 Give Yearn Developers the mandate to roll out the above components

- Components can be introduced based on the requirements as set out here, with minor modifications as deemed necessary.
- Exact setting of parameters such as max lock duration and penalty system is left to be set at the discretion of the implementers.
- There is no requirement to add all four components, but components need to be in the order outlined as they build on each other.
- Timelines are at the discretion of the contributors doing the implementation work.

### 4 Restrict the YFI eligible to vote

- Once xYFI is introduced, only YFI staked is eligible to vote in Yearn Governance.
- Once veYFI is introduced, only veYFI is accepted voting power in Yearn Governance.

## Vote

[Cast your vote on Snapshot](https://snapshot.org/#/ybaby.eth/proposal/0x8f7417fa5565d9f46e16618503e8808c36d51b2a9e8217a68c632d7c090d69d9)

## References

1. https://gov.yearn.finance/t/yip-56-buyback-and-build/8929
1. https://gov.yearn.finance/t/call-for-ideas-yfi-tokenomics-revamp/11573
1. https://px2hc2blifd.typeform.com/report/yj5p5iIo/zIj0Alc03WFWfKTg
1. https://yearn.snapshot.page/#/proposal/0x783cb3d57dd59b2827f6a42967375f06504cc947ebaa3c0e495c7b29ffd47aea
1. https://github.com/yearn/yearn-security/blob/master/disclosures/2021-02-04.md
1. https://github.com/yearn/yearn-pm/tree/master/financials/reports
1. https://twitter.com/bantg/status/1461910717494398983
1. https://www.yfistats.com/financials/YFIBuybacks.html (Page 2)
1. https://gov.yearn.finance/t/yip-57-funding-yearns-future/9319
1. https://andrecronje.medium.com/fair-launches-decentralized-collaboration-and-fixed-forex-ab327a2e4fc4

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

## Information

_Source: [Snapshot](https://snapshot.org/#/ybaby.eth/proposal/0x8f7417fa5565d9f46e16618503e8808c36d51b2a9e8217a68c632d7c090d69d9)_

| Name           | Value                                                                           |
| -------------- | ------------------------------------------------------------------------------- |
| Snapshot Space | [ybaby.eth](https://snapshot.org/#/ybaby.eth)                                   |
| Strategie(s)   | YFI, delegation                                                                 |
| Author         | wentokyo.eth                                                                    |
| IPFS           | https://cloudflare-ipfs.com/ipfs/QmNxWT18NXKcvJJVbR63bYHSbKenw1oKP95wuzLM8dicrc |
| Voting System  | Single choice voting                                                            |
| Start date     | Dec 23, 2021, 12:03 PM                                                          |
| End date       | Dec 28, 2021, 12:03 PM                                                          |
| Snapshot       | https://etherscan.io/block/13859920                                             |

## Results

| Result | Value |
| ------ | ----- |
| Yes    |  908 YFI (99.68%)     |
| No     |  2.9 YFI (0.32%)      |

repo_name: yearn/YIPS

repo_language: HTML

file_name: config

mime_type: text/plain


text:
---
yip: 62
title: Fund Builder-First Legal Activism DAO
status: Implemented
author: Andre Cronje (@andrecronje), tracheopteryx (@tracheopteryx), lexnode (@lex-node), Judge Jowday (@judge-jowday), Sh Brennan, Birdman Haxxor
discussions-to: https://gov.yearn.finance/t/yip-63-fund-builder-first-legal-activism-dao/11280
created: 2021-08-06
---

## Authors

[@andre.cronje](https://twitter.com/andrecronjetech) [@tracheopteryx](https://twitter.com/tracheopteryx) [@lex_node](https://twitter.com/lex_node) [@judge_jowday](https://twitter.com/judge_jowday) [@sh_brennan](https://twitter.com/SH_Brennan) [@birdman_haxxor](https://twitter.com/Birdman_Haxxor)

## Summary/Abstract

Amidst intensifying regulatory scrutiny of DeFi, we propose that Yearn contribute to a new LeXpunK_DAO dedicated to legal advocacy for yearn and other builder-centric DeFi communities. The LeXpunK_DAO will be governed by builders from contributing communities (including yearn) and practicing lawyers from the [LeXpunK Army](https://judge-jowday.medium.com/rise-of-lexpunk-army-5afad79966f1). 5% of the current supply of L3X, the non-transferable reputational token of the LeXpunK Army, would be airdropped to YFI holders who support this proposal, to enable direct sentiment polling on relevant legal issues from the Yearn community. LeXpunK will effect additional airdrops from time to time, proportionally in line with the relative contributions of other builder communities, with the goal of forming a broad coalition to pool resources for funding shared advocacy goals.

A similar proposal is being made to Curve governance, here: https://gov.curve.fi/t/fund-a-builder-first-legal-activism-dao/2025. We also aim to make similar proposals to other value-aligned DAOs and prominent ecosystem builders if the Curve and Yearn proposals are successful.

### Status

_This proposal is currently in the discussion phase_.

🗳 [Cast your vote on Snapshot.](https://snapshot.org/#/ybaby.eth/proposal/QmPK9AqeoV6v5xeuiTeFcj9Px7y87KMQ1gGhvHft2GMtqE)

You can learn about our voting rules in [YIP-55](https://gov.yearn.finance/t/yip-55-formalize-the-yip-process/7959).

## Motivation/Rationale

Growing mainstream awareness of DeFi is coinciding with institutional outrage over the "Wall St. Bets" phenomenon and political change in the United States to brew a perfect storm of aggressive legal threats against DeFi:

- mainstream media calls DeFi a "[shadow financial market](https://www.politico.com/news/2021/07/24/shadow-financial-market-spooks-regulators-500696)" and warns that regulatory action is imminent
- new SEC Chair Gary Gensler concludes [a recent speech](https://cointelegraph.com/news/sec-chairman-says-cryptocurrency-falls-under-security-based-swaps-rules) to the American Bar Association Derivatives and Futures Law Committee with a warning that many DeFi platforms may involve securities swaps
- CFTC Commissioner Dan Berkovitz, having googled DeFi, [positioned it](https://www.cryptoglobe.com/latest/2021/06/cftc-commissioner-dan-berkovitz-is-concerned-about-decentralized-finance-defi/#:~:text=%E2%80%9CIn%20a%20pure%20'peer%2D,customers%20whole%20when%20processes%20fail.) as being squarely incompatible with the policy of 'mandatory intermediation' enshrined in CFTC regulations on leveraged retail commodities transactions and commodities swaps and referenced unfair advantages DeFi has to TradFi due to the lack of regulated intermediaries
- many blue-chip DeFi projects have already been [called in front of regulators](https://africa.businessinsider.com/markets/us-regulators-are-reportedly-meeting-with-defi-companies-as-scrutiny-of-crypto-builds/1gqq2kc) or are [receiving SEC subpoenas](https://twitter.com/arrington/status/1418314425795231754) and are forming organized political lobbying efforts which may have distinct and zero-sum goals

DeFi is a DAO of DAOs. These DAOs have many shared goals. For instance, we all aim to build, use, and enjoy open financial technologies. However, DAOs also compete with one another and often differ in ethos and strategy.

Existing advocacy orgs like the Blockchain Association, Coin Center, and the Uniswap-funded DeFi Education Fund have mutually overlapping membership and staff which are heavily intertwined with Silicon Valley venture capital funds and traditional crypto businesses like Coinbase. Many of the teams most directly represented by these organizations have pursued dual token/equity strategies, which means they also seek to accrue value to their equityholders through KYC-gated and censorable forks of their protocols which will cater to institutions and 'fintechs'.

Builder-centric, bottom-up communities like Yearn, Curve, and SushiSwap have a different cultural ethos and a different story to tell. We are spontaneous, cryptonative communities of builders that have no TradFi backup plan and value openness, lack of hierarchy, and creativity above all else. Thus, we should have our own unique voice in the evolving regulatory landscape, and by doing so we may be able to make or emphasize lines of legal argument that are not as available to other kinds of projects. After all, the former head of the SEC's CorpFin division [views "sufficient decentralization" as the point where traditional regulations end](https://www.sec.gov/news/speech/speech-hinman-061418), and there is nothing more decentralized than a community of builders, users and investors that come together with no contracts or rules, no board of directors or stockholders to answer to, yet somehow build remarkable innovations together.

We believe that cryptolaw should be done in the crypto spirit. If DeFi communities want to show regulators, lawyers, and politicians what is special about DeFi, then Orwellian-named trade associations and non-profits staffed by D.C. insiders are not the best way to go. Instead, we should present ourselves as we are--as DAOs, as token communities, as builder communities. The values underlying these modes of expression are too important to cast aside in the name of expediency when the going gets tough and there are legal threats. On the contrary, the values of openness, transparency, and decentralization are DeFi's greatest defense to traditional regulation and should be front-and-center when regulators and politicians interface with DeFi communities. This is why [LeXpunK](https://lex-node.medium.com/lexpunk-a1bb9f769ec) was created--to bring lawyers and builders together under a shared ethos that is as disruptive to law as it is to finance.

Through a new, community-funded LeXpunK_DAO, we will not merely hire existing lawyers or fund existing traditional advocacy groups--We will bootstrap a new community of lawyers and builders working side-by-side to legitimize and protect shared creative values. This community will become a flywheel unto itself and yield benefits long after these initial donations are spent and far beyond the benefits of the specific projects these donations end up funding.

## Specification

### Overview

LeXpunK_DAO will mix long-term strategic advocacy campaigns with rapid-response 'guerilla lawfare' raids. LeXpunK_DAO will be structured either as a Moloch DAO, Gnosis multisig, or other DAO implementation; in any case, with balanced representation of LeXpunK Army members and representatives of the contributing DeFi communities. Un-committed contributed funds will be 'ragequittable' at the discretion of each community's representatives. We estimate that $1M from Yearn and $1M from Curve would provide a sufficient starting point to get the ball rolling (this is far less than the massive warchest recently raised from Uniswap to fund already heavily VC-/Silicon-Valley-backed advocates).

#### A. Campaigns

Campaigns are major strategic initiatives, such as:

- a landmark position paper advocating for positive analysis under securities law, commodities law or tax law of Yearn-relevant DeFi primitives such as flash loans, vault strategies, CDPs, and deposit-claim tokens (e.g., yAssets)
- a legal defense of DeFi developers against regulatory litigation;
- proposed 'safe harbor' legislation legalizing key aspects of DeFi;
- if/when the SEC files a case premised on a novel, expansive view of securities laws that could adversely affect DeFi builders (for example, that all project participants are collectively responsible as an '[unincorporated association](https://lawstreetmedia.com/tech/sec-charges-five-in-connection-with-2b-bitconnect-securities-offering/)'); the LeXpunK_DAO would file an _amicus curiae_ brief in the litigation

Campaigns will be defined with thorough specifications and funded with pre-announced bounties. Campaign fulfillment will be by teams hand-picked by the Advocacy Fund Multisig. Relevant experts--both lawyers and developers--will be recruited from within the LeXpunK community, other DeFi communities and, if needed, from traditional law firms; these will be our 'MandDAOlorians' working for a piece of the bounty. A 'taskmaster' will be assigned from the most trusted ranks of the LeXpunK Army--typically an experienced attorney--who is not eligible for the bounty, but receives a flat fee to monitor the working group's progress, help remove blockers and make the final determination of when the project has been completed to spec and the bounty is due to be paid. Upon project completion, the team members themselves will decide how the bounty should be allocated, using another yearn ecosystem offshoot--[coordinape](https://coordinape.com/). Campaigns will be pre-checked with the LeXpunK community through L3X snapshot polls.

#### B. Raids

Raids are rapid-response initiatives tailored to respond to current events in realtime. Examples of raids would be:

- a politician like Elizabeth Warren sends an [adversarial public letter](https://www.warren.senate.gov/imo/media/doc/Draft%20SEC%20Crypto%20Exchange%20Letter%2007.7.2021%20clean.pdf) regarding DeFi to a regulator; the LeXpunK_DAO funds a rapid public response detailing community views about her questions;
- a contributing DeFi protocol suffers from a hack or exploit and the team needs help coordinating with law enforcement or CEXs to help block or recover funds
- builders from a contributing community receive an informal SEC inquiry; the LeXpunK_DAO helps strategize and marshal a legal team to defend the builder

Raids will be funded on an emergency, _ad hoc_ basis at the discretion of the LeXpunK_DAO.

## Conclusion

The time is now. Let's do cryptolaw the crypto way.

![photo_2021-08-06 17.06.53](/YIPS/assets/yip-63/figure1.jpeg)

## Binding Snapshot Vote

🗳 **Voting is live!**
https://snapshot.org/#/ybaby.eth/proposal/QmPK9AqeoV6v5xeuiTeFcj9Px7y87KMQ1gGhvHft2GMtqE

## References

Read up on LeXpunK:
(1) [LeXpunK: The New Legal Praxis](https://lex-node.medium.com/lexpunk-a1bb9f769ec)
(2) [Autonomous Lawyering](https://lexnode.substack.com/p/autonomous-lawyering)
(3) [Rise of LeXpunK Army](https://judge-jowday.medium.com/rise-of-lexpunk-army-5afad79966f1)

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

## Information

_Source: [Snapshot](https://snapshot.org/#/ybaby.eth/proposal/QmPK9AqeoV6v5xeuiTeFcj9Px7y87KMQ1gGhvHft2GMtqE)_

| Name           | Value                                                                           |
| -------------  | ------------------------------------------------------------------------------- |
| Snapshot Space | [ybaby.eth](https://snapshot.org/#/ybaby.eth)                                   |
| Strategie(s)   | pagination, delegation                                                          |
| Author         | 0x7A1057E6e9093DA9C1D4C1D049609B6889fC4c67                                      |
| IPFS           | https://cloudflare-ipfs.com/ipfs/QmPK9AqeoV6v5xeuiTeFcj9Px7y87KMQ1gGhvHft2GMtqE |
| Voting System  | Single choice voting                                                            |
| Start date     | Aug 6, 2021, 10:00 PM                                                           |
| End date       | Aug 11, 2021, 10:00 PM                                                          |
| Snapshot       | https://etherscan.io/block/12971775                                             |

## Results

| Result | Value             |
| ------ | ----------------- |
| Yes    | 862.01 YFI (100%) |
| No     | 0 YFI (0%)        |


text:
---
yip: 5
title: Reducing YFI weekly supply
status: Rejected
author: Damir Bandalo (@sikiriki12)
discussions-to: https://gov.yearn.finance/t/proposal-5-reducing-yfi-weekly-supply/110
created: 2020-07-20
---

## Simple Summary

Currently the weekly supply increase of YFI is 30,000 per week. Vote under proposal #0 is if more YFI tokens should be minted.

I’m voting “FOR” on proposal #0 as I think continuous incentivization of LPs is important for growth of the platform.

However I also think early participants of the platform that are taking more risk should be rewarded with a higher % of YFI supply.

This is a proposal for reducing the weekly issuance rate with a simple halvening model similar to that of BTC but accelerated due to the significant interest in the platform (so a long discovery period is not necessary) and with a inflation floor to always have some level of incentive to attract new users to the platform.

So issuance week 0 is 30,000. Issuance week 1 should be halved to 15,000. (5k per pool). After that every 4 weeks the rewards should half to 7,500 starting from week 5, 3,750 starting week 9, 1,875 starting week 13, 937.5 starting week 17, 468.75 starting week 21 and final halvening in week 25 to a long term issuance rate of 234.375.

![Issuance](assets/yip5.png)

In summary. If proposal #0 passes the issuance model should be altered as described above.

**FOR**: Support the new issuance model.

**AGAINST**: Do not support the new issuance model.

## Metadata

| Name                | Value                                      |
| ------------------- | ------------------------------------------ |
| Proposed by         | 0x5398850A9399Da87624874704FEAa8A9C6C4089B |
| Total for votes     | 1123689.4842 (69.84%)                      |
| Total against votes | 485164.6894 (30.15%)                       |
| Quorum              | 6.19% 𐄂                                    |
| Start block         | 10496829                                   |
| End block           | 10514109                                   |

Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/)

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).


text:
---
yip: 51
title: Set Vault v2 fee structure
status: Approved
author: banteg (@banteg), lehnberg (@lehnberg), milkyklim (@milkyklim), tracheopteryx (@tracheopteryx)
discussions-to: https://gov.yearn.finance/t/yip-51-set-vault-v2-fee-structure/7752
created: 2020-11-06
---

## Summary

- Focused proposal to set the fee structure for Vaults v2 to:
  1. No withdrawal fee
  2. Management fee (2%)
  3. Performance fee (20%)
- The proposal leaves:
  - Total fees collected at roughly the same level as for Vaults v1
  - Strategist reward allocation unchanged
  - YFI staking and rewards unchanged
  - Treasury management unchanged

## Background

The high level design of the next iteration of Yearn Vaults, v2, has been voted on and approved by YFI holders. It is currently in the later stages of the development cycle. Testing has begun, and security audits are in progress.

With the new vaults likely being weeks away from launch, it is high time to finalize how fees will be collected in them.

### Out of scope

There are currently active discussions underway in the community about many related topics, such as to what extent:

- Rewards should be distributed to YFI stakers
- Strategist creators should be rewarded for their contributions
- Contributors should be allocated a portion of rewards for the purpose of long term incentivization

Those questions are not answered by this proposal, and are not discussed further here. Specifically, anything that concerns what fees are spent on, how different stakeholders are compensated, or how the treasury should be run, is not covered by this proposal and is assumed to be unchanged.

### In scope

Instead, the focus here is to determine _how fees are collected_, and _the total amount collected_, with the intention to meet the following objectives:

- **Keep fees at roughly the same level.** The proposal should not lead to a significant change in the overall fee levels that are in place today with Vaults v1.
- Ensure fees incentivize the desired behavior among various stakeholders:
  - **Users** should be encouraged to keep funds in a vault if it performs well, and withdraw if the vault under-performs.
  - **Yearn** should be encouraged to design the best possible vaults, by ensuring rewards go up as a vault attracts and retains capital, and go down as capital leaves the vault. Similarly, rewards should increase if the vault performs well, and decrease if it under-performs.
  - **Third party integrations** should be encouraged to integrate Yearn vaults in their own products and services. It should be easy for them to reason about the expected behavior when depositing and withdrawing, and the fees charged by the vault.

## Motivation

### Previous fee structure, Vaults v1

- 5% performance fee, out of which
  - 4.5% went to Treasury
  - 0.5% went to the Strategist
- 0 to 0.5% withdrawal fee
  - 0% when funds were available in the Vault
  - 0.5% when funds had to be withdrawn from the Strategy

### Problems with a fee on withdrawals

- **Charges Users when they are the least happy with the vault.** You are charged a withdrawal fee when you no longer use the vault. If the vault performs, you would leave your funds in it and avoid paying for the service.
- **Rewards Yearn when there is capital flight.** More money leaving the vault leads to more fees, when it should be the opposite.
- **Can be gamed.** Astute users and integrations can time it so that they make free withdrawals in the period after the vault has seen deposits, as long as it's done before those funds have been sent to the Strategy for investing.
- **Makes fees unpredictable for integrations.** It's unclear what the fees charged will be prior to the actual withdrawal, making it harder for third party integrations to calculate ROI accurately.

### Benefits with a management fee

- **Continuous pay based on usage.** The vault provides a service that people are paying for, continuously, based on the time their capital is in the vault. There is no incentive to withdraw late or early.
- **Encourages optimizing for retention.** Yearn earns more fees when users keep funds in the vault, and makes less when they withdraw.
- **Benefits composability.** Makes it easier to integrate Vaults with other products and services.

### Comparing fees with v1

The backtesting data produced shows how the new fee model is delivering roughly the same amount of total fees, compared to the model used in Vaults v1:

![bar chart|1800x1200,30%](assets/yip-51/figure1.png)

|         | Withdrawal fee | Performance fee | Management fee |  Total fees |    % |
| ------- | -------------: | --------------: | -------------: | ----------: | ---: |
| **Old** |    \$2,243,078 |       \$466,822 |            N/A | \$2,709,900 | 100% |
| **New** |            N/A |     \$1,867,288 |      \$699,237 | \$2,566,525 |  95% |

#### Comments

- The previous withdrawal fee accounted for a whopping **83%** of all fees collected. This is very high for a fee that is unrelated to actual performance of the service.
- In contrast, the management fee in Vaults v2 would only account for **27%** of total fees.
- A much larger portion of fees are now made out of the performance fee component, **17%** of total fees in the old model, **73%** in the new model. This means that incentives are better aligned as Yearn earns most of it fees and Users pay most of their fees only if the Vaults are performing well.

## Specification

### New fee structure

- 0% withdrawal fee
- 2% annualized management
  - Full amount allocated to Treasury
  - Accrued per block
  - Collected on each harvest)
- 20% performance fee
  - 19.5% allocated to Treasury
  - 0.5% allocated to the Strategist (unchanged to v1)

## Vote

**For:** Release Vaults v2 with the proposed fee structure.

**Against:** Release Vaults v2 with some other fee to be defined fee structure.

## Metadata

| Name                | Value                                      |
| ------------------- | ------------------------------------------ |
| Proposed by         | 0x7A1057E6e9093DA9C1D4C1D049609B6889fC4c67 |
| Total for votes     | 1.77k YFI (99.74%)                         |
| Total against votes | 4.53 YFI (0.26%)                           |
| Start date          | Nov 7                                      |
| End date            | Nov 10                                     |

_Source: [Snapshot](https://snapshot.page/#/yearn/proposal/QmSaYHR97LDMDvg9xeTfdNZw6aqL9njxBKM6JVFtCYxKvB)_

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).


text:
---
yip: 45
title: Add a bounty for proposing YIPs that are implemented
status: Implemented
author: Sunil Srivatsa (@alphastorm)
discussions-to: https://gov.yearn.finance/t/yip-45-add-a-bounty-for-proposing-yips-that-are-implemented/3337
created: 2020-09-01
---

## Simple Summary

Add a bounty for proposing YIPs that are implemented.

## Abstract

Implement a \$500 yCRV bounty for proposing a YIP that reaches the ‘Implemented’ phase, payable from the treasury.

## Motivation

This should incentivize community members to propose useful YIPs which should be beneficial for the protocol. This is inspired by the 500 sUSD bounty that Synthetix pays out for [implemented SIPs](https://github.com/Synthetixio/SIPs#contributing).

**FOR**: Start offering a bounty for proposing YIPs that are implemented.

**AGAINST**: No change.

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).


text:
---
yip: 14
title: Yearn Rewards Reserve
status: Rejected
author: YieldBouncer (@yieldbouncer)
discussions-to: https://gov.yearn.finance/t/yip-14-yearn-rewards-reserve/136
created: 2020-07-24
---

## Simple Summary

Without a cash reserve, it is difficult to sustain and improve the protocol further. As a community, we need to start capturing and reserving a percentage of the value being generated by Yearn in order to support further development, improve security, sponsor research, e.t.c.

To get started, I propose we capture 5% of all yields earned through Yearn to be used as a reserve for the protocol.

## Abstract

@andre.cronje has done an amazing job so far at developing the protocol. As a community, we should support his efforts. To achieve that, I propose that we should start reserving 5% of all yields earned for protocol use. How we plan to use it and what would be the sensible threshold for the reserve percentage can be determined in a different proposal

## Motivation

One of the best things about the Yearn ecosystem is that there isn’t any pre-mined tokens. No money was taken from VC nor did @andre.cronje attempted to IXO (e.g. IDO, ICO) YFI tokens. This is as good as we can get when it comes to decentralization for a working and profitable defi project! Unfortunately, there are also downsides for not having some cash reserved:

- Unable to cover expensive audits for contracts
- Incentive to continue building awesome products
- Fund/grants to sponsor researches in order to improve the products
- General marketing and user support

**FOR**: Reserve 5% of all yields earned through Yearn for protocol use.

**AGAINST**: No changes. All rewards will continue to distribute evenly among YFI stakers.

## Metadata

| Name                | Value                                      |
| ------------------- | ------------------------------------------ |
| Proposed by         | 0x09173487b272311Edda01F45f97911aEB6aBd602 |
| Total for votes     | 332839.5446 (99.69%)                       |
| Total against votes | 1005.9567 (0.30%)                          |
| Quorum              | 3.06% 𐄂                                    |
| Start block         | 10525527                                   |
| End block           | 10542807                                   |

Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/)

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).


text:
---
yip: 38
title: Distribute / Keep Balancer Rewards
status: Implemented
author: Klim K (@milkyklim)
discussions-to: https://gov.yearn.finance/t/yip-38-distribute-keep-balancer-rewards/2436

created: 08/18/2020
---

<!--You can leave these HTML comments in your merged SIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new SIPs. Note that an SIP number will be assigned by an editor. When opening a pull request to submit your SIP, please use an abbreviated title in the filename, `sip-draft_title_abbrev.md`. The title should be 44 characters or less.-->

## Simple Summary

<!--"If you can't explain it simply, you don't understand it well enough." Simply describe the outcome the proposed changes intends to achieve. This should be non-technical and accessible to a casual community member.-->

Keep seized $BAL tokens as part of operational capital instead of distributing to old governance pool $BPT stakers.

## Abstract

<!--A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what *will* be done if the SIP is implemented, not *why* it should be done or *how* it will be done. If the SIP proposes deploying a new contract, write, "we propose to deploy a new contract that will do x".-->

~891 $BAL (~18500$) tokens were sent to one of the previous distribution pools. These tokens are seized and sitting in the multisig wallet now. We either have to distribute them or keep them for operational capital.

## Motivation

<!--This is the problem statement. This is the *why* of the SIP. It should clearly explain *why* the current state of the protocol is inadequate.  It is critical that you explain *why* the change is needed, if the SIP proposes changing how something is calculated, you must address *why* the current calculation is innaccurate or wrong. This is not the place to describe how the SIP will address the issue!-->

Since \$BALs belong to BPT stakers it is essential to decide what we should do with tokens.

However, the amount of $BAL seized is 3 times lower than protocol fees generated within a week (18k vs 60k). Therefore, I propose to keep $BALs in the multisig and count them towards operational capital, rather than writing a custom claim contract – this solution saves time and gas.

## Specification

<!--The specification should describe the syntax and semantics of any new feature, there are five sections
1. Overview
2. Rationale
3. Technical Specification
4. Test Cases
5. Configurable Values
-->

### Overview

<!--This is a high level overview of *how* the SIP will solve the problem. The overview should clearly describe how the new feature will be implemented.-->

Largest staker should get ~31% (~5735$) of all $BAL tokens, see graph:

https://explore.duneanalytics.com/embed/query/7901/visualization/15749?api_key=8AAmxEmXrkxj56sw0hjDtrVbMN7jZtmsZ6SmZfFo 4

While this might sound impressive there are a bunch of small stakers eligible for less than 8$. Taking into account current gas prices, fact that people have to claim their $BAL themselves I argue that it is more reasonable to keep \$BAL as operational capital for the team.

Moreover, this proposal saves time as we skip writing a custom distribution contract.

### Rationale

<!--This is where you explain the reasoning behind how you propose to solve the problem. Why did you propose to implement the change in this way, what were the considerations and trade-offs. The rationale fleshes out what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->

Taking into account current gas prices, the fact that people have to claim their $BAL themselves I argue that it is more reasonable to keep $BAL as operational capital for the team.

**For:** Keep \$BAL for operational capital.

**Against:** Allow stakers to claim \$BAL.


text:
---
yip: 42
title: Add RenBTC to yVaults
status: Rejected
author: Azeem (@zu-ctrl)
discussions-to: https://gov.yearn.finance/t/proposal-yrenbtc-delegated-vault/3470
implementation: https://github.com/zu-ctrl/yfi-str-pub/blob/master/StrategyCreamRENBTC.sol
created: 08/26/2020
---

<!--You can leave these HTML comments in your merged SIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new SIPs. Note that an SIP number will be assigned by an editor. When opening a pull request to submit your SIP, please use an abbreviated title in the filename, `sip-draft_title_abbrev.md`. The title should be 44 characters or less.-->

## Simple Summary

<!--"If you can't explain it simply, you don't understand it well enough." Simply describe the outcome the proposed changes intends to achieve. This should be non-technical and accessible to a casual community member.-->

Add RenBTC as a volatile asset to be used as collateral in delegated yVaults.

## Abstract

<!--A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what *will* be done if the SIP is implemented, not *why* it should be done or *how* it will be done. If the SIP proposes deploying a new contract, write, "we propose to deploy a new contract that will do x".-->

Add RenBTC as a volatile asset to be used as collateral in delegated yVaults.

## Motivation

<!--This is the problem statement. This is the *why* of the SIP. It should clearly explain *why* the current state of the protocol is inadequate.  It is critical that you explain *why* the change is needed, if the SIP proposes changing how something is calculated, you must address *why* the current calculation is innaccurate or wrong. This is not the place to describe how the SIP will address the issue!-->

wBTC has pretty good growth rates as seen on DeFi Pulse but as a custodial solution is hampered by trust-based systems which BTC holders do not by and large feel comfortable with.

RenBTC is a tokenized representation of BTC on the Ethereum blockchain. It is an ERC20, and backed 1:1 with real BTC locked in RenVM, a decentralized custodian. It is redeemable at any time for real BTC.

When Curve created an opportunity for RenBTC to generate returns, the RenVM TVL growth chart exploded. This is a clear signal that when the right solution is available, there is a LOT of BTC waiting on the sidelines to jump into farming yield on ETH. Let’s be there for them.

Refer to thread with an overwhelming majority FOR the BTC strategic focus. This is a vote to approve the current Strategy Smart contract to go live and start generating returns for RenBTC depositors without forcing them to figure out Curve deposits.

## Specification

<!--The specification should describe the syntax and semantics of any new feature, there are five sections-->

The strategy linked to above models the current yYFI yVault strategy of farming CREAM and generating returns in more CREAM. We will require a new row in the yVault to accept RenBTC deposits.

> Strategy 1:

- Add a new Vault row in Table for yRenBTC Vault
- User deposits RenBTC start farming CREAM the same way as yYFI Vault, and deliver returns for depositors as RenBTC.

**For:** Yes! Add yRenBTC Vault Strategy 1 - StrategyCreamRENBTC

**Against:** No change.

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).


text:
---
yip: 71
title: Activate veYFI
author: darkghosty, flashfish, jiji, saltyfacu
discussions-to: https://gov.yearn.finance/t/proposal-activate-veyfi/12783
status: Implemented
created: 2022-11-25
---

## Summary

Replace YFI voting with vote-escrowed YFI (veYFI) voting for all future governance proposals.

### Status

**Discussion**
This proposal is currently in the discussion phase. As per our voting rules outlined in YIP-55, it will be in discussion for at least 3 days with a non-binding forum poll to gauge sentiment before it can be assigned a YIP number and move to Snapshot for a binding vote.

## Abstract

**If adopted**, this proposal seeks to:
* Replace YFI with veYFI as the voting token in Governance
* Adopt a 2 week long moratorium on new YIPs where no proposals will be voted on

## Background

This proposal is the first step in the implementation of YIP-65: Evolving YFI Tokenomics[[1]](#References). YFI is time-locked up to 4 years where a longer lock increases the relative weight in relation to other locked tokens. It is strongly recommended that the reader first familiarize themselves with the concepts of YIP-65 in order to better understand this proposal.

### Out of scope

The following topics were intentionally not covered by this proposal:
* Yearn Tokenomics
* Gauges
* Rewards
* On-chain voting

## Motivation

This implements parts of what was was adopted by YFI voters in YIP-65, namely locking YFI into veYFI, managing one's lock, and using it to vote in governance. There are no YFI rewards or gauges yet. There is no advantage to locking early.

### Future possibilities
* Deploy additional components of YIP-65
* Transition to on-chain voting and governance

### Risks

* Governance attacks, mitigated by a moratorium on new YIPs being accepted
* Smart contract risk in the veYFI contracts, which have been mitigated through security reviews by Statemind, yAcademy, and ChainSecurity[[2]](#References).

### Alternatives considered

None

## Specification

1. veYFI is implemented as per the deployed contract[[3]](#References), from the veYFI github repo[[4]](#References).
2. **DO NOT INTERACT WITH THE CONTRACT TO LOCK YFI** until this proposal passes. There is **NO USE** for locking YFI until this time. There is **NO UPSIDE** in locking early. There are **NO REWARDS** at this point.
3. It's a typical veCRV style locking design:
   * 1 lock per address
   * Min lock: 1 week, max lock 208 weeks (4y)
   * Linear decay
   * Extendable lock duration
4. Immediately upon the passing of this YIP, **all subsequent YIPs are voted on using veYFI**.
5. Voting continues to be done using Snapshot.
6. To reduce the risk of governance attacks by allowing enough YFI holders to lock so as not to give small YFI balances outsize influence over the protocol, a **2 week moratorium** on YIPs are passed. Any YIP proposal submitted in this period will only be considered for voting 2 weeks after the passing of this YIP.
7. Contributor YFI is migrated into veYFI as per YIP-66: Streamlining contributor compensation[[5]](#References).
8. veYFI voters may replace this voting mechanism in the future with some other design, by submitting a YIP and voting it through.

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

## References

1. https://gov.yearn.finance/t/yip-65-evolving-yfi-tokenomics/11994
1. https://github.com/yearn/yearn-security/pull/70/files
1. https://etherscan.io/address/0x90c1f9220d90d3966fbee24045edd73e1d588ad5#code
1. https://github.com/yearn/veYFI/commit/bb9d8ac9dd90a9a9772b9663ce4fa232fda7bce2
1. https://gov.yearn.finance/t/yip-66-streamlining-contributor-compensation/12247

## Information

_Source: [Snapshot](https://snapshot.org/#/ybaby.eth/proposal/0xc50b60f712adb8568f10f565fc467e8c5d8fe1f4920683696f81c7920397942a)_

| Name          | Value                                                                           |
| ------------- | ------------------------------------------------------------------------------- |
| Snapshot Space| [ybaby.eth](https://snapshot.org/#/ybaby.eth)                                   |
| Strategie(s)  | YFI, delegation                                                                 |
| Author        | wentokyo.eth                                                                    |
| IPFS          | https://snapshot.mypinata.cloud/ipfs/bafkreihcrsciiqm3fhr2kehbtqfjwk7fykepgfv2xgb6rjwwbxm2orwxfq |
| Voting System | Single choice voting                                                            |
| Start date    | Nov 25, 2022                                                                    |
| End date      | Nov 30, 2022                                                                    |
| Snapshot      | https://etherscan.io/block/16048538                                             |

## Results

| Result  | Value             |
| ------  | ----------------- |
| Yes     | 1300 YFI (99.78%) |
| No      | 2.7 YFI (0.21%)   |
| Abstain | 0.025 YFI (0%)    |


text:
---
yip: 12
title: Reducing the quorum for accepting proposal
status: Implemented
author: cp287 (@illlefr4u)
discussions-to: https://gov.yearn.finance/t/yip-12-reducing-the-quorum-for-accepting-proposal/578
created: 2020-07-24
implementation: https://etherscan.io/tx/0x64ff868305c1271c51b85a4f69f547f3137bebeae611eff1e0a2d86714469b77#
---

## Simple Summary

<!--"If you can't explain it simply, you don't understand it well enough." Simply describe the outcome the proposed changes intends to achieve. This should be non-technical and accessible to a casual community member.-->

At the moment, it is difficult for the Yearn governance mechanism to achieve a quorum of 33%. For the control system to function, the threshold must be lowered so that at least some decisions can be made.

## Abstract

<!--A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what *will* be done if the YIP is implemented, not *why* it should be done or *how* it will be done. If the YIP proposes deploying a new contract, write, "we propose to deploy a new contract that will do x".-->

It is proposed to reduce the quorum threshold for accepting the proposal to 20%.
At the moment, no changes to the on-chain are necessary, since the quorum check is currently being carried out off-chain. Thus, it is enough to simply make a decision by onchain voting.

## Motivation

<!--This is the problem statement. This is the *why* of the YIP. It should clearly explain *why* the current state of the protocol is inadequate.  It is critical that you explain *why* the change is needed, if the YIP proposes changing how something is calculated, you must address *why* the current calculation is innaccurate or wrong. This is not the place to describe how the YIP will address the issue!-->

At the moment, it is difficult for the Yearn governance mechanism to achieve a quorum of 33%. We could observe this even with the important proposal 1, which could not reach the quorum.
This is due to both:

- general passivity and lack of motivation to participate in governance system;
- negative motivation to participate (lock of funds).

Thus, Yearn protocol is under the threat of forever remaining as it is, since all proposals may not reach the required quorum (with a high probability, the activity in voting will only decrease over time).

There are many different solutions, which I will describe below, and I propose to start discussing them in the topic, but it is critical now to make a simple decision that will allow the protocol to evolve, and the community to make decisions on the development of the protocol.
In my opinion, such a decision may be to reduce the quorum threshold to 20%, which I put up for voting.

Other ways to solve the quorum problem:

- you get rewards for staking only if you vote;
- delegation of votes (implementation will take some time);
- quorum should be not for ALL tokens, but for only those “escrowed” to be voting;
- should have a quorum schedule which after x amount of time with no proposal meeting quorum the threshold goes down 1%-2% for year1, 0.5%-1% for year 2, etc.

**FOR**: The threshold for accepting the proposal drops to 20%.

**AGAINST**: No change for threshold.

## Metadata

| Name                | Value                                      |
| ------------------- | ------------------------------------------ |
| Proposed by         | 0x74630370197b4c4795bFEeF6645ee14F8cf8997D |
| Total for votes     | 5291919.8701 (66.22%)                      |
| Total against votes | 2699427.0543 (33.77%)                      |
| Quorum              | 39.76% ✔                                   |
| Start block         | 10522307                                   |
| End block           | 10539587                                   |

Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/)

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).


text:
---
yip: 0
title: YIP Purpose and Guidelines
status: Implemented
author: Yearn Community
discussions-to: https://gov.yearn.finance/
created: 2020-07-22
updated: 2020-09-03
---

## What is an YIP?

YIP stands for Yearn Improvement Proposal, it has been adapted from the SIP (Synthetix Improvement Proposal). The purpose of this process is to ensure changes to Yearn are transparent and well governed. An YIP is a design document providing information to the Yearn community about a proposed change to the system. The author is responsible for building consensus within the community and documenting dissenting opinions.

## YIP Rationale

We intend YIPs to be the primary mechanisms for proposing new features, collecting community input on an issue, and for documenting the design decisions for changes to Yearn. Because they are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.

It is highly recommended that a single YIP contain a single key proposal or new idea. The more focused the YIP, the more successful it is likely to be.

An YIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement.

## YIP Work Flow

Parties involved in the process are the _author_, the [_YIP editors_](#yip-editors), and the Yearn community.

:warning: Before you begin, vet your idea, this will save you time. Ask the Yearn community first if an idea is original to avoid wasting time on something that will be rejected based on prior research (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will have the intend effect. The appropriate public forum to gauge interest around your YIP is [the unofficial Yearn Discord] or [the unofficial Yearn Telegram].

Your role as the champion is to write the YIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea. Following is the process that a successful YIP will move along:

```
Proposed -> Approved -> Implemented
  ^                     |
  +----> Rejected       +----> Moribund
  |
  +----> Withdrawn
  v
Deferred
```

Each status change is requested by the YIP author and reviewed by the YIP editors. Use a pull request to update the status. Please include a link to where people should continue discussing your YIP. The YIP editors will process these requests as per the conditions below.

- **Work in progress (WIP)** -- Once the champion has asked the Yearn community whether an idea has any chance of support, they will write a draft YIP as a [pull request]. Consider including an implementation if this will aid people in studying the YIP.
- **Proposed** If agreeable, YIP editor will assign the YIP a number (generally the issue or PR number related to the YIP) and merge your pull request. The YIP editor will not unreasonably deny an YIP. Proposed YIPs will be discussed on governance calls and in Discord. If there is a reasonable level of consensus around the change on the governance call the change will be moved to approved. If the change is contentious a vote of token holders may be held to resolve the issue or approval may be delayed until consensus is reached.
- **Approved** -- This YIP has passed community governance and is now being prioritised for development.
- **Implemented** -- This YIP has been implemented and deployed to mainnet.
- **Rejected** -- This YIP has failed to reach community consensus.
- **Withdrawn** -- This YIP has has been withdrawn by the author(s).
- **Deferred** -- This YIP is pending another YIP/some other change that should be bundled with it together.
- **Moribund** -- This YIP has been implemented and is now obsolete and requires no explicit replacement.

## What belongs in a successful YIP?

Each YIP should have the following parts:

- Preamble - RFC 822 style headers containing metadata about the YIP, including the YIP number, a short descriptive title (limited to a maximum of 44 characters), and the author details.
- Simple Summary - “If you can’t explain it simply, you don’t understand it well enough.” Provide a simplified and layman-accessible explanation of the YIP.
- Abstract - a short (~200 word) description of the technical issue being addressed.
- Motivation (\*optional) - The motivation is critical for YIPs that want to change Yearn. It should clearly explain why the existing specification is inadequate to address the problem that the YIP solves. YIP submissions without sufficient motivation may be rejected outright.
- Specification - The technical specification should describe the syntax and semantics of any new feature.
- Rationale - The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.
- Test Cases - Test cases may be added during the implementation phase but are required before implementation.
- Copyright Waiver - All YIPs must be in the public domain. See the bottom of this YIP for an example copyright waiver.

## YIP Formats and Templates

YIPs should be written in [markdown] format.
Image files should be included in a subdirectory of the `assets` folder for that YIP as follows: `assets/yip-X` (for yip **X**). When linking to an image in the YIP, use relative links such as `../assets/yip-X/image.png`.

## YIP Header Preamble

Each YIP must begin with an [RFC 822](https://www.ietf.org/rfc/rfc822.txt) style header preamble, preceded and followed by three hyphens (`---`). This header is also termed ["front matter" by Jekyll](https://jekyllrb.com/docs/front-matter/). The headers must appear in the following order. Headers marked with "\*" are optional and are described below. All other headers are required.

`yip:` <YIP number> (this is determined by the YIP editor)

`title:` <YIP title>

`author:` <a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s). Details are below.>

`* discussions-to:` \<a url pointing to the official discussion thread at gov.yearn.finance\>

`status:` < WIP | PROPOSED | APPROVED | IMPLEMENTED >

`created:` <date created on>

`* updated:` <comma separated list of dates>

`* requires:` <YIP number(s)>

`* resolution:` \<a url pointing to the resolution of this YIP\>

Headers that permit lists must separate elements with commas.

Headers requiring dates will always do so in the format of ISO 8601 (yyyy-mm-dd).

#### `author` header

The `author` header optionally lists the names, email addresses or usernames of the authors/owners of the YIP. Those who prefer anonymity may use a username only, or a first name and a username. The format of the author header value must be:

> Random J. User <address@dom.ain>

or

> Random J. User (@username)

if the email address or GitHub username is included, and

> Random J. User

if the email address is not given.

#### `discussions-to` header

While an YIP is in WIP or Proposed status, a `discussions-to` header will indicate the URL at [gov.yearn.finance](https://gov.yearn.finance/) where the YIP is being discussed.

#### `created` header

The `created` header records the date that the YIP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14.

#### `updated` header

The `updated` header records the date(s) when the YIP was updated with "substantial" changes. This header is only valid for YIPs of Draft and Active status.

#### `requires` header

YIPs may have a `requires` header, indicating the YIP numbers that this YIP depends on.

## Auxiliary Files

YIPs may include auxiliary files such as diagrams. Such files must be named YIP-XXXX-Y.ext, where “XXXX” is the YIP number, “Y” is a serial number (starting at 1), and “ext” is replaced by the actual file extension (e.g. “png”).

## YIP Editors

The current YIP editors are:

`* Artem K (@banteg)`

`* Cooper Turley (@Cooopahtroopa)`

`* Daryl Lau (@Daryllautk)`

`* Klim K (@milkyklim)`

`* Sunil Srivatsa (@alphastorm)`

## YIP Editor Responsibilities

For each new YIP that comes in, an editor does the following:

- Read the YIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status.
- The title should accurately describe the content.
- Check the YIP for language (spelling, grammar, sentence structure, etc.), markup (Github flavored Markdown), code style

If the YIP isn't ready, the editor will send it back to the author for revision, with specific instructions.

Once the YIP is ready for the repository, the YIP editor will:

- Assign an YIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this YIP)

- Merge the corresponding pull request

- Send a message back to the YIP author with the next step.

The YIP editors monitor YIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.

The editors don't pass judgment on YIPs. We merely do the administrative & editorial part.

## History

The YIP document was derived heavily from the SIP Synthetix Improvement Proposal document in many places text was simply copied and modified. Any comments about the YIP document should be directed to the YIP editors.

### Bibliography

[the unofficial yearn discord]: https://discord.com/invite/3AGgWxy
[the unofficial yearn telegram]: https://t.me/yearnfinance
[pull request]: https://github.com/yearn/YIPS/pulls
[markdown]: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).


text:
---
yip: 33
title: Add LINK to yVaults
status: Implemented
author: franklin (@franklin501)
discussions-to: https://gov.yearn.finance/t/add-link-as-the-first-asset-for-the-upcoming-delegated-yvaults-release/847
created: 2020-08-02
---

## Simple Summary

Add Chainlink (LINK) as the first volatile asset to be used as collateral in delegated yVaults.

## Abstract

Add Chainlink (LINK) as the first volatile asset to be used as collateral in delegated yVaults.

## Motivation

Delegated yVaults have initially launched with only USDC as collateral. Additional assets are necessary in order to generate more revenue for the protocol and grow the ecosystem. This proposal nominates LINK as the first volatile asset to be used as collateral. LINK was the top choice in a preliminary [poll](https://gov.yearn.finance/t/add-link-as-the-first-asset-for-the-upcoming-delegated-yvaults-release/847/7) and is a good first candidate for trials before other volatile assets are added.

**FOR**: Add LINK as the first volatile asset to be used in delegated yVaults.

**AGAINST**: Don't add LINK.

### Overview

Adding LINK as a collateral option to delegated yVaults will enable LINK holders to deposit tokens to the vault, which will increase the total value locked (TVL) and generate more fees for the protocol.

### Rationale

Chainlink is among the highest valued and most liquid ERC-20 tokens. There is a significant number of tokens and thus liquidity idle, which could be deposited for delegated yVaults. LINK’s high market capitalization makes it well suited to be the first delegated yVault volatile asset as it will likely contribute to the most fees that will be accrued the protocol.

Chainlink also has one of the strongest communities in crypto and successful initial trials of delegated yVaults will likely encourage larger token holders to join the ecosystem adding even more fees. Large deposits of LINK as collateral will significantly increase total value locked (TVL) in yVaults, compared to other token communities that are not as immersed in DeFi.

## Metadata

| Name                | Value                                      |
| ------------------- | ------------------------------------------ |
| Proposed by         | 0x071243c8f33A3e7c15499a8E51fF852DbaF05854 |
| Total for votes     | 3069.4359 (99.46%)                         |
| Total against votes | 16.3954 (0.53%)                            |
| Quorum              | 31.68% ✔                                   |
| Start block         | 10582615                                   |
| End block           | 10599895                                   |

Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/)

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).


text:
---
yip: 35
title: Distribute Donations vs Purchase YFI
status: Implemented
author: Andre Cronje (@andrecronje), Klim K (@milkyklim)
discussions-to: https://gov.yearn.finance/t/distribution-donations-vs-purchasing-yfi/2244

created: 2020-08-10
---

## Simple Summary

Allow donors who donated to claim back donations or leave them to be used to purchase YFI.

## Abstract

While I am very appreciative of the donations, the [article](https://decrypt.co/37995/exclusive-yfi-andre-cronje-broke-quitting-defi) was a gross misrepresentation of our discussion. I am not in financial detriment, I do have debt, but I have assets in crypto to offset my fiat debt. I am simply not interested to swap my crypto to fiat, since I value my crypto more than fiat.

As such, I propose a small system, whereby donors can claim back their donations, should they wish. If however they do not claim it back by x date, then the funds (currently \$150,000) will be used to market buy YFI. I wish to use this YFI as a governance vote and we can also use it to incentivize other events or requirements.

## Motivation

Having spoken to donors, its a mix of “use it for the protocol” vs “it is an insult to return it”, so I wanted to come up with a new solution that benefits all participants.

**FOR**: Build the claim back and purchase system.

**AGAINST**: Return the donations.

## Specification

I will implement a simplistic contract that allows donors to reclaim, should they not wish to do so, after maturity date, YFI will be purchased and staked in governance.

## Metadata

| Name                | Value                                      |
| ------------------- | ------------------------------------------ |
| Proposed by         | 0x74630370197b4c4795bFEeF6645ee14F8cf8997D |
| Total for votes     | 1644.3648 (93.59%)                         |
| Total against votes | 112.4983 (6.40%)                           |
| Quorum              | 37.43% ✔                                   |
| Start block         | 10633099                                   |
| End block           | 10650379                                   |

Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/)

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).


text:
---
yip: 67
title: Contribute $400,000 to Nomic Foundation
author: FrancoNomic
discussions-to: https://gov.yearn.finance/t/yip-67-contribute-to-the-nomic-foundation/12326
status: Implemented
created: 2022-03-09
---

# Should Yearn governance contribute funding to the Nomic Foundation?
## Summary

- Nomic Labs, the team behind Hardhat, has become the Nomic Foundation, a non-profit organization dedicated to Ethereum. Our mission is to empower developers to decentralize the world.
- The Nomic Foundation's work will be focused on Ethereum's developer platform with the objective of achieving a world-class developer experience, and generally improving Ethereum's public goods support structures.
- [Hardhat](https://hardhat.org/) is the de facto standard developer tool used to build Ethereum software, with more than 23000 Github repositories using it and tens of thousands of active users. Prominent teams relying on it include ENS, Uniswap, Optimism, OpenZeppelin, Aave, Balancer, Chainlink, Synthetix, and many more leading teams.
- The new foundation will expand the Hardhat suite of tools and, most importantly, build long-term infrastructure to catalyze organic growth in the Ethereum tooling ecosystem, decreasing Ethereum's dependence on any one organization to build and maintain core development platform components.
- Seeking $30m in total funding from the ecosystem. Donations of $15M already secured by the Ethereum Foundation, Vitalik Buterin, Coinbase, a16z, The Graph, Polygon, Chainlink, a16z, and Kaszek Ventures.
- **We're proposing to Yearn Governance to make a contribution of $400k to the Nomic Foundation to support its mission.**

## Ethereum developer experience

When it comes to Ethereum, which is primarily a software development platform to build decentralized systems, developer experience is a key strategic aspect for success. Ecosystem growth requires more developers to build more software on top of Ethereum. Developer adoption and learning speed, core contributors to this growth, are critically affected by developer experience.

The rate at which the ecosystem innovates, coming up with new creations and solving difficult problems, both at the dapp layer and EVM/Solidity/Vyper layer, is also directly affected by developer productivity.

Software development platforms aren't new, and playbooks established by the great developer experience success stories (Rust, .Net, TypeScript, etc) prove that achieving a quality developer experience requires a specialized approach paired with a long-term, big-picture strategy. The potential impact in executing a dedicated effort for Ethereum would increase the ecosystem’s pace of innovation and growth, building a powerful compounding effect over the long term for the entire industry.

The inspiration for our vision came from our experience building Hardhat, which allowed us to see how deeply challenging it is to build sophisticated Ethereum tooling. **These challenges must be alleviated to bring about organic ecosystem-led improvement of developer experience that achieves world-class quality.**

## Nomic Foundation

Nomic Labs has been fully dedicated to Ethereum developer experience since 2019, and we're [now pivoting](https://medium.com/nomic-labs-blog/introducing-the-nomic-foundation-an-ethereum-public-goods-organization-31012af67df9) to a non-profit foundation formally dedicated to Ethereum. We're aiming to build a long-lasting organization that makes Ethereum's public goods support structures stronger by contributing to the Ethereum Foundation's existing efforts, and reducing the ecosystem's reliance on any one organization for development platform components.

### Roadmap

Given the size and innovation pace of the ecosystem, there's no way to foresee exactly what needs developers are going to have as things scale. However, we do know what engineering foundations the ecosystem will need in order to build its own solutions.

Our overarching engineering strategy is to empower the ecosystem to build its own specialized tools. This plan is based on four strategic pillars of the stack, each of which offers an opportunity to leverage a platform to empower the ecosystem to keep building open-source infrastructure.

For each of these pillars, we will build a platform. The four ecosystem pillars and platform opportunities we've identified are:

1. Solidity
2. EVM tooling
3. Local development environment
4. Ethereum connector library

## The projects

### Slang & Rethnet

Over the long term, these are our most important projects. Targeting the Solidity and EVM tooling pillars, Slang and Rethnet will serve as core infrastructure for the ecosystem to build new tools faster, cheaper, and better. We're essentially building the tools that would have let us build Hardhat a lot faster. We previously published a [Medium post](https://medium.com/nomic-labs-blog/slang-rethnet-2ad465fd7880) with high-level descriptions of how both projects will complement each other.

**Slang**

A Solidity compiler designed as a platform for tooling development, an approach also known as compiler as a service. Its top priority will be servicing tools through domain-specific APIs. Much like .Net's Roslyn, it will feature a compilation pipeline made of distinct reusable components with standalone APIs. A completely modular design guarantees that others can build on top of it by replacing the part of functionality they need to, and reusing everything else:

1. Parser that is only concerned with producing trees from code. Usable on its own, for example, to create third-party formatters like Prettier plugins.
2. Semantic analysis (binding) is concerned only with building a type system and validating the produced trees. Usable on its own, to implement third-party type checking, security/threat models, and more advanced third-party linting.
3. Code generation. By replacing just this isolated part, the compiler can compile for different targets (e.g. non-EVM L2s).
4. Language services. These will receive an immutable representation of the above (syntax trees, bound trees, codegen settings), and will only be tasked with answering questions. Usable on its own to expose in different IDEs (same service for VSCode, IntelliJ, Vim, etc). Reusable to extend the functionality of other editor features (task runners, testing, deployment, CI, debugging).
5. Runtime observation APIs to support Rethnet.

All of this will be reusable to create entirely new EVM programming languages, since by replacing the parser and type system, one can get an entire high-quality toolchain working from the get-go.

**Rethnet**

To provide a simulated environment where developers can build and test their Ethereum software, tools need to replicate many of the components that make up a full Ethereum node implementation. This is a significant engineering effort, which given the complexity of Ethereum, represents a barrier to entry to tooling development given the depth of knowledge that is required.

Rethnet aims to make this easier by offering a native, flexible, extensible, fast, and language-agnostic EVM local development network, distributed as a Rust library, that is designed to be the underlying core in tools that provide debugging information to developers (like Hardhat, Foundry, Remix, Truffle, DappTools, etc). It will be a Rust library made to be consumed from other languages like TypeScript, Go, Python, etc as a native dependency. It will implement the baseline of essential functionality every tool should have like Solidity console.log, stack traces, and descriptive error messages, as well as implement code coverage, gas profiling, and a step debugger. At its core, it's an implementation of an Ethereum node with a layer of EVM runtime observation to provide development features.

Building a new Hardhat, Truffle, Remix, or DappTools using Rethnet will be a much more manageable project, and Rethnet will be completely reusable for any EVM language through adapters.

### Hardhat

Our flagship project targets the local development environment pillar, and it's currently at an advanced level of progress and adoption. While Slang and Rethnet mature and catalyze organic growth in the tooling space, developers still have needs to be met, positioning Hardhat as our immediate-term solution to empower developers to keep decentralizing the world.

Hardhat is an Ethereum development environment that developers use to compile, deploy, test, and debug Ethereum software. Most importantly, it's highly flexible, extensible, and designed to empower the community to build their own solutions. This strategy has been successful, and there's already [a valuable ecosystem of reusable plugins](https://hardhat.org/plugins/).

Hardhat's roadmap is focused on becoming an extensible development environment with deep integrations across components in key areas of the tooling stack:

- [Hardhat VSCode](https://medium.com/nomic-labs-blog/hardhat-vscode-9de29467fc26) — programming editor
- [Hardhat Ignition](https://medium.com/nomic-labs-blog/hardhat-ignition-5a34a4e3d2de) — contract deployment
- [Hardhat Network](https://hardhat.org/hardhat-network/) — local development network
- [Hardhat Runner](https://hardhat.org/getting-started/#overview) — build/testing workflow

This roadmap leads to developers being well equipped to build powerful extensions to their workflow that increase their productivity according to their exact needs, and to then share them with the ecosystem in the form of plugins.

Hardhat will also eventually migrate to using Rethnet and Slang, increasing its feature richness, speed, and stability while enabling dogfooding at scale for our brand new building blocks.

### Web3.js as a frontend platform

The OG Ethereum connector library, Web3.js, is being revitalized into a high-value project. By focusing on community and ecosystem growth, supported by an extensible architecture, it can become a great source of value, much like React represents in the front-end world, but for dapps. A website hub connecting community spaces, support spaces, educational resources, extensions, and related projects, combined with an active ecodev effort (workshops, talks, contests, and incentives), will create a source of leverage for the ecosystem. This will provide better troubleshooting, faster developer training, more reusable code, and, most importantly, the possibility of extending the library. This effort is currently spearheaded by the ChainSafe team.

## Funding

The Nomic Foundation aims to benefit the entire Ethereum ecosystem, which is why we’re fundraising across multiple organizations and individuals within it.

The Ethereum Foundation is leading this round of contributions with $8M, alongside contributions from Vitalik Buterin, Coinbase, Consensys, The Graph, Polygon, Chainlink, Gnosis, a16z, a_capital, and Kaszek Ventures. These donors make up $15M, and we're aiming to raise $15M more.

## Why Yearn?

Generally, we think that allocating capital to the Nomic Foundation makes strategic sense for any protocol treasury that is aligned long term with the growth of Ethereum, and we've approached and will continue approaching several protocols.

Currently, Yearn [builds](https://github.com/yearn/hardhat-monorepo/tree/main/packages) [some](https://github.com/yearn/ygift-ui/blob/master/hardhat.config.ts) of [its projects](https://github.com/yearn/stealth-txs/blob/main/hardhat.config.ts) [using Hardhat](https://github.com/yearn/strategies-keep3r/blob/main/hardhat.config.ts). While this is a signal of Hardhat’s value, the projects that the Nomic Foundation will deliver will create more value not just for Yearn, but for the entire ecosystem. We’ll provide services to the Ethereum community that will:

1. Continue the maintenance of critical infrastructure used to build most protocols (Hardhat).
2. Increase developer productivity for every team in the ecosystem.
3. Accelerate developer onboarding to Ethereum, increasing the size of the experienced engineering hiring pool and making time-to-productivity shorter for new hires.
4. Accelerate the pace of innovation and the number of products being built.
5. Increase market volume driven by new users and new products.

We believe this grows the market for everyone, including Yearn, and we’d love to have the **Yearn DAO contribute $400k in funding to this community effort**.

## An ecosystem-wide effort

We’re currently seeking funding from multiple DAOs. We’ll update with the corresponding links below as we create each forum thread.

- [Uniswap forum thread](https://gov.uniswap.org/t/temperature-check-should-uniswap-governance-contribute-funding-to-the-nomic-foundation/16354)
- [Compound forum thread](https://www.comp.xyz/t/proposal-should-compound-governance-contribute-funding-to-the-nomic-foundation/3032)
- [ENS forum thread](https://discuss.ens.domains/t/temperature-check-should-ens-governance-contribute-funding-to-the-nomic-foundation/11148)
- [SushiSwap forum thread](https://forum.sushi.com/t/proposal-should-sushiswap-governance-contribute-funding-to-the-nomic-foundation/9658)

## Links

[Nomic Foundation Announcement](https://medium.com/nomic-foundation-blog/introducing-the-nomic-foundation-an-ethereum-public-goods-organization-31012af67df9)

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

## Information

_Source: [Snapshot](https://snapshot.org/#/ybaby.eth/proposal/0xd1988feec955cb93d42b63b7b4845d35da8f60859f55ec18b3d5609ecd4eb9e2)_

| Name          | Value                                                                           |
| ------------- | ------------------------------------------------------------------------------- |
| Snapshot Space| [ybaby.eth](https://snapshot.org/#/ybaby.eth)                                   |
| Strategie(s)  | YFI, delegation                                                                 |
| Author        | wentokyo.eth                                                                    |
| IPFS          | https://snapshot.mypinata.cloud/ipfs/QmbrLDy77zwLEGeXBssvx2LXc317Vb7vatJ4kKJq1kH13u |
| Voting System | Single choice voting                                                            |
| Start date    | Mar 09, 2022                                                                    |
| End date      | Mar 14, 2022                                                                    |
| Snapshot      | https://etherscan.io/block/14353009                                             |

## Results

| Result  | Value               |
| ------- | ------------------- |
| Yes     | 657 YFI (99.95%)    |
| No      | 0.36 YFI (0.05%)    |


text:
---
yip: 30
title: YFI Inflation Schedule
status: Rejected
author: Substreight (@substreight), DeltaTiger (@deltatigernz), Hannes Graah (@Graadient), Daryl Lau (@Daryllautk), yfi_whale
discussions-to: https://gov.yearn.finance/t/yip-30-yfi-inflation-schedule/1439
created: 2020-07-28
---

## Simple Summary

Implement an inflation schedule of 20,000 YFI over the next 8 years, with 12,802 distributed in the first 3 years, ending with a trailing tail of 1% inflation.

## Abstract

- Update the YFI mint contract to reflect new inflation schedule.

## Motivation

To create an inflation schedule after the passing of YIP-0.

**FOR**: Implement an inflation schedule of 20,000 YFI over the next 8 years, with 12,802 distributed in the first 3 years, ending with a trailing tail of 1% inflation.

**AGAINST**: No changes.

## Specification

### Overview

1. Adjust supply schedule to follow [[YFI Inflation Schedule](https://docs.google.com/spreadsheets/d/1yomUGpAWR8svL9RXD-_vL2ArgQPGj1x2XPNKDEuZR9Q/edit?usp=sharing)].

- Beginning annual inflation: 22.384%
- Weekly emissions reduction multiplier: 0.9937
- Week that terminal inflation starts: 416 weeks
- Fixed % ongoing inflation (tail emission): 1%

2. This model will stay in place until it is stopped or adjusted.

### Rationale

- Liquidity provider yields are maintained at reasonably competitive levels in various YFI price and TVL scenarios (see modeling sheet).
- Lower initial inflation (22%) to keep long-term rewards reasonable.
- 8 year emission schedule to support long-term development.

Reference: [synthetix/contracts/SupplySchedule.sol](https://github.com/Synthetixio/synthetix/blob/master/contracts/SupplySchedule.sol)

## Metadata

| Name                | Value                                      |
| ------------------- | ------------------------------------------ |
| Proposed by         | 0x2D407dDb06311396fE14D4b49da5F0471447d45C |
| Total for votes     | 3380.7051 (38.73%)                         |
| Total against votes | 5346.6313 (61.26%)                         |
| Quorum              | 82.39% ✔                                   |
| Start block         | 10560113                                   |
| End block           | 10577393                                   |

Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/)

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).