text:
source "https://rubygems.org"

# Hello! This is where you manage which Jekyll version is used to run.
# When you want to use a different version, change it below, save the
# file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
#
#     bundle exec jekyll serve
#
# This will help ensure the proper Jekyll version is running.
# Happy Jekylling!
gem "jekyll", "~> 3.9.0"

# This is the default theme for new Jekyll sites. You may change this to anything you like.
gem "minima", "~> 2.5"

# If you want to use GitHub Pages, remove the "gem "jekyll"" above and
# uncomment the line below. To upgrade, run `bundle update github-pages`.
# gem "github-pages", group: :jekyll_plugins

# If you have any plugins, put them here!
group :jekyll_plugins do
  gem "jekyll-feed", "~> 0.15"
  gem "github-pages"
end

# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
gem "tzinfo-data", platforms: [:mingw, :mswin, :x64_mingw, :jruby]

# Performance-booster for watching directories on Windows
gem "wdm", "~> 0.1.0" if Gem.win_platform?

gem "html-proofer", '>=3.3.1'

gem "yip_validator", ">=1.1.0"


text:
---
layout: page
title: All YIPs
---

{% assign yips=site.pages|where_exp:"page","page.yip > -1" %} {% include
yiptable.html yips=yips %}

repo_name: yearn/YIPS

repo_language: HTML

file_name: config

mime_type: text/plain


text:
---
layout: null
---
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Yearn Finance YIPs - Last Call Review</title>
    <description>All YIPs which are in the two-week "last call" status, please help review these and provide your feedback!</description>
    <link>{{ site.url }}</link>
    <atom:link href="{{ site.url }}/last-call.xml" rel="self" type="application/rss+xml" />
    <lastBuildDate>{{ site.time | date_to_rfc822 }}</lastBuildDate>
    {% assign YIPs = site.pages | sort: 'YIP' %}
    {% for YIP in YIPs %}
      {% if YIP.status == "Last Call" %}
      {% capture description %}

YIP #{{ YIP.YIP }} - {{YIP.title }} is in Last Call status. It is authored by {{ YIP.author }} and was originally created {{ YIP.created }}. It is in the {{ YIP.category }} category of type {{ YIP.type }}. Please review and note any changes that should block acceptance.

        {% if YIP.discussions-to %}

The author has requested that discussions happen at the following URL: {{ YIP.discussions-to }}

        {% else %}

Please visit the [yearn/YIPs issues to comment](https://github.com/yearn/YIPs/issues/{{YIP.YIP}}).

        {% endif %}

        {{ YIP.content }}
      {% endcapture %}
      <item>
        <title>{{ YIP.title | xml_escape }}</title>
        <description>{{ description | xml_escape }}</description>
        <pubDate>{{ YIP.created | date_to_rfc822 }}</pubDate>
        <link>{{ site.url }}/{{ YIP.url }}</link>
        <guid isPermaLink="true">{{ site.url }}/{{ YIP.url }}</guid>
      </item>
      {% endif %}
    {% endfor %}
  </channel>
</rss>


text:
MathJax = {
  tex: {
    inlineMath: [["\\(", "\\)"]],
    displayMath: [["\\[", "\\]"]],
  },
  svg: {
    fontCache: "global",
  },
};


text:
---
yip: <to be assigned>
title: <YIP title>
status: WIP
author: <a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s), e.g. (use with the parentheses or triangular brackets): FirstName LastName (@GitHubUsername), FirstName LastName <foo@bar.com>, FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)>
discussions-to: <Create a new thread on https://gov.yearn.finance/ and drop the link here>

created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
requires (*optional): <YIP number(s)>
implementation (*optional): <Added if YIP passes>
---

<!--You can leave these HTML comments in your merged YIP 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 YIPs. Note that an YIP number will be assigned by an editor. When opening a pull request to submit your YIP, please use an abbreviated title in the filename, `yip-draft_title_abbrev.md`. The title should be 44 characters or less.-->

This is the suggested template for new YIPs. Note that an YIP number will be assigned by an editor. When opening a pull request to submit your YIP, please use an abbreviated title in the filename, `yip-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.-->

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

## 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".-->

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".

## 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!-->

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!

## 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 YIP will solve the problem. The overview should clearly describe how the new feature will be implemented.-->

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.

### 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.-->

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.

### Technical Specification

<!--The technical specification should outline the public API of the changes proposed. That is, changes to any of the interfaces Yearn Finance currently exposes or the creations of new ones.-->

The technical specification should outline the public API of the changes proposed. That is, changes to any of the interfaces Yearn Finance currently exposes or the creations of new ones.

### Test Cases

<!--Test cases for an implementation are mandatory for YIPs but can be included with the implementation..-->

Test cases for an implementation are mandatory for YIPs but can be included with the implementation.

## Copyright

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


text:
YIPs

<align="center">

![Validate](https://github.com/iearn-finance/YIPS/workflows/Validate/badge.svg?branch=master) [![Discord](https://img.shields.io/discord/734804446353031319.svg?color=768AD4&label=discord&logo=https%3A%2F%2Fdiscordapp.com%2Fassets%2F8c9701b98ad4372b58f13fd9f65f966e.svg)](https://discordapp.com/channels/734804446353031319/) [![Telegram](https://img.shields.io/badge/chat-on%20Telegram-blue.svg)](https://t.me/yearnfinance) [![Twitter Follow](https://img.shields.io/twitter/follow/iearnfinance.svg?label=iearnfinance&style=social)](https://twitter.com/iearnfinance)

- [YIPs](#yips)
  * [Contributing](#contributing)
  * [YIP Statuses](#yip-statuses)
  * [Validation](#validation)

[Visit the Governance Proposal Documentation Webpage](https://docs.yearn.finance/governance/proposal-repository)

**Yearn Finance Improvement Proposals (YIPs)** describe standards for the Yearn platform, including:

- core protocol specification
- client APIs
- contract standards
- governance operations
- and more

## Contributing

1.  Review [YIP-0](YIPS/yip-0.md).
2.  Fork the repository by clicking "Fork" in the top right.
3.  Add your YIP to your fork of the repository. There is a [template YIP here](yip-X.md).
4.  Submit a Pull Request to Yearn's [YIPs repository](https://github.com/iearn-finance/YIPS/).

Your first PR should be a first draft of the final YIP. It must meet the formatting criteria enforced by the build (largely, correct metadata in the header). An editor will manually review the first PR for a new YIP and assign it a number before merging it. Make sure you include a `discussions-to` header with the URL to a new thread on [gov.yearn.finance](https://gov.yearn.finance/) where people can discuss the YIP as a whole.

If your YIP requires images, the image files should be included in a subdirectory of the `assets` folder for that YIP as follow: `assets/yip-X` (for yip **X**). When linking to an image in the YIP, use relative links such as `../assets/yip-X/image.png`.

When you believe your YIP is mature and ready to progress past the WIP phase, you should ask to have your issue added to the next governance call where it can be discussed for inclusion in a future platform upgrade. If the community agrees to include it, the YIP editors will update the state of your YIP to 'Approved'.

## YIP Statuses

- **WIP** - a YIP that is still being developed.
- **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 is pending another YIP/some other change that should be bundled with it together.
- **Moribund** - a YIP that was implemented but is now obsolete and requires no explicit replacement.
- **Voting** - a YIP that is in the voting phase on snapshot.

## Validation

YIPs must pass some validation tests. The YIP repository ensures this by running tests using [html-proofer](https://rubygems.org/gems/html-proofer) and [yip_validator](https://rubygems.org/gems/yip_validator).

It is possible to run the YIP validator locally:

```
gem install yip_validator
yip_validator <INPUT_FILES>
```

## YIP Generator

A YIP Generator is available [as a nodejs package here](https://github.com/sambacha/generator-yyip).

## Copyright

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


text:
# To get started with Dependabot version updates, you'll need to specify which
# package ecosystems to update and where the package manifests are located.
# Please see the documentation for all configuration options:
# https://help.github.com/github/administering-a-repository/configuration-options-for-dependency-updates

version: 2
updates:
  - package-ecosystem: "bundler"
    directory: "/" # Location of package manifests
    schedule:
      interval: "daily"


text:
 blank_issues_enabled: false
contact_links:
  - name: Yearn Finance Community Forums and Support
    url: https://gov.yearn.finance/
    about: Please ask and answer questions here.
  - name: Yearn Finance Security & Bug Bounty
    url: https://github.com/yearn/yearn-security
    about: Please report security vulnerabilities here.


text:
name: Project Board

on:
  issues:
    types: [opened]

jobs:
  project:
    runs-on: ubuntu-latest

    steps:
      - name: Create or Update Project Card
        uses: peter-evans/create-or-update-project-card@v1
        with:
          token: ${{ secrets.PAT }}
          project-location: yearn
          project-name: Web
          column-name: Back log


text:
name: Validate

on:
  push:
    branches: ["master"]
  pull_request:
    branches: ["*"]

jobs:
  Validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 2.6 # Not needed with a .ruby-version file
          bundler-cache: true # runs 'bundle install' and caches installed gems automatically

      - name: Install dependencies
        run: |
          bundle config path vendor/bundle
          bundle install --jobs 4 --retry 3
      - name: Doctor
        run: bundle exec jekyll doctor

      - name: Build
        run: bundle exec jekyll build

      - name: Run HTMLProofer
        run: bundle exec htmlproofer ./_site --internal-domains=yips.yearn.finance --check-html --check-opengraph --report-missing-names --log-level=:debug --assume-extension --empty-alt-ignore --timeframe=6w --url-ignore=/YIPS/yip-0 --disable-external

      - name: Run GH pages healthcheck
        run: bundle exec github-pages health-check

      - name: Run YIP validator
        run: bundle exec yip_validator $(ls YIPS/*.md | egrep "yip-[0-9]+.md")


text:
---
---

// Give headings a little breathing room.
h2,
h3,
h4,
h5,
h6 {
  margin-top: 25px;
}

.center-image {
  margin: 0 auto;
  display: block;
}


text:
---
layout: default
---

<link rel="stylesheet" href="/assets/additional-styles.css">

    YIP {{ page.yip | xml_escape }}: {{ page.title | xml_escape }}
    <svg role="img" aria-label="Source" xmlns="https://www.w3.org/2000/svg" width="14" height="16" viewBox="0 0 14 16"><title>Source</title><path fill-rule="evenodd" d="M9.5 3L8 4.5 11.5 8 8 11.5 9.5 13 14 8 9.5 3zm-5 0L0 8l4.5 5L6 11.5 2.5 8 6 4.5 4.5 3z"/></svg>

Author	{% include authorlist.html authors=page.author %}

    {% if page["discussions-to"] != undefined %}

Discussions-To	{{ page["discussions-to"] | xml_escape }}

    {% endif %}

Status	{{ page.status | xml_escape }}
    {% if page.review-period-end != undefined %}
      (review ends {{ page.review-period-end | xml_escape }})
    {% endif %}

    {% if page.category != undefined %}

Category	{{ page.category | xml_escape }}

    {% endif %}

Created	{{ page.created | xml_escape }}

    {% if page.implementation != undefined %}

Implementation	{% include yipnums.html yips=page.implementation %}

    {% endif %}
    {% if page.requires != undefined %}

Requires	{% include yipnums.html yips=page.requires %}

    {% endif %}
    {% if page.replaces != undefined %}

Replaces	{% include yipnums.html yips=page.replaces %}

    {% endif %}
    {% if page["superseded-by"] != undefined %}

Superseded by	{% include yipnums.html yips=page.superseded-by %}

    {% endif %}
    {% if page.resolution != undefined %}

Resolution	{{ page.resolution | xml_escape }}

    {% endif %}

  {{ content }}


text:
{%- assign authors=include.authors|split:"," -%}
{%- for author in authors -%}
  {%- if author contains "<" -%}
    {%- assign authorparts=author|split:"<" -%}
    "}}">{{authorparts[0]|strip}}
  {%- elsif author contains "(@" -%}
    {%- assign authorparts=author|split:"(@" -%}
    {{authorparts[0]|strip}}
  {%- else -%}
    {{author}}
  {%- endif -%}
  {% if forloop.last == false %}, {% endif %}
{%- endfor -%}


text:
{% capture tocWorkspace %}
{% comment %}
    Version 1.0.10
      https://github.com/allejo/jekyll-toc

    "...like all things liquid - where there's a will, and ~36 hours to spare, there's usually a/some way" ~jaybe

    Usage:
        {% include toc.html html=content sanitize=true class="inline_toc" id="my_toc" h_min=2 h_max=3 %}

    Parameters:
        * html         (string) - the HTML of compiled markdown generated by kramdown in Jekyll

    Optional Parameters:
        * sanitize     (bool)   : false  - when set to true, the headers will be stripped of any HTML in the TOC
        * class        (string) :   ''   - a CSS class assigned to the TOC
        * id           (string) :   ''   - an ID to assigned to the TOC
        * h_min        (int)    :   1    - the minimum TOC header level to use; any header lower than this value will be ignored
        * h_max        (int)    :   6    - the maximum TOC header level to use; any header greater than this value will be ignored
        * ordered      (bool)   : false  - when set to true, an ordered list will be outputted instead of an unordered list
        * item_class   (string) :   ''   - add custom class(es) for each list item; has support for '%level%' placeholder, which is the current heading level
        * baseurl      (string) :   ''   - add a base url to the TOC links for when your TOC is on another page than the actual content
        * anchor_class (string) :   ''   - add custom class(es) for each anchor element

    Output:
        An ordered or unordered list representing the table of contents of a markdown block. This snippet will only
        generate the table of contents and will NOT output the markdown given to it
{% endcomment %}

{% capture my_toc %}{% endcapture %}
{% assign orderedList = include.ordered | default: false %}
{% assign minHeader = include.h_min | default: 1 %}
{% assign maxHeader = include.h_max | default: 6 %}
{% assign nodes = include.html | split: '<h' %}
{% assign firstHeader = true %}

{% capture listModifier %}{% if orderedList %}1.{% else %}-{% endif %}{% endcapture %}

{% for node in nodes %}
    {% if node == "" %}
        {% continue %}
    {% endif %}

    {% assign headerLevel = node | replace: '"', '' | slice: 0, 1 | times: 1 %}

    {% if headerLevel < minHeader or headerLevel > maxHeader %}
        {% continue %}
    {% endif %}

    {% if firstHeader %}
        {% assign firstHeader = false %}
        {% assign minHeader = headerLevel %}
    {% endif %}

    {% assign indentAmount = headerLevel | minus: minHeader %}
    {% assign _workspace = node | split: '</h' %}

    {% assign _idWorkspace = _workspace[0] | split: 'id="' %}
    {% assign _idWorkspace = _idWorkspace[1] | split: '"' %}
    {% assign html_id = _idWorkspace[0] %}

    {% assign _classWorkspace = _workspace[0] | split: 'class="' %}
    {% assign _classWorkspace = _classWorkspace[1] | split: '"' %}
    {% assign html_class = _classWorkspace[0] %}

    {% if html_class contains "no_toc" %}
        {% continue %}
    {% endif %}

    {% capture _hAttrToStrip %}{{ _workspace[0] | split: '>' | first }}>{% endcapture %}
    {% assign header = _workspace[0] | replace: _hAttrToStrip, '' %}

    {% assign space = '' %}
    {% for i in (1..indentAmount) %}
        {% assign space = space | prepend: '    ' %}
    {% endfor %}

    {% if include.item_class and include.item_class != blank %}
        {% capture listItemClass %}{:.{{ include.item_class | replace: '%level%', headerLevel }}}{% endcapture %}
    {% endif %}

    {% capture heading_body %}{% if include.sanitize %}{{ header | strip_html }}{% else %}{{ header }}{% endif %}{% endcapture %}
    {% capture my_toc %}{{ my_toc }}
{{ space }}{{ listModifier }} {{ listItemClass }} [{{ heading_body | replace: "|", "\|" }}]({% if include.baseurl %}{{ include.baseurl }}{% endif %}#{{ html_id }}){% if include.anchor_class %}{:.{{ include.anchor_class }}}{% endif %}{% endcapture %}
{% endfor %}

{% if include.class and include.class != blank %}
    {% capture my_toc %}{:.{{ include.class }}}
{{ my_toc | lstrip }}{% endcapture %}
{% endif %}

{% if include.id %}
    {% capture my_toc %}{: #{{ include.id }}}
{{ my_toc | lstrip }}{% endcapture %}
{% endif %}
{% endcapture %}{% assign tocWorkspace = '' %}{{ my_toc | markdownify | strip }}


text:
{% assign yips=include.yips|split:"," %} {% for yipnum in yips %}
{{yipnum|strip}}{% if forloop.last ==
false %}, {% endif %} {% endfor %}


text:
<head>
  <meta charset="utf-8" />
  <meta http-equiv="X-UA-Compatible" content="IE=edge" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <title>
    {% if page.yip %}YIP-{{page.yip}}: {% endif %}{% if page.title
    %}{{page.title }}{% else %}{{ site.homeMetaTitle }}{% endif %}
  </title>
  {%- seo -%} <link rel="stylesheet" href="{{ "/assets/main.css" | relative_url
  }}">
  <link rel="shortcut icon" type="image/png" href="/favicon.ico" />
  {%- feed_meta -%} {%- if jekyll.environment == 'production' and
  site.google_analytics -%} {%- include google-analytics.html -%} {%- endif -%}
</head>


text:
{% capture headingsWorkspace %}
{% comment %}
  Version 1.0.5
    https://github.com/allejo/jekyll-anchor-headings

  "Be the pull request you wish to see in the world." ~Ben Balter

  Usage:
    {% include anchor_headings.html html=content %}

  Parameters:
    * html          (string) - the HTML of compiled markdown generated by kramdown in Jekyll

  Optional Parameters:
    * beforeHeading (bool)   : false  - Set to true if the anchor should be placed _before_ the heading's content
    * anchorAttrs   (string) :  ''    - Any custom HTML attributes that will be added to the `<a>` tag; you may NOT use `href`, `class` or `title`
    * anchorBody    (string) :  ''    - The content that will be placed inside the anchor; the `%heading%` placeholder is available
    * anchorClass   (string) :  ''    - The class(es) that will be used for each anchor. Separate multiple classes with a space
    * anchorTitle   (string) :  ''    - The `title` attribute that will be used for anchors
    * h_min         (int)    :  1     - The minimum header level to build an anchor for; any header lower than this value will be ignored
    * h_max         (int)    :  6     - The maximum header level to build an anchor for; any header greater than this value will be ignored
    * bodyPrefix    (string) :  ''    - Anything that should be inserted inside of the heading tag _before_ its anchor and content
    * bodySuffix    (string) :  ''    - Anything that should be inserted inside of the heading tag _after_ its anchor and content

  Output:
    The original HTML with the addition of anchors inside of all of the h1-h6 headings.
{% endcomment %}

{% assign minHeader = include.h_min | default: 1 %}
{% assign maxHeader = include.h_max | default: 6 %}
{% assign beforeHeading = include.beforeHeading %}
{% assign nodes = include.html | split: '<h' %}

{% capture edited_headings %}{% endcapture %}

{% for _node in nodes %}
  {% capture node %}{{ _node | strip }}{% endcapture %}

  {% if node == "" %}
    {% continue %}
  {% endif %}

  {% assign nextChar = node | replace: '"', '' | strip | slice: 0, 1 %}
  {% assign headerLevel = nextChar | times: 1 %}

  <!-- If the level is cast to 0, it means it's not a h1-h6 tag, so let's see if we need to fix it -->
  {% if headerLevel == 0 %}
    <!-- Split up the node based on closing angle brackets and get the first one. -->
    {% assign firstChunk = node | split: '>' | first %}

    <!-- If the first chunk does NOT contain a '<', that means we've broken another HTML tag that starts with 'h' -->
    {% unless firstChunk contains '<' %}
      {% capture node %}<h{{ node }}{% endcapture %}
    {% endunless %}

    {% capture edited_headings %}{{ edited_headings }}{{ node }}{% endcapture %}
    {% continue %}
  {% endif %}

  {% assign _workspace = node | split: '</h' %}
  {% assign _idWorkspace = _workspace[0] | split: 'id="' %}
  {% assign _idWorkspace = _idWorkspace[1] | split: '"' %}
  {% assign html_id = _idWorkspace[0] %}

  {% capture _hAttrToStrip %}{{ _workspace[0] | split: '>' | first }}>{% endcapture %}
  {% assign header = _workspace[0] | replace: _hAttrToStrip, '' %}

  <!-- Build the anchor to inject for our heading -->
  {% capture anchor %}{% endcapture %}

  {% if html_id and headerLevel >= minHeader and headerLevel <= maxHeader %}
    {% capture anchor %}href="#{{ html_id }}"{% endcapture %}

    {% if include.anchorClass %}
      {% capture anchor %}{{ anchor }} class="{{ include.anchorClass }}"{% endcapture %}
    {% endif %}

    {% if include.anchorTitle %}
      {% capture anchor %}{{ anchor }} title="{{ include.anchorTitle | replace: '%heading%', header }}"{% endcapture %}
    {% endif %}

    {% if include.anchorAttrs %}
      {% capture anchor %}{{ anchor }} {{ include.anchorAttrs }}{% endcapture %}
    {% endif %}

    {% capture anchor %}<a {{ anchor }}>{{ include.anchorBody | replace: '%heading%', header | default: '' }}</a>{% endcapture %}

    <!-- In order to prevent adding extra space after a heading, we'll let the 'anchor' value contain it -->
    {% if beforeHeading %}
      {% capture anchor %}{{ anchor }} {% endcapture %}
    {% else %}
      {% capture anchor %} {{ anchor }}{% endcapture %}
    {% endif %}
  {% endif %}

  {% capture new_heading %}
    <h{{ _hAttrToStrip }}
      {{ include.bodyPrefix }}
      {% if beforeHeading %}
        {{ anchor }}{{ header }}
      {% else %}
        {{ header }}{{ anchor }}
      {% endif %}
      {{ include.bodySuffix }}
    </h{{ _workspace | last }}
  {% endcapture %}
  {% capture edited_headings %}{{ edited_headings }}{{ new_heading }}{% endcapture %}
{% endfor %}
{% endcapture %}{% assign headingsWorkspace = '' %}{{ edited_headings | strip }}


text:
{% for status in site.data.statuses %} {% assign yips =
include.yips|where:"status",status|sort:"yip" %} {% assign count = yips|size %}
{% if count > 0 %}

{{status}}

      Number
      Title
      Author

  {% for page in yips %}

      {{page.yip|xml_escape}}

    {{page.title|xml_escape}}
    {% include authorlist.html authors=page.author %}

  {% endfor %}

{% endif %} {% endfor %}


text:
  {%- if site.dribbble_username -%}

    <svg class="svg-icon">
        <use
          xlink:href="{{ '/assets/minima-social-icons.svg#dribbble' | relative_url }}"
        ></use>
      </svg>
      {{ site.dribbble_username| escape }}

  {%- endif -%} {%- if site.facebook_username -%}

    <svg class="svg-icon">
        <use
          xlink:href="{{ '/assets/minima-social-icons.svg#facebook' | relative_url }}"
        ></use>
      </svg>
      {{ site.facebook_username| escape }}

  {%- endif -%} {%- if site.flickr_username -%}

    <svg class="svg-icon">
        <use
          xlink:href="{{ '/assets/minima-social-icons.svg#flickr' | relative_url }}"
        ></use>
      </svg>
      {{ site.flickr_username| escape }}

  {%- endif -%}

    <svg class="svg-icon">
        <use
          xlink:href="{{ '/assets/minima-social-icons.svg#github' | relative_url }}"
        ></use>
      </svg>
      yearn/YIPS

  {%- if site.instagram_username -%}

    <svg class="svg-icon">
        <use
          xlink:href="{{ '/assets/minima-social-icons.svg#instagram' | relative_url }}"
        ></use>
      </svg>
      {{ site.instagram_username| escape }}

  {%- endif -%} {%- if site.linkedin_username -%}

    <svg class="svg-icon">
        <use
          xlink:href="{{ '/assets/minima-social-icons.svg#linkedin' | relative_url }}"
        ></use>
      </svg>
      {{ site.linkedin_username| escape }}

  {%- endif -%} {%- if site.pinterest_username -%}

    <svg class="svg-icon">
        <use
          xlink:href="{{ '/assets/minima-social-icons.svg#pinterest' | relative_url }}"
        ></use>
      </svg>
      {{ site.pinterest_username| escape }}

  {%- endif -%} {%- for mst in site.mastodon -%}{%- if mst.username and
  mst.instance -%}

    <svg class="svg-icon">
        <use
          xlink:href="{{ '/assets/minima-social-icons.svg#mastodon' | relative_url }}"
        ></use>
      </svg>
      {{ mst.username|escape }}

  {%- endif -%}{%- endfor -%} {%- if site.twitter_username -%}

    <svg class="svg-icon">
        <use
          xlink:href="{{ '/assets/minima-social-icons.svg#twitter' | relative_url }}"
        ></use>
      </svg>
      {{ site.twitter_username| escape }}

  {%- endif -%} {%- if site.youtube_username -%}

    <svg class="svg-icon">
        <use
          xlink:href="{{ '/assets/minima-social-icons.svg#youtube' | relative_url }}"
        ></use>
      </svg>
      {{ site.youtube_username| escape }}

  {%- endif -%} {%- if site.googleplus_username -%}

    <svg class="svg-icon">
        <use
          xlink:href="{{ '/assets/minima-social-icons.svg#googleplus' | relative_url }}"
        ></use>
      </svg>
      {{ site.googleplus_username| escape }}

  {%- endif -%} {%- if site.rss -%}

    <svg class="svg-icon">
        <use
          xlink:href="{{ '/assets/minima-social-icons.svg#rss' | relative_url }}"
        ></use>
      </svg>
      {{ site.rss | escape }}

  {%- endif -%}


text:
- WIP
- Proposed
- Approved
- Implemented
- Rejected
- Withdrawn
- Deferred
- Moribund


text:
---
yip: 32
title: Remove YFI burning
status: Implemented
author: Sunil Srivatsa (@alphastorm)
discussions-to: https://gov.yearn.finance/t/yip-32-remove-yfi-burning/1907
created: 2020-08-01
---

## Simple Summary

Remove YFI burning from the protocol.

## Abstract

YFI represents a claim on Yearn protocol fees. To claim fees, YFI can either be burned or staked in the governance pool.

This YIP is to decide whether or not to keep the burning mechanism.

## Motivation

It makes no sense to burn because the price of YFI will always be higher than the claimable fee value. This is because YFI represents current assets in the fee pool plus future expected cashflows. Staking is just obviously better.

**FOR**: Remove YFI burning from the protocol.

**AGAINST**: No change (start burning YFI for fees).

## Metadata

| Name                | Value                                      |
| ------------------- | ------------------------------------------ |
| Proposed by         | 0x74630370197b4c4795bFEeF6645ee14F8cf8997D |
| Total for votes     | 3054.9983 (97.89%)                         |
| Total against votes | 65.8346 (2.10%)                            |
| Quorum              | 24.5% ✔                                    |
| Start block         | 10576777                                   |
| End block           | 10594057                                   |

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: 54
title: Formalize Operations Funding
status: Approved
author: banteg (@banteg), lehnberg (@lehnberg), lex_node (@lex_node), milkyklim (@milkyklim), tracheopteryx (@tracheopteryx)
discussions-to: https://gov.yearn.finance/t/yip-54-formalize-operations-funding/7956
created: 2020-11-12
---

## Summary

- Transform the one-off YIP-41 budget into an Operations Fund that is allocated the same amount of funding on a continuous basis.
- Permit the Fund to **buy back YFI** or other assets at its discretion.
- Publish a quarterly report to make it easy for YFI holders to audit fund activities.
- This proposal supersedes the treasury cap of YIP-36 and the operations budget of YIP-41. Future changes can be made through additional YIPs.
- Together with the previously approved YIP-51 and YIP-52, this is the final piece in a trilogy of YIPs seeking to upgrade Yearn operations and financials.

## Background

As Yearn evolves, so does the need to cover operational expenses and quickly react to changes.

YIP-36[[1]](#1) laid the groundwork for Yearn operations funding. YIP-41[[2]](#2) extended this with the inclusion of a one-off operations budget. A forum thread envisioned the Multisig acting as an "operations special interest group"[[3]](#3). Today, there are multiple special interest groups (such as development, documentation, governance, branding/design, and communications) that are not directly related to the Multisig, but partly financed through the YIP-41 budget. The Multisig acts as an executor of the spending decisions of these groups.

This YIP builds on the previously adopted proposals to formalize a structure for sustainable funding of operations, to further Yearn's development and growth.

### Out of scope

The following questions are not covered:

- **How should YFI staking rewards be spent?** Proposals such as [[4]](#4) argue for a change in how staking rewards should be spent. This should be decided on separately by YFI voters.
- **How should spending decisions be made?** This proposal focuses on the funding of operations activities, and how these are reported transparently. Decision-making processes are assumed to be existing per YIP-41.
- **What is Yearn's long term governance structure?** YIP-41 temporarily empowers the Multisig while preparations are made for "a more robust governance architecture". Any material change to Yearn's governance would also need to consider the management of the Operations Fund.

### In scope

The proposal attempts to answer the following questions:

- **How do we sustainably fund operations over the longer term?** The budget in YIP-41 is one-off, for six months only. How do we ensure that operations activities are funded on an ongoing basis?
- **How do we reward contributors better?** Today, contributors are paid in yUSD. There's a desire to partially reward contributors in YFI as well, to give them skin in the game and a stake in the success of Yearn. With a fixed supply of YFI, there needs to be a way to acquire YFI to be used as such.
- **How do we keep accountability, without adding unnecessary overhead?** While we want sustainable funding and contributors to be empowered to act quickly and decisively, we also need to scrutinize spending decisions and hold those who make them accountable. Ideally this should be a simple process that avoids slowing down progress.

### Examples of Operations Expenditure

- **Security costs.** 3rd party audits, bug bounties, tools.
- **Contributor funding.** Recurring payments for full time contributors, one-off grants, bounties.
- **Third party products & services.** Freelancers, companies.
- **Running costs.** Gas expenditure, tools, equipment, infrastructure.

#### Current Yearn operations spend

Estimated to total ~\$434,000 as of November 10, 2020. More than half of the operations spend is security related, with the greater part of the remainder spent on funding contributors in various forms.

![](assets/yip-54/figure1.svg)

## Motivation

### Justifying the proposal

#### 1. Sizing the Operations Fund

The budget set in YIP-41 has so far been sufficient; there is no desire to increase it. Rather, the purpose is to transition from a one-off budget to a continuous funding process.

##### Approximating current allocation

![|3200x1440, 20%](assets/yip-54/figure2.svg)

The above diagram is based on data of the total fees collected by Yearn vaults in a four month period, from July 30 - Nov 05 2020.[[5]](#5)

The fees have then been allocated according to the new vault fee structure of YIP-51[[6]](#6) and the updated Strategist allocation of YIP-52[[7]](#7).

The current budget for operations is based off of the allocation in YIP-41[[2]](#2), calculated as:

```
(a) $ 500,000 + (b) 4 * $ 181,000 = $ 1,224,000
```

Where `(a)` is the bug bounty allocation, and `(b)` is four months worth of monthly operations expenses.

This gives an **approximation** of how rewards would be allocated today, based on YIP-41, -51, and -52. Roughly **53% of the treasury funds** would be allocated to Operations.

##### Proposed allocation

Based on this, the proposal is to round this number down to an **even 50%** and divide the Treasury funds equally between YFI staking rewards and Operations:

![|3200x1440, 20%](assets/yip-54/figure3.svg)

#### 2. Rewarding contributors

Paying a proportion of grants in YFI is an obvious and immediate way to give contributors a stake in the success of Yearn.

As the Treasury does not earn YFI, nor is it able to mint YFI, the straightforward way to acquire YFI is to **buy back YFI** with part of the Operations Fund.

Although this could incidentally have the added benefit of increasing buy demand for YFI, the purpose would not be to manipulate YFI price or to engineer long-term YFI price appreciation. Rather, the purpose would be to add YFI to the Operations Fund in order to reward contributors through YFI grants.

Rather than making an explicit pledge, or revealing a process that then is at risk of being exploited, it thought to be better to trial this on an ad-hoc basis. Exact capital allocations would be determined at the discretion of the Multisig based on various factors, including prevailing market conditions.

For instance, the recent negative downturn of the YFI price would have made an excellent buy opportunity for the Operations Fund.

As new Yearn products are introduced, so could the need emerge to buy back other assets than YFI. The Operations Fund therefore should have the right to buy any asset as required.

#### 3. Keeping contributors accountable

As operations move to continuous funding, tracking spending decisions and holding contributors accountable becomes ever more important.

This proposal does not introduce any new spending mechanisms. All spending is signed off by the Multisig, with activities already tracked and published in a dedicated repo, `/ychad-audit`[[8]](#8).

In addition, a quarterly Operations Fund Report will be published documenting the activities of the previous period, how funds were spent, the current health of the Operations Fund, and what the focus for the upcoming quarter will be. The report helps YFI holders to audit the fund, and intervene as required by passing a YIP with new fund guidelines.

### Alternatives considered

In addition to the above 50-50 split, the following alternative spending allocations were considered:

- **Allocating 100% of the management fee to the Operations Fund.** This would mean that 100% of the performance fee share would go to YFI stakers. This proposal would have meant a slightly larger Operations Fund, with income that would have been more predictable, as it would not be determined by actual vault performance but by total funds locked in Yearn.
- **Allocating 75% of the management fee to Operations, and 25% of the performance fee.** Similarly, this would add a bit of performance fee into the mix, but keep the majority of the funds assigned to Operations coming from the amount of capital held in the vaults.

While stability and predictability for the Operations Fund is desired, it is more important for contributors to have an equal amount of skin in the game as YFI stakers, even if this leads to a smaller budget if vaults underperform.

### Future possibilities

- **Long-term YFI vesting, or yVest.** An obvious next step would be to establish some form of vesting plan for YFI allocation for long-term contributors. This could be realized with a contributor vault that "dog foods" strategies.
- **Team Funds.** As teams mature, they could be allocated dedicated budgets from the Operations Fund, increasing decentralization and autonomy.
- **Financial planning and analysis.** As Operations continues to evolve, further planning, budgeting, and forecasting can be added when deemed necessary.

## Specification

1. Effective with the introduction of Vaults v2, allocate 50% of Treasury fees to an Operations Fund, with the other 50% distributed to YFI stakers.
2. Permit the Operations Fund to buy YFI or any other asset as required with its funds, and to include such in the assets at its disposal.
3. Produce quarterly financial reports of the Operations Fund activities and decisions.
4. As it goes in effect, the Operations Fund replaces the treasury cap of YIP-36 and the budget of YIP-41.
5. The Operations Fund, its asset purchase authorization, and the other matters contemplated herein are not permanent, and can be altered or replaced by YFI holders as required, through the passing of a new YIP.

## Vote

**For:** Yes, establish the Operations Fund.

**Against:** No, reject the proposal.

## Metadata

| Name                | Value                                      |
| ------------------- | ------------------------------------------ |
| Proposed by         | 0x0Cec743b8CE4Ef8802cAc0e5df18a180ed8402A7 |
| Total for votes     | 935.4 YFI/yYFI (99.85%)                    |
| Total against votes | 1.38 YFI/yYFI (0.15%)                      |
| Start date          | Nov 12                                     |
| End date            | Nov 15                                     |

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

## References

1. https://yips.yearn.finance/YIPS/yip-36
2. https://yips.yearn.finance/YIPS/yip-41
3. https://gov.yearn.finance/t/understanding-decentralization-prioritizing-an-operations-team/
4. https://gov.yearn.finance/t/proposal-rethinking-capital-allocation/
5. Dataset available on request
6. https://snapshot.page/#/yearn/proposal/QmSaYHR97LDMDvg9xeTfdNZw6aqL9njxBKM6JVFtCYxKvB
7. https://snapshot.page/#/yearn/proposal/QmbAq6jPB6ocrihjkDo5TLNF4D4w9dw1HsEsJ7vwdwd9g3
8. https://github.com/yearn/ychad-audit/tree/master/reports/financial

## Copyright

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


text:
---
yip: 62
title: Change Two Multisig Signers
status: Implemented
author: banteg (@banteg), lehnberg (@lehnberg), milkyklim (@milkyklim), tracheopteryx (@tracheopteryx)
discussions-to: https://gov.yearn.finance/t/yip-62-change-two-multisig-signers/10758
created: 2021-05-24
---

## Authors

[@banteg](https://gov.yearn.finance/u/banteg), [@lehnberg](https://gov.yearn.finance/u/lehnberg), [@milkyklim](https://gov.yearn.finance/u/milkyklim), [@tracheopteryx](https://gov.yearn.finance/u/tracheopteryx)

## Summary

A proposal to exercise the 'Change Multisig Signers' power held by YFI holders as defined by Governance 2.0[[1]](https://gov.yearn.finance/t/yip-62-change-two-multisig-signers/10758#References) in order to change two signers who have served yearn well and rotate in fresh blood to improve signing speed.

## Status

This proposal is currently in the voting phase. Cast your vote on [Snapshot 32](https://snapshot.org/#/ybaby.eth/proposal/QmddCbGYbkooZ1zp8oYnbBz6frXLRc9xbkapXcuZcdzmMF).

You can learn about our voting rules in YIP-55[[2]](https://gov.yearn.finance/t/yip-62-change-two-multisig-signers/10758#References).

## Abstract

If adopted, this proposal will:

- remove [@Substreight](https://gov.yearn.finance/u/substreight) (Joe Mahon)[[3]](https://gov.yearn.finance/t/yip-62-change-two-multisig-signers/10758#References) and [@tchitra](https://gov.yearn.finance/u/tchitra) (Tarun Chitra)[[4]](https://gov.yearn.finance/t/yip-62-change-two-multisig-signers/10758#References) as multisig signers
- add [@RyanWatkins](https://gov.yearn.finance/u/ryanwatkins)[[5]](https://gov.yearn.finance/t/yip-62-change-two-multisig-signers/10758#References) and [@Lumberg](https://gov.yearn.finance/u/lumberg) (Leo Cheng)[[6]](https://gov.yearn.finance/t/yip-62-change-two-multisig-signers/10758#References) as mulitsig signers

## Motivation

Serving on the yearn multisig is hard work, we should rotate signers regularly and ensure that all signers are reasonably active and available to keep signing speed and engagement high. Both Substreight and Tarun have agreed to step out and Leo and Ryan have agreed to step in.

Big thanks to everyone on the multisig, this adjustment should not be seen as a critique in any way. We are all busy and appreciate all the work this group does.

![photo_2021-05-20 17.06.53](/YIPS/assets/yip-62/figure1.png)

_Analysis of multisig signer activity as of 26 April 2021_

## Specification

To execute the transition we don't need to change the threshold, just execute 2 sequential multisig transactions:

1.  Replace 0x6626593c237f530d15ae9980a95ef938ac15c35c (Tarun) with 0x757280Bd46fC5B1C8b85628E800c443525Afc09b (Ryan)
2.  Replace 0x50B0C406a5C1fC492F84c3F3D4552391cF4672f2 (Substreight) with 0x7321ED86B0Eb914b789D6A4CcBDd3bB10f367153 (Leo)

## Information

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

| Name           | Value                                                                     |
| -------------  | ------------------------------------------------------------------------- |
| Snapshot Space | [ybaby.eth](https://snapshot.org/#/ybaby.eth)                             |
| Strategie(s)   | pagination, delegation                                                    |
| Author         | 0x29C4dbC1a81d06c9AA2fAed93Bb8B4a78F3eabDb                                |
| IPFS           | https://ipfs.fleek.co/ipfs/QmddCbGYbkooZ1zp8oYnbBz6frXLRc9xbkapXcuZcdzmMF |
| Voting System  | Single choice voting                                                      |
| Start date     | May 24, 2021, 12:00 PM                                                    |
| End date       | May 29, 2021, 12:00 PM                                                    |
| Snapshot       | https://etherscan.io/block/12498244                                       |

## Results

| Result | Value               |
| ------ | ------------------- |
| Yes    | 415.75 YFI (99.64%) |
| No     | 1.51 YFI (0.36%)    |


text:
---
yip: 34
title: Add Synthetix (SNX) to yVaults
status: Approved
author: Substreight (@substreight)
discussions-to: https://gov.yearn.finance/t/yip-34-add-synthetix-snx-to-yvaults/2149
created: 2020-08-06
---

## Simple Summary

Add Synthetix (SNX) as the second volatile asset to be used as collateral in delegated yVaults.

## Abstract

Add Synthetix (SNX) as the second volatile asset to be used as collateral in delegated yVaults.

## Motivation

Additional assets are necessary in order to generate more revenue for the protocol and grow the ecosystem. This proposal nominates SNX as the second volatile asset to be used as collateral. While other tokens have polled higher, the strategy for SNX has already been developed and will be quicker to launch.

**FOR**: Add SNX as the second volatile asset to be used in delegated yVaults.

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

### Overview

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

### Rationale

Synthetix stakers currently incur regularly high gas costs when claiming minted SNX rewards on a weekly basis. With the addition of SNX to yVaults, smaller SNX holders will be able to either allow their rewards to compound or claim them on a regular basis at very low gas costs. This inclusive model will likely draw small and large SNX holders alike, further increasing AUM and driving fee generation for YFI holders. While other tokens have polled higher, the strategy for SNX has already been developed and will be quicker to launch as a vault.

## Metadata

| Name                | Value                                      |
| ------------------- | ------------------------------------------ |
| Proposed by         | 0xCa845A71d1ff53E7DB7769Ae3f356AF53Fb43000 |
| Total for votes     | 4207.0774 (90.40%)                         |
| Total against votes | 446.7678 (9.59%)                           |
| Quorum              | 41.95% ✔                                   |
| Start block         | 10609260                                   |
| End block           | 10626540                                   |

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: 69
title: Reduce and cap fees through yRates
author: banteg, flashfish, jiji, jmonteer, newmickymousse, saltyfacu, wavey
discussions-to: https://gov.yearn.finance/t/yip-69-reduce-and-cap-fees-through-yrates/12588
status: Implemented
created: 2022-06-17
---

## Summary

Establish a new yTeam, **yRates**, and transfer to it the "Set Fees" power, with the requirement that earned  fees must never exceed the yield earned by vault depositors.

### 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.

## Background

In the previous bull market, opportunities were readily available, and Yearn vaults could generate high yields. Since the height of DeFi Summer those yields have shrunk, and it is now common for many crypto assets to return in the lower single-digit APRs.

Yearn vaults never deploy funds unless vault depositors profit from this, as this would add unnecessary risk to depositor funds.

In current low APR environments, this rule forces Yearn vaults to have large amounts of capital uninvested, earning no income for depositors or the Yearn treasury.

### Current state of fees

As per YIP-51[[1]](#References), the current fee structure is:
- 2% management fee
- 20% performance fee

Fees are automatically levied on deployed capital only, and is the primary income source for the Yearn treasury. It finances protocol expenses including grants, gas costs, infrastructure, YFI buybacks, and more.

If a vault strategy is earning 2.5% APR or less, depositors stand to realize no profit on harvest (after the current mgmt + performance fees), which means that funds do not get deployed to this strategy. In such a scenario, some of the implications are that:

-   All strategies which earn between 0.5% - 2.5% APR become non-viable.
-   Yearn treasury earns no fees.
-   Yearn vaults require additional monitoring to react to situations where APR dips too low capital needs to be unallocated.

### yTeams

* As per YIP-61[[2]](#References), yTeams...

   > ...are small, autonomous groups of yearn contributors empowered by YFI holders to act independently in the best interest of Yearn within a constrained domain of action and with enumerated, discrete decision-making powers.

   Examples of existing yTeams are yBudget, yOps, and yPeople, each having their own distinct domain and decision-making powers.
* "Set Fees" power is currently with YFI holders, as per YIP-61[[2]](#References).
* YFI holders have the power to ratify new yTeams.
* The yOps team has the power to ratify new signers for yTeams.

## Motivation

Efforts are underway to evolve protocol operations across several areas to improve performance during the bear market.[[3]](#References) As part of this, a dedicated team that is responsible for product fee structures and can react on short notice will allow vaults to stay competitive with higher yields that draw more TVL.

This benefits all stakeholders: vault depositors earn more yield, yearn treasury accrues more fees, and YFI holders see more capital allocated for YFI buybacks.

By establishing strict fee guidelines, yTeam powers become better restricted. Vault depositors also get an understanding of the worst case impact of fees.

### Future possibilities

* **A fee dashboard** to visualize current fee structures across vaults to depositors and improve transparency.
* Delegation to veYFI[[4]](#References) lockers to **dynamically adjust fees** of vaults.

## Specification

1. Ratify a new yTeam, **yRates**. yOps is tasked with ratifying initial signers and quorum, but it must consist of at least four individual signers. This does not imply increasing full time grants, signers can be taken from the existing contributor pool.
2. **Transfer the "Set Fees" power to yRates** from YFI holders.
3. Enforce a strict condition that **Yearn fees must never exceed the yield paid out to its vault depositors**, instructing yRates team members in their work to optimize fees to benefit both vault depositors and the Yearn treasury.
4. Moving forward, **the published quarterly financial reports[[5]](#References) should include an update prepared by yRates** on past fee structures performance and the future outlook. These updates should not block the publication of the report.

## References

1. https://gov.yearn.finance/t/yip-51-set-vault-v2-fee-structure/
2. https://gov.yearn.finance/t/yip-61-governance-2-0/
3. https://medium.com/iearn/building-during-bera-2209f44746fa
4. https://github.com/yearn/yearn-pm/tree/master/financials/reports
5. https://gov.yearn.finance/t/yip-65-evolving-yfi-tokenomics/

## Copyright

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

## Information

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

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

## Results

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


text:
---
yip: 41
title: Temporarily Empower Multisig
status: Implemented
author: tracheopteryx (@tracheopteryx), Joe Mahon (@Substreight), franklin501 (@franklin501), Michael Anderson, Vance Spencer
discussions-to: https://gov.yearn.finance/t/empower-the-multisig/2891

created: 2020-08-24
---

## Summary

Temporarily empower the Multisig members to make basic, limited operational decisions including budgetary expenditures, protocol grants, and hiring for six months, as we prepare a more robust governance architecture.

## Abstract

The proposed change would allow Multisig members to make personnel & budgetary decisions for no more than six (6) months. Any budget is to be proposed to governance for approval. This change would allow operational decisions to be made at a rapid pace for the next six (6) months. During this six-month term, the Multisig will be responsible for facilitating the creation and transition to a multi-DAO structure. These powers, as well as members of the Multisig, can be removed or modified by governance at any time.

## Motivation

In this nascent stage of Yearn's lifetime, it is crucial to make rapid decisions in order to establish a strong foundation. Structure and support needs to be quickly built around Andre’s development speed in order to ensure the success of the protocol. This proposal formalizes administrative roles that will serve as a foundation for the protocol’s transition to a multi-DAO structure in the near term.

## Specification

### Overview

This proposal grants the Multisig operational authority on the following decisions for six (6) months from implementation:

- Determining and distributing protocol grants.
- Determining and distributing community grants.
- Determining and distributing legal + DAO consultation grants.
- Identifying and executing key hires listed on the attached budget.
- Identifying and engaging security firms.
- Identifying and engaging analytical firms.
- Continue executing yVault strategy changes until a dedicated team can take over.
- Facilitating UI & front-end development.
- Facilitating business development and integrations.

This proposal does not grant the Multisig:

- Authority over YFI token or emissions.
- Leadership powers beyond those described above.
- Any powers over the YIP process or governance.
- Authority over the composition of the Multisig group -- any changes to Multisig signers will need to be approved by governance.
- The power to ignore or hinder any approved YIPs or the governance process in general.
- The power to create a legal entity.

### Rationale

Forum Poll (202 votes)

- 78% “Yes, empower the Multisig”
- 22% “No, find a better solution”

Important objections raised in the forum poll argued against moving to a foundation model and overly centralizing powers. Here is how we’re learning and adjusting from this feedback:

- Clarification that this proposal is not for a foundation model and that the yearn governance DAO will retain its dominant authority including the ability to modify or remove the multisig’s members or powers via future on-chain votes.
- A deeper discussion about decentralization, governance, and the urgency for this YIP to pass can be found in this thread: [Understanding Decentralization & Prioritizing an Operations Team](https://gov.yearn.finance/t/understanding-decentralization-prioritizing-an-operations-team/3396).
- Clearer limitations on the multisig’s authority detailed above to be controlled via smart contract.

### Technical Specification

**For:** Empower the Multisig for six (6) months.

**Against:** No changes.

### Proposed Budget

![Budget](assets/yip-41-budget.png)

## Copyright

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


text:
---
yip: 1
title: Minting more YFI
status: Implemented
author: Andre Cronje (@andrecronje)
discussions-to: https://gov.yearn.finance/t/proposal-0-yfi-supply/24
created: 2020-07-19
---

## Simple Summary

**FOR**: Allows weekly distribution of YFI. A second proposal will be submitted to decide how much would be printed weekly.

**AGAINST**: No more YFI tokens will be distributed. Global supply is locked at 30000 YFI permanently.

_NOTE: This was proposal 0 on-chain._

## Metadata

| Name                | Value                                      |
| ------------------- | ------------------------------------------ |
| Proposed by         | 0x473afAb58B2C5D4DbC5FAD5D236f6658AD84E83b |
| Total for votes     | 7734007.4689 (61.02%)                      |
| Total against votes | 4939315.7347 (38.97%)                      |
| Quorum              | 62.68% ✔                                   |
| Start block         | 10490942                                   |
| End block           | 10508222                                   |

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: 66
title: Streamlining contributor compensation
author: 15 members of the Compensation group inc @0xJiji
discussions-to: https://gov.yearn.finance/t/yip-66-streamlining-contributor-compensation/12247
status: Implemented
created: 2022-02-05
---

## Summary

Builds on top of the recently adopted YFI Tokenomics program to simplify Yearn contributor compensation through the introduction of a yDiscount program. Migrates and retires the previous contributor vesting and strategist compensation schemes.

## Abstract

**If adopted**, this proposal seeks to streamline future Yearn contributor compensation through the following steps:
1. Establish that contributors moving forward should all be primarily compensated using the same baseline mechanism, consisting of payouts in stables.
1. As an extension to the baseline mechanism, introduce a new method of rewarding Yearn contributors with YFI tokens, yDiscount, where:
   * Contributors will be able to purchase discounted YFI up to their current monthly compensation level.
   * All the purchased YFI gets locked into veYFI immediately.
   * The discount ranges from 10-60% of current market price, determined by the duration of each contributor's veYFI lock.
3. Retire the use of YFI vesting contracts, and migrate existing contracts to the new mechanism, giving those with remaining vests two options to choose from, either:
   * Lock their entire remaining vesting YFI amount into veYFI for an equal or greater duration; or
   * Release them from their vesting contracts, taking a haircut on the YFI they receive, determined by the remaining duration of their vesting package.
4. Retire Strategist performance fee sharing, and "buy out" existing Strategies in production from this system:
   * Each affected strategist receive a payout based on their net earnings from Strategies.
   * The payout is a multiple of their average historical monthly net earnings, paid out as locked veYFI.
   * The multiple ranges from 3-18 and is determined by the duration of their veYFI lock.
   * Strategist total compensation (including migration) is expected to be  be more or less on the same level as before.
5. Instruct yBudget to set funds aside for a dedicated team budget for Strategists, to be used at their discretion, including to help onboard and retain new team members.

## Background
### An extension of YIP-65

This proposal picks up one of the future possibilities outlined in YIP-65: Evolving YFI Tokenomics[[1]](#References) where a future time-locking mechanism of YFI is integrated with how contributors get rewarded. While it is not required, it is 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:

* **Coordinape & one-time grants.** Coordinape[[2]](#References) is used as a mechanism to distribute rewards for smaller and/or less regular contributions. Occassionaly one-time grants are also being paid by Treasury. These mechanisms are not covered by this proposal and remain as is.
* **Contributor compensation specifics.** This is not a proposal about who should get how much, or how this is decided. For the sake of this proposal, it is simply assumed that there is some group of contributors getting some compensation, which is allocated in some pre-determined way.

### The evolution of compensation

* **Strategists get 10% performance fee.**
YIP-52: Make Strategist Skin in Game Partner for Make Benefit of Glorious Brain of Yearn[[3]](#References) makes a distinction of "Strategists", the group of individual contributors that write autonomous investment strategies to be attached to vaults, and considers them separate from the rest of the contributors.

   With the passing of YIP-52, the 20% performance fee from vaults and strategies is split equally between Treasury and Strategists, with the intention that this is going to be the only compensation for the latter:

   > **Survival of the fittest.** Strategists should “eat what they kill”, rewarding only the most ambitious and best performing, filtering out the rest.

   Regular protocol contributors are being paid in stables from Treasury, income which is formalized by the establishment of the Operations Fund with the passing of YIP-54.[[4]](#References)

* **The mint introduces vesting YFI to new and existing contributors.** The Treasury receives 6,666 YFI with the passing of YIP-57: Funding Yearn's Future[[5]](#References), and a mandate to allocate ~1/3rd of those to existing contributor vesting packages. Four strategists also receives vesting packages at this point[[6]](#References), in recognition of their service, and in an early contradiction to the "eat what you kill" spirit of YIP-52.

   The Yearn treasury explicitly has a right of first refusal to buy back YFI from team members, and selling tokens is explicitly frowned upon and strongly advised against.

* **Governance 2.0 and beyond.** From the passing of YIP-61: Governance 2.0[[7]](#References), the yPeople team is responsible for making final compensation and onboarding decisions, guided by the advice of other contributors, and with the backing of a budget allocation from yBudget / Treasury. Newcomers joining full time tend to get rewarded with stablecoins and YFI vesting packages. Strategists earn the 10% performance fee, and as they get onboarded to become regular contributors, they also earn YFI vesting packages.

### Key Learnings

* **Strategists are a part of Yearn.** They are not outsiders, they are a fundamental part of the Yearn community.
* **Strategists work as a team.** They do not work as single individuals following the "you eat what you kill" logic, they work in groups and as a team of teams, some of the most sovereign and well functioning within the Yearn community. They have established profit sharing amongst themselves, strategy committees, and a "Strategist Multisig" pool in which strategists donate 5% of their earnings to spend on various initiatives.
* **Performance is a team job.** While Strategists write profitable strategies, they are not alone responsible for vault performance. Protocol developers write vault upgrades, Security reviewers audit both vaults and strategies, the Web teams maintain the front-end, yMechanics protect against MEV and improves harvesting margins, the Growth team promotes the product, and the Partnership team helps integrators bring TVL, while banteg keeps the morale up across the board with exquisitely curated hentai. To name a few. It's a team effort that makes Yearn into what it is.
* **Contributors work fluidly across teams and roles.** Contributing to Yearn comes with a lot of freedom, and trying to "assign" a contributor a role or a particular team or identity is more odd than helpful. One contributor can have many roles at the same time: They might be a Strategist, but also work in the Web team, while taking onboarding decisions in yPeople.
* **Legacy compensation packages cloud forward looking compensation.** The first vesting packages were awarded to long time contributors that contributed Yearn in the very early days, with no expectation of compensation. These are naturally greater than the packages awarded to new joiners today. Contributors still get anchored to the legacy packages.
* **The "No YFI dumping" rule is unfair and strikes unevenly.** Some contributors are forced to sell YFI to pay for their taxes, others are not. YFI is fairly liquid, selling these quantities does not impact the markets. And even if it did, it's not  clear that it would be a net negative for Yearn: If a contributor dumps their YFI making the YFI price drop, it creates a buying opportunity for Treasury buybacks.
* **YFI price volatility makes vesting unfair.** Joining when the YFI/USD $60k or $30k gives you at completely different perspective on vesting amounts. It is extremely difficult to account for this fairly when onboarding new contributors and avoid some from feeling short changed.
* **Complexity and effort does not scale with TVL.** The 10% performance fee to Strategists was a wild success. So much that our TVL and Yearn community grew and evolved. Yearn is completely different at $5bn TVL than it was at $500m TVL.
* **Unclear what happens once the vesting expires.** The vesting packages are for 3 years, with the olders having ~1.5 years left to vest. It's undetermined what will happen once these expire.

### Snapshot of current state
#### Vesting packages

As of Jan 06 2022 there were **35** active vesting packages, with a total of **1689.91 YFI** remaining to vest. See below chart for a breakdown of duration.

![image alt](https://svgshare.com/i/dLp.svg)

#### Strategists performance share

In Q4 2021, contributing Strategists earned $5,142,137 in performance fees net.

From this, they donated 5%, or $257,107 to a Strategy Multi-sig treasury that gives grants to newcomers and strategists who do not have a strategy in production.

There are in total eight strategists who are considered full-time contributors with strategies active in production.

These eight received on average ~$203,543/month in Q4.

```
Q4 2021 10% perf fee share, net     = $ 5,142,137
less 5% sms donation                -     257,107
per full time strategist                      / 8
per month                                     / 3
-------------------------------------------------
avg strategist $/month              = $   203,543
```

## Motivation
### Benefits

The following are some of the ways how the new compensation process is expected to improve over the previous state:

* All contributors come under one single system
* Historical vesting packages and strategist comps are removed from the compensation equation, making only recent contributions relevant
* YFI allocation is handled by the contributors themselves, reducing process and decision complexity, and improving decentralization of decision making
* Allows all contributors to align themselves to YFI according to their own preferences
* Directly ties into the veYFI tokenomics design
* Removes the need for a "no YFI dumping rule"
* Supports contributors working in many different roles and teams at the same time
* Can run autonomously for an indefinite period, there's no expiry date on the design

### Expected financial impact
#### yDiscount

* Generates revenue for Treasury that can be spent on more YFI buybacks
* Depletes treasury of YFI from the mint, at the rate contributors decide to spend their earnings on buying YFI.

#### Vesting migration

The impact can be said to be somewhere inbetween the two extremes of possible outcomes:

* **If all choose to migrate and lock for at least as long as their current vesting package**, then the impact on Treasury funds is 0.
* **If all choose to take the haircut**, then the Treasury would stand to save 394.6 YFI in returns from the vesting packages, using the Jan 06 data provided above, or ~23% of what's remaining in the active vesting packages.

In other words, migrating the vesting contracts will result in immediate savings of 0-394.6 YFI. The saved YFI can subsequently be used in the yDiscount program.

#### Strategist performance fee migration

Similarly, if we as per above assume eight strategists that earn on average $200k/mo net, the impact of retiring the perfomance fee sharing can be measured against the possible extreme outcomes of their choices.

```
Total net strategy earnings = 8 strategists x $200k/mo = $1.6m/mo
```

veYFI_lock | Combined Monthly Multiple | Amount to lock in veYFI (USD) |
|---|---:|---:|
| All lock min: 6 months or less | 3 | $4.8m |
| All lock for 1 year | 9 | $14.4m |
| All lock max: 4 years | 18 | $28.8m |

In other words, buying out strategists from the 10% performance fee arrangements is likely to result in YFI in the range of ~$5-25m to be locked into veYFI. In addition, at current performance, Treasury will be earning an additional ~$5.1m per quarter from increased performance fees. This will in turn be partially offset by an increase in the costs of compensation as the eight strategists now come to earn in the same system as all the others contributors. Strategist total compensation (including migration) is expected to be  be more or less on the same level as before.

### Mechanics of the design

Both the migration of vesting packages and the performance fee sharing, as well as the yDiscount program creates a trade-off for contributors that can be expressed as:

_The longer you lock YFI as veYFI, the more rewards you earn._

This by design allows each contributor to lock veYFI in whatever duration they feel suitable, and acts as a proxy to their long term conviction of Yearn's future. Those with the longest time preference, benefit the most. In turn, since each contributor can only have one veYFI lock in the address where they receive compensation, they will need to continuously extend the lock in order to earn the same benefit. This in turn creates a trade-off where:

_If you want to exit veYFI, you will earn less and less until your lock period expires._

This suggests that while the migration and the yDiscount program as proposed may offer seemingly generous rewards at a first glance, the impact of time-locking (and the required constant extension of the lock in order to continue earning the same rewards) should not be underestimated.

### Future possibilities

* Simple, self-governing compensation mechanics can be used to make onboarding and offboarding more autonomous, reducing the decision making burden

### Risks

* **Individual contributor tax position may become negatively affected.** This is highly dependent on the tax jurisdiction of contributors and their personal tax situation. All contributors are advised to seek relevant tax advice to meet their individual needs and circumstances.
* **Migration offers may be too generous.** By design, this proposal errs on the side of being more generous towards contributors than less. The reason for this is simple: Yearn's most valuable assets are its group of contributors. The current onboarding climate in web3 is extremely competitive. Saving a couple of YFI for the Treasury is simply not worth while if it risks alienating key contributors in the process.
* **The migration process is one way.** Once vesting contracts and strategists payments have been migrated, resulting payments cannot be clawed back. There is no return.
* **Existing contributors may leave.** Further to the previous point, once the migration has happened, it's possible that current contributors decide to leave as they now have less to lose in doing so. To be clear, this is not considered a likely outcome, it is the opinion of the authors of this proposal that those who contribute frequently to Yearn today do so primarily out of a high degree of conviction. Nevertheless, this is by design considered an acceptable risk, and may be a net positive if it was to materialize: The migration creates a natural moment of opportunity for those that are less motivated to contribute to Yearn to exit. This in turn creates opportunity for others to step up and fill their shoes. By ensuring that only those with true conviction remain, this could be a chance to make Yearn's culture stronger.
* **Onboarding of new strategists may be negatively affected.** Currently the 10% performance fee acts as a form of marketing tool to draw attention and attract new talent to write strategies for Yearn vaults. Whilst the strategists would still be compensated, this marketing tool may be lost and this may adversely affect onboarding. On the other hand, the way it is advertised today might also be considered “false advertising”, as it’s hardly a “set it and forget it” type of task that earns passive income. Instead it’s a complex effort to maintain a Yearn strategy and vault in production, requiring more resources than its single author, and as committees have shown, rewards end up being shared among several either way. There is currently no strategy live at Yearn that is the result of a solo effort. Part time strategists would be able to contribute and be compensated as they are today, through grants from the Strategist's multi-sig.

### Alternatives considered

* Rather than YFI discounts when purchasing, instead offer bonus YFI when contributors make veYFI deposits. This however means it's hard to track where this YFI comes from and opens up for this to be gamed.
* Traditional options model detached from the YFI Tokenomics program.

## Specification
### 0. The below goes into effect with veYFI

* This entire proposal is blocked by the introduction of `veYFI`, as outlined in YIP-65 (phase 2 and onwards).
* None of these changes go into effect before veYFI has been released to production.
* Once veYFI has been released, these changes may be implemented at the discretion of Yearn's community of contributors.

### 1. Contributor compensation is streamlined to one single process that is equal to all

* All frequent and regularly contributing members are paid the same way.
* Compensation is in stablecoins, or equivalent.
* Spending on compensation remains at the discretion of yBudget/Treasury as per Governance 2.0.
* Individual contributor compensation remains at the discretion of yPeople as per Governance 2.0.
* This excludes occasional part-time grants and funding via Coordinape, which have their own separate procesess.

### 2. Contributors are rewarded with YFI tokens through yDiscount

* All contributors being compensated as per the previous point have the option to purchase YFI through a new yDiscount program.
* Contributors can purchase YFI at discounts to current YFI market price, _subject to their current veYFI lock_. The longer the ve-YFI lock, the greater the discount.
* YFI purchased through this program are immediately locked into veYFI according to the duration of their lock.
* Contributors are only eligible to purchase YFI _up to 100% of the compensation amount they received that month_, once the discount has been factored in.
* Once feasible, the intention is to have these operations occuring on chain each month with contributors directly interacting with smart contracts. Until then, manual off-chain calculations are used.
* Contributors are only allowed to participate with one ethereum wallet address in the program, which can only have one single ve-YFI lock at any time.
* Changing a participating wallet address is only permitted in exceptional circumstances and requires yPeople approval.
* The YFI minted with YIP-57 is used to finance this program, and once this has been depleted, yBudget will allocate YFI from treasury buybacks.
* Funds received from contributors participating in yDiscount is used for more YFI buybacks.
* yBudget has the power to pause the yDiscount program at their discretion.

#### ve-lock Discount

```
# yfi_discount: discount (%) of purchased YFI
# ve_lock: current weeks locked in veYFI
yfi_discount = 0.00245 * ve_lock + 0.0902
```

So if the coming veYFI implementation is with the following parameters:
```
min_lock_duration = 1 month, or 4 weeks
max_lock_duration = 4 years, or 208 weeks
```

Then the discount table would look as follows:

| % of max lock | duration | `ve_lock` | `yfi_discount` |
|---:|---|---:|---:|
|1.92% | 1 month |4 | 10% |
| 11.5% |6 months | 24 | 14.9% |
|25% | 1 year | 52 | 21.8% |
| 50% | 2 years | 104 | 34.5% |
|100% | 4 years | 208 | 60% |

#### YFI for purchase

```
# yfi_allowed: total YFI allowed to purchase this month
# comp: contributor compensation in stables this month
# yfi_price: current YFI price in stables
yfi_allowed = comp / (1 - yfi_discount) * yfi_price
```

#### Example

Alice is a contributor earning 3,000 DAI this month. The current price of YFI is 100,000 DAI. She has just extended her ve-lock to be 48% of max, or 99.84 weeks of 208 max possible (`ve_lock=99.84`). She therefore is entitled to purchase YFI at 33.4% discount (`yfi_discount=0.334`).

At the current price, factoring in the discount, Alice is entitled to purchase up to 0.04504504 YFI this way.

Alice decides to spend 1500 DAI to purchase 0.02252252 YFI this month, which immediately becomes locked into veYFI according to her existing lock.

### 3. Retire & Migrate YFI vesting contracts

1. Vesting contracts are no longer offered to contributors by default, and are only to be used in exceptional circumstances. Instead, yDiscount is the default method of YFI compensation.
1. Existing YFI vesting contract are migrated and closed down, with recipients having the choice of one of two options:
   1. **Full migration into veYFI.** If the contributor sets a veYFI lock that is equal or longer than their existing vesting package, 100% of their remaining vest is locked into veYFI.

      _Example: Bob has 1.5 years remaining to vest 9.731 YFI. Bob creates a veYFI lock of 2 years. The full 9.731 YFI is locked on his behalf into his veYFI lock._
   3. **Exit vesting package with a haircut.** For every 1 week remaining of a vesting package, the recipient takes a 0.25% haircut, and is paid out the remaining in unlocked YFI that they can do whatever they please with.

      _Example: Carol has 98.321 weeks left to vest 18.821 YFI. She takes a 24.58% haircut (`98.321 x 0.25`) and is paid out 14.19 YFI._

### 4. Retire Strategist performance fee sharing and buy out existing Strategies

1. Strategy authors are no longer offered the 10% performance fee share for new strategies that get deployed to Production, instead Treasury receives the full 2% management fee and 20% performance fee.
1. Strategists are compensated the same way as any other contributor: stablecoins + yOption system.
1. Strategies already in Production and earning 10% performance fee are "bought out" using the following scheme:
   * Earn `x` times previously averaged monthly earnings from the strategy, paid out as veYFI, where `x` depends on the veYFI lock:
        ```
        # buy_out: total amount of YFI to be locked in the strategist's veYFI
        # net_earnings: strategist's average monthly earnings the past 6 months
        # x: multiple, depending on strategist's excisting veYFI lock
        # YFI_price: current YFI price in stables
        buy_out = (net_earnings * x) / yfi_price
        ```

        | % of max lock | duration | `ve_lock` | `x` |
        |---:|---|---:|---:|
        | < 12.5% | no lock or < 6 months | < 26 | 3 |
        | 12.5% |6 months | 26 | 6 |
        |25% | 1 year | 52 | 9 |
        | 50% | 2 years | 104 | 12 |
        |100% | 4 years | 208 | 18 |

       In other words, if a Strategist creates a veYFI lock for four years, they receive 18 months of their averaged earnings paid out as veYFI locked for four years.

   * Average monthly earnings is calculated as an average of the past six months, and is done with the help of each individual strategist, where __net earnings__ is calculated. Net earnings would include earnings from other strategies, committees, or strategists, and exclude payments made to committees, or strategists.

   _Example: David is a strategist with 2 strategies in Production and is also member of a committee. He donates 5% of his earnings to the Strategist Multisig. Looking back over the last 6 months, David's net earnings was on average $45,500/month. David creates a veYFI lock of 2 years. YFI/USD is $35,000. David receives 15.6 veYFI that are locked for 2 years._

### 5. Establish a dedicated team budget for Strategists

1. As a replacement for the donations to the Strategist Multisig, yBudget are instructed to set funds aside for a dedicated team budget for Strategists.
2. This can go to the existing Strategist Multisig wallet, no changes to signers are required.
3. Funds are to be used at the discretion of the Strategists, including to help onboard and retain new team members, but also any other activity that is not in conflict with Yearn spending policies.

## Changelog

* Feb 01 2022: Rename yOptions to yDiscount, add another identified risk
* Feb 02: Make edits and clarifications as per feedback below

## References

1. https://gov.yearn.finance/t/yip-65-evolving-yfi-tokenomics/11994#future-possibilities-11
1. https://coordinape.com/
1. https://gov.yearn.finance/t/yip-52-make-strategist-skin-in-game-partner-for-make-benefit-of-glorious-brain-of-yearn/7856
1. https://gov.yearn.finance/t/yip-54-formalize-operations-funding/7956
1. https://gov.yearn.finance/t/yip-57-funding-yearns-future/9319
1. https://gov.yearn.finance/t/yearn-retention-packages/9698
1. https://gov.yearn.finance/t/yip-61-governance-2-0/10460

## Copyright

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

## Information

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

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

## Results

| Result  | Value               |
| ------- | ------------------- |
| Yes     | 476 YFI (99.79%)    |
| No      | 1 YFI (0.21%)       |


text:
---
yip: 39
title: Add Curve sBTC Pool LP-Tokens yVault
status: Implemented
author: uhmpeps (@az)
discussions-to: https://gov.yearn.finance/t/proposal-add-curve-sbtc-pool-lp-tokens-yvault/3251

created: 08/23/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.-->

Capture up to \$214b in AUM from BTC holders who want to passively grow their BTC holdings by using some voting power to increase sBTC pool CRV returns and create a Vault for sBTC Curve Pool LP-token holders who deposit renBTC / wBTC / sBTC in Curve Pool 6. This can generate significant goodwill from Bitcoin holders who may not be aware of other use cases for their holdings currently.

It’s the Curve sBTC pool which accepts renBTC / wBTC / sBTC which are all equally acceptable and gives the most potential rewards.
We only need to accept the LP-token which is a single token type given to depositors of any type of wrapped BTC.

## 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".-->

Create a Grow Vault for sBTC Curve Pool LP-token depositors which functions almost identically to the yCRV and yYFI vault. Harvest CRV, sell it for more LP-tokens or renBTC which is then re-deposited to create, distribute and compound LP-token growth.

## 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!-->

First big mover advantage. There is room to generate significant goodwill from bitcoin holders (\$214b in potential AUM) by using our voting power to kick % rewards increase toward the sBTC pool, and to create the first fully passive mechanism for BTC holders to increase their Bitcoin holdings. Right now only the most confident BTC holders are depositing and recycling / farming CRV. This can become a black hole for BTC deposits into Curve via renBTC and LP tokens into yVault for passive returns and governance fees.

## 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
-->

[1]

- Add a table row under the Grow Vault product, for LP-token holders who deposited funds into the Curve sBTC Pool named appropriately (don’t know what the LP token is called atm)
- When user deposits Curve sBTC LP-token, system stakes the LP-token to Curve DAO and farms CRV
- Upon receipt and sale of CRV on market, system buys either more LP-token if liquidity/pools are available, or buys renBTC or sBTC
- xBTC is then deposited back to the Curve sBTC pool, LP-tokens generated, shown in table for depositors as gains, and meanwhile LP-tokens are cycled back into Curve DAO to compound CRV generation

[2]

- Use some voting power to increase CRV return generation for BTC depositors to 50-70% to make it highly compelling for BTC holders
- Ensure the new yVault is communicated to the appropriate audiences as a viable alternative to holding a non functional pet rock with no other purpose currently.

**For:** Add Vault for sBTC Curve Pool.

**Against:** No change.


text:
---
yip: 40
title: Replace inactive multisig signers
status: Implemented
author: cp287 (@illlefr4u), Artem K (@banteg)
discussions-to: https://gov.yearn.finance/t/change-participants-of-the-multisig-wallet/2991

created: 2020-08-24
---

## Summary

With more responsibilty for the multisig signers, four of the least active signers have decided to give up their slots for more engaged participants. This proposal replaces the four signers with new ones chosen based on activity and merit.

## Abstract

Currently executing a multisig transaction can often take up to 24 hours. With Andre’s pace of work and a rapidly changing environment, this creates problems and an unnecessary time gap. Multisig participants must be responsible, but they must also be constantly inside the project and take the necessary actions for its rapid development.

## Motivation

Yearn needs a multisig which will quickly implement the decisions made, while not violating the security of the funds under the wallet's control.

## Specification

### Overview

The following signers have given up their spots:

- Michael (Curve.fi)
- Cooper Turley
- Calvin Liu
- Damir Bandalo

After careful consideration and voting, we suggest these four nominees:

- Joe Mahon (Substreight)
- Tarun Chitra (Gauntlet)
- Vasiliy Shapovalov (p2p.org)
- Mariano Conti (ex-MakerDAO)

### Rationale

We need a strong and responsive protocol multisig which can figure stuff out when some of the members are not immediately available. See also the dicussion links for activity stats and further rationale.

### Technical Specification

To execute the transition we don't need to change the threshold, just execute 8 sequential multisig transactions:

1. Add 0x6E83d6f57012D74e0F131753f8B5Ab557824507D (Vasily)
2. Remove 0xFe45baf0F18c207152A807c1b05926583CFE2e4b (Michael)
3. Add 0x6F2A8Ee9452ba7d336b3fba03caC27f7818AeAD6 (Mariano)
4. Remove 0x59171b87817C5F07157066Bd5284707A711229B3 (Cooper)
5. Add 0x07425B7a76a52dE36dFA313E13E9E3a8DBC476CF (Tarun)
6. Remove 0xb0325DbE7fA891436E83A094f9F12848c78e449b (Calvin)
7. Add 0x50B0C406a5C1fC492F84c3F3D4552391cF4672f2 (Substreight)
8. Remove 0xa83838221278f22ee5bAe3E523f34D42b066D67D (Damir)

## Discussion

https://gov.yearn.finance/t/change-participants-of-the-multisig-wallet/2991

https://gov.yearn.finance/t/nominate-yourself-for-the-foundation-model/3166