diff --git a/docs/contributing/contribute.md b/docs/contributing/contribute.md index 39c8ae8d3b..d9456a54b2 100644 --- a/docs/contributing/contribute.md +++ b/docs/contributing/contribute.md @@ -90,7 +90,7 @@ This is complementary to the above, but it's not directly related to creating st - [yearn.fi](https://yearn.fi/), [GitHub](https://github.com/yearn/yearn.fi) - [Yearn Documentation](https://docs.yearn.fi/), [GitHub](https://github.com/yearn/yearn-devdocs) - [Yearn Governance Forum](https://gov.yearn.fi/) -- [Yearn Snapshot Governance Voting](https://snapshot.box/#/s:veyfi.eth) +- [Yearn Snapshot Governance Voting](https://snapshot.org/#/s:styfi.eth) #### List of Yearn Data Tools @@ -105,10 +105,11 @@ This is complementary to the above, but it's not directly related to creating st - v3 yearn.fi, [GitHub](https://github.com/yearn/yearn-finance-v3) - [Yearn Borrow](https://yborrow.finance/), [GitHub](https://github.com/yearn/iborrow-finance) - [Yearn Governance](https://ygov.finance/), [GitHub](https://github.com/yearn/ygov-finance) - V1 Governance -- [Legacy Yearn Snapshot Governance Voting](https://snapshot.org/#/ybaby.eth) +- [Legacy veYFI Snapshot Governance Voting](https://snapshot.org/#/s:veyfi.eth) +- [Legacy yBaby Snapshot Governance Voting](https://snapshot.org/#/ybaby.eth) - [Yearn Newsletter](https://yearn.substack.com/) - Weekly YFI newsletter - [Trackavault](https://trackavault.com/) - Track V2 Vaults - [Yearn Watch](https://yearn.watch/), [GitHub](https://github.com/yearn/yearn-watch) - [YFI Address Stats](https://www.yfistats.com/) - Yearn Financial Information - [yCosystem (Yearn Community Aggregator)](https://ycosystem.info/) - Repository Of Yearn Links -- [GitHub Project Board](https://contribute.yearn.farm) \ No newline at end of file +- [GitHub Project Board](https://contribute.yearn.farm) diff --git a/docs/contributing/governance/proposal-process.md b/docs/contributing/governance/proposal-process.md index c45374d367..f159d1071a 100644 --- a/docs/contributing/governance/proposal-process.md +++ b/docs/contributing/governance/proposal-process.md @@ -1,40 +1,32 @@ # Proposal Process -[veYFI](/contributing/governance/veyfi) token holders control the Yearn ecosystem through offchain proposals and votes via [Snapshot](https://snapshot.org/#/s:veyfi.eth). Proposals that generate majority support (>50% of the vote) are implemented by a 9-member multi-signature wallet, and 6 out of 9 wallet signers must sign for a change to be implemented. The [members of the multi-signature wallet](/developers/security/multisig#members) were voted in by YFI holders and are subject to change from future governance votes. +[stYFI](/contributing/governance/styfi) token holders govern the Yearn ecosystem through offchain proposals and votes via [Snapshot](https://snapshot.org/#/s:styfi.eth). Proposals that generate majority support (>50% of the vote) are expected to be implemented by the proposed relevant parties. The 9-member [yChad multi-signature wallet](/developers/security/multisig) is then empowered to execute all related transactions after their own review. The [members of the multi-signature wallet](/developers/security/multisig#members) are voted in by YFI holders and are subject to change via future governance votes. ## Discussion -Discussion regarding changes in the protocol happens on a variety of platforms, such as: +Public discussion regarding changes to the protocol happens mostly on the [Governance Forum](https://gov.yearn.fi/). Other, informal discussion may also happen on [Discord](https://discord.gg/yearn) and [Telegram](https://t.me/yearnfinance), although all final language and implementation details are expected to be presented on the governance forum. -- [Governance Forum](https://gov.yearn.fi/) -- [Discord](https://discord.gg/yearn) -- [Telegram](https://t.me/yearnfinance) +Getting as much feedback as possible from the various Yearn stakeholders is recommended before introducing a formal proposal. The governance forum and Discord server have dedicated channels for proposals and governance. -Getting as much feedback as possible from the various communication channels is recommended before introducing a formal proposal. The governance forum and Discord server have dedicated channels for specific topics. +## Proposals -## Proposal - -### Types of proposals - -**Yearn Improvement Proposals** (YIPs) are an all-encompassing vehicle for exercising power that token holders have. After [YIP-61](https://gov.yearn.fi/t/yip-61-governance-2-0/10460), **Yearn Delegation Proposals** (YDPs) were introduced, which allow token holders to change where any discrete decision-making power is delegated. - -![](https://i.imgur.com/ZRNp2Zq.png) +**Yearn Improvement Proposals** (YIPs) are Yearn's comprehensive vehicle for exercising governance power. #### Previous and current proposals - Previous: [Proposal Repository](/contributing/governance/proposal-repository) -- Current: [Snapshot](https://snapshot.org/#/ybaby.eth) +- Current: [Snapshot](https://snapshot.org/#/s:styfi.eth) #### Requirements to pass proposals - 3 day discussion on the [forum](https://gov.yearn.fi/) - At least 50% vote 'for' the change -- 1 veYFI in possession to submit to snapshot -- 5 day [snapshot](https://snapshot.org/#/ybaby.eth) with over 50% passing votes +- 1 stYFI in possession to submit to snapshot +- 5 day [snapshot](https://snapshot.org/#/s:styfi.eth) with over 50% passing votes ### Making a proposal -Anyone can post a proposal on the forum for discussion within the community. If it's promoted to offchain votation (via [Snapshot](https://snapshot.org/#/ybaby.eth)), only someone holding 1 veYFI can submit it to Snapshot. If your proposal made it to offchain votation and you don't have enough veYFI, mods will help you through this stage. +Anyone can post a proposal on the forum for discussion. If it successfully gets over 50% of "for" votes on the forum, then it can move to the token weighted voting step via [Snapshot](https://snapshot.org/#/s:styfi.eth). Posting a vote to snapshot requires holding 1 stYFI. If your proposal made it to the snapshot phase and you don't have enough stYFI, you must find someone with at least 1 stYFI to propose on your behalf. The default template for proposals can be found on [GitHub](https://github.com/yearn/YIPS/blob/master/yip-X.md) + on the [forum](https://gov.yearn.fi), if you post under "proposals" or "discussion" it will auto-fill in the template as well. @@ -49,15 +41,15 @@ The default template for proposals can be found on [GitHub](https://github.com/y #### How do I vote? -- Holding [veYFI](/contributing/governance/veyfi) enables you to vote on Yearn's [Snapshot](https://snapshot.org/#/ybaby.eth) page +- Holding [veYFI](/contributing/governance/veyfi) enables you to vote on Yearn's [Snapshot](https://snapshot.org/#/s:styfi.eth) page #### What’s the difference between voting for a poll on the forum and an offchain vote? -- A poll gauges the sentiment of what the community is feeling on the proposal while an offchain vote (via [Snapshot](https://snapshot.org/#/ybaby.eth)) will be binding and will take effect if it passes. +- A poll gauges the sentiment of what the community is feeling on the proposal while an offchain vote (via [Snapshot](https://snapshot.org/#/s:styfi.eth)) will be binding and will be considered binding if it passes. ## Implementation -Once a Snapshot votes have passed, changes will be implemented by Yearn's protocol or operations team and signed by the multi-sig, if necessary. +Once a Snapshot vote has passed, changes will be implemented by Yearn's protocol or operations team and signed by the multi-sig, if necessary. ## Guardian Role diff --git a/docs/contributing/governance/proposal-repository.md b/docs/contributing/governance/proposal-repository.md index 8002054994..1c6c3e9bd6 100644 --- a/docs/contributing/governance/proposal-repository.md +++ b/docs/contributing/governance/proposal-repository.md @@ -2,62 +2,79 @@ Yearn Improvement Proposals (YIPs), Yearn Delegation Proposals (YDPs) and Yearn Signaling Proposals (YSPs) are all tools that token holders use to maintain and grow the protocol. -## Approved +## Proposals -| Number | Title | Author | -| ------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | -| [34](https://yips.yearn.fi/YIPS/yip-34) | Add Synthetix (SNX) to yVaults | [Substreight](https://github.com/substreight) | -| [52](https://yips.yearn.fi/YIPS/yip-52) | Make Strategist Skin in Game Partner for Make Benefit of Glorious Brain of Yearn | [banteg](https://github.com/banteg), [lehnberg](https://github.com/lehnberg), [milkyklim](https://github.com/milkyklim) | -| [65](https://snapshot.org/#/ybaby.eth/proposal/0x8f7417fa5565d9f46e16618503e8808c36d51b2a9e8217a68c632d7c090d69d9) | Evolving YFI Tokenomics (veYFI) | [0xJiji](https://gov.yearn.fi/u/0xjiji), [banteg](https://github.com/banteg), daryllautk, HAtTip3675, [onlylarping](https://gov.yearn.fi/u/onlylarping), [vany365](https://gov.yearn.fi/u/vany365), [Wot_Is_Goin_On](https://gov.yearn.fi/u/wot_is_goin_on) | +Proposals are listed in reverse numerical order, with the most recent first. Select a YIP number to open its archived proposal, metadata, forum discussion, and voting record. Recovered Snapshot outcomes are linked directly; "Active" means voting has not yet closed. -## Implemented - -| Number | Title | Author | -| ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [0](https://yips.yearn.fi/YIPS/yip-0) | YIP Purpose and Guidelines | Yearn Community | -| [1](https://yips.yearn.fi/YIPS/yip-1) | Minting more YFI | [Andre Cronje](https://github.com/andrecronje) | -| [10](https://yips.yearn.fi/YIPS/yip-10) | Transitionary YFI Only Voting | [Rewkang](https://github.com/rewkang) | -| [12](https://yips.yearn.fi/YIPS/yip-12) | Reducing the quorum for accepting proposal | [cp287](https://github.com/illlefr4u) | -| [32](https://yips.yearn.fi/YIPS/yip-32) | Remove YFI burning | [Sunil Srivatsa](https://github.com/alphastorm) | -| [33](https://yips.yearn.fi/YIPS/yip-33) | Add LINK to yVaults | [franklin](https://github.com/franklin501) | -| [35](https://yips.yearn.fi/YIPS/yip-35) | Distribute Donations vs Purchase YFI | [Andre Cronje](https://github.com/andrecronje),[Klim K](https://github.com/milkyklim) | -| [36](https://yips.yearn.fi/YIPS/yip-36) | System rewards as operational capital | [Andre Cronje](https://github.com/andrecronje), iTo, [n00b](https://github.com/jchi18), [Artem K](https://github.com/banteg) | -| [37](https://yips.yearn.fi/YIPS/yip-37) | Participate in CRV governance and 2.5x CRV reward boost | [Andre Cronje](https://github.com/andrecronje), [Artem K](https://github.com/banteg) | -| [38](https://yips.yearn.fi/YIPS/yip-38) | Distribute / Keep Balancer Rewards | [Klim K](https://github.com/milkyklim) | -| [39](https://yips.yearn.fi/YIPS/yip-39) | Add Curve sBTC Pool LP-Tokens yVault | [uhmpeps](https://github.com/az) | -| [40](https://yips.yearn.fi/YIPS/yip-40) | Replace inactive multisig signers | [cp287](https://github.com/illlefr4u), [Artem K](https://github.com/banteg) | -| [41](https://yips.yearn.fi/YIPS/yip-41) | Temporarily Empower Multisig | [tracheopteryx](https://github.com/tracheopteryx), [Joe Mahon](https://github.com/Substreight), [franklin501](https://github.com/franklin501), Michael Anderson, Vance Spencer | -| [44](https://yips.yearn.fi/YIPS/yip-44) | Improve YIP categories | [sam bacha](mailto:sam@freighttrust.com) | -| [45](https://yips.yearn.fi/YIPS/yip-45) | Add a bounty for proposing YIPs that are implemented | [Sunil Srivatsa](https://github.com/alphastorm) | -| [51](https://yips.yearn.fi/YIPS/yip-51) | Set Vault v2 Fee Structure | [banteg](https://github.com/banteg), [lehnberg](https://github.com/lehnberg), [milkyklim](https://github.com/milkyklim), [tracheopteryx](https://github.com/tracheopteryx) | -| [54](https://yips.yearn.fi/YIPS/yip-54) | Formalize Operations Funding | [banteg](https://github.com/banteg), [lehnberg](https://github.com/lehnberg), [lex_node](https://github.com/lex-node), [milkyklim](https://github.com/milkyklim), [tracheopteryx](https://github.com/tracheopteryx) | -| [55](https://gov.yearn.fi/t/yip-55-formalize-the-yip-process/7959/7) | Formalize the YIP Process | [franklin](https://github.com/franklin501) | -| [56](https://snapshot.org/#/yearn/proposal/Qmb6gBzjvgLMazSrQQGVcjutLNdkVyM2Lh6yckMzdoaHWZ) | BABY: Buyback and Build | [lex_node](https://github.com/lex-node), [tracheopteryx](https://github.com/tracheopteryx), [Artem K](https://github.com/banteg), [Klim K](https://github.com/milkyklim), [Ryan Watkins](https://twitter.com/RyanWatkins_), [lehnberg](https://github.com/lehnberg) | -| [57](https://snapshot.org/#/yearn/proposal/QmX8oYTSkaXSARYZn7RuQzUufW9bVVQtwJ3zxurWrquS9a) | Funding Yearn's Future | [aleks-blockchaincap](https://gov.yearn.fi/u/aleks-blockchaincap/summary), [Artem K](https://github.com/banteg), [dudesahn](https://twitter.com/dudesahn), [ekrenzke](https://gov.yearn.fi/u/ekrenzke), [lehnberg](https://github.com/lehnberg), [Klim K](https://github.com/milkyklim), [Ryan Watkins](https://twitter.com/RyanWatkins_), [srs-parafi](https://gov.yearn.fi/u/srs-parafi/summary), [tracheopteryx](https://github.com/tracheopteryx), [vooncer](https://gov.yearn.fi/u/vooncer/summary), [yfi-cent](https://gov.yearn.fi/u/yfi-cent/summary) | -| [59](https://snapshot.org/#/yearn/proposal/QmdRCXH6BQpNcucoZqAtS5hQKjckE2428qiZoWjxmJXbs3) | Temporarily extend Multisig empowerment | [lehnberg](https://github.com/lehnberg) | -| [60](https://snapshot.org/#/ybaby.eth/proposal/QmNqAqRKMFcoRjaRYAKCVETij6sjJ4S1293kbpYDMVvcjB) | Airdrops to Yearn Vaults | [lehnberg](https://github.com/lehnberg) | -| [61](https://snapshot.org/#/ybaby.eth/proposal/QmSMyYeKrRpnA7Xn56o2NtbCUzxmhzCupL7LxMA1reXxq4) | Governance 2.0 | [tracheopteryx](https://github.com/tracheopteryx), [lex_node](https://github.com/lex-node) | -| [62](https://snapshot.org/#/ybaby.eth/proposal/QmddCbGYbkooZ1zp8oYnbBz6frXLRc9xbkapXcuZcdzmMF) | Change Two Multisig Signers | [tracheopteryx](https://github.com/tracheopteryx), [banteg](https://github.com/banteg), [lehnberg](https://github.com/lehnberg), [milkyklim](https://github.com/milkyklim) | -| [63](https://snapshot.org/#/ybaby.eth/proposal/QmPK9AqeoV6v5xeuiTeFcj9Px7y87KMQ1gGhvHft2GMtqE) | Fund Builder-First Legal Activism DAO | [Andre Cronje](https://github.com/andrecronje), [tracheopteryx](https://github.com/tracheopteryx), [lex_node](https://github.com/lex-node), [Judge Jowday](https://twitter.com/judge_jowday), [S. Brennan](https://twitter.com/SH_Brennan), [Birdman_Haxxor](https://twitter.com/Birdman_Haxxor) | -| [66](https://yearn.snapshot.page/#/proposal/0x804d3765e70d6e4f0f0a225222dadd396cd328595d5fd097b732b36fdf8e6af6) | Streamlining contributor compensation | [0xJiji](https://gov.yearn.fi/u/0xjiji) + 14 authors from the Compensation group | -| [67](https://snapshot.org/#/ybaby.eth/proposal/0xd1988feec955cb93d42b63b7b4845d35da8f60859f55ec18b3d5609ecd4eb9e2) | Contribute to the Nomic Foundation | [FrancoNomic](https://gov.yearn.fi/u/franconomic/summary) | -| [68](https://snapshot.org/#/ybaby.eth/proposal/0xc5386b7237f6c90359c56ac6dcb942b99a56a4de8ca60d109f4b999716148734) | Rotate multisig signers | [banteg](https://github.com/banteg) | -| [69](https://snapshot.org/#/ybaby.eth/proposal/0xe4c2c990eaf4bb4a7a8031c461f5db820bae08fd7b81441d56e8cc0378c44afe) | Reduce and cap fees through yRates | [0xJiji](https://gov.yearn.fi/u/0xjiji), [banteg](https://github.com/banteg), flashfish, jiji, jmonteer, newmickymousse, saltyfacu, wavey | - -## Rejected - -| Number | Title | Author | -| -------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [2](https://yips.yearn.fi/YIPS/yip-2) | Burn YFI for fees | [Andre Cronje](https://github.com/andrecronje) | -| [5](https://yips.yearn.fi/YIPS/yip-5) | Reducing YFI weekly supply | [Damir Bandalo](https://github.com/sikiriki12) | -| [8](https://yips.yearn.fi/YIPS/yip-8) | Halving YFI weekly supply the same as bitcoin | steamer.eth | -| [14](https://yips.yearn.fi/YIPS/yip-14) | Yearn Rewards Reserve | [YieldBouncer](https://github.com/yieldbouncer) | -| [30](https://yips.yearn.fi/YIPS/yip-30) | YFI Inflation Schedule | [Substreight](https://github.com/substreight), [DeltaTiger](https://github.com/deltatigernz), [Hannes Graah](https://github.com/Graadient), [Daryl lau](https://github.com/Daryllautk), yfi_whale | -| [31](https://yips.yearn.fi/YIPS/yip-31) | YFI Inflation Distribution | [Substreight](https://github.com/substreight), [DeltaTiger](https://github.com/deltatigernz), [Hannes Graah](https://github.com/Graadient), [Daryl lau](https://github.com/Daryllautk) | -| [42](https://yips.yearn.fi/YIPS/yip-42) | Add RenBTC to yVaults | [Azeem](https://github.com/zu-ctrl) | -| [43](https://yips.yearn.fi/YIPS/yip-43) | Improve YIP categories | Sam Bacha | -| [64](https://yips.yearn.fi/YIPS/yip-43) | Adjust fees on non-stablecoin yVaults | wavey, philbert, saltyfacu | +| Number | Title | Author | Outcome | +| --- | --- | --- | --- | +| [91](/contributing/governance/yips/yip-91) | yTranche | Vaults Team | [Active](https://snapshot.org/#/s:styfi.eth/proposal/0xa348d353b66f46c6957a938a42fbf860eaffc855cd9163d8042780f65ea72612) | +| [90](/contributing/governance/yips/yip-90) | yETH Optimistic Recovery Plan | 0xPickles | [Passed](https://snapshot.org/#/s:veyfi.eth/proposal/0xe76f57663ce9311eb830ef097812702cbbb55fccbb280d254cdfc1f2c11c261a) | +| [89](/contributing/governance/yips/yip-89) | Proposal to Rotate Multisig Signers | wavey | [Passed](https://snapshot.org/#/s:veyfi.eth/proposal/0x02ac9f5cc91ad090938195c37e17fd24941a668082b2b6b58f20e11e32d73003) | +| [88](/contributing/governance/yips/yip-88) | Governance Overhaul: ⓷ Incentives | 0xPickles, governance team contributors | [Passed](https://snapshot.org/#/s:veyfi.eth/proposal/0x9b3a40326411eea6c51ec389a802ed695de53961fa49f6d3525e256513d0a7f9) | +| [88](/contributing/governance/yips/yip-88) | Governance Overhaul: ⓶ stYFI | 0xPickles, governance team contributors | [Passed](https://snapshot.org/#/s:veyfi.eth/proposal/0x9b3a40326411eea6c51ec389a802ed695de53961fa49f6d3525e256513d0a7f9) | +| [88](/contributing/governance/yips/yip-88) | Governance Overhaul: ⓵ DAO Restructuring | 0xPickles, governance team contributors | [Passed](https://snapshot.org/#/s:veyfi.eth/proposal/0x9b3a40326411eea6c51ec389a802ed695de53961fa49f6d3525e256513d0a7f9) | +| [87](/contributing/governance/yips/yip-87) | Convert ychad.eth into a BORG | MetaLeX | [Passed](https://snapshot.org/#/s:veyfi.eth/proposal/0x4726de81255b4be972e0b7bb9f03fac222cfbcef9bd1e148e647be4b8b1fb47d) | +| [86](/contributing/governance/yips/yip-86) | Resupply Bad Debt Repayment Loan | dudesahn | [Passed](https://snapshot.org/#/s:veyfi.eth/proposal/0xe2fc56f50b1c434ca2f80d07542b66b5ff035b22891c8d6ebb79afca62664d02) | +| [85](/contributing/governance/yips/yip-85) | Disable Protocol Fees on Yearn V3 | V3 Protocol Team | [Passed](https://snapshot.org/#/s:veyfi.eth/proposal/0xa3223b388c484ea8a81b60bb88cda99f23d6d06b4b9798b4d0acafaa2207b686) | +| [84](/contributing/governance/yips/yip-84) | Proposal to rotate multisig signer | wavey | [Passed](https://snapshot.org/#/s:veyfi.eth/proposal/0xeecd2a9ca79f9b22071d79d436a7e5ccc56593eb4c3bc8ef1b57c8389809a101) | +| [83](/contributing/governance/yips/yip-83) | Bearn BIP YIP #2 | Schlag | [Passed](https://snapshot.org/#/s:veyfi.eth/proposal/0x872f23d57eea829e5fb0a5e0868f805efdb231d8a3c9e39820dd33432ccd629c) | +| [82](/contributing/governance/yips/yip-82) | The BIP YIP, Bearn Finance | The yBera Boyzzzz | [Rejected](https://snapshot.org/#/s:veyfi.eth/proposal/0x24ae3413fcf92bcb92cbbe8845d0684a4e8d36c7f164b4afee6c45c629f16f83) | +| [81](/contributing/governance/yips/yip-81) | Prepare for Full On-Chain Governance | 0xPickles | [Passed](https://snapshot.org/#/s:veyfi.eth/proposal/0x6f3082db2cef3e0c254e569580d063cb14130a92d0bf1729bef342a386e419f2) | +| [80](/contributing/governance/yips/yip-80) | Sonne Hack Victims Revised Proposal | Yearninger | [Rejected](https://snapshot.org/#/s:veyfi.eth/proposal/0x2a9ecea04244b83ed8f1ef6b4f62e9ee9a31d16c5ef3b52d00e3a185e78df78e) | +| [79](/contributing/governance/yips/yip-79) | Multisig Compensation and Rotation | wavey | [Passed](https://snapshot.org/#/s:veyfi.eth/proposal/0xc7ded2863a10154b6b520921af4ada48d64d74e5b7989f98cdf073542b2e4411) | +| [78](/contributing/governance/yips/yip-78) | Partial Compensation Sonne Hack Victims | Yearninger | [Rejected](https://snapshot.org/#/s:veyfi.eth/proposal/0x47c2883308fafd286697c391748c1381cf374b98cfa3af9d23d2fe79d31df6fb) | +| [77](/contributing/governance/yips/yip-77) | Launch new yLockers Staking | wavey | [Passed](https://snapshot.org/#/s:veyfi.eth/proposal/0xe79fb2ef4f21ef1e9cc30dd1522c9751c74b631c4782bccbbeb25185d4ddae1d) | +| [76](/contributing/governance/yips/yip-76) | Launch yPools | 0xkorin, 0xPickles, 0xValJohn | [Passed](https://snapshot.org/#/s:veyfi.eth/proposal/0xa07123d5f6d3eb236969c798c024098be32231d2c3a205bd197200c955baa10c) | +| [75](/contributing/governance/yips/yip-75) | Launch V3 | V3 Protocol Team, V3 Secret Admirers Group | [Passed](https://snapshot.org/#/s:veyfi.eth/proposal/0xdb02fe93b77c6addfa9b197bb47f5b6d7779f69000210cffe54ea1fb35b91eec) | +| [74](/contributing/governance/yips/yip-74) | YFI Wintermute Loan & CRV Plans | Callen Wintermute | [Rejected](https://snapshot.org/#/s:veyfi.eth/proposal/0x3840d5b6daa3363933806c98335103c9086419b68513bd40f326f5cb0e07e9cf) | +| [73](/contributing/governance/yips/yip-73) | Activate veYFI rewards with oYFI Gauges | veYFI Secret Admirers working group | [Passed](https://snapshot.org/#/s:veyfi.eth/proposal/0xcc2a5f2bad97b551a02230975def5640c6f582d64c3c42eecfb1c6c76eea3b28) | +| [72](/contributing/governance/yips/yip-72) | Launch yETH | 0xkorin, 0xPickles | [Passed](https://snapshot.org/#/s:veyfi.eth/proposal/0x8969cde98d5d8a7be745e442a3288ce0cf3b35bf99ab72265f66c96d117a0f78) | +| [71](/contributing/governance/yips/yip-71) | Activate veYFI | darkghosty, flashfish, jiji, saltyfacu | [Passed](https://snapshot.org/#/s:ybaby.eth/proposal/0xc50b60f712adb8568f10f565fc467e8c5d8fe1f4920683696f81c7920397942a) | +| [70](/contributing/governance/yips/yip-70) | ApeWorX <> Yearn Partnership | fubuloubu, defidipshit | [Passed](https://snapshot.org/#/s:ybaby.eth/proposal/0x1d34233f80a83c3fc4e41583ba115bfd51d3308c7b35249198cab0e49cd527f3) | +| [69](/contributing/governance/yips/yip-69) | Reduce and cap fees through yRates | 0xJiji, banteg, flashfish, jiji, jmonteer, newmickymousse, saltyfacu, wavey | [Passed](https://snapshot.org/#/s:ybaby.eth/proposal/0xe4c2c990eaf4bb4a7a8031c461f5db820bae08fd7b81441d56e8cc0378c44afe) | +| [68](/contributing/governance/yips/yip-68) | Rotate multisig signers | [banteg](https://github.com/banteg) | [Passed](https://snapshot.org/#/s:ybaby.eth/proposal/0xc5386b7237f6c90359c56ac6dcb942b99a56a4de8ca60d109f4b999716148734) | +| [67](/contributing/governance/yips/yip-67) | Contribute to the Nomic Foundation | FrancoNomic | [Passed](https://snapshot.org/#/s:ybaby.eth/proposal/0xd1988feec955cb93d42b63b7b4845d35da8f60859f55ec18b3d5609ecd4eb9e2) | +| [66](/contributing/governance/yips/yip-66) | Streamlining contributor compensation | 0xJiji + 14 authors from the Compensation group | [Passed](https://snapshot.org/#/s:ybaby.eth/proposal/0x804d3765e70d6e4f0f0a225222dadd396cd328595d5fd097b732b36fdf8e6af6) | +| [65](/contributing/governance/yips/yip-65) | Evolving YFI Tokenomics (veYFI) | 0xJiji, banteg, daryllautk, HAtTip3675, onlylarping, vany365, Wot_Is_Goin_On | [Passed](https://snapshot.org/#/s:ybaby.eth/proposal/0x8f7417fa5565d9f46e16618503e8808c36d51b2a9e8217a68c632d7c090d69d9) | +| [64](/contributing/governance/yips/yip-64) | Adjust fees on non-stablecoin yVaults | wavey, philbert, saltyfacu | [Rejected](https://snapshot.org/#/s:ybaby.eth/proposal/0xfe7296601d199b89a8aa53f95d6243ef935d736bea2f13109979d8d5098017d2) | +| [63](/contributing/governance/yips/yip-63) | Fund Builder-First Legal Activism DAO | Andre Cronje, tracheopteryx, lex_node, Judge Jowday, S. Brennan, Birdman_Haxxor | [Passed](https://snapshot.org/#/s:ybaby.eth/proposal/QmPK9AqeoV6v5xeuiTeFcj9Px7y87KMQ1gGhvHft2GMtqE) | +| [62](/contributing/governance/yips/yip-62) | Change Two Multisig Signers | [tracheopteryx](https://github.com/tracheopteryx), [banteg](https://github.com/banteg), [lehnberg](https://github.com/lehnberg), [milkyklim](https://github.com/milkyklim) | [Passed](https://snapshot.org/#/s:ybaby.eth/proposal/QmddCbGYbkooZ1zp8oYnbBz6frXLRc9xbkapXcuZcdzmMF) | +| [61](/contributing/governance/yips/yip-61) | Governance 2.0 | [tracheopteryx](https://github.com/tracheopteryx), [lex_node](https://github.com/lex-node) | [Passed](https://snapshot.org/#/s:ybaby.eth/proposal/QmSMyYeKrRpnA7Xn56o2NtbCUzxmhzCupL7LxMA1reXxq4) | +| [60](/contributing/governance/yips/yip-60) | Airdrops to Yearn Vaults | [lehnberg](https://github.com/lehnberg) | [Passed](https://snapshot.org/#/s:ybaby.eth/proposal/QmNqAqRKMFcoRjaRYAKCVETij6sjJ4S1293kbpYDMVvcjB) | +| [59](/contributing/governance/yips/yip-59) | Temporarily extend Multisig empowerment | [lehnberg](https://github.com/lehnberg) | [Passed](https://snapshot.org/#/s:yearn/proposal/QmdRCXH6BQpNcucoZqAtS5hQKjckE2428qiZoWjxmJXbs3) | +| [57](/contributing/governance/yips/yip-57) | Funding Yearn's Future | aleks-blockchaincap, Artem K, dudesahn, ekrenzke, lehnberg, Klim K, Ryan Watkins, srs-parafi, tracheopteryx, vooncer, yfi-cent | [Passed](https://snapshot.org/#/s:yearn/proposal/QmX8oYTSkaXSARYZn7RuQzUufW9bVVQtwJ3zxurWrquS9a) | +| [56](/contributing/governance/yips/yip-56) | BABY: Buyback and Build | [lex_node](https://github.com/lex-node), [tracheopteryx](https://github.com/tracheopteryx), [Artem K](https://github.com/banteg), [Klim K](https://github.com/milkyklim), [Ryan Watkins](https://twitter.com/RyanWatkins_), [lehnberg](https://github.com/lehnberg) | [Passed](https://snapshot.org/#/s:yearn/proposal/Qmb6gBzjvgLMazSrQQGVcjutLNdkVyM2Lh6yckMzdoaHWZ) | +| [55](/contributing/governance/yips/yip-55) | Formalize the YIP Process | [franklin](https://github.com/franklin501) | [Passed](https://snapshot.org/#/s:yearn/proposal/QmZA8zJtLPqQAHi1jMdYX9MdMQ1ZmtRP8zuHccm6HFSzpF) | +| [54](/contributing/governance/yips/yip-54) | Formalize Operations Funding | [banteg](https://github.com/banteg), [lehnberg](https://github.com/lehnberg), [lex_node](https://github.com/lex-node), [milkyklim](https://github.com/milkyklim), [tracheopteryx](https://github.com/tracheopteryx) | [Passed](https://snapshot.org/#/s:yearn/proposal/QmW2ZPfGrcNxVLvT2jm9fmvNwQLD9PrdToQDU8DNPp6Ckg) | +| [53](/contributing/governance/yips/yip-53) | yAcademy: Planting the Seed of a Sustainably Secure Future for Yearn and Beyond | aliatiia | [Passed](https://snapshot.org/#/s:yearn/proposal/QmPTAfJCq3UtFZqY3jdgNEJsxc6yuHwfESnQyjjkoccZrJ) | +| [52](/contributing/governance/yips/yip-52) | Make Strategist Skin in Game Partner for Make Benefit of Glorious Brain of Yearn | [banteg](https://github.com/banteg), [lehnberg](https://github.com/lehnberg), [milkyklim](https://github.com/milkyklim) | [Passed](https://snapshot.org/#/s:yearn/proposal/QmbAq6jPB6ocrihjkDo5TLNF4D4w9dw1HsEsJ7vwdwd9g3) | +| [51](/contributing/governance/yips/yip-51) | Set Vault v2 Fee Structure | [banteg](https://github.com/banteg), [lehnberg](https://github.com/lehnberg), [milkyklim](https://github.com/milkyklim), [tracheopteryx](https://github.com/tracheopteryx) | [Passed](https://snapshot.org/#/s:yearn/proposal/QmSaYHR97LDMDvg9xeTfdNZw6aqL9njxBKM6JVFtCYxKvB) | +| [45](/contributing/governance/yips/yip-45) | Add a bounty for proposing YIPs that are implemented | [Sunil Srivatsa](https://github.com/alphastorm) | Passed | +| [44](/contributing/governance/yips/yip-44) | Improve YIP categories | [Sam Bacha](mailto:sam@freighttrust.com) | Passed | +| [43](/contributing/governance/yips/yip-43) | Improve YIP categories | [Sam Bacha](mailto:sam@freighttrust.com) | Rejected | +| [42](/contributing/governance/yips/yip-42) | Add RenBTC to yVaults | [Azeem](https://github.com/zu-ctrl) | Rejected | +| [41](/contributing/governance/yips/yip-41) | Temporarily Empower Multisig | [tracheopteryx](https://github.com/tracheopteryx), [Joe Mahon](https://github.com/Substreight), [franklin501](https://github.com/franklin501), Michael Anderson, Vance Spencer | Passed | +| [40](/contributing/governance/yips/yip-40) | Replace inactive multisig signers | [cp287](https://github.com/illlefr4u), [Artem K](https://github.com/banteg) | Passed | +| [39](/contributing/governance/yips/yip-39) | Add Curve sBTC Pool LP-Tokens yVault | [uhmpeps](https://github.com/az) | Passed | +| [38](/contributing/governance/yips/yip-38) | Distribute / Keep Balancer Rewards | [Klim K](https://github.com/milkyklim) | Passed | +| [37](/contributing/governance/yips/yip-37) | Participate in CRV governance and 2.5x CRV reward boost | [Andre Cronje](https://github.com/andrecronje), [Artem K](https://github.com/banteg) | Passed | +| [36](/contributing/governance/yips/yip-36) | System rewards as operational capital | [Andre Cronje](https://github.com/andrecronje), iTo, [n00b](https://github.com/jchi18), [Artem K](https://github.com/banteg) | Passed | +| [35](/contributing/governance/yips/yip-35) | Distribute Donations vs Purchase YFI | [Andre Cronje](https://github.com/andrecronje), [Klim K](https://github.com/milkyklim) | Passed | +| [34](/contributing/governance/yips/yip-34) | Add Synthetix (SNX) to yVaults | [Substreight](https://github.com/substreight) | Passed | +| [33](/contributing/governance/yips/yip-33) | Add LINK to yVaults | [franklin](https://github.com/franklin501) | Passed | +| [32](/contributing/governance/yips/yip-32) | Remove YFI burning | [Sunil Srivatsa](https://github.com/alphastorm) | Passed | +| [31](/contributing/governance/yips/yip-31) | YFI Inflation Distribution | [Substreight](https://github.com/substreight), [DeltaTiger](https://github.com/deltatigernz), [Hannes Graah](https://github.com/Graadient), [Daryl Lau](https://github.com/Daryllautk) | Rejected | +| [30](/contributing/governance/yips/yip-30) | YFI Inflation Schedule | [Substreight](https://github.com/substreight), [DeltaTiger](https://github.com/deltatigernz), [Hannes Graah](https://github.com/Graadient), [Daryl Lau](https://github.com/Daryllautk), yfi_whale | Rejected | +| [14](/contributing/governance/yips/yip-14) | Yearn Rewards Reserve | [YieldBouncer](https://github.com/yieldbouncer) | Rejected | +| [12](/contributing/governance/yips/yip-12) | Reducing the quorum for accepting proposal | [cp287](https://github.com/illlefr4u) | Passed | +| [10](/contributing/governance/yips/yip-10) | Transitionary YFI Only Voting | [Rewkang](https://github.com/rewkang) | Passed | +| [8](/contributing/governance/yips/yip-8) | Halving YFI weekly supply the same as bitcoin | steamer.eth | Rejected | +| [5](/contributing/governance/yips/yip-5) | Reducing YFI weekly supply | [Damir Bandalo](https://github.com/sikiriki12) | Rejected | +| [2](/contributing/governance/yips/yip-2) | Burn YFI for fees | [Andre Cronje](https://github.com/andrecronje) | Rejected | +| [1](/contributing/governance/yips/yip-1) | Minting more YFI | [Andre Cronje](https://github.com/andrecronje) | Passed | +| [0](/contributing/governance/yips/yip-0) | YIP Purpose and Guidelines | Yearn Community | Passed | --- -For current proposals, please visit [Snapshot](https://snapshot.org/#/ybaby.eth) +For current proposals, please visit [Snapshot](https://snapshot.org/#/s:styfi.eth) diff --git a/docs/contributing/governance/styfi.md b/docs/contributing/governance/styfi.md index 3f7b157ff7..e2225c552a 100644 --- a/docs/contributing/governance/styfi.md +++ b/docs/contributing/governance/styfi.md @@ -5,6 +5,8 @@ Yearn governance staking is centered on **stYFI** and **stYFIx**: - **stYFI**: stake YFI, earn rewards, and retain direct governance rights. - **stYFIx**: a more passive option that delegates voting power (recommended if you do not want to manage governance actions directly). +Read more about the *How* and *Why* of stYFI in [this blog post](https://blog.yearn.fi/upgrading-the-yield-machine) + ## Where to use it - **stYFI dashboard**: https://styfi.yearn.fi diff --git a/docs/contributing/governance/yfi.md b/docs/contributing/governance/yfi.md index a00921131a..d81ea4f424 100644 --- a/docs/contributing/governance/yfi.md +++ b/docs/contributing/governance/yfi.md @@ -46,6 +46,10 @@ YSPs allow token holders to formally request that a yTeam executes a decision wi YDPs are proposals that change where any discrete decision-making power is delegated. This is relevant in Governance 2.0 as it introduces yTeams, who are given an objective, and certain powers that can be modified by token holders. -## veYFI +### veYFI -With [veYFI](/contributing/governance/veyfi) launch, governance changed from using YFI to veYFI as voting power. \ No newline at end of file +With the passing of YIP-71 and the launch of veYFI, Yearn changed from using YFI as the voting token to using a locked derivative called veYFI. veYFI was modelled on Curve's veCRV token. You can find more information about veYFI [here](/contributing/governance/veyfi). The veYFI stystem has since been migrated to stYFI. + +### stYFI + +stYFI is the most recent interation of Yearn Governance. stYFI is a simplified token model that routes protocol revenue to aligned YFI stakers and secures governance without four-year locks. YFI is locked, with a 14 day cooldown, to gain voting power in the new governance system. Read more about stYFI [here](/contributing/governance/styfi) \ No newline at end of file diff --git a/docs/contributing/governance/yips/assets/.gitkeep b/docs/contributing/governance/yips/assets/.gitkeep new file mode 100644 index 0000000000..e69de29bb2 diff --git a/docs/contributing/governance/yips/assets/yip-41-budget.png b/docs/contributing/governance/yips/assets/yip-41-budget.png new file mode 100644 index 0000000000..4ccb3ae7ad Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-41-budget.png differ diff --git a/docs/contributing/governance/yips/assets/yip-51/figure1.png b/docs/contributing/governance/yips/assets/yip-51/figure1.png new file mode 100644 index 0000000000..031fdd5b8d Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-51/figure1.png differ diff --git a/docs/contributing/governance/yips/assets/yip-52/figure1.jpg b/docs/contributing/governance/yips/assets/yip-52/figure1.jpg new file mode 100644 index 0000000000..b64cf00805 Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-52/figure1.jpg differ diff --git a/docs/contributing/governance/yips/assets/yip-52/figure2.png b/docs/contributing/governance/yips/assets/yip-52/figure2.png new file mode 100644 index 0000000000..bed42bd4c2 Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-52/figure2.png differ diff --git a/docs/contributing/governance/yips/assets/yip-52/figure3.png b/docs/contributing/governance/yips/assets/yip-52/figure3.png new file mode 100644 index 0000000000..c49e099d3e Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-52/figure3.png differ diff --git a/docs/contributing/governance/yips/assets/yip-54/figure1.svg b/docs/contributing/governance/yips/assets/yip-54/figure1.svg new file mode 100644 index 0000000000..1bc405da5f --- /dev/null +++ b/docs/contributing/governance/yips/assets/yip-54/figure1.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/contributing/governance/yips/assets/yip-54/figure2.svg b/docs/contributing/governance/yips/assets/yip-54/figure2.svg new file mode 100644 index 0000000000..0c5a9c4576 --- /dev/null +++ b/docs/contributing/governance/yips/assets/yip-54/figure2.svg @@ -0,0 +1,15 @@ +Your Diagram TitleVault Fees → Perf. Fee: +$2,263,108Treasury → YIP-41 Budget: +$1,224,000Vault Fees → Mgmt. Fee: +$1,158,537Mgmt. Fee → Treasury: +$1,158,537Perf. Fee → Strategist: +$1,131,554Perf. Fee → Treasury: +$1,131,554Treasury → YFI Stakers: +$1,066,091Vault Fees: +$3,421,645Vault Fees: $3,421,645Perf. Fee: +$2,263,108Perf. Fee: $2,263,108Mgmt. Fee: +$1,158,537Mgmt. Fee: $1,158,537Strategist: +$1,131,554Strategist: $1,131,554Treasury: +$2,290,091Treasury: $2,290,091YFI Stakers: +$1,066,091YFI Stakers: $1,066,091YIP-41 Budget: +$1,224,000YIP-41 Budget: $1,224,000 \ No newline at end of file diff --git a/docs/contributing/governance/yips/assets/yip-54/figure3.svg b/docs/contributing/governance/yips/assets/yip-54/figure3.svg new file mode 100644 index 0000000000..81fc81a05f --- /dev/null +++ b/docs/contributing/governance/yips/assets/yip-54/figure3.svg @@ -0,0 +1,15 @@ +Your Diagram TitleVault Fees → Perf. Fee: +$2,263,108Vault Fees → Mgmt. Fee: +$1,158,537Mgmt. Fee → Treasury: +$1,158,537Treasury → YFI Stakers: +$1,145,046Treasury → Operations Fund: +$1,145,045Perf. Fee → Strategist: +$1,131,554Perf. Fee → Treasury: +$1,131,554Vault Fees: +$3,421,645Vault Fees: $3,421,645Perf. Fee: +$2,263,108Perf. Fee: $2,263,108Mgmt. Fee: +$1,158,537Mgmt. Fee: $1,158,537Strategist: +$1,131,554Strategist: $1,131,554Treasury: +$2,290,091Treasury: $2,290,091YFI Stakers: +$1,145,046YFI Stakers: $1,145,046Operations Fund: +$1,145,045Operations Fund: $1,145,045 \ No newline at end of file diff --git a/docs/contributing/governance/yips/assets/yip-55/figure1.png b/docs/contributing/governance/yips/assets/yip-55/figure1.png new file mode 100644 index 0000000000..d3feb2938b Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-55/figure1.png differ diff --git a/docs/contributing/governance/yips/assets/yip-56/figure1.png b/docs/contributing/governance/yips/assets/yip-56/figure1.png new file mode 100644 index 0000000000..c50d0e4d4a Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-56/figure1.png differ diff --git a/docs/contributing/governance/yips/assets/yip-57/figure1.png b/docs/contributing/governance/yips/assets/yip-57/figure1.png new file mode 100644 index 0000000000..665e8ef1fe Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-57/figure1.png differ diff --git a/docs/contributing/governance/yips/assets/yip-57/figure2.png b/docs/contributing/governance/yips/assets/yip-57/figure2.png new file mode 100644 index 0000000000..248b7c1b4a Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-57/figure2.png differ diff --git a/docs/contributing/governance/yips/assets/yip-57/figure3.png b/docs/contributing/governance/yips/assets/yip-57/figure3.png new file mode 100644 index 0000000000..4b69a8af0b Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-57/figure3.png differ diff --git a/docs/contributing/governance/yips/assets/yip-57/figure4.png b/docs/contributing/governance/yips/assets/yip-57/figure4.png new file mode 100644 index 0000000000..7038ad6889 Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-57/figure4.png differ diff --git a/docs/contributing/governance/yips/assets/yip-57/figure5.png b/docs/contributing/governance/yips/assets/yip-57/figure5.png new file mode 100644 index 0000000000..895a54e2d8 Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-57/figure5.png differ diff --git a/docs/contributing/governance/yips/assets/yip-61/figure1.png b/docs/contributing/governance/yips/assets/yip-61/figure1.png new file mode 100644 index 0000000000..d838770618 Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-61/figure1.png differ diff --git a/docs/contributing/governance/yips/assets/yip-62/figure1.png b/docs/contributing/governance/yips/assets/yip-62/figure1.png new file mode 100644 index 0000000000..bc0443e7c9 Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-62/figure1.png differ diff --git a/docs/contributing/governance/yips/assets/yip-63/figure1.jpeg b/docs/contributing/governance/yips/assets/yip-63/figure1.jpeg new file mode 100644 index 0000000000..7d2566dc17 Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-63/figure1.jpeg differ diff --git a/docs/contributing/governance/yips/assets/yip-65/01-xYFI.png b/docs/contributing/governance/yips/assets/yip-65/01-xYFI.png new file mode 100644 index 0000000000..ec0e270632 Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-65/01-xYFI.png differ diff --git a/docs/contributing/governance/yips/assets/yip-65/01-xYFI.svg b/docs/contributing/governance/yips/assets/yip-65/01-xYFI.svg new file mode 100644 index 0000000000..6d67fd154e --- /dev/null +++ b/docs/contributing/governance/yips/assets/yip-65/01-xYFI.svg @@ -0,0 +1,270 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Produced by OmniGraffle 7.19.2\n2021-12-17 11:44:03 +0000 + + Component 1: xYFI 1 + + + Layer 1 + + + + + + Actor + + + + + + + Yearn + + + + + + + External + + + + + + + + 🧮 + Treasury + + + + + + + 👤 + User + + + + Stack + + + + + + + + + + + + + + 🏦 + Vaults & other products + + + + Stack + + + + + + + + + + + + + + 🧩 + AMMs + (Cowswap, etc) + + + + + + + 👤 + YFI holder + + + + Stack + + + + + + + + + + + + + + 🏗 + Teams & Services + + + + + + + + + Deposit / Withdraw + funds + + + + + + + + + Pay fees + + + + + + + + + Pay + Operational Expenses + + + + + + + + + Build, service, and grow + + + + + + + + + Sell tokens + + + + + + + + + Buy YFI + + + + + + + + + Donate YFI + + + + + + + + + Stake YFI, + claim YFI rewards + + + + + Evolve YFI Tokenomics - Component 1: xYFI + v0.2 | @0x7171 + + + + + Legend: + + + + + + + 🔵 + xYFI + + + + + + + 🏛 + Governance + + + + + + + + + Set + voting power + + + + + + + + + Vote on proposals + + + + + diff --git a/docs/contributing/governance/yips/assets/yip-65/02-veYFI.png b/docs/contributing/governance/yips/assets/yip-65/02-veYFI.png new file mode 100644 index 0000000000..f879649a1a Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-65/02-veYFI.png differ diff --git a/docs/contributing/governance/yips/assets/yip-65/02-veYFI.svg b/docs/contributing/governance/yips/assets/yip-65/02-veYFI.svg new file mode 100644 index 0000000000..206c826137 --- /dev/null +++ b/docs/contributing/governance/yips/assets/yip-65/02-veYFI.svg @@ -0,0 +1,367 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Produced by OmniGraffle 7.19.2\n2021-12-17 11:44:03 +0000 + + Component 2: veYFI 1 + + + Layer 1 + + + + + + Actor + + + + + + + Yearn + + + + + + + External + + + + + + + + 🧮 + Treasury + + + + + + + 👤 + User + + + + Stack + + + + + + + + + + + + + + 🏦 + Vaults & other products + + + + Stack + + + + + + + + + + + + + + 🧩 + AMMs + (Cowswap, etc) + + + + + + + 👤 + YFI holder + + + + Stack + + + + + + + + + + + + + + 🏗 + Teams & Services + + + + + + + + + Deposit / Withdraw + funds + + + + + + + + + Pay fees + + + + + + + + + Pay + Operational Expenses + + + + + + + + + Build, service, and grow + + + + + + + + + Sell tokens + + + + + + + + + Buy YFI + + + + + + + + + Donate YFI + + + + + + + + + Time-lock YFI, + receive veYFI + + + + + Evolve YFI Tokenomics - Component 2: Vote-locked YFI + v0.4 | @0x7171 + + + + + Legend: + + + + + + + ⏳ + veYFI + Timelock + + + + + + + + + Extend + time-lock + + + + + + + 🔵 + veYFI + Rewards + + + + + + + + + Earn weekly + rewards + (unlocked YFI) + + + + + + + 🏛 + Governance + + + + + + + + + + + + + Instructs + + + + + + + + + + + + Rewards + share + + + + + + Voting + power + + + + + + + + + Vote on proposals + + + + + + + + + Decays + + + + + + + + + Pay penalty + (unlocked YFI) + + + + + + + + + + + + + Early + Exit + + + + + + + + + Receive + remaining YFI + + + + + diff --git a/docs/contributing/governance/yips/assets/yip-65/03-gauges.png b/docs/contributing/governance/yips/assets/yip-65/03-gauges.png new file mode 100644 index 0000000000..3cde1b02c8 Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip-65/03-gauges.png differ diff --git a/docs/contributing/governance/yips/assets/yip-65/03-gauges.svg b/docs/contributing/governance/yips/assets/yip-65/03-gauges.svg new file mode 100644 index 0000000000..9ce76e03f5 --- /dev/null +++ b/docs/contributing/governance/yips/assets/yip-65/03-gauges.svg @@ -0,0 +1,466 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Produced by OmniGraffle 7.19.2\n2021-12-17 11:44:03 +0000 + + Component 3: gauges 1 + + + Layer 1 + + + + + + Actor + + + + + + + Yearn + + + + + + + External + + + + + + + + 🧮 + Treasury + + + + + + + 👤 + User + + + + Stack + + + + + + + + + + + + + + 🏦 + Vaults & other products + + + + Stack + + + + + + + + + + + + + + 🧩 + AMMs + (Cowswap, etc) + + + + + + + 👤 + YFI holder + + + + Stack + + + + + + + + + + + + + + 🏗 + Teams & Services + + + + + + + + + Deposit / Withdraw + funds + + + + + + + + + Pay fees + + + + + + + + + Pay + Operational Expenses + + + + + + + + + Build, service, and grow + + + + + + + + + Sell tokens + + + + + + + + + Buy YFI + + + + + + + + + Donate YFI + + + + + + + + + Time-lock YFI, + receive veYFI + + + + + Evolve YFI Tokenomics - Component 3: Vault Gauges + v0.1 | @0x7171 + + + + + Legend: + + + + + + + ⏳ + veYFI + Timelock + + + + + + + + + Extend + time-lock + + + + + + + 🔵 + veYFI + Rewards + + + + + + + 🏛 + Governance + + + + + + + + + + + + + Instructs + + + + + + + + + + + + Rewards + share + + + + + + Voting + power + + + + + + + + + Vote on proposals + + + + + + + + + Decays + + + + + + + + + Pay penalty + (unlocked YFI) + + + + + + + + + + + + + Early + Exit + + + + + + + + + Receive + remaining YFI + + + + Stack + + + + + + + + + + + + + + 🐚 + Vault Gauges + + + + + + + + + Stake Vault token + + + + + + + + + + + + + Set YFI + allocation + + + + + + + + + Allocate YFI + + + + + + + + + Rewards/Penalty + ratio + + + + + + + + + + + + + Pay YFI + rewards + + + + + + + + + Earn YFI rewards + (unlocked YFI) + + + + + + + + + Earn YFI rewards + (unlocked YFI) + + + + + + + + + Pay penalty + (unlocked YFI) + + + + + diff --git a/docs/contributing/governance/yips/assets/yip5.png b/docs/contributing/governance/yips/assets/yip5.png new file mode 100644 index 0000000000..3b26ff0d15 Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip5.png differ diff --git a/docs/contributing/governance/yips/assets/yip8.png b/docs/contributing/governance/yips/assets/yip8.png new file mode 100644 index 0000000000..a78151d3ed Binary files /dev/null and b/docs/contributing/governance/yips/assets/yip8.png differ diff --git a/docs/contributing/governance/yips/yip-0.md b/docs/contributing/governance/yips/yip-0.md new file mode 100644 index 0000000000..164929f055 --- /dev/null +++ b/docs/contributing/governance/yips/yip-0.md @@ -0,0 +1,178 @@ +--- +title: "YIP-0: YIP Purpose and Guidelines" +hide_title: true +sidebar_position: -0 +--- + +# YIP-0: YIP Purpose and Guidelines + +| Metadata | Details | +| --- | --- | +| YIP | 0 | +| Outcome | **Passed** | +| Authors | Yearn Community | +| Created | 2020-07-22 | +| Forum discussion | [View discussion](https://gov.yearn.fi/) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-0.md) | + +## What is an YIP? + +YIP stands for Yearn Improvement Proposal, it has been adapted from the SIP (Synthetix Improvement Proposal). The purpose of this process is to ensure changes to Yearn are transparent and well governed. An YIP is a design document providing information to the Yearn community about a proposed change to the system. The author is responsible for building consensus within the community and documenting dissenting opinions. + +## YIP Rationale + +We intend YIPs to be the primary mechanisms for proposing new features, collecting community input on an issue, and for documenting the design decisions for changes to Yearn. Because they are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. + +It is highly recommended that a single YIP contain a single key proposal or new idea. The more focused the YIP, the more successful it is likely to be. + +An YIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. + +## YIP Work Flow + +Parties involved in the process are the _author_, the [_YIP editors_](#yip-editors), and the Yearn community. + +:warning: Before you begin, vet your idea, this will save you time. Ask the Yearn community first if an idea is original to avoid wasting time on something that will be rejected based on prior research (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will have the intend effect. The appropriate public forum to gauge interest around your YIP is [the unofficial Yearn Discord] or [the unofficial Yearn Telegram]. + +Your role as the champion is to write the YIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea. Following is the process that a successful YIP will move along: + +``` +Proposed -> Approved -> Implemented + ^ | + +----> Rejected +----> Moribund + | + +----> Withdrawn + v +Deferred +``` + +Each status change is requested by the YIP author and reviewed by the YIP editors. Use a pull request to update the status. Please include a link to where people should continue discussing your YIP. The YIP editors will process these requests as per the conditions below. + +- **Work in progress (WIP)** -- Once the champion has asked the Yearn community whether an idea has any chance of support, they will write a draft YIP as a [pull request]. Consider including an implementation if this will aid people in studying the YIP. +- **Proposed** If agreeable, YIP editor will assign the YIP a number (generally the issue or PR number related to the YIP) and merge your pull request. The YIP editor will not unreasonably deny an YIP. Proposed YIPs will be discussed on governance calls and in Discord. If there is a reasonable level of consensus around the change on the governance call the change will be moved to approved. If the change is contentious a vote of token holders may be held to resolve the issue or approval may be delayed until consensus is reached. +- **Approved** -- This YIP has passed community governance and is now being prioritised for development. +- **Implemented** -- This YIP has been implemented and deployed to mainnet. +- **Rejected** -- This YIP has failed to reach community consensus. +- **Withdrawn** -- This YIP has has been withdrawn by the author(s). +- **Deferred** -- This YIP is pending another YIP/some other change that should be bundled with it together. +- **Moribund** -- This YIP has been implemented and is now obsolete and requires no explicit replacement. + +## What belongs in a successful YIP? + +Each YIP should have the following parts: + +- Preamble - RFC 822 style headers containing metadata about the YIP, including the YIP number, a short descriptive title (limited to a maximum of 44 characters), and the author details. +- Simple Summary - “If you can’t explain it simply, you don’t understand it well enough.” Provide a simplified and layman-accessible explanation of the YIP. +- Abstract - a short (~200 word) description of the technical issue being addressed. +- Motivation (\*optional) - The motivation is critical for YIPs that want to change Yearn. It should clearly explain why the existing specification is inadequate to address the problem that the YIP solves. YIP submissions without sufficient motivation may be rejected outright. +- Specification - The technical specification should describe the syntax and semantics of any new feature. +- Rationale - The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion. +- Test Cases - Test cases may be added during the implementation phase but are required before implementation. +- Copyright Waiver - All YIPs must be in the public domain. See the bottom of this YIP for an example copyright waiver. + +## YIP Formats and Templates + +YIPs should be written in [markdown] format. +Image files should be included in a subdirectory of the `assets` folder for that YIP as follows: `assets/yip-X` (for yip **X**). When linking to an image in the YIP, use relative links such as `../assets/yip-X/image.png`. + +## YIP Header Preamble + +Each YIP must begin with an [RFC 822](https://www.ietf.org/rfc/rfc822.txt) style header preamble, preceded and followed by three hyphens (`---`). This header is also termed ["front matter" by Jekyll](https://jekyllrb.com/docs/front-matter/). The headers must appear in the following order. Headers marked with "\*" are optional and are described below. All other headers are required. + +`yip:` `` (this is determined by the YIP editor) + +`title:` `` + +`author:` `` + +`* discussions-to:` `` + +`status:` `< WIP | PROPOSED | APPROVED | IMPLEMENTED >` + +`created:` `` + +`* updated:` `` + +`* requires:` `` + +`* resolution:` `` + +Headers that permit lists must separate elements with commas. + +Headers requiring dates will always do so in the format of ISO 8601 (yyyy-mm-dd). + +#### `author` header + +The `author` header lists the usernames of the authors/owners of the YIP. The format of the author header value must be: + +> username + +Use commas to separate multiple authors. + +#### `discussions-to` header + +While an YIP is in WIP or Proposed status, a `discussions-to` header will indicate the URL at [gov.yearn.finance](https://gov.yearn.fi/) where the YIP is being discussed. + +#### `created` header + +The `created` header records the date that the YIP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14. + +#### `updated` header + +The `updated` header records the date(s) when the YIP was updated with "substantial" changes. This header is only valid for YIPs of Draft and Active status. + +#### `requires` header + +YIPs may have a `requires` header, indicating the YIP numbers that this YIP depends on. + +## Auxiliary Files + +YIPs may include auxiliary files such as diagrams. Such files must be named YIP-XXXX-Y.ext, where “XXXX” is the YIP number, “Y” is a serial number (starting at 1), and “ext” is replaced by the actual file extension (e.g. “png”). + +## YIP Editors + +The current YIP editors are: + +`* banteg` + +`* Cooopahtroopa` + +`* Daryllautk` + +`* milkyklim` + +`* alphastorm` + +## YIP Editor Responsibilities + +For each new YIP that comes in, an editor does the following: + +- Read the YIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status. +- The title should accurately describe the content. +- Check the YIP for language (spelling, grammar, sentence structure, etc.), markup (Github flavored Markdown), code style + +If the YIP isn't ready, the editor will send it back to the author for revision, with specific instructions. + +Once the YIP is ready for the repository, the YIP editor will: + +- Assign an YIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this YIP) + +- Merge the corresponding pull request + +- Send a message back to the YIP author with the next step. + +The YIP editors monitor YIP changes, and correct any structure, grammar, spelling, or markup mistakes we see. + +The editors don't pass judgment on YIPs. We merely do the administrative & editorial part. + +## History + +The YIP document was derived heavily from the SIP Synthetix Improvement Proposal document in many places text was simply copied and modified. Any comments about the YIP document should be directed to the YIP editors. + +### Bibliography + +[the unofficial yearn discord]: https://discord.com/invite/3AGgWxy +[the unofficial yearn telegram]: https://t.me/yearnfinance +[pull request]: https://github.com/yearn/YIPS/pulls +[markdown]: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet diff --git a/docs/contributing/governance/yips/yip-1.md b/docs/contributing/governance/yips/yip-1.md new file mode 100644 index 0000000000..d083b0a007 --- /dev/null +++ b/docs/contributing/governance/yips/yip-1.md @@ -0,0 +1,39 @@ +--- +title: "YIP-1: Minting more YFI" +hide_title: true +sidebar_position: -1 +--- + +# YIP-1: Minting more YFI + +| Metadata | Details | +| --- | --- | +| YIP | 1 | +| Outcome | **Passed** | +| Authors | andrecronje | +| Created | 2020-07-19 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/proposal-0-yfi-supply/24) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-1.md) | + +## 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/) diff --git a/docs/contributing/governance/yips/yip-10.md b/docs/contributing/governance/yips/yip-10.md new file mode 100644 index 0000000000..5c49e26b60 --- /dev/null +++ b/docs/contributing/governance/yips/yip-10.md @@ -0,0 +1,59 @@ +--- +title: "YIP-10: Transitionary YFI Only Voting" +hide_title: true +sidebar_position: -10 +--- + +# YIP-10: Transitionary YFI Only Voting + +| Metadata | Details | +| --- | --- | +| YIP | 10 | +| Outcome | **Passed** | +| Authors | rewkang | +| Created | 2020-07-24 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-10-transitionary-yfi-only-voting/481) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-10.md) | + +## Simple Summary + + + +The current Yearn governance mechanism puts the protocol at risk of a hostile takeover. The best immediate course of action would be to temporarily transition the protocol to a new voting contract recently deployed by Andre. + +## Abstract + + + +Update the ygov.finance voting page to link to the new voting contract where only YFI can be staked. + +Contract: [Etherscan](https://etherscan.io/address/0xad7e09665caa3404d9c6525d5997a10fc6c12cfe) + +## Motivation + + + +The current Yearn voting contract accepts BPT (Balancer Pool Tokens) from a pool consisting of 98% yCRV / 2% YFI. This creates a dynamic where large stablecoin holders hold a disproportionate amount of voting shares and thereby governance power, while those whom have a high proportion of YFI vs. stablecoin are underrepresented in governance. Governance should be dictated by those with the most vested long term interest of the protocol - YFI holders - irrespective of their portfolio composition. More importantly, the protocol is currently vulnerable to a hostile takeover of governance by stablecoin whales who could potentially pass a proposal to mint a large supply of YFI and disproportionately reward themselves (via favoring large stablecoin holders). + +There are multiple different long term governance/voting approaches being debated, and it will take time to align on community consensus. While these are being analyzed/discussed, we should immediately transition to a temporary governance structure where only YFI can be used to vote in order to mitigate hostile takeover attacks. + +The community can replace this temporary YFI only voting structure after passing a new YIP. + +**FOR**: Governance moves to newly deployed YFI only voting contract. + +**AGAINST**: No governance changes. + +## Metadata + +| Name | Value | +| ------------------- | ------------------------------------------ | +| Proposed by | 0x09173487b272311Edda01F45f97911aEB6aBd602 | +| Total for votes | 13641124.8956 (77.08%) | +| Total against votes | 4054142.5578 (22.91%) | +| Quorum | 45.92% ✔ | +| Start block | 10518707 | +| End block | 10535987 | + +Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/) diff --git a/docs/contributing/governance/yips/yip-12.md b/docs/contributing/governance/yips/yip-12.md new file mode 100644 index 0000000000..1caa6d759e --- /dev/null +++ b/docs/contributing/governance/yips/yip-12.md @@ -0,0 +1,70 @@ +--- +title: "YIP-12: Reducing the quorum for accepting proposal" +hide_title: true +sidebar_position: -12 +--- + +# YIP-12: Reducing the quorum for accepting proposal + +| Metadata | Details | +| --- | --- | +| YIP | 12 | +| Outcome | **Passed** | +| Authors | illlefr4u | +| Created | 2020-07-24 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-12-reducing-the-quorum-for-accepting-proposal/578) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-12.md) | + +## Simple Summary + + + +At the moment, it is difficult for the Yearn governance mechanism to achieve a quorum of 33%. For the control system to function, the threshold must be lowered so that at least some decisions can be made. + +## Abstract + + + +It is proposed to reduce the quorum threshold for accepting the proposal to 20%. +At the moment, no changes to the on-chain are necessary, since the quorum check is currently being carried out off-chain. Thus, it is enough to simply make a decision by onchain voting. + +## Motivation + + + +At the moment, it is difficult for the Yearn governance mechanism to achieve a quorum of 33%. We could observe this even with the important proposal 1, which could not reach the quorum. +This is due to both: + +- general passivity and lack of motivation to participate in governance system; +- negative motivation to participate (lock of funds). + +Thus, Yearn protocol is under the threat of forever remaining as it is, since all proposals may not reach the required quorum (with a high probability, the activity in voting will only decrease over time). + +There are many different solutions, which I will describe below, and I propose to start discussing them in the topic, but it is critical now to make a simple decision that will allow the protocol to evolve, and the community to make decisions on the development of the protocol. +In my opinion, such a decision may be to reduce the quorum threshold to 20%, which I put up for voting. + +Other ways to solve the quorum problem: + +- you get rewards for staking only if you vote; +- delegation of votes (implementation will take some time); +- quorum should be not for ALL tokens, but for only those “escrowed” to be voting; +- should have a quorum schedule which after x amount of time with no proposal meeting quorum the threshold goes down 1%-2% for year1, 0.5%-1% for year 2, etc. + +**FOR**: The threshold for accepting the proposal drops to 20%. + +**AGAINST**: No change for threshold. + +## Metadata + +| Name | Value | +| ------------------- | ------------------------------------------ | +| Proposed by | 0x74630370197b4c4795bFEeF6645ee14F8cf8997D | +| Total for votes | 5291919.8701 (66.22%) | +| Total against votes | 2699427.0543 (33.77%) | +| Quorum | 39.76% ✔ | +| Start block | 10522307 | +| End block | 10539587 | + +Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/) diff --git a/docs/contributing/governance/yips/yip-14.md b/docs/contributing/governance/yips/yip-14.md new file mode 100644 index 0000000000..2fe0459d99 --- /dev/null +++ b/docs/contributing/governance/yips/yip-14.md @@ -0,0 +1,54 @@ +--- +title: "YIP-14: Yearn Rewards Reserve" +hide_title: true +sidebar_position: -14 +--- + +# YIP-14: Yearn Rewards Reserve + +| Metadata | Details | +| --- | --- | +| YIP | 14 | +| Outcome | **Rejected** | +| Authors | yieldbouncer | +| Created | 2020-07-24 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-14-yearn-rewards-reserve/136) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-14.md) | + +## Simple Summary + +Without a cash reserve, it is difficult to sustain and improve the protocol further. As a community, we need to start capturing and reserving a percentage of the value being generated by Yearn in order to support further development, improve security, sponsor research, e.t.c. + +To get started, I propose we capture 5% of all yields earned through Yearn to be used as a reserve for the protocol. + +## Abstract + +@andre.cronje has done an amazing job so far at developing the protocol. As a community, we should support his efforts. To achieve that, I propose that we should start reserving 5% of all yields earned for protocol use. How we plan to use it and what would be the sensible threshold for the reserve percentage can be determined in a different proposal + +## Motivation + +One of the best things about the Yearn ecosystem is that there isn’t any pre-mined tokens. No money was taken from VC nor did @andre.cronje attempted to IXO (e.g. IDO, ICO) YFI tokens. This is as good as we can get when it comes to decentralization for a working and profitable defi project! Unfortunately, there are also downsides for not having some cash reserved: + +- Unable to cover expensive audits for contracts +- Incentive to continue building awesome products +- Fund/grants to sponsor researches in order to improve the products +- General marketing and user support + +**FOR**: Reserve 5% of all yields earned through Yearn for protocol use. + +**AGAINST**: No changes. All rewards will continue to distribute evenly among YFI stakers. + +## Metadata + +| Name | Value | +| ------------------- | ------------------------------------------ | +| Proposed by | 0x09173487b272311Edda01F45f97911aEB6aBd602 | +| Total for votes | 332839.5446 (99.69%) | +| Total against votes | 1005.9567 (0.30%) | +| Quorum | 3.06% 𐄂 | +| Start block | 10525527 | +| End block | 10542807 | + +Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/) diff --git a/docs/contributing/governance/yips/yip-2.md b/docs/contributing/governance/yips/yip-2.md new file mode 100644 index 0000000000..1f48503cc7 --- /dev/null +++ b/docs/contributing/governance/yips/yip-2.md @@ -0,0 +1,39 @@ +--- +title: "YIP-2: Burn YFI for fees" +hide_title: true +sidebar_position: -2 +--- + +# YIP-2: Burn YFI for fees + +| Metadata | Details | +| --- | --- | +| YIP | 2 | +| Outcome | **Rejected** | +| Authors | andrecronje | +| Created | 2020-07-19 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/proposal-1-yfi-fee-collection/25) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-2.md) | + +## Simple Summary + +**FOR**: Will continue to with the current burn model. + +**AGAINST**: Rewards will be claimed via a staking model instead. + +_NOTE: This was proposal 1 on-chain._ + +## Metadata + +| Name | Value | +| ------------------- | ------------------------------------------ | +| Proposed by | 0x473afAb58B2C5D4DbC5FAD5D236f6658AD84E83b | +| Total for votes | 502445.8576 (11.27%) | +| Total against votes | 3953417.1244 (88.72%) | +| Quorum | 22.03% 𐄂 | +| Start block | 10490942 | +| End block | 10508222 | + +Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/) diff --git a/docs/contributing/governance/yips/yip-30.md b/docs/contributing/governance/yips/yip-30.md new file mode 100644 index 0000000000..2d58c5c790 --- /dev/null +++ b/docs/contributing/governance/yips/yip-30.md @@ -0,0 +1,68 @@ +--- +title: "YIP-30: YFI Inflation Schedule" +hide_title: true +sidebar_position: -30 +--- + +# YIP-30: YFI Inflation Schedule + +| Metadata | Details | +| --- | --- | +| YIP | 30 | +| Outcome | **Rejected** | +| Authors | substreight, deltatigernz, Graadient, Daryllautk, yfi_whale | +| Created | 2020-07-28 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-30-yfi-inflation-schedule/1439) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-30.md) | + +## Simple Summary + +Implement an inflation schedule of 20,000 YFI over the next 8 years, with 12,802 distributed in the first 3 years, ending with a trailing tail of 1% inflation. + +## Abstract + +- Update the YFI mint contract to reflect new inflation schedule. + +## Motivation + +To create an inflation schedule after the passing of YIP-0. + +**FOR**: Implement an inflation schedule of 20,000 YFI over the next 8 years, with 12,802 distributed in the first 3 years, ending with a trailing tail of 1% inflation. + +**AGAINST**: No changes. + +## Specification + +### Overview + +1. Adjust supply schedule to follow [[YFI Inflation Schedule](https://docs.google.com/spreadsheets/d/1yomUGpAWR8svL9RXD-_vL2ArgQPGj1x2XPNKDEuZR9Q/edit?usp=sharing)]. + +- Beginning annual inflation: 22.384% +- Weekly emissions reduction multiplier: 0.9937 +- Week that terminal inflation starts: 416 weeks +- Fixed % ongoing inflation (tail emission): 1% + +2. This model will stay in place until it is stopped or adjusted. + +### Rationale + +- Liquidity provider yields are maintained at reasonably competitive levels in various YFI price and TVL scenarios (see modeling sheet). +- Lower initial inflation (22%) to keep long-term rewards reasonable. +- 8 year emission schedule to support long-term development. + +Reference: [synthetix/contracts/SupplySchedule.sol](https://github.com/Synthetixio/synthetix/blob/master/contracts/SupplySchedule.sol) + +## Metadata + +| Name | Value | +| ------------------- | ------------------------------------------ | +| Proposed by | 0x2D407dDb06311396fE14D4b49da5F0471447d45C | +| Total for votes | 3380.7051 (38.73%) | +| Total against votes | 5346.6313 (61.26%) | +| Quorum | 82.39% ✔ | +| Start block | 10560113 | +| End block | 10577393 | + +Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/) diff --git a/docs/contributing/governance/yips/yip-31.md b/docs/contributing/governance/yips/yip-31.md new file mode 100644 index 0000000000..c2d056b55d --- /dev/null +++ b/docs/contributing/governance/yips/yip-31.md @@ -0,0 +1,64 @@ +--- +title: "YIP-31: YFI Inflation Distribution" +hide_title: true +sidebar_position: -31 +--- + +# YIP-31: YFI Inflation Distribution + +| Metadata | Details | +| --- | --- | +| YIP | 31 | +| Outcome | **Rejected** | +| Authors | substreight, deltatigernz, Graadient, Daryllautk | +| Created | 2020-07-30 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-31-yfi-inflation-distribution/1445) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-31.md) | + +## Simple Summary + +Divide any further YFI inflation, allocating 50% to Liquidity Pools and 50% to the Multisig. + +## Abstract + +- There are currently no funds being allocated to developing and improving the yearn ecosystem. +- Further inflation of YFI provides an opportunity to fulfill funding needs. + +## Motivation + +Using YFI from inflation to fund development is a sustainable mechanism to strengthen the yearn ecosystem and align contributors. + +**FOR**: Allocate 50% of YFI inflation to Liquidity Pool incentives and 50% to the Multisig. + +**AGAINST**: No changes to YFI inflation distribution. + +## Specification + +### Overview + +- Designate 50% of future YFI emissions to LP rewards contract. +- Designate 50% of future YFI emissions to Multisig (or DAO if applicable). +- This will stay in place until stopped or adjusted. + +### Rationale + +Some YFI should be reserved to secure and improve the yearn ecosystem while properly incentivizing liquidity pools. Starting with a 50% // 50% split to LPs and Multisig, respectively, allows proper funding for both stakeholders, while retaining flexibility to adjust the distribution if necessary. + +Reference + +- Inflation schedule proposal [YIP-30](https://github.com/yearn/YIPS/blob/master/YIPS/yip-30.md) + +## Metadata + +| Name | Value | +| ------------------- | ------------------------------------------ | +| Proposed by | 0x24394A4758DBdCf6fcbC14dc35af64Ac0D9a450A | +| Total for votes | 3304.5260 (42.28%) | +| Total against votes | 4509.5851 (57.71%) | +| Quorum | 73.42% ✔ | +| Start block | 10560736 | +| End block | 10578016 | + +Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/) diff --git a/docs/contributing/governance/yips/yip-32.md b/docs/contributing/governance/yips/yip-32.md new file mode 100644 index 0000000000..840e848c09 --- /dev/null +++ b/docs/contributing/governance/yips/yip-32.md @@ -0,0 +1,49 @@ +--- +title: "YIP-32: Remove YFI burning" +hide_title: true +sidebar_position: -32 +--- + +# YIP-32: Remove YFI burning + +| Metadata | Details | +| --- | --- | +| YIP | 32 | +| Outcome | **Passed** | +| Authors | alphastorm | +| Created | 2020-08-01 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-32-remove-yfi-burning/1907) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-32.md) | + +## 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/) diff --git a/docs/contributing/governance/yips/yip-33.md b/docs/contributing/governance/yips/yip-33.md new file mode 100644 index 0000000000..e1db7dd3db --- /dev/null +++ b/docs/contributing/governance/yips/yip-33.md @@ -0,0 +1,57 @@ +--- +title: "YIP-33: Add LINK to yVaults" +hide_title: true +sidebar_position: -33 +--- + +# YIP-33: Add LINK to yVaults + +| Metadata | Details | +| --- | --- | +| YIP | 33 | +| Outcome | **Passed** | +| Authors | franklin501 | +| Created | 2020-08-02 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/add-link-as-the-first-asset-for-the-upcoming-delegated-yvaults-release/847) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-33.md) | + +## Simple Summary + +Add Chainlink (LINK) as the first volatile asset to be used as collateral in delegated yVaults. + +## Abstract + +Add Chainlink (LINK) as the first volatile asset to be used as collateral in delegated yVaults. + +## Motivation + +Delegated yVaults have initially launched with only USDC as collateral. Additional assets are necessary in order to generate more revenue for the protocol and grow the ecosystem. This proposal nominates LINK as the first volatile asset to be used as collateral. LINK was the top choice in a preliminary [poll](https://gov.yearn.fi/t/add-link-as-the-first-asset-for-the-upcoming-delegated-yvaults-release/847/7) and is a good first candidate for trials before other volatile assets are added. + +**FOR**: Add LINK as the first volatile asset to be used in delegated yVaults. + +**AGAINST**: Don't add LINK. + +### Overview + +Adding LINK as a collateral option to delegated yVaults will enable LINK holders to deposit tokens to the vault, which will increase the total value locked (TVL) and generate more fees for the protocol. + +### Rationale + +Chainlink is among the highest valued and most liquid ERC-20 tokens. There is a significant number of tokens and thus liquidity idle, which could be deposited for delegated yVaults. LINK’s high market capitalization makes it well suited to be the first delegated yVault volatile asset as it will likely contribute to the most fees that will be accrued the protocol. + +Chainlink also has one of the strongest communities in crypto and successful initial trials of delegated yVaults will likely encourage larger token holders to join the ecosystem adding even more fees. Large deposits of LINK as collateral will significantly increase total value locked (TVL) in yVaults, compared to other token communities that are not as immersed in DeFi. + +## Metadata + +| Name | Value | +| ------------------- | ------------------------------------------ | +| Proposed by | 0x071243c8f33A3e7c15499a8E51fF852DbaF05854 | +| Total for votes | 3069.4359 (99.46%) | +| Total against votes | 16.3954 (0.53%) | +| Quorum | 31.68% ✔ | +| Start block | 10582615 | +| End block | 10599895 | + +Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/) diff --git a/docs/contributing/governance/yips/yip-34.md b/docs/contributing/governance/yips/yip-34.md new file mode 100644 index 0000000000..a07873aa93 --- /dev/null +++ b/docs/contributing/governance/yips/yip-34.md @@ -0,0 +1,55 @@ +--- +title: "YIP-34: Add Synthetix (SNX) to yVaults" +hide_title: true +sidebar_position: -34 +--- + +# YIP-34: Add Synthetix (SNX) to yVaults + +| Metadata | Details | +| --- | --- | +| YIP | 34 | +| Outcome | **Passed** | +| Authors | substreight | +| Created | 2020-08-06 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-34-add-synthetix-snx-to-yvaults/2149) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-34.md) | + +## 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/) diff --git a/docs/contributing/governance/yips/yip-35.md b/docs/contributing/governance/yips/yip-35.md new file mode 100644 index 0000000000..07468739a5 --- /dev/null +++ b/docs/contributing/governance/yips/yip-35.md @@ -0,0 +1,53 @@ +--- +title: "YIP-35: Distribute Donations vs Purchase YFI" +hide_title: true +sidebar_position: -35 +--- + +# YIP-35: Distribute Donations vs Purchase YFI + +| Metadata | Details | +| --- | --- | +| YIP | 35 | +| Outcome | **Passed** | +| Authors | andrecronje, milkyklim | +| Created | 2020-08-10 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/distribution-donations-vs-purchasing-yfi/2244) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-35.md) | + +## Simple Summary + +Allow donors who donated to claim back donations or leave them to be used to purchase YFI. + +## Abstract + +While I am very appreciative of the donations, the [article](https://decrypt.co/37995/exclusive-yfi-andre-cronje-broke-quitting-defi) was a gross misrepresentation of our discussion. I am not in financial detriment, I do have debt, but I have assets in crypto to offset my fiat debt. I am simply not interested to swap my crypto to fiat, since I value my crypto more than fiat. + +As such, I propose a small system, whereby donors can claim back their donations, should they wish. If however they do not claim it back by x date, then the funds (currently \$150,000) will be used to market buy YFI. I wish to use this YFI as a governance vote and we can also use it to incentivize other events or requirements. + +## Motivation + +Having spoken to donors, its a mix of “use it for the protocol” vs “it is an insult to return it”, so I wanted to come up with a new solution that benefits all participants. + +**FOR**: Build the claim back and purchase system. + +**AGAINST**: Return the donations. + +## Specification + +I will implement a simplistic contract that allows donors to reclaim, should they not wish to do so, after maturity date, YFI will be purchased and staked in governance. + +## Metadata + +| Name | Value | +| ------------------- | ------------------------------------------ | +| Proposed by | 0x74630370197b4c4795bFEeF6645ee14F8cf8997D | +| Total for votes | 1644.3648 (93.59%) | +| Total against votes | 112.4983 (6.40%) | +| Quorum | 37.43% ✔ | +| Start block | 10633099 | +| End block | 10650379 | + +Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/) diff --git a/docs/contributing/governance/yips/yip-36.md b/docs/contributing/governance/yips/yip-36.md new file mode 100644 index 0000000000..4a49067d52 --- /dev/null +++ b/docs/contributing/governance/yips/yip-36.md @@ -0,0 +1,57 @@ +--- +title: "YIP-36: System rewards as operational capital" +hide_title: true +sidebar_position: -36 +--- + +# YIP-36: System rewards as operational capital + +| Metadata | Details | +| --- | --- | +| YIP | 36 | +| Outcome | **Passed** | +| Authors | andrecronje, iTo, jchi18, banteg | +| Created | 2020-08-10 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/system-rewards-as-operational-capital/1974) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-36.md) | + +## Simple Summary + +Assign system rewards as operational capital for expenditures instead of streaming them to governance. + +## Abstract + +Cover operational expenses with no immediate issuance of YFI required. + +## Motivation + +The YFI community is currently working with Delphi and Gauntlet to develop an economic model and inflation schedule. Until this process is complete, the project lacks the funds for any operational expenses including, but not exclusive to, security audits, deployment costs, consulting expenses, and compensations. + +But with the state of the market, the system rewards are adequately sufficient to cover operational expenses. The YIP proposes that the system rewards are directed to the multisig instead of streamed to governance stakers. This allows the multisig to cover operational expenses without minting additional YFI. + +**FOR:** Use system rewards for operational expenses with \$500k treasury cap and surplus distributed to governance stakers. + +**AGAINST:** Keep streaming rewards to governance stakers. + +## Specification + +100% of rewards collected by the system are directed to multisig treasury. + +Treasury should maintain a buffer of 500,000 USD equivalent, with further rewards distributed to YFI staked in the governance pool. + +All surplus rewards are directed to the governance pool. + +## Metadata + +| Name | Value | +| ------------------- | ------------------------------------------ | +| Proposed by | 0x24394A4758DBdCf6fcbC14dc35af64Ac0D9a450A | +| Total for votes | 2002.4442 (94.51%) | +| Total against votes | 116.1982 (5.48%) | +| Quorum | 45.11% ✔ | +| Start block | 10633194 | +| End block | 10650474 | + +Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/) diff --git a/docs/contributing/governance/yips/yip-37.md b/docs/contributing/governance/yips/yip-37.md new file mode 100644 index 0000000000..7e61436540 --- /dev/null +++ b/docs/contributing/governance/yips/yip-37.md @@ -0,0 +1,53 @@ +--- +title: "YIP-37: Participate in CRV governance and 2.5x CRV reward boost" +hide_title: true +sidebar_position: -37 +--- + +# YIP-37: Participate in CRV governance and 2.5x CRV reward boost + +| Metadata | Details | +| --- | --- | +| YIP | 37 | +| Outcome | **Passed** | +| Authors | andrecronje, banteg | +| Created | 2020-08-17 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/pre-crv-rewards-distribution-liquidation-or-boost/2481) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-37.md) | + +## Summary + +Use early LP rewards to enable YFI holders to participate in Curve DAO governance and vote-lock them for 4 years to boost yVault CRV generation by up to 2.5x. + +## Abstract + +All vested CRV tokens earned by StrategyYfii will be vote-locked to give YFI holders voting rights in Curve DAO and to boost the rewards earned by yCRV pool. + +## Motivation + +yVault currently holds 609,688 CRV with 1 year linear vesting. Starting August 28th, 2020, we can leverage these rewards to increase CRV generation and greatly incentivize capital inflow into Yearn. + +## Specification + +### Overview + +Funnel all the vested CRV into 4 year vote lock and enable delegated voting with it with YFI. + +### Rationale + +Forum poll snapshot: + +- 80% Participate in CRV governance and 2.5x boost +- 12% Distribute to YFI treasury and holders +- 8% Distribute to yVault LPs + +### Technical Specification + +- Total early LP CRV rewards collected: 609688.7992009243 + - 0x8816B2Fb982281c36E6c535B9e56B7a4417e68cF = 1606.9780365084564 + - 0xBE197E668D13746BB92E675dEa2868FF14dA0b73 = 39433.37196717059 + - 0x2De055fec2b826ed4A7478CeDDBefF82C1EdFA70 = 568648.4491972453 +- Vesting: from 2020-08-13 to 2021-08-13 +- Unlocked per day: 1670 CRV diff --git a/docs/contributing/governance/yips/yip-38.md b/docs/contributing/governance/yips/yip-38.md new file mode 100644 index 0000000000..23212b5280 --- /dev/null +++ b/docs/contributing/governance/yips/yip-38.md @@ -0,0 +1,64 @@ +--- +title: "YIP-38: Distribute / Keep Balancer Rewards" +hide_title: true +sidebar_position: -38 +--- + +# YIP-38: Distribute / Keep Balancer Rewards + +| Metadata | Details | +| --- | --- | +| YIP | 38 | +| Outcome | **Passed** | +| Authors | milkyklim | +| Created | 08/18/2020 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-38-distribute-keep-balancer-rewards/2436) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-38.md) | + +## Simple Summary + + + +Keep seized $BAL tokens as part of operational capital instead of distributing to old governance pool $BPT stakers. + +## Abstract + + + +~891 $BAL (~18500$) tokens were sent to one of the previous distribution pools. These tokens are seized and sitting in the multisig wallet now. We either have to distribute them or keep them for operational capital. + +## Motivation + + + +Since \$BALs belong to BPT stakers it is essential to decide what we should do with tokens. + +However, the amount of $BAL seized is 3 times lower than protocol fees generated within a week (18k vs 60k). Therefore, I propose to keep $BALs in the multisig and count them towards operational capital, rather than writing a custom claim contract – this solution saves time and gas. + +## Specification + + + +### Overview + + + +Largest staker should get ~31% (~5735$) of all $BAL tokens, see graph: + +https://explore.duneanalytics.com/embed/query/7901/visualization/15749?api_key=8AAmxEmXrkxj56sw0hjDtrVbMN7jZtmsZ6SmZfFo 4 + +While this might sound impressive there are a bunch of small stakers eligible for less than 8$. Taking into account current gas prices, fact that people have to claim their $BAL themselves I argue that it is more reasonable to keep \$BAL as operational capital for the team. + +Moreover, this proposal saves time as we skip writing a custom distribution contract. + +### Rationale + + + +Taking into account current gas prices, the fact that people have to claim their $BAL themselves I argue that it is more reasonable to keep $BAL as operational capital for the team. + +**For:** Keep \$BAL for operational capital. + +**Against:** Allow stakers to claim \$BAL. diff --git a/docs/contributing/governance/yips/yip-39.md b/docs/contributing/governance/yips/yip-39.md new file mode 100644 index 0000000000..7e984f11da --- /dev/null +++ b/docs/contributing/governance/yips/yip-39.md @@ -0,0 +1,59 @@ +--- +title: "YIP-39: Add Curve sBTC Pool LP-Tokens yVault" +hide_title: true +sidebar_position: -39 +--- + +# YIP-39: Add Curve sBTC Pool LP-Tokens yVault + +| Metadata | Details | +| --- | --- | +| YIP | 39 | +| Outcome | **Passed** | +| Authors | az | +| Created | 08/23/2020 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/proposal-add-curve-sbtc-pool-lp-tokens-yvault/3251) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-39.md) | + +## Simple Summary + + + +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 + + + +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 + + + +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 + + + +[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. diff --git a/docs/contributing/governance/yips/yip-40.md b/docs/contributing/governance/yips/yip-40.md new file mode 100644 index 0000000000..c9c59978a7 --- /dev/null +++ b/docs/contributing/governance/yips/yip-40.md @@ -0,0 +1,71 @@ +--- +title: "YIP-40: Replace inactive multisig signers" +hide_title: true +sidebar_position: -40 +--- + +# YIP-40: Replace inactive multisig signers + +| Metadata | Details | +| --- | --- | +| YIP | 40 | +| Outcome | **Passed** | +| Authors | illlefr4u, banteg | +| Created | 2020-08-24 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/change-participants-of-the-multisig-wallet/2991) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-40.md) | + +## 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.fi/t/change-participants-of-the-multisig-wallet/2991 + +https://gov.yearn.fi/t/nominate-yourself-for-the-foundation-model/3166 diff --git a/docs/contributing/governance/yips/yip-41.md b/docs/contributing/governance/yips/yip-41.md new file mode 100644 index 0000000000..f171197002 --- /dev/null +++ b/docs/contributing/governance/yips/yip-41.md @@ -0,0 +1,78 @@ +--- +title: "YIP-41: Temporarily Empower Multisig" +hide_title: true +sidebar_position: -41 +--- + +# YIP-41: Temporarily Empower Multisig + +| Metadata | Details | +| --- | --- | +| YIP | 41 | +| Outcome | **Passed** | +| Authors | tracheopteryx, Substreight, franklin501, Michael Anderson, Vance Spencer | +| Created | 2020-08-24 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/empower-the-multisig/2891) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-41.md) | + +## 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.fi/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) diff --git a/docs/contributing/governance/yips/yip-42.md b/docs/contributing/governance/yips/yip-42.md new file mode 100644 index 0000000000..5676b94680 --- /dev/null +++ b/docs/contributing/governance/yips/yip-42.md @@ -0,0 +1,57 @@ +--- +title: "YIP-42: Add RenBTC to yVaults" +hide_title: true +sidebar_position: -42 +--- + +# YIP-42: Add RenBTC to yVaults + +| Metadata | Details | +| --- | --- | +| YIP | 42 | +| Outcome | **Rejected** | +| Authors | zu-ctrl | +| Created | 08/26/2020 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/proposal-yrenbtc-delegated-vault/3470) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-42.md) | + +## Simple Summary + + + +Add RenBTC as a volatile asset to be used as collateral in delegated yVaults. + +## Abstract + + + +Add RenBTC as a volatile asset to be used as collateral in delegated yVaults. + +## Motivation + + + +wBTC has pretty good growth rates as seen on DeFi Pulse but as a custodial solution is hampered by trust-based systems which BTC holders do not by and large feel comfortable with. + +RenBTC is a tokenized representation of BTC on the Ethereum blockchain. It is an ERC20, and backed 1:1 with real BTC locked in RenVM, a decentralized custodian. It is redeemable at any time for real BTC. + +When Curve created an opportunity for RenBTC to generate returns, the RenVM TVL growth chart exploded. This is a clear signal that when the right solution is available, there is a LOT of BTC waiting on the sidelines to jump into farming yield on ETH. Let’s be there for them. + +Refer to thread with an overwhelming majority FOR the BTC strategic focus. This is a vote to approve the current Strategy Smart contract to go live and start generating returns for RenBTC depositors without forcing them to figure out Curve deposits. + +## Specification + + + +The strategy linked to above models the current yYFI yVault strategy of farming CREAM and generating returns in more CREAM. We will require a new row in the yVault to accept RenBTC deposits. + +> Strategy 1: + +- Add a new Vault row in Table for yRenBTC Vault +- User deposits RenBTC start farming CREAM the same way as yYFI Vault, and deliver returns for depositors as RenBTC. + +**For:** Yes! Add yRenBTC Vault Strategy 1 - StrategyCreamRENBTC + +**Against:** No change. diff --git a/docs/contributing/governance/yips/yip-43.md b/docs/contributing/governance/yips/yip-43.md new file mode 100644 index 0000000000..1701253b29 --- /dev/null +++ b/docs/contributing/governance/yips/yip-43.md @@ -0,0 +1,158 @@ +--- +title: "YIP-43: Improve YIP categories" +hide_title: true +sidebar_position: -43 +--- + +# YIP-43: Improve YIP categories + +| Metadata | Details | +| --- | --- | +| YIP | 43 | +| Outcome | **Rejected** | +| Authors | sambacha | +| Created | 2020-08-24 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/proposal-add-new-statuses-to-yip-proposals-non-protocol-change/3608) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-43.md) | + +## Simple Summary + + + +Add new `status`(s) to `YIPs` so that author(s) may better manage their `YIPs` in the context of community collaboration and so that governance is given the proper procedures to foster community cooperation. + +## Abstract + + + +This will _only_ add to the current state of `proposal YIPs` in that it only changes the _potential_ `statuses` available of a `YIP`. It does not add any `protocol` changes: only documentation and governance procedures (off chain only). + +I proposal the following changes to reflect a new state of possible 'YIPs': + +1. Modifying YIP Templates +2. Modifying YIP Validator Gemfile +3. Modifying YIP README file + +## Motivation + + + +> The current state of procedures for `YIPS` is inadequate as it unnecessarily limits the possible outcomes of a proposed `YIP` while not affording both the author(s) nor the governance council flexibility in being able to deal with community driven `YIPs` + +This is a _documentation_ and _procedure_ change. In fact there is no explicit description for proposing such changes in governance _(that I could find)._ + +This change is needed as it better explains the _intent_ of the YIP format to author(s). It also provides for governance additional functionality in their procedures so as to not potentially 'alienate' author(s) by rejecting a YIP when it could have been withdrawn. This ensures that also the author(s) are active in the process of their submitted proposal and in the larger community (in so far as they are knowledgable about other potentially competing YIPS.) + +## Specification + +_Additions in 'BOLD'_ + +Proposed - a YIP that is ready to be reviewed in a governance call. +Approved - a YIP that has been accepted for implementation by the Yearn community. +Implemented - a YIP that has been released to mainnet. +Rejected - a YIP that has been rejected. +**Withdrawn - a YIP that has been withdrawn by the author(s).** +**Deferred - a YIP that governance has decided to wait for another YIP/some other change that should be bundled with it together** +**Moribund - a YIP that was once Implemented. It is now Obsolete 'AND' requires no explicit replacement.** + +The "Withdrawn" status is similar - it means that the YIP author has decided that the YIP is actually a 'bad' idea, or has accepted that a competing proposal is a better alternative. + +### Workflow Specification + +``` +Proposed -> Approved -> Implemented + ^ | + +----> Rejected +----> Moribund + | + +----> Withdrawn + v +Deferred +``` + +#### New Statuses for YIPs + +> To be added are the following + +- Withdrawn +- Moribund +- Deferred + +### Overview + + + +#### New YIP statuses + +- Withdrawn + Means that the YIP author has decided that the YIP is actually a bad idea, or has accepted that a competing proposal is a better alternative. +- Moribund + Obsolete and requires no explicit replacement, it SHOULD be marked "Moribund" +- Deferred + Governance placed status upon a YIP that means that they would like to know more information, or that they would like to see if the author(s) can work with another proposed YIP and combine it into a single YIP, etc. + +### Rationale + +The reasoning behind this is that it is unclear what will happen to a YIP should material facts change during its initial formal proposal and when its actually voted on by governance. Changes may be introduced between then, and the author may want to withdraw the proposal. This also frees up the governance council in that they are no longer obligated to reject every single YIP that may no longer be relevant, instead sharing the responsibility with the actual author(s). + +### Technical Specification + + + +Technical implementation involves: + +- changes in the validation Gemfile +- changes in the template `.md` file + +#### Changes in Template `.md` file + +Below is a sample `.yaml` file to illustrate the _new_ header that should be used in the `yip-template.md` file + +```yaml +--- +YIP: `` +Title: `` +Author: `` +Type: `` +Status: + Version: ``[.``] + Created: `` + Requires (*optional): `` + Implementation (*optional): `` + +Discussions-to: `` + +* Requires: `` +* Replaces: `` +* Replaced-By: `` +--- +``` + +#### YIP Validator (Ruby Gem) + +> current version: `1.0.2`, should be bumped to `1.1.0` +> Changes located [github.com/yearn/yip_validator/blob/master/lib/yip_validator/validator.rb#L25](https://github.com/yearn/yip_validator/blob/master/lib/yip_validator/validator.rb#L25) + +```ruby + validates_inclusion_of :status, in: ['WIP', 'Proposed', 'Approved', 'Implemented', 'Rejected'] +``` + +```ruby + validates_inclusion_of :status, in: ['WIP', 'Proposed', 'Approved', 'Implemented', 'Rejected', 'Withdrawn', 'Deferred', 'Moribund'] +``` + +See Files Changed here [https://github.com/sambacha/yip_validator/tree/YIP-Proposed](https://github.com/sambacha/yip_validator/tree/YIP-Proposed) + +### Test Cases + +See `travis-ci` logs for the `Rub Gem` update here [https://travis-ci.com/github/sambacha/yip_validator/builds/181226022](https://travis-ci.com/github/sambacha/yip_validator/builds/181226022) + +```bash +total:2, valid:2, invalid:0, errors:0 + statuses: [["Withdrawn", 1], ["Implemented", 1]] + raises exception if it includes invalid yips +spec/fixtures/invalid/yip-7.md is NOT valid: {:status=>["is not included in the list"]} + +``` diff --git a/docs/contributing/governance/yips/yip-44.md b/docs/contributing/governance/yips/yip-44.md new file mode 100644 index 0000000000..fd8e2ad585 --- /dev/null +++ b/docs/contributing/governance/yips/yip-44.md @@ -0,0 +1,158 @@ +--- +title: "YIP-44: Improve YIP categories" +hide_title: true +sidebar_position: -44 +--- + +# YIP-44: Improve YIP categories + +| Metadata | Details | +| --- | --- | +| YIP | 44 | +| Outcome | **Passed** | +| Authors | sambacha | +| Created | 2020-08-31 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-44-improve-yip-categories/3608) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-44.md) | + +## Simple Summary + + + +Add new `status`(s) to `YIPs` so that author(s) may better manage their `YIPs` in the context of community collaboration and so that governance is given the proper procedures to foster community cooperation. + +## Abstract + + + +This will _only_ add to the current state of `proposal YIPs` in that it only changes the _potential_ `statuses` available of a `YIP`. It does not add any `protocol` changes: only documentation and governance procedures (off chain only). + +I proposal the following changes to reflect a new state of possible 'YIPs': + +1. Modifying YIP Templates +2. Modifying YIP Validator Gemfile +3. Modifying YIP README file + +## Motivation + + + +> The current state of procedures for `YIPS` is inadequate as it unnecessarily limits the possible outcomes of a proposed `YIP` while not affording both the author(s) nor the governance council flexibility in being able to deal with community driven `YIPs` + +This is a _documentation_ and _procedure_ change. In fact there is no explicit description for proposing such changes in governance _(that I could find)._ + +This change is needed as it better explains the _intent_ of the YIP format to author(s). It also provides for governance additional functionality in their procedures so as to not potentially 'alienate' author(s) by rejecting a YIP when it could have been withdrawn. This ensures that also the author(s) are active in the process of their submitted proposal and in the larger community (in so far as they are knowledgable about other potentially competing YIPS.) + +## Specification + +_Additions in 'BOLD'_ + +Proposed - a YIP that is ready to be reviewed in a governance call. +Approved - a YIP that has been accepted for implementation by the Yearn community. +Implemented - a YIP that has been released to mainnet. +Rejected - a YIP that has been rejected. +**Withdrawn - a YIP that has been withdrawn by the author(s).** +**Deferred - a YIP that governance has decided to wait for another YIP/some other change that should be bundled with it together** +**Moribund - a YIP that was once Implemented. It is now Obsolete 'AND' requires no explicit replacement.** + +The "Withdrawn" status is similar - it means that the YIP author has decided that the YIP is actually a 'bad' idea, or has accepted that a competing proposal is a better alternative. + +### Workflow Specification + +``` +Proposed -> Approved -> Implemented + ^ | + +----> Rejected +----> Moribund + | + +----> Withdrawn + v +Deferred +``` + +#### New Statuses for YIPs + +> To be added are the following + +- Withdrawn +- Moribund +- Deferred + +### Overview + + + +#### New YIP statuses + +- Withdrawn + Means that the YIP author has decided that the YIP is actually a bad idea, or has accepted that a competing proposal is a better alternative. +- Moribund + Obsolete and requires no explicit replacement, it SHOULD be marked "Moribund" +- Deferred + Governance placed status upon a YIP that means that they would like to know more information, or that they would like to see if the author(s) can work with another proposed YIP and combine it into a single YIP, etc. + +### Rationale + +The reasoning behind this is that it is unclear what will happen to a YIP should material facts change during its initial formal proposal and when its actually voted on by governance. Changes may be introduced between then, and the author may want to withdraw the proposal. This also frees up the governance council in that they are no longer obligated to reject every single YIP that may no longer be relevant, instead sharing the responsibility with the actual author(s). + +### Technical Specification + + + +Technical implementation involves: + +- changes in the validation Gemfile +- changes in the template `.md` file + +#### Changes in Template `.md` file + +Below is a sample `.yaml` file to illustrate the _new_ header that should be used in the `yip-template.md` file + +```yaml +--- +YIP: `` +Title: `` +Author: `` +Type: `` +Status: + Version: ``[.``] + Created: `` + Requires (*optional): `` + Implementation (*optional): `` + +Discussions-to: `` + +* Requires: `` +* Replaces: `` +* Replaced-By: `` +--- +``` + +#### YIP Validator (Ruby Gem) + +> current version: `1.0.2`, should be bumped to `1.1.0` +> Changes located [github.com/yearn/yip_validator/blob/master/lib/yip_validator/validator.rb#L25](https://github.com/yearn/yip_validator/blob/master/lib/yip_validator/validator.rb#L25) + +```ruby + validates_inclusion_of :status, in: ['WIP', 'Proposed', 'Approved', 'Implemented', 'Rejected'] +``` + +```ruby + validates_inclusion_of :status, in: ['WIP', 'Proposed', 'Approved', 'Implemented', 'Rejected', 'Withdrawn', 'Deferred', 'Moribund'] +``` + +See Files Changed here [https://github.com/sambacha/yip_validator/tree/YIP-Proposed](https://github.com/sambacha/yip_validator/tree/YIP-Proposed) + +### Test Cases + +See `travis-ci` logs for the `Rub Gem` update here [https://travis-ci.com/github/sambacha/yip_validator/builds/181226022](https://travis-ci.com/github/sambacha/yip_validator/builds/181226022) + +```bash +total:2, valid:2, invalid:0, errors:0 + statuses: [["Withdrawn", 1], ["Implemented", 1]] + raises exception if it includes invalid yips +spec/fixtures/invalid/yip-7.md is NOT valid: {:status=>["is not included in the list"]} + +``` diff --git a/docs/contributing/governance/yips/yip-45.md b/docs/contributing/governance/yips/yip-45.md new file mode 100644 index 0000000000..75e1c13a94 --- /dev/null +++ b/docs/contributing/governance/yips/yip-45.md @@ -0,0 +1,34 @@ +--- +title: "YIP-45: Add a bounty for proposing YIPs that are implemented" +hide_title: true +sidebar_position: -45 +--- + +# YIP-45: Add a bounty for proposing YIPs that are implemented + +| Metadata | Details | +| --- | --- | +| YIP | 45 | +| Outcome | **Passed** | +| Authors | alphastorm | +| Created | 2020-09-01 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-45-add-a-bounty-for-proposing-yips-that-are-implemented/3337) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-45.md) | + +## Simple Summary + +Add a bounty for proposing YIPs that are implemented. + +## Abstract + +Implement a \$500 yCRV bounty for proposing a YIP that reaches the ‘Implemented’ phase, payable from the treasury. + +## Motivation + +This should incentivize community members to propose useful YIPs which should be beneficial for the protocol. This is inspired by the 500 sUSD bounty that Synthetix pays out for [implemented SIPs](https://github.com/Synthetixio/SIPs#contributing). + +**FOR**: Start offering a bounty for proposing YIPs that are implemented. + +**AGAINST**: No change. diff --git a/docs/contributing/governance/yips/yip-5.md b/docs/contributing/governance/yips/yip-5.md new file mode 100644 index 0000000000..5bad545e8a --- /dev/null +++ b/docs/contributing/governance/yips/yip-5.md @@ -0,0 +1,51 @@ +--- +title: "YIP-5: Reducing YFI weekly supply" +hide_title: true +sidebar_position: -5 +--- + +# YIP-5: Reducing YFI weekly supply + +| Metadata | Details | +| --- | --- | +| YIP | 5 | +| Outcome | **Rejected** | +| Authors | sikiriki12 | +| Created | 2020-07-20 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/proposal-5-reducing-yfi-weekly-supply/110) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-5.md) | + +## Simple Summary + +Currently the weekly supply increase of YFI is 30,000 per week. Vote under proposal #0 is if more YFI tokens should be minted. + +I’m voting “FOR” on proposal #0 as I think continuous incentivization of LPs is important for growth of the platform. + +However I also think early participants of the platform that are taking more risk should be rewarded with a higher % of YFI supply. + +This is a proposal for reducing the weekly issuance rate with a simple halvening model similar to that of BTC but accelerated due to the significant interest in the platform (so a long discovery period is not necessary) and with a inflation floor to always have some level of incentive to attract new users to the platform. + +So issuance week 0 is 30,000. Issuance week 1 should be halved to 15,000. (5k per pool). After that every 4 weeks the rewards should half to 7,500 starting from week 5, 3,750 starting week 9, 1,875 starting week 13, 937.5 starting week 17, 468.75 starting week 21 and final halvening in week 25 to a long term issuance rate of 234.375. + +![Issuance](assets/yip5.png) + +In summary. If proposal #0 passes the issuance model should be altered as described above. + +**FOR**: Support the new issuance model. + +**AGAINST**: Do not support the new issuance model. + +## Metadata + +| Name | Value | +| ------------------- | ------------------------------------------ | +| Proposed by | 0x5398850A9399Da87624874704FEAa8A9C6C4089B | +| Total for votes | 1123689.4842 (69.84%) | +| Total against votes | 485164.6894 (30.15%) | +| Quorum | 6.19% 𐄂 | +| Start block | 10496829 | +| End block | 10514109 | + +Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/) diff --git a/docs/contributing/governance/yips/yip-51.md b/docs/contributing/governance/yips/yip-51.md new file mode 100644 index 0000000000..ba7f949cdd --- /dev/null +++ b/docs/contributing/governance/yips/yip-51.md @@ -0,0 +1,128 @@ +--- +title: "YIP-51: Set Vault v2 fee structure" +hide_title: true +sidebar_position: -51 +--- + +# YIP-51: Set Vault v2 fee structure + +| Metadata | Details | +| --- | --- | +| YIP | 51 | +| Outcome | **Passed** | +| Authors | banteg, lehnberg, milkyklim, tracheopteryx | +| Created | 2020-11-06 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-51-set-vault-v2-fee-structure/7752) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:yearn/proposal/QmSaYHR97LDMDvg9xeTfdNZw6aqL9njxBKM6JVFtCYxKvB) | +| Vote result | Release Vaults v2 with the proposed fee structure: 1,771.73; Release Vaults v2 with some other fee to be defined fee structure: 4.53 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-51.md) | + +## Summary + +- Focused proposal to set the fee structure for Vaults v2 to: + 1. No withdrawal fee + 2. Management fee (2%) + 3. Performance fee (20%) +- The proposal leaves: + - Total fees collected at roughly the same level as for Vaults v1 + - Strategist reward allocation unchanged + - YFI staking and rewards unchanged + - Treasury management unchanged + +## Background + +The high level design of the next iteration of Yearn Vaults, v2, has been voted on and approved by YFI holders. It is currently in the later stages of the development cycle. Testing has begun, and security audits are in progress. + +With the new vaults likely being weeks away from launch, it is high time to finalize how fees will be collected in them. + +### Out of scope + +There are currently active discussions underway in the community about many related topics, such as to what extent: + +- Rewards should be distributed to YFI stakers +- Strategist creators should be rewarded for their contributions +- Contributors should be allocated a portion of rewards for the purpose of long term incentivization + +Those questions are not answered by this proposal, and are not discussed further here. Specifically, anything that concerns what fees are spent on, how different stakeholders are compensated, or how the treasury should be run, is not covered by this proposal and is assumed to be unchanged. + +### In scope + +Instead, the focus here is to determine _how fees are collected_, and _the total amount collected_, with the intention to meet the following objectives: + +- **Keep fees at roughly the same level.** The proposal should not lead to a significant change in the overall fee levels that are in place today with Vaults v1. +- Ensure fees incentivize the desired behavior among various stakeholders: + - **Users** should be encouraged to keep funds in a vault if it performs well, and withdraw if the vault under-performs. + - **Yearn** should be encouraged to design the best possible vaults, by ensuring rewards go up as a vault attracts and retains capital, and go down as capital leaves the vault. Similarly, rewards should increase if the vault performs well, and decrease if it under-performs. + - **Third party integrations** should be encouraged to integrate Yearn vaults in their own products and services. It should be easy for them to reason about the expected behavior when depositing and withdrawing, and the fees charged by the vault. + +## Motivation + +### Previous fee structure, Vaults v1 + +- 5% performance fee, out of which + - 4.5% went to Treasury + - 0.5% went to the Strategist +- 0 to 0.5% withdrawal fee + - 0% when funds were available in the Vault + - 0.5% when funds had to be withdrawn from the Strategy + +### Problems with a fee on withdrawals + +- **Charges Users when they are the least happy with the vault.** You are charged a withdrawal fee when you no longer use the vault. If the vault performs, you would leave your funds in it and avoid paying for the service. +- **Rewards Yearn when there is capital flight.** More money leaving the vault leads to more fees, when it should be the opposite. +- **Can be gamed.** Astute users and integrations can time it so that they make free withdrawals in the period after the vault has seen deposits, as long as it's done before those funds have been sent to the Strategy for investing. +- **Makes fees unpredictable for integrations.** It's unclear what the fees charged will be prior to the actual withdrawal, making it harder for third party integrations to calculate ROI accurately. + +### Benefits with a management fee + +- **Continuous pay based on usage.** The vault provides a service that people are paying for, continuously, based on the time their capital is in the vault. There is no incentive to withdraw late or early. +- **Encourages optimizing for retention.** Yearn earns more fees when users keep funds in the vault, and makes less when they withdraw. +- **Benefits composability.** Makes it easier to integrate Vaults with other products and services. + +### Comparing fees with v1 + +The backtesting data produced shows how the new fee model is delivering roughly the same amount of total fees, compared to the model used in Vaults v1: + +![bar chart|1800x1200,30%](assets/yip-51/figure1.png) + +| | Withdrawal fee | Performance fee | Management fee | Total fees | % | +| ------- | -------------: | --------------: | -------------: | ----------: | ---: | +| **Old** | \$2,243,078 | \$466,822 | N/A | \$2,709,900 | 100% | +| **New** | N/A | \$1,867,288 | \$699,237 | \$2,566,525 | 95% | + +#### Comments + +- The previous withdrawal fee accounted for a whopping **83%** of all fees collected. This is very high for a fee that is unrelated to actual performance of the service. +- In contrast, the management fee in Vaults v2 would only account for **27%** of total fees. +- A much larger portion of fees are now made out of the performance fee component, **17%** of total fees in the old model, **73%** in the new model. This means that incentives are better aligned as Yearn earns most of it fees and Users pay most of their fees only if the Vaults are performing well. + +## Specification + +### New fee structure + +- 0% withdrawal fee +- 2% annualized management + - Full amount allocated to Treasury + - Accrued per block + - Collected on each harvest) +- 20% performance fee + - 19.5% allocated to Treasury + - 0.5% allocated to the Strategist (unchanged to v1) + +## Vote + +**For:** Release Vaults v2 with the proposed fee structure. + +**Against:** Release Vaults v2 with some other fee to be defined fee structure. + +## Metadata + +| Name | Value | +| ------------------- | ------------------------------------------ | +| Proposed by | 0x7A1057E6e9093DA9C1D4C1D049609B6889fC4c67 | +| Total for votes | 1.77k YFI (99.74%) | +| Total against votes | 4.53 YFI (0.26%) | +| Start date | Nov 7 | +| End date | Nov 10 | + +_Source: [Snapshot](https://snapshot.page/#/yearn/proposal/QmSaYHR97LDMDvg9xeTfdNZw6aqL9njxBKM6JVFtCYxKvB)_ diff --git a/docs/contributing/governance/yips/yip-52.md b/docs/contributing/governance/yips/yip-52.md new file mode 100644 index 0000000000..1f7c74f8cc --- /dev/null +++ b/docs/contributing/governance/yips/yip-52.md @@ -0,0 +1,157 @@ +--- +title: "YIP-52: Make Strategist Skin in Game Partner for Make Benefit of Glorious Brain of Yearn" +hide_title: true +sidebar_position: -52 +--- + +# YIP-52: Make Strategist Skin in Game Partner for Make Benefit of Glorious Brain of Yearn + +| Metadata | Details | +| --- | --- | +| YIP | 52 | +| Outcome | **Passed** | +| Authors | banteg, lehnberg, milkyklim | +| Created | 2020-11-09 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-52-make-strategist-skin-in-game-partner-for-make-benefit-of-glorious-brain-of-yearn/) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:yearn/proposal/QmbAq6jPB6ocrihjkDo5TLNF4D4w9dw1HsEsJ7vwdwd9g3) | +| Vote result | Accept proposal: 1,341.94; Reject proposal: 260.13 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-52.md) | + +## Summary + +- With 97.5% of the Vault's performance fee going to the Yearn treasury, Strategists have barely any skin in the game–**39x less than Yearn's Treasury** to be precise. +- Such a misaligned balance of interests does not make it attractive for Strategists to build on Yearn. This could turn into an **existential threat** to the protocol. +- This proposal sets Yearn and Strategists out to be **equal partners** in the success of a Vault, with each allocated an even share of the 20% performance fee: + - Treasury allocation: 10% + - Strategist: 10% + +## Background + +### What is Yearn's competitive edge? + +#### Yearn as an aggregator + +Yearn is often referred to as a "Yield aggregator", in the context of Ben Thompson's Aggregation Theory[[1]]. + +![Aggregation Theory|1816x780, 30%](assets/yip-52/figure1.jpg) + +Similar to Google for search, Facebook for social, Netflix for movies, Airbnb for holiday rentals, and Uber for rides, the idea is that Yearn should be the go-to source for users who want to earn the best and most predictable ROI on their DeFi investments. + +Unlike these big tech companies however, there are some important differences in the case of Yearn as an aggregator: + +- **The code base is open source.** If Yearn solves a hard problem, this means that others can now solve it too. The code base itself is not the competitive moat that it is for other aggregators. As we've seen it's straightforward to create forks/clones and launch competitors to Yearn. +- **There is no stickiness.** Aggregators have different degrees of stickiness. The Facebook Social Graph is extremely hard to replicate and makes it very difficult for users to switch to a competitor. While it's easy to switch to a Netflix competitor, they will miss out on exclusive original Netflix content so it comes at a cost. Uber's driver pool and Airbnb's housing stock is less unique and easier for its competitors to bootstrap or poach, but is still not trivial to replicate. Yearn on the other hand has no systemic stickiness. It does not even require canceling a subscription, or closing of an account. In the DeFi space, money flows to where it earns the best and most predictable returns. +- **What's on offer is ever changing and not easily commoditized.** The aggregators turn "the hardest problem digitized" into a commodity. For Facebook it is news articles and social content. For Netflix it's movies and tv-shows. In the case of Yearn, this would be yield-producing investment strategies. _But these cannot be easily commoditized:_ + - As soon as a strategy goes live, it can be replicated by competitors, thus affecting its performance. + - As more capital flows into the strategy, it can become harder to realize the same opportunities, thus affecting its performance. + - As time passes, a successful strategy will lose its alpha as the rest of the market adapts in response, thus affecting its performance. + +#### Yearn's Gingerbread Man strategy + +When Snap filed to go public, they wrote in their S-1 filing: + +> In a world where anyone can distribute products instantly and provide them for free, the best way to compete is by innovating to create the most engaging products. That’s because it’s difficult to use distribution or cost as a competitive advantage—new software is available to users immediately, and for free. We believe this means that our industry favors companies that innovate, because people will use their products. + +This triggered the same Ben Thompson to quip that Snap was pursuing a Gingerbread Man strategy[[2]]: + +> Run, run, run as fast as you can. +> You’ll never catch me, I’m the gingerbread man. + +This applies well to describe Yearn and the advantage it has over its competition. It's not the total value locked. It's not the APY returns. It's the ability to ship more innovating products, that are more secure and better performant than anything else on the market. This at a faster pace than the competition can keep up with and try to imitate. + +#### Yearn's edge is the collective brain power it attracts and can retain building for it + +If Yearn's business is aggregating yield-bearing strategies, its Strategy creators are the equivalent of Uber's drivers. **Strategy creators are however very different from Uber drivers.** They have much more unique skill sets, making them harder to replace, and more important to retain. + +### A Strategist's choices + +Someone who develops an investment strategy that results in a positive yield has the following choices today: + +1. **Work for Yearn.** Partner up, work with protocol devs to integrate Strategy in a vault, hope for launch with a large influx of capital, be compensated as part of the performance. +2. **Create competing project or work for a competitor.** Either launch a competing project to Yearn, or work for an existing competitor, in the hopes of earning more fees. +3. **One man wolf pack it.** Deploy strategy solo, perhaps raising funds from friends and family, and keep all the fees. + +In order for Yearn to remain competitive over the long term, the best and the brightest strategists must consistently choose to work with Yearn. This an existential question, necessary in order to ensure the long term sustainability of the protocol. + +### How are strategists rewarded today? + +The next version of Yearn vaults will launch with a two-pronged fee structure[[3]]: + +1. A 2% management fee levied on AUM that goes to the Treasury; +2. A 20% performance fee levied on returns from the vault, which is split as follows: + - 19.5% to the Treasury + - **0.5% to the Strategy creator** + +Strategists are expected to cover their own development, testing, gas, and monitoring costs. Under the current allocation, Strategists are not breaking even at times.[[4]] + +## Motivation + +### Why not share the management fee? + +- **The protocol requires predictable income.** There are a lot of constant costs on the protocol side. Operations, Development, maintenance, and R&D. These require a stable source of funding and should not be affected by Strategists. +- **Survival of the fittest.** Strategists should "eat what they kill", rewarding only the most ambitious and best performing, filtering out the rest. + +### Why split the fee equally between Treasury and Strategists? + +- **Establishes a partnership.** The message is clear: Yearn and Strategists are in this together, and it's a symbiotic relationship, where both are held accountable and are equally responsible for success. +- **Acquisition.** Creates success stories of high earning Strategists that will make it more aspirational and attractive for others to become Strategists. +- **Retention.** Strategists with a lot of skin in the game will work and further Yearn as opposed to a competitor. + +### Future possibilities + +**Tiered fee system.** As the Strategy creation space matures, there could be justification to distinguish between different qualities of strategies, creating a tiered system that rewards a different share of the performance fee based on the novelty and the sophistication of the strategy, as proposed in [[5]]. At this stage, it's recommended to keep a simple structure that is easy to reason about and for Strategists to understand the appeal of. This should be revisited in the future when needed. + +### Comparing allocations + +Drawing from the backtesting data produced in [[6]], below is the Vaults V2 fee model applied to the yUSD vault, showing the difference in earnings between Strategists and Yearn treasury between allocation models. + +#### Previous allocation + +![Previous model sankey |2400x1400, 20%](assets/yip-52/figure2.png) + +#### Proposed allocation + +![Previous model sankey|2400x1400, 20%](assets/yip-52/figure3.png) + +#### Comments + +- The previous allocation to Strategists is disproportionately small compared to the value created by them. +- In the proposed allocation, the **Yearn treasury receives 64% of all fees** as it is paid the entirety of the management fee. +- The Strategist now earns a sizable reward that is entirely based on performance. + +## Specification + +### New performance fee structure + +- 20% performance fee + - 10% allocated to Treasury + - 10% allocated to the Strategist + +The Strategist is expected to pay for all expenses incurred, including those of development, testing, gas, monitoring, and operation. + +## Vote + +**For:** Accept proposal. + +**Against:** Reject proposal. + +## Metadata + +| Name | Value | +| ------------------- | ------------------------------------------ | +| Proposed by | 0x0Cec743b8CE4Ef8802cAc0e5df18a180ed8402A7 | +| Total for votes | 1.34k YFI/yYFI (83.76%) | +| Total against votes | 260.13 YFI/yYFI (16.24%) | +| Start date | Nov 9 | +| End date | Nov 12 | + +_Source: [Snapshot](https://snapshot.page/#/yearn/proposal/QmbAq6jPB6ocrihjkDo5TLNF4D4w9dw1HsEsJ7vwdwd9g3)_ + +## References + +1. https://stratechery.com/concept/aggregation-theory/ +2. https://stratechery.com/2017/snaps-apple-strategy/ +3. https://snapshot.page/#/yearn/proposal/QmSaYHR97LDMDvg9xeTfdNZw6aqL9njxBKM6JVFtCYxKvB +4. https://gov.yearn.fi/t/proposal-increase-strategist-rewards/7299/8 +5. https://gov.yearn.fi/t/proposal-increase-strategist-rewards/7299/10 +6. https://gov.yearn.fi/t/restructure-fees-and-align-incentives/ diff --git a/docs/contributing/governance/yips/yip-53.md b/docs/contributing/governance/yips/yip-53.md new file mode 100644 index 0000000000..b3f06fe24d --- /dev/null +++ b/docs/contributing/governance/yips/yip-53.md @@ -0,0 +1,109 @@ +--- +title: "YIP-53: yAcademy" +hide_title: true +sidebar_position: -53 +--- + +# YIP-53: yAcademy + +| Metadata | Details | +| --- | --- | +| YIP | 53 | +| Outcome | **Passed** | +| Authors | aliatiia | +| Created | 2020-11-11 | +| Forum discussion | [View discussion 1](https://gov.yearn.fi/t/yip-53-yacademy-planting-the-seed-of-a-sustainably-secure-future-for-yearn-and-beyond), [View discussion 2](https://gov.yearn.fi/t/lets-poach-samczsun-and-plant-the-seed-for-an-auditing-academy/5507) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:yearn/proposal/QmPTAfJCq3UtFZqY3jdgNEJsxc6yuHwfESnQyjjkoccZrJ) | +| Vote result | Launch yAcademy: 937.09; Do not launch yAcademy: 0.1 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-53.md) | + +# Simple Summary + +We launch the yAcademy: a security wing tasked with auditing Yearn's contracts, attracting and retaining top talent, and eventually generating revenue by expanding its auditing services to the ecosystem at large. Mission: audit Yearn contracts in a collaborative and semi-structured process. Administrative costs are kept near zero, as the tasks of advocacy, event organizing, educational curriculum are handled by our partners at Gitcoin and Status. The yAcademy is net positive from day one since money that would have otherwise been an operational expense given to auditing firms is now an investment that should pay back the principle immediately (in the form of audits of Yearn contracts) and generate revenue eventually (once the team has expanded to offer services to the ecosystem). + +yAcademy will be operated as a joint venture by the yAcademy partners—Yearn (through the Multisig Council), Gitcoin, Status and member-auditors (including the first five auditors to join). The alignment can be seen in the following figure: + +![yAcademy incentive structure](https://aws1.discourse-cdn.com/business20/uploads/yearn/optimized/2X/4/4a46800d098c0f382f7cbb72147981fbd6e30bc0_2_690x408.png) + +## _Glossary of terms_ +**_Stakeholders_**: Yearn (through the Multisig Council), Gitcoin, Status, yAcademy permanent members (auditors) +**_Founding members_**: the first five auditors to join the yAcademy. They get membership interests in yAcademy. +**_Mentees_**: outstanding participants in the KERNEL program that complete the curriculum and show promise, they are invited to shadow audit in yAcademy in close collaboration with Founding Members and Yearn core team. +**_Menbership Interests_**: non-transferable governance and economic rights in the yAcademy joint venture. + + +## Abstract + +The Yearn technical community is innovating at a rapid speed. Efforts must be made to mitigate software bugs. Auditing talent is currently scarce and will continue to be for sometime because the pace of innovation in smart-contract products is much faster than that of producing auditors. + +The Yearn community already expends a significant amount of time negotiating audit contracts or coordinating one-off informal audits. Planting the seed for an auditing wing of Yearn will bring immense benefits in the short and long term. Money spent on audits is a realized cost, while money spent on yAcademy is an investment. Yearn has thus far this year spent more on audits/bounties more than the projected budget for yAcademy. By keeping administrative costs near zero, the yAcademy should be a net positive to YFI holders from day one. If structured and run efficiently, we should witness the rise of a new breed of excellent auditors that get vetted by going through the KERNEL program run by our partners at Gitcoin and Status. + +The Yearn community should incentivise rising stars to stay and continue to work on Yearn contracts full time. As Yearn matures over-time, yAcademy can begin to offer services to the outside world. At that point, the yAcademy becomes a self-sufficient, and potentially massively profitable. To align incentives, equity in the yAcademy is distributed to YFI holders (65%), Gitcoin (10%), Status (10%), and the first five permanent auditors (5%, 4%, 3%, 1.5%, 1.5% to the 1st, 2nd, 3rd, 4th, and 5th members respectively). + +## Motivation + +- Yearn is innovating at an ever increasing speed. + +- Software bugs are a matter of "when" and "how bad", not "if". We must make mitigation efforts. + +- Auditing firms are overbooked, they have financial incentive to speed up audits which can affect quality. + +- Negotiating audit contracts with auditing firms is a laborious and clunky analog process. + +- Audit contracts are very expensive. + +- Yearn is a hub of innovation and as a result should attract top talent. + +- Smart contracts will probably experience an even bigger cambrian explosion once the enterprise starts using permissionless networks such as Ethereum as a settlement layer. Hence, the yAdademy will most likely become a highly-profitable organization, thereby paying back all the investment put into it, and then some—this could lead to a new source of sustainable research & development funding for Yearn ecosystem grants. + +- Yearn are better off having auditing expenditure be an investment that pays itself back and more, rather than a realized operational cost lost to auditing firms. + +- Yearn has spent on security audits/bounties this year more than the projected budget for Yearn. + +## Specification + +The figure above summarizes the flow, responsibilities, and expectations. + +### Overview + +- The academy is governed by all of its stakeholders but not micro-managed. The day to day by the auditors themselves autonomously, in close collaboration with the Yearn core team and supervision of the multisig holders (with input from YFI holders).Gitcoin, and Status may get involved if major decisions are to be made. + +- Start with 1 founding auditor, with the expectation to add 1-2 more at the end of each KERNEL-Curriculum-Shadowing iteration depicted in the figure above (2-4 iterations per year). + +- Communication between auditors and mentees is kept as efficient as possible. No endless tm discussions, but rather a streamlined lines of communication using productivity software. + +- Being a mentee in the yAcademy is trial-by-fire type of situation: mentees walk along the process of auditing a contract, receiving hints and/or assignments, results are shared in a certain format etc.. + +- Mentees join by invitation only, and are unpaid. A few select mentees are selected based from the cohort of ~100 participants in the KERNEL program, but may be invited from the outside as founding auditors, core team, and the community at large see fit. + +- Mentees that show merit begin to receive rewards. If they continue shining, they may be extended an offer to become permanent members with competitive compensation and membership interests ( full membership interests to the first 5 founding members only). + +- Yearn gets a 65% membership interest in the yAcademy in return for bootstrapping funding, sponsorship of KERNELs, and rewards to outstanding shadow auditors. The Yearn core team will be instrumental in the early stages of yAcademy to bring auditors up to speed and share their expertise. The remaining membership interests go 10% to Gitcoin, 10% to Status, and 15% to the first five founding members: 5%, 4%, 3%, 1.5%, and 1.5% to the 1st, 2nd, 3rd, 4th and 5th founding members, respectively. + +### Rationale: + +- Traditional ways of education and collaboration are obsolete. + +- Invitation-only is an efficiency measure, to make sure time and energy is not wasted hand-holding mentees. But anyone who shows interest and meets the basic minimal requirements should get an invitation. + +- Merit-based: auditors that stick around and bring value are rewarded. + +- Synchronous communication is inefficient. + +- Some structure in the collaboration between mentors and mentees is needed to reduce time waste. + +- No time is spent authoring and delivering educational materials: this is a trial-by-fire type of situation, mentees learn by walking along the auditing process of **real** contracts. + +- Membership interests ensure incentive alignments and reduces bootstrapping operational costs to the absolute minimum. By granting membership interests to founding members, yAcademy can stay competitive with the industry standard while not allocating too much money on salaries. At the same time, auditors are incentivized to perform well since yAcademy's growth means the growth of their membership value. + +### Short-term operational outlook (1-2 years): + +We expect a budget of ~150-200k in the first year out of the Multisig Council treasury, covering the funding of 1-2 founding members and including mentee rewards and kernel sponsorship. The second year's budget will be decided when the time comes, but is expected to not exceed the first year's significantly because the founding members may by then have reached a level where they can take on outside contracts for a premium, which then goes back to funding the yAcademy itself. + +yAcademy may go through iterations as we learn and adjust during the first 1-2 years. Current stakeholders all have a track record of being good actor in the ecosystem, and so the happy case outlined in the figure above has a good chance of squeezing out incredible value for the stakeholders and the ecosystem as a whole. + +# Vote + +**Yes**: launch the yAcademy, allocate the budget, hire the first member, and start scouting for the second after the first KERNEL event Jan-Mar 2021. + +**No**: do not launch yAcademy, keep the status quo of Yearn paying auditing firms and/or having the core team take on security and/or rely on white hackers to find bugs for bounties. diff --git a/docs/contributing/governance/yips/yip-54.md b/docs/contributing/governance/yips/yip-54.md new file mode 100644 index 0000000000..9628d58dc5 --- /dev/null +++ b/docs/contributing/governance/yips/yip-54.md @@ -0,0 +1,169 @@ +--- +title: "YIP-54: Formalize Operations Funding" +hide_title: true +sidebar_position: -54 +--- + +# YIP-54: Formalize Operations Funding + +| Metadata | Details | +| --- | --- | +| YIP | 54 | +| Outcome | **Passed** | +| Authors | banteg, lehnberg, lex_node, milkyklim, tracheopteryx | +| Created | 2020-11-12 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-54-formalize-operations-funding/7956) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:yearn/proposal/QmW2ZPfGrcNxVLvT2jm9fmvNwQLD9PrdToQDU8DNPp6Ckg) | +| Vote result | Yes, establish the Operations Fund: 935.4; No, reject the proposal: 1.38 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-54.md) | + +## 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]] laid the groundwork for Yearn operations funding. YIP-41[[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]]. 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]] 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]] + +The fees have then been allocated according to the new vault fee structure of YIP-51[[6]] and the updated Strategist allocation of YIP-52[[7]]. + +The current budget for operations is based off of the allocation in YIP-41[[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]]. + +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. /contributing/governance/yips/yip-36 +2. /contributing/governance/yips/yip-41 +3. https://gov.yearn.fi/t/understanding-decentralization-prioritizing-an-operations-team/ +4. https://gov.yearn.fi/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 diff --git a/docs/contributing/governance/yips/yip-55.md b/docs/contributing/governance/yips/yip-55.md new file mode 100644 index 0000000000..cb0b75cab4 --- /dev/null +++ b/docs/contributing/governance/yips/yip-55.md @@ -0,0 +1,73 @@ +--- +title: "YIP-55: Formalize the YIP Process" +hide_title: true +sidebar_position: -55 +--- + +# YIP-55: Formalize the YIP Process + +| Metadata | Details | +| --- | --- | +| YIP | 55 | +| Outcome | **Passed** | +| Authors | franklin, dudesahn | +| Created | 2020-11-12 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-55-formalize-the-yip-process/7959) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:yearn/proposal/QmZA8zJtLPqQAHi1jMdYX9MdMQ1ZmtRP8zuHccm6HFSzpF) | +| Vote result | Snapshot record recovered; detailed scores are unavailable from the current API. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-55.md) | + +## Summary + +The purpose of this proposal is to standardize the Yearn Improvement Proposal (YIP) introduction, voting, and implementation process that governs the Yearn Finance protocol. + +## Abstract + +This proposal formalizes the process for introducing, voting, and implementing YIPs. Valid proposals are to be discussed for at least 3 days on Yearn’s [governance forum](https://gov.yearn.fi/) 6 and include a forum poll to gauge sentiment. If after three days there is a 25% “For” vote in the forum poll it will then move to formal voting via Snapshot. In order for a vote to pass it must have a majority support (> 50%) after at least five days of voting. Following a successful vote, necessary changes will be implemented by Yearn’s protocol or operations team and signed by the multi-sig, if necessary. Changes to this policy, including quorum requirements or what constitutes a majority vote, can only be enacted by a valid YIP that overwrites this policy. + +## Motivation + +Although there are several informal standards governing the YIP introduction, voting, and implementation process there is no single, clear policy. Recent proposals have not followed the quorum requirement defined in [YIP-12](/contributing/governance/yips/yip-12) 5. Additionally, no YIP or formal policy has been implemented that specifies votes conducted via Snapshot are formal and binding. This YIP would define and formalize the process in order for proposals to be valid and binding, and reduce any confusion in the YIP introduction and voting process. + +## Specification + +**_Introducing the YIP_** + +In order to submit a potential YIP for voting a user must first create a thread for the proposal on the Yearn governance forum (https://gov.yearn.fi). Complete the auto-populated fields that appear when creating a proposal on the forum. A screenshot of these fields are below: + +![](./assets/yip-55/figure1.png) + +Additionally, the thread should include a poll from the governance forum to gauge interest from the wider governance community. After the thread has been on the governance forum for at least 3 days and has received over 25% “For” votes it can proceed to formal voting via Snapshot. This allows the community to suggest potential changes to the proposal before it moves to the formal voting phase on Snapshot. Please do not assign your proposal a YIP number; numbers will be assigned by moderators prior to a vote taking place. + +If a proposal was introduced on the governance forum and achieved at least a 25% “For” from the poll but is not submitted to Snapshot within 30 days, the author of the proposal must re-submit the proposal to the governance forum and restart the process. This ensures that proposals that previously received support from governance still retain support from the community. + +**_Formal Voting Phase_** + +Snapshot is used for formal, binding votes. The user who authored the YIP will also create the Snapshot proposal using this link ([Snapshot](https://snapshot.page/#/yearn) 8). Snapshot requires 1 YFI in a user’s wallet to create a proposal. If the author does not meet this requirement then contact a moderator who will submit the proposal on your behalf. Before creating the Snapshot vote, please wait for a moderator to assign your YIP a number and begin your Snapshot title with it. +A previous version of this proposal called for a minimum of 72 hours for voting, and a 20% quorum requirement. In response to feedback that a quorum requirement might be difficult to quantify and could lead to time-consuming rallying of apathetic voters, we have instead opted to extend the minimum voting window to 120 hours (5 days), with a maximum length of 7 days. This extension period, coupled with an active communication of YIPs via the governance forums and on social media should help ensure that no YIPs slip by, or malicious ones are approved. 5 days is sufficient time for the wider community to participate. + +The block selected for the Snapshot vote should be a block close to the Snapshot submission. In order for a vote to pass it needs to have a majority approval (>50%) by eligible voters. The eligible vote is defined as YFI held in the governance staking contract and the yYFI vault at the time the vote is proposed on Snapshot. If the Snapshot vote does not meet a 50% majority approval then the vote is rejected and no changes will be enacted. Authors of proposals that are rejected may resubmit their proposal, but should include significant changes that address issues that may have prevented the YIP from passing during the initial vote. + +### Scope + +This specification aims to clarify which proposals should move to the YIP stage, how long they should be discussed for, and how long the vote should be open for. By only allowing proposals to move to YIP/voting after several days of discussion, we ensure that everyone’s voice is heard, and proposals should more accurately reflect community consensus. + +Additionally, while some may think that three days is too short to adequately discuss a proposal, this is simply the minimum requirement. We expect most discussions to last for significantly longer than this (as they have in the past), with only a select few well-planned and researched proposals with near unanimous approval moving through so quickly. This proposal also will not stifle the open source protocol improvements that are made daily by dozens of Yearn’s contributors. It only aims to govern those proposals that seek community feedback and ratification as YIPs. + +**_Other Uses for Snapshot_** + +Snapshot may still be used for informal signal voting, including community contests, but its primary purpose will be to conduct formal, binding votes. + +## TL;DR + +1. All proposals must be discussed for at least 3 days with a forum poll before they will be assigned a YIP number and move to Snapshot voting. +1. The Snapshot vote will be binding, and must be open for at least 5 days. At least 50% must vote “For” the proposal for it to pass. +1. Most open-source protocol updates do not require YIPs; this process only governs those changes or proposals that wish to be discussed and enacted as YIPs. + +**For**: Formalize the YIP introduction, voting, and implementation process as specified above + +**Against**: Do not formalize the process. No changes made. + +## Authors + +@franklin @dudesahn diff --git a/docs/contributing/governance/yips/yip-56.md b/docs/contributing/governance/yips/yip-56.md new file mode 100644 index 0000000000..ee373ebb33 --- /dev/null +++ b/docs/contributing/governance/yips/yip-56.md @@ -0,0 +1,130 @@ +--- +title: "YIP-56: BABY:\\ Buyback and Build Yearn" +hide_title: true +sidebar_position: -56 +--- + +# YIP-56: BABY:\ Buyback and Build Yearn + +| Metadata | Details | +| --- | --- | +| YIP | 56 | +| Outcome | **Passed** | +| Authors | banteg, lex-node, lehnberg, milkyklim, tracheopteryx, RyanWatkins | +| Created | 2021-01-16 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-56-buyback-and-build/8929) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:yearn/proposal/Qmb6gBzjvgLMazSrQQGVcjutLNdkVyM2Lh6yckMzdoaHWZ) | +| Vote result | Yes: 790.83; No: 4.47 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-56.md) | + +## Authors + +[@banteg](https://gov.yearn.fi/u/banteg), [@lex_node](https://gov.yearn.fi/u/lex_node), [@lehnberg](https://gov.yearn.fi/u/lehnberg), [@milkyklim](https://gov.yearn.fi/u/milkyklim), [@RyanWatkins](https://gov.yearn.fi/u/ryanwatkins), [@tracheopteryx](https://gov.yearn.fi/u/tracheopteryx) + +## Summary + +Use YFI staking rewards to buy back YFI on the open market. Use bought back YFI for contributor rewards and other Yearn initiatives. Retire the YFI governance vault as it no longer has a use, opening up for it to be replaced in the future with a regular vault. Make it possible to participate in Governance even if one's YFI is being used elsewhere. + +## Abstract + +If adopted, this proposal seeks to: + +1. Replace YFI staking rewards with YFI buybacks, until further notice. +2. Enable YFI that's actively being used in ways that bring benefit to Yearn to participate in Governance. +3. Retire the YFI governance vault (yGov). + +This benefits Yearn as a whole by: + +- Simplifying Treasury design and operation. +- Simplifying YFI token mechanics to equally align interests across Yearn stakeholders. +- Builds up a treasury of YFI that can be deployed through Governance for various uses. + +This benefits YFI holders in particular by: + +- Removing the need to stake YFI to enjoy rewards; in contrast to staking (which only benefits stakers), buybacks should benefit every YFI holder. +- Potentially making gains more tax efficient as capital appreciation through buybacks could be taxed less than dividend income through staking rewards. +- Allowing participation in YFI Governance even whilst the YFI tokens are utilized elsewhere, for example providing liquidity in SushiSwap. + +## Motivation + +### Previous proposals + +This proposal comes on the back of previously made proposals and YIPs: + +- The adoption of YIP-54[[1]](https://gov.yearn.fi/t/yip-56-buyback-and-build/8929#References) formalized an Operations Fund and allowed for discretionary YFI buybacks. +- [@RyanWatkins](https://gov.yearn.fi/u/ryanwatkins) proposed a rethink of Yearn's capital allocation strategy.[[2]](https://gov.yearn.fi/t/yip-56-buyback-and-build/8929#References) Arguing for protocol rewards to be used to buy back YFI rather than to reward YFI stakers, distributing protocol income as dividends would be a suboptimal capital allocation strategy given Yearn's stage of maturity. Instead, the proposal claimed it would be more optimal to use income to drive growth and asset appreciation instead. +- [@dudesahn](https://gov.yearn.fi/u/dudesahn) called for the existing Governance vault and strategy to be replaced with more conventional investment strategy.[[3]](https://gov.yearn.fi/t/yip-56-buyback-and-build/8929#References) Utilizing MakerDAO to mint DAI, this would be used for liquidity mining. One part of the returns would be rewarded to stakers, and the other would be used to fund Yearn's Bug Bounty program and yAcademy. +- Joel Monegro (Placeholder VC) recently published the essay "Stop Burning Tokens -- Buyback And Make Instead"[[4]](https://gov.yearn.fi/t/yip-56-buyback-and-build/8929#References) where he suggested that protocols should buy back and reissue tokens to incentivize growth rather than buying back and burning tokens to return value to token holders. This buyback strategy could be especially well suited for Yearn as the YFI supply is capped at 30,000, meaning that the initial conditions for Yearn's wealth distribution have been set, and no YFI can be further issued to incentivize growth. Such a "Buyback and Make" strategy could allow Yearn to receive the benefits of YFI inflation without any inflation. + +### Rationale + +![](./assets/yip-56/figure1.png) + +_Figure 1. Staking rewards earned over time (USD).[[5]](https://gov.yearn.fi/t/yip-56-buyback-and-build/8929#References)_ + +#### Replace staking rewards with buybacks + +- More suitable at this stage in the lifecycle. It is unconventional to pay out returns in the form of staking rewards this early in a project's lifecycle. Typically this would happen at a stage where funds no longer can be allocated efficiently. +- Better aligns with YFI's use case. YFI is primarily intended to be used for the governance of Yearn. Token mechanics should cater to those who take interest in the protocol and wish to actively participate in its improvement, over those looking to passively collect staking income. +- Potentially more tax-efficient for YFI holders. The gains on YFI staking may be treated as ordinary income. In contrast, a buyback program enables growth in YFI while YFI holders should only be taxed on a capital gains basis for a sale. Results may vary by jurisdiction and this does not constitute tax advice; consult your own tax advisor. +- Recycles YFI that can be spent through Governance. The resulting accumulation of YFI in the Treasury could enable future governance proposals on the use of this YFI for the further benefit of Yearn. + +#### Widen YFI accepted for Governance voting + +- Acknowledge more uses of YFI for the benefit of Yearn. There are other ways than holding YFI in your wallet that can benefit Yearn, for example by providing liquity to a YFI pair on SushiSwap. These YFI are not allowed to vote in Governance today, but they should be. +- Remove capital efficiency and governance trade-offs. Similarly, there shouldn't need to be a trade-off between participating in Governance or utilizing YFI efficiently. + +#### Retire the yGov vault + +- Vault no longer needed. Without staking rewards, there is no need for a yGov staking vault that's tied to Governance. +- Staking returns are aenemic. At the time of this writing, the APY estimate is 0.9% annually [[6]](https://gov.yearn.fi/t/yip-56-buyback-and-build/8929#References). This is not competitive, and may even dissuade YFI holders from participating in governance. In comparison, Binance recently announced up to 4.49% APY for staking YFI.[[7]](https://gov.yearn.fi/t/yip-56-buyback-and-build/8929#References). + +### Future possibilities + +- Introduce contributor retention program, with vesting YFI rewards to create long term skin-in-the-game for existing and new contributors. +- Re-introduce dividends once Yearn has matured and protocol income no longer can be re-invested as efficiently into growth. +- Introduce a conventional vault for YFI, using the v2 vault design. Such a vault would not be related to governance or staking rewards, and would be free to pursue other, to-be-determined strategies. + +## Specification + +### Replace staking rewards with buybacks + +#### Buy back YFI + +- All funds that are used for YFI staking rewards are to be used to buy back YFI. Staking rewards cease until further governance action. +- Buybacks should be handled in a continuous and automated way, and not be discretionary or requiring any sign-offs. +- Care should be taken to avoid creating arbitrage or front-running opportunities. Detailed specification of design is left to the developers implementing. + +#### Use of bought YFI + +- There are no changes in how funds are spent. +- The YFI bought back flows into the Operations Fund established by YIP-54 and can be spent accordingly. +- Example of current spends include: Security audits, Bug bounties, Contributor funding, Grants, Gas reimbursment, Development overhead. See the recently published quarterly financial report[[8]](https://gov.yearn.fi/t/yip-56-buyback-and-build/8929#References) for a detailed breakdown. + +### Widen YFI accepted for Governance voting + +- Link snapshot to use guest-list[[9]](https://gov.yearn.fi/t/yip-56-buyback-and-build/8929#References) to determine which YFI is eligible for voting. +- This functionality is already supported and excludes protocols such as Aave which could be utilized in governance attacks. The list of supported protocols is configurable and is being reviewed continuously, improvements and suggestions can be submitted to the repo. +- Any YFI in the Yearn Treasury / Operations Fund is not eligible to vote. + +### Retire YFI Governance vault + +- Retire the ygov.finance[[10]](https://gov.yearn.fi/t/yip-56-buyback-and-build/8929#References) staking vault and the YFI yVault YFIGovernance strategy that relies on it. + +## Changelog + +- Jan 13: Clarified voting specification to explicitly state that YFI in the treasury cannot be used to vote. [DL] +- Jan 16: Snapshot poll link added. + +## References + +1. [https://gov.yearn.fi/t/yip-54-formalize-operations-funding/](https://gov.yearn.fi/t/yip-54-formalize-operations-funding/) +2. [https://gov.yearn.fi/t/proposal-rethinking-capital-allocation/](https://gov.yearn.fi/t/proposal-rethinking-capital-allocation/) +3. [https://gov.yearn.fi/t/proposal-yfi-governance-vault-yacademy/](https://gov.yearn.fi/t/proposal-yfi-governance-vault-yacademy/) +4. [Stop Burning Tokens -- Buyback and Make Instead --- Placeholder 21](https://www.placeholder.vc/blog/2020/9/17/stop-burning-tokens-buyback-and-make-instead) +5. Data available upon request. +6. [yearn - stats.finance 6](https://stats.finance/yearn) +7. [Binance Staking Launches YFI Staking with Up to 4.49% APY | Binance Support 8](https://www.binance.com/en/support/announcement/de1dfcb0846a422a9d1f50f98ee0e8b8) +8. [yearn-pm/2020Q3-yearn-quarterly-report.pdf at master - iearn-finance/yearn-pm - GitHub 20](https://github.com/iearn-finance/yearn-pm/blob/master/financials/reports/2020Q3-yearn-quarterly-report.pdf) +9. [GitHub - banteg/guest-list 10](https://github.com/banteg/guest-list) +10. [https://ygov.finance/ 13](https://ygov.finance/) diff --git a/docs/contributing/governance/yips/yip-57.md b/docs/contributing/governance/yips/yip-57.md new file mode 100644 index 0000000000..e6cd91c86c --- /dev/null +++ b/docs/contributing/governance/yips/yip-57.md @@ -0,0 +1,179 @@ +--- +title: "YIP-57: Funding Yearn’s Future" +hide_title: true +sidebar_position: -57 +--- + +# YIP-57: Funding Yearn’s Future + +| Metadata | Details | +| --- | --- | +| YIP | 57 | +| Outcome | **Passed** | +| Authors | aleks-blockchaincap, banteg, dudesahn, ekrenzke, lehnberg, ryanwatkins, srs-parafi, tracheopteryx, vooncer, yfi-cent, milkyklim | +| Created | 2021-01-28 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:yearn/proposal/QmX8oYTSkaXSARYZn7RuQzUufW9bVVQtwJ3zxurWrquS9a) | +| Vote result | Yes: 1,670.23; No: 331.03 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-57.md) | + +## Authors + +[@aleks-blockchaincap](https://gov.yearn.fi/u/aleks-blockchaincap), [@banteg](https://gov.yearn.fi/u/banteg), [@dudesahn](https://gov.yearn.fi/u/dudesahn), [@ekrenzke](https://gov.yearn.fi/u/ekrenzke) [@lehnberg](https://gov.yearn.fi/u/lehnberg), [@ryanwatkins](https://gov.yearn.fi/u/ryanwatkins), [@srs-parafi](https://gov.yearn.fi/u/srs-parafi), [@tracheopteryx](https://gov.yearn.fi/u/tracheopteryx), [@vooncer](https://gov.yearn.fi/u/vooncer), [@yfi-cent](https://gov.yearn.fi/u/yfi-cent), [@milkyklim](https://gov.yearn.fi/u/milkyklim) + +## Summary + +Safeguard Yearn's future development. Mint 6,666 YFI. Use ~1/3 of minted YFI to reward key contributors and put ~2/3 of minted YFI in the Treasury under the control of the community through future proposals. + +## Abstract + +If adopted, this proposal seeks to: + +1. Mint 6,666 YFI. +2. Allocate ~1/3 of the minted YFI to key contributors as vesting retention packages. +3. Allocate the remaining ~2/3 to the Treasury, which will be deployed through existing Governance for various uses, for example: + - Future contributor incentives + - Liquidity mining programs + - Staking rewards + - Protocol mergers & talent acquisitions + - Cross-protocol incentives to tighten co-operation across the ecosystem family of projects + +This benefits Yearn as a whole by: + +- Retaining existing contributors +- Incentivizing new contributors +- Capitalizing the Treasury to a scale comparable to industry peers in order to better support growth + +This benefits YFI holders in particular by: + +- Creating a strategic reserve to advance Yearn as one of the world's leading DeFi protocols +- Aligning incentives across stakeholders +- Providing for Yearn's future + +## Motivation + +### Evolve the fair launch + +- Yearn's launch was exceptional at creating a decentralized and engaged community, but it did not provide adequate incentives to retain existing and future contributors on an ongoing basis, nor did it provide the protocol with a war chest to fund future activities. +- Viewing the fair launch as a living concept rather than a single event, this proposal seeks to remedy this +- It does so with an emphasis on funding the Treasury for the benefit of all active protocol participants over the existing contributors at a ratio of rougly 2:1 in terms of allocated YFI + +### Remove Yearn's Competitive Disadvantage + +_Excerpt from [[1]](https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319#References):_ + +> Team token allocations\ +> Projects such as Uniswap, Aave, Synthetix, Compound, 1inch, Curve, and Balancer hold anywhere from $300 million-$2.13 billion in tokens aside for [contributors], with the average being between $500-600 million. This is generally 20-30% of the total token allocation. Newer projects such as SushiSwap, Badger, CREAM, Harvest, and Cover vary more between teams, but allocate between 10-25% of token supply to their teams and early contributors. +> +> Treasury/operations token allocations\ +> While the numbers vary here more widely, most of the major projects still have significant token amounts set aside for operations. Uniswap is on the high end with $4 billion, Aave, Synthetix, Balancer, and 1inch all have between $200-$570 million, and likely other projects without any tokens set aside for operations have ample funding from investors (Curve and Compound). + +### Why mint? + +_Excerpt from [[2]](https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319#References):_ + +> [The decision] comes down to the market for talent and the opportunity cost for YFI contributors. We looked at other successful DeFi projects to see what the market says top-tier talent is worth: +> +> [![](./assets/yip-57/figure1.png) +> +> The UNI team has 21.3% of tokens (which includes tokens for future employees) and UNI holders collectively control a treasury with 43% of the supply. At current market prices of $9.2 (which reflects a fully diluted valuation of $9.2B), each bucket has several billion dollars worth of UNI -- team ~$2B and treasury ~$4B -- giving the Uniswap team significant fire power for hiring and enabling a lot of future growth spend from the treasury (both buckets are subject to 4-year vesting). +> +> The COMP team has 26% of tokens and a smaller but still significant treasury with 7.8%. At the current market price of $226 per COMP, the team allocation is ~$580M and treasury ~$176M. +> +> You can quickly see that a treasury of $500K and a team allocation of 0% is way off market. The reality is that for Yearn to allocate even 5% (which would be well below the examples above), at current market prices (~$37K) Yearn would need to either earn $56M or mint $56M worth of YFI. Given that a conservative figure is presently an order of magnitude higher than annualized YFI holder income, the only reasonable way to bridge the gap in the near-term is through a mint. + +### Why 6,666 YFI? + +- 6,666 is 22% of the current total supply of 30,000 YFI. +- After gathering feedback, modeling a number of mint scenarios and various retention package estimates, a ~20% increase was determined to be the minimum viable amount to provide competitive retention plan, using only roughly 1/3 of the total mint amount. +- 22% is in line with yearn's peers, for example Aave minted 23% when they migrated from LEND to AAVE.[[3]](https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319#References) + +### Improve Talent Retention & Acquisition + +- Contributors have recently been poached by other projects. +- With the current operational treasury size of $500,000 and 0% token allocation to the team, Yearn struggles to compete with the compensation packages offered in the current market. These are becoming increasingly competitive. + +### BABY is a great first step, but not enough on its own + +Buyback and Build Yearn (BABY)[[4]](https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319#References) establishes a moving target for YFI buybacks in USD terms. As Yearn earns more revenue in USD terms, it's possible that the YFI price in USD adjusts upwards to reflect those increased earnings. So it would be like trying to catch your own tail. Modeling shows that using 50% of Treasury earnings for buybacks would purchase 100-300 YFI per year (see sensitivities below). Even with the assumption that V2 vaults end up being very successful, earnings will likely not be enough to accumulate a sufficient amount of YFI for the Treasury. + +Below are two different BABY scenarios. One sensitizing aggregate yields on V2 vaults and their effect on YFI buybacks. The other sensitizing operating expenses and their effect on YFI buybacks. The other with 100% of net income. + +_Aggregate Yields Sensitivity_\ +![](./assets/yip-57/figure2.png) + +![](./assets/yip-57/figure3.png) + +_Operating Expenses Sensitivity_\ +![](./assets/yip-57/figure4.png) + +![](./assets/yip-57/figure5.png) + +## Previous Proposals + +There have been a number of previous proposals relating to the YFI supply.[[5]](https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319#References) + +| Title | Comment | Outcome | Ref. | +| --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------- | +| Proposal 0: YFI Supply | For: Allow future YFI to be minted. This will be superseded by a new proposal to discuss (and then vote) on weekly YFI allocations. | Passed | [[6]](https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319#References) | +| Proposal 5: Reducing YFI weekly supply | At the time of this proposal a weekly emission was planned, this proposal sought to introduce a weekly halving over 25 weeks | Did not pass | [[7]](https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319#References) | +| Proposal 8: Halving YFI weekly supply the same as bitcoin | Another attempt to introduce a halving | Majority for, but did not meet quorum | [[8]](https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319#References) | +| YIP 30: YFI Inflation Schedule | FOR : Implement an inflation schedule of 20,000 YFI over the next 8 years, with 12,802 distributed in the first 3 years, ending with a trailing tail of 1% inflation. | Did not pass | [[9]](https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319#References) | +| Burn YFI minting ability permanently | Signaling poll to burn the minting keys after on-chain governance is deployed | Majority for, but was not followed up with a binding proposal or on-chain governance | [[10]](https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319#References) | + +## Specification + +## 1\. Mint 6666 YFI + +A proof of concept for minting has been produced [[11]](https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319#References). If accepted, Yearn Governance would need to do these things: + +1. Deploy the vesting contract (deployed at [`0x0C97B9E8bdEc88fe683DD11607f66F351cEc6110` 18](https://etherscan.io/address/0x0c97b9e8bdec88fe683dd11607f66f351cec6110#code)) +2. Call `TimelockGovernance.setTargetGovernance(YearnPact)` +3. Wait 3 days +4. Call `TimelockGovernance.updateTargetGovernance()` +5. Call `YearnPact.brrr()`, which will mint and then revert the YFI token governance back to `TimelockGovernance` immediately thereafter. + +## 2\. Allocate ~1/3rd to vested retention packages + +- Out of the 6,666 minted YFI, allocate roughly 1/3rd (5% margin on either side) to retention packages in order to provide the sufficient face melt required for effective contributor stickiness. +- All YFI allocated to retention packages will be subject to vesting. +- Retention package details, including eligibility, amounts, and overall terms, will be prepared and presented by a *Compensation Working Group:* + - Working group members are recommended by the Operations team and should include a variety of project contributors. + - The Multi-sig approves the proposed members of the working group. + - The working group can gather feedback and input from existing community groups or form new ones as required. +- Once appointed, the working group's tasks will be to: + 1. Finalize compensation packages + 2. Finalize vesting terms + 3. Identify eligible recipients + 4. Prepare a Compensation plan for the Multi-sig to review +- After review, the Multi-sig approves the Compensation plan, or requests changes. +- Separately, the working group is also tasked with formalizing the qualification process and retention packages for future contributors. Funding for this comes from the portion allocated to Treasury (see below). + +## 3\. Allocate ~2/3rds to Treasury + +- Allocate the remainder of the minted YFI, i.e. roughly 2/3rds (5% margin on either side) to Treasury. +- This allocation flows into the Operations Fund established by YIP-54 [[12]](https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319#References) and can be spent accordingly, which includes through ad-hoc Governance proposals brought forward as YIPs. +- The Operations Fund remains under the supervision of the Multi-sig. +- As YIP-56 [[4]](https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319#References) makes clear, YFI in the Treasury, including those in the Operations Fund, cannot be used to vote. + +## Changelog + +- Jan 28: Clarified in the Specification that YFI in the treasury cannot be used to vote. +- Jan 28: Clarified in the Specification that all YFI retention packages will be subject to vesting. +- Jan 28: Changed title to YIP-57 and added binding snapshot vote link. + +## References + +1. [https://gov.yearn.fi/t/token-allocations-at-peer-projects](https://gov.yearn.fi/t/token-allocations-at-peer-projects) +2. [Keeping Yearn Great - Funds, Incentives & Rewards - #19 by aleks-blockchaincap 14](https://gov.yearn.fi/t/keeping-yearn-great-funds-incentives-rewards/9167/19) +3. [Flashpaper - Aavenomics 1](https://docs.aave.com/aavenomics/flashpaper#aave-token-migration) +4. [YIP-56: Buyback and Build 18](https://gov.yearn.fi/t/yip-56-buyback-and-build/8929) +5. h/t to [Nick Almond 2](https://twitter.com/DrNickA) for his tweetstorm that informed this section: [https://twitter.com/DrNickA/status/1350792604754075649 12](https://twitter.com/DrNickA/status/1350792604754075649) +6. [https://gov.yearn.fi/t/proposal-0-yfi-supply](https://gov.yearn.fi/t/proposal-0-yfi-supply) +7. [https://gov.yearn.fi/t/proposal-5-reducing-yfi-weekly-supply](https://gov.yearn.fi/t/proposal-5-reducing-yfi-weekly-supply) +8. [https://gov.yearn.fi/t/proposal-8-halving-yfi-weekly-supply-the-same-as-bitcoin/](https://gov.yearn.fi/t/proposal-8-halving-yfi-weekly-supply-the-same-as-bitcoin/) +9. [https://gov.yearn.fi/t/yip-30-yfi-inflation-schedule](https://gov.yearn.fi/t/yip-30-yfi-inflation-schedule) +10. [https://gov.yearn.fi/t/burn-yfi-minting-ability-permanently](https://gov.yearn.fi/t/burn-yfi-minting-ability-permanently) +11. [GitHub - banteg/yfi-pact: our pact with the devil 8](https://github.com/banteg/yfi-pact) +12. [https://gov.yearn.fi/t/yip-54-formalize-operations-funding/](https://gov.yearn.fi/t/yip-54-formalize-operations-funding/) +13. [YIP-55: Formalize the YIP Process 18](https://gov.yearn.fi/t/yip-55-formalize-the-yip-process/7959) diff --git a/docs/contributing/governance/yips/yip-59.md b/docs/contributing/governance/yips/yip-59.md new file mode 100644 index 0000000000..aabbd8d52e --- /dev/null +++ b/docs/contributing/governance/yips/yip-59.md @@ -0,0 +1,57 @@ +--- +title: "YIP-59: Temporarily extend Multisig empowerment" +hide_title: true +sidebar_position: -59 +--- + +# YIP-59: Temporarily extend Multisig empowerment + +| Metadata | Details | +| --- | --- | +| YIP | 59 | +| Outcome | **Passed** | +| Authors | lehnberg | +| Created | 2021-02-18 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-59-temporarily-extend-multisig-empowerment/9746) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:yearn/proposal/QmdRCXH6BQpNcucoZqAtS5hQKjckE2428qiZoWjxmJXbs3) | +| Vote result | Yes: 379.59; No: 0 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-59.md) | + +## Author + +[@lehnberg](https://gov.yearn.fi/u/lehnberg) + +## Summary + +Extend Multi-sig powers by another three months until end of May 2021 whilst an in-progress replacement proposal matures further. + +## Abstract + +If adopted, this proposal seeks to extend the existing Multisig empowerment as was established by YIP-41[[1]](https://gov.yearn.fi/t/yip-59-temporarily-extend-multisig-empowerment/9746#References) for another three months until May 24 2021. This is done in order for a currently in-progress governance architecture proposal to mature further, and ultimately have longer time to be discussed in the community, prior to it being proposed. + +## Rationale + +The existing mandate expires on February 24 2021. As is stated in YIP-41, the Multisig was empowered for rapid decision making until the protocol transitioned to a "multi-DAO structure". A plan to decentralize power away from the Multisig, led by [@tracheopteryx](https://gov.yearn.fi/u/tracheopteryx), is in-progress of being finalized. It has been delayed due to recent Governance activities. + +The three month extension would be used to introduce the proposal to the wider community, iterate on it further to incorporate feedback, without being rushed by the somewhat arbitrary deadline that the mandate expiration sets. + +### Alternatives considered + +#### Rush the new governance proposal + +One alternative would have been to instead publish the current draft of the proposal as is, and hurry to have it adopted by YFI voters before the existing empowerment expires on February 24. The outcome of this process is uncertain. It is likely to result in a less mature YIP being adopted, if one is adopted at all. + +#### Let mandate expire, replace with some alternative + +Another alternative would be to let the Multisig mandate expire, and be replaced by some other Governance alternative. It is unlikely that a feasible alternative solution could be devised, proposed, and finalized in the little time that remains before expiry. + +## Specification + +- Extend the current Multisig authority and remit as was granted by YIP-41 for an additional three months, expiring on May 24 2021. +- Do not change or modify the existing mandate in any way. +- Any changes made by YIPs adopted after YIP-41 still apply. +- Further changes to the mandate can be made through Yearn's Governance process. + +## References + +1. /contributing/governance/yips/yip-41 diff --git a/docs/contributing/governance/yips/yip-60.md b/docs/contributing/governance/yips/yip-60.md new file mode 100644 index 0000000000..5096cb022a --- /dev/null +++ b/docs/contributing/governance/yips/yip-60.md @@ -0,0 +1,58 @@ +--- +title: "YIP-60: Airdrops to Yearn Vaults" +hide_title: true +sidebar_position: -60 +--- + +# YIP-60: Airdrops to Yearn Vaults + +| Metadata | Details | +| --- | --- | +| YIP | 60 | +| Outcome | **Passed** | +| Authors | lehnberg | +| Created | 2021-04-07 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-60-airdrops-to-yearn-vaults/10356) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:ybaby.eth/proposal/QmNqAqRKMFcoRjaRYAKCVETij6sjJ4S1293kbpYDMVvcjB) | +| Vote result | Yes, support: 1,046.98; No, oppose: 0.05 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-60.md) | + +## Authors + +[@lehnberg](https://gov.yearn.fi/u/lehnberg) + +## Summary + +Formalize how airdrops to Yearn vaults are handled: Tokens that are worth the effort, are sustainably claimed and donated to the affected vault as its `want` token in order to boost the returns of vault depositors. + +This, in order to be aligned with what is the fundamental proposition for end users and third party integrators alike: Having a gas efficient, frictionless, set-it-and-forget-it way of earning compounding returns through Yearn's vaults. + +## Background + +The Ellipsis airdrop[[0]](https://gov.yearn.fi/t/yip-60-airdrops-to-yearn-vaults/10356#References) and the resulting eligibility for the yveCRV to receive tokens over the course of a year has resulted in Yearn governance discussions[[1]](https://gov.yearn.fi/t/yip-60-airdrops-to-yearn-vaults/10356#References) about how this should be handled. + +While this is the first airdrop of its kind, it is unlikely to be the last. It would be beneficial to agree on a general approach that outlines how these situations are to be handled. + +### Airdrop factors + +- Cost to claim. Claiming airdrops can involve manual work, sometimes on different chains than Ethereum, for uncertain rewards. +- Time periods to claim. Claiming may at times be done in one go, and other times over multiple times, sometimes lasting as long as a year or more. +- Relationships and image. Acting in bad faith, i.e. "claiming & dumping" can lead to exclusion from future airdrops, bad publicity, and being labeled as an adversary rather than a partner. +- Tokenomics. Depending on the protocol design, there can be lucrative farming opportunities or heavy penalties to incentivize good actors in the airdrop protocol. Considering these can lead to better rewards. + +## Motivation + +The rationale for this proposal is motivated by the following objectives: + +- Do right by the vault's depositors. In principle, airdrops belong to whoever holds the private key. Practically, many vault depositors expect to benefit from airdrop proceeds. Yearn should do right by them, which in turn does good for Yearn's reputation and attracts more users of its products. +- Set expectations straight. At the moment, it is unclear what will happen in airdrop situations. Vault depositors should have clarity about what they should expect to happen. +- Do not overload Yearn's resources. Yearn's vaults are different, and airdrops are different. Subjective judgement about which airdrop to claim, and what the best way for realising it, is unavoidably going to be required. Airdrops should not end up becoming an effective Denial-of-Service attack on Yearn teams and distract them from delivering on existing roadmaps and priorities. +- Keep it simple. Yearn is meant to make DeFi simple, and should try to live up to that. Depositing a token into a Yearn vault shouldn't come with expectations of potentially having to deal with the handling of other unrelated tokens, possibly even accessible from other blockchains. +- Keep it composable. Yearn vaults are being used by end users, defi protocols, businesses, and other intelligent life such as smart contracts and robots. They should benefit from airdrops automatically, without no additional effort, letting rewards compound. This avoids unexpected behaviour and edge cases, making Yearn's vaults easier to integrate with. + +## Specification + +1. A decision is made whether the effort to claim a specific airdrop is worth while given other current priorities. +1. Specific claiming, farming, and token exchange strategies are determined on a case by case basis, depending on prevailing airdrop terms and market conditions, with the objective to maximize risk-adjusted returns. +1. Returns are used to boost the returns of the affected vault for the benefit of its current depositors. This is done by converting the returns into `want` tokens, and donating them to the vault in question, boosting the returns of each current tokenholder as a result. +1. Decisions on the details of the above steps are left to be taken by the Operations, Engineering, and Finance teams with the instruction to meet these instructions as best as possible. Decisions can be overruled as usual through the existing Multi-sig and Governance processes. Both groups should be kept up to date on airdrop claims as they progress. diff --git a/docs/contributing/governance/yips/yip-61.md b/docs/contributing/governance/yips/yip-61.md new file mode 100644 index 0000000000..563ecaee27 --- /dev/null +++ b/docs/contributing/governance/yips/yip-61.md @@ -0,0 +1,249 @@ +--- +title: "YIP-61: Governance 2.0" +hide_title: true +sidebar_position: -61 +--- + +# YIP-61: Governance 2.0 + +| Metadata | Details | +| --- | --- | +| YIP | 61 | +| Outcome | **Passed** | +| Authors | tracheopteryx, lexnode | +| Created | 2021-04-20 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#binding-snapshot-vote-28) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:ybaby.eth/proposal/QmSMyYeKrRpnA7Xn56o2NtbCUzxmhzCupL7LxMA1reXxq4) | +| Vote result | Yes, I vote for this proposal: 683.09; No, I vote against this proposal: 0.2 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-61.md) | + +## Authors + +[@tracheopteryx](https://gov.yearn.fi/u/tracheopteryx), [@lex_node](https://gov.yearn.fi/u/lex_node) + +## Summary + +A proposal to establish the future of yearn's operational governance by extending certain of the Multisig's[[1]](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#References) powers from YIP-41 (Temporarily Empower Multisig)[[2]](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#References) on a newly clarified basis in coordination with newly empowered autonomous contributor teams ('yTeams'). + +## Status + +This proposal passed on April 25, 2021 at 7:00 UTC with 99.97% voting for.\ +See the vote on [Snapshot 80](https://snapshot.org/#/ybaby.eth/proposal/QmSMyYeKrRpnA7Xn56o2NtbCUzxmhzCupL7LxMA1reXxq4).\ +Learn about our voting rules in YIP-55[[3]](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#References). + +## Abstract + +if adopted, this proposal seeks to: + +- ratify continued delegation by YFI holders to the Multisig of certain powers first approved in YIP-41 (Temporarily Empower Multisig), together with certain modifications and clarifications to the nature and scope of such powers as set forth below; +- delegate certain powers to a set of yearn contributor teams that have emerged organically from the community ('yTeams'), as appropriate for each yTeam based on its objective ('yGuard,' 'yBrain,' 'yDev,' 'yPeople,' 'yBudget,' 'yFarm,' 'yTx,' and 'yOps'); +- update and clarify YFI holders' role in governance and the types of proposals available. + +## Motivation + +In August 2020, YIP-41 (Temporarily Empower Multisig) was approved by YFI holders to: + +- temporarily empower yearn Multisig members "to make personnel & budgetary decisions" for a six-month period; and +- task the Multisig with "facilitating the creation and transition to a multi-DAO structure". + +Since YIP-41 was approved, the Multisig has fostered a 'multi-DAO structure' by encouraging the development of autonomous 'yTeams' consisting of volunteer and paid specialist contributors. + +The six-month Multisig empowerment period was extended for three-months via YIP-59[[4]](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#References) on February 24th, 2021 and will expire on May 24th, 2021. Thus, before the expiration date, YFI holders should approve a new proposal to establish the future direction of yearn governance. This YIP constitutes such a proposal and, if approved, would supersede YIP-41 and ratify yearn's current *de facto* operational governance practices. + +## Specification + +### Governance 2.0 Overview + +We present here the first phase of a progressive decentralization and improvement to yearn's governance. This proposal seeks to update the decision-making structures within yearn, not their software implementation. It is our intent to offer implementation proposals in the future once this model is validated and the appropriate technologies become available for use. + +[![Gov 2.0 v1](./assets/yip-61/figure1.png) + +Yearn is a network of independent doers united by a shared vision. Our bias is on action over bureaucracy. We move fast with great freedom and agency. This is our way. Towards this end, we have pioneered a method of governance we call 'constrained delegation' whereby YFI holders delegate their governance powers to autonomous groups like the Multisig and yTeams and thus empower them to be creative. Gov 2.0 takes that a step farther by making governance powers discrete and transferable objects under the direct control of YFI holders. + +### YFI Holders + +Gov 2.0 connects YFI holders to yearn's products and teams through a more direct, aligned, and transparent mechanism --- giving them direct control over who gets to make decisions. Rather than being asked to make specific, operational decisions, YFI holders will conduct how power flows within yearn, wielding granular and clear control over every aspect of what yearn does. + +YFI holders will now be empowered to take three kinds of actions: + +| Proposal | Description | Hypothetical Examples | +| -------------------------------- | ----------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Yearn Improvement Proposal (YIP) | A proposal to execute on any power delegated to YFI holders or outside the scope of enumerated powers | Ratify a new yTeam and assign it power; Burn the YFI minting keys; Do anything outside the scope of proscribed powers, like change yearn's name; remove a yOps signer; mint a new power | +| Yearn Delegation Proposal (YDP) | A proposal to change where any discrete decision-making power is delegated | Move the 'Pay Team' power from yPeople to a new yTeam; undelegate the 'Set Budgets' power from underperforming yBudget team and delegate to YFI holders until a new solution can be found | +| Yearn Signaling Proposal (YSP) | A non-binding proposal to signal community feelings or intent on any issue | A suggestion to change membership in a yTeam; A desire for a new kind of vault or product | + +### yTeams + +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. + +Each yTeam will be organized around a group of signers. The signers for each yTeam should be nominated by rough social consensus of that yTeam and be reasonably acceptable to the Ops yTeam ('yOps'). yTeam signers are empowered to choose their own consensus mechanism for decision-making and curate their own discussion and feedback groups on telegram. Decisions issued by yTeams will be executed on-chain by the Multisig until a more decentralized system is approved for implementation. + +It is important to note that yTeams are not the only teams that can work on the yearn ecosystem. Indeed, each of the current yTeams was formed permissionlessly, emerging on an ad hoc basis as enthusiasts grouped around a workstream. This proposal is merely recognizing that a number of such informal groups have achieved sufficient consistency of membership, quality of results and autonomy of internal governance to deserve a constrained delegation of powers from YFI holders. More informal contributors should continue working, alone or in groups, on yearn and seeking to have their contributions ratified by YFI holders on a more granular, post hoc basis; these informal groups may also eventually coalesce into additional yTeams. + +See below under "Constrained Delegation" for additional thinking on the governance philosophy underlying yTeams. + +| yTeam | Objective | Membership Pool | +| ------- | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| yGuard | Protect the vaults | YFI Protocol Dev, YFI Strategists, YFI Mechanics, YFI Secret Admirers | +| yBrain | Manage the strats | YFI Strategists | +| yDev | Manage the protocol | YFI Protocol Dev | +| yPeople | Curate the team | YFI Compensation Working Group, YFI Advisors | +| yBudget | Spend money well | YFI Finances, YFI Advisors | +| yFarm | Grow the treasury | YFI Secret Admirers, YFI Secret Entrance | +| yTx | Write transactions | YFI Doers | +| yOps | Coordinate contributors | YFI Ops (initial signers: [@banteg](https://gov.yearn.fi/u/banteg), [@lehnberg](https://gov.yearn.fi/u/lehnberg), [@milkyklim](https://gov.yearn.fi/u/milkyklim), [@tracheopteryx](https://gov.yearn.fi/u/tracheopteryx)) | + +### The Multisig + +In effect, the Multisig is a special yTeam ('yChad') utilizing a Gnosis Safe multisig[[5]](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#References) for on-chain execution. While most of the decision-making powers previously held by the Multisig move to yTeams, the execution power stays with the Multisig pending future proposals. The Multisig is tasked with executing the decisions issued by yTeams within their domains of action and with 'Veto Power' should they feel a decision needs further review. As we iterate on governance in the future, YFI holders can decide to delegate this 'Veto Power' to external arbitration or other forms of secure adjudication. + +## Decision-Making Powers + +| Power | Delegation | Description | +| ------------------------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | +| Manage Powers | YFI Holders | YFI holders can vote to create, assign, or revoke discrete powers to or from yTeams. | +| Change YFI Token Contract | YFI Holders | Any interaction with the YFI token contract, such as to mint YFI or burn the minting keys, remains under the control of YFI holders. | +| Set Fees | YFI Holders | Set the standard fee structures in the Yearn Protocol | +| Change Multisig Signers | YFI Holders | As the Multisig will continue to hold critical powers over the near term, only YFI holders can vote to change its signers | +| Ratify yTeams | YFI Holders | Formally ratify or deratify yTeams to control which yTeams can hold delegated powers | +| Change yOps Signers | YFI Holders | As yOps has the power to change signers of other yTeams, this is a special power to change the signers of yOps | +| Spend Treasury Funds | YFI Holders | Spend funds from the treasury | +| YIP Power | YFI Holders | YFI Holders have the power to propose a YIP on anything not already delegated | +| Execution Power | Multisig | The power to execute decisions made by YFI holders and yTeams on-chain | +| Veto Power | Multisig | This power allows the Multisig to veto any decision and ideally should not be needed | +| Transitionary Power | Multisig | A temporary power enabling the Multisig to operate under the mandate of YIP-41 until the set of decision-making powers covers all needed transactions | +| Emergency Powers | yGuard | Immediately intervene in case of attack or bug to shutdown or rollback strategies or vaults | +| Manage Strategies | yBrain | Activate, deactivate, tune, and maintain strategies | +| Define Yearn Protocol | yDev | Decide what code is considered part of yearn and what isn't | +| Manage Protocol | yDev | Maintain and improve the Yearn Protocol | +| Add Strategies | yDev | Add new strategies to vaults | +| Delegate Transactions | yTx | Create delegated transactions for the multisig to sign and execute | +| Pay Team | yPeople | Create, deploy, modify, or terminate Yearn compensation packages | +| Set Budgets | yBudget | Create budgets for coordinape, grants, hiring, operations, or other workstreams | +| Farm Treasury | yFarm | Farm with the treasury and make decisions on airdrops | +| Ratify yTeam Signers | yOps | Formally approve or remove signers for each yTeam | + +## Implementation + +This proposal requires no additional implementation beyond the adoption of new processes utilizing the platforms currently active within yearn. + +The nested consensus mechanisms needed for yTeams can be implemented in a number of ways today, but after much discussion and feedback from the core team and yearn community the authors decided to limit this proposal to the social layer. The detailed description of yearn governance provided in the proposal is intended to guide the research and development of new governance platforms custom tailored to yearn's specific needs to be developed and proposed for our use in the near future. + +Our friends at Gnosis[[5]](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#References), Colony[[6]](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#References), LEGO Dao[[7]](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#References), Snapshot[[8]](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#References), Tally[[9]](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#References), finance.vote[[10]](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#References), and Orca Protocol[[11]](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#References) have offered to help us build whatever we need to implement our vision of governance. + +## Examples + +To help clarify how the changes proposed in this specification will function in the wild, here are some hypothetical examples of decision-making in Governance 2.0. + +### Replacing a yOps Signer + +Banteg goes rogue, starts shilling XRP hard and is absent from important Yearn work. Someone creates a YIP to replace him from yOps with Justin Sun (who has become a benevolent, humble, and trusted yearn contributor). The vote passes, banteg is removed as a signer and Justin is added. + +### Creating a new yTeam + +It turns out pension funds are yearn's golden opportunity. A group of contributors on the dev team have been working on a whole new product line. Someone creates a YIP to ratify this group as a yTeam ('yPension') and assign them management power over the new set of contracts for the pension product. The vote fails to pass, the new pension contracts remain under the control of yDev where they were made, and the pension group can still work but without specific power. + +### Deciding on an Airdrop + +Spurn Finance, an unauthorized fork of yearn on Iota launches and sends a large airdrop of SPYFI direct to the Multisig. They say in their docs it's supposed to "reward the yearn community." The yFarm team has the 'Farm Treasury' power which includes deciding on what to do with airdrops. They decide to give 50% of the tokens to Andre and the rest to a Coordinape[[12]](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#References) contributor circle for distribution. + +This causes conflict in the community. Some members feel the airdrop should have been given to all YFI holders proportional to their holdings. Other think they should have been given to vault users proportional to TVL. Others think all should have gone to the community contributors not just half. + +yFarm decides to stick to their belief and they send their decision to yTx. yTx creates a transaction to implement yFarm's decision and delegates it to the Multisig. During this time there is much discussion on twitter, telegram, discord, and the forum. People ask the Multisig to veto it to give them time. Since there is so much turmoil, the Multisig does decide to veto and give the community more time to think about other options. yFarm is fine with that, they can always resubmit again later. + +Someone makes a YDP to remove the 'Farm Treasury' power from yFarm but it fails since they were being super reasonable. A number of alternate allocations are suggested. Andre comes out and says thank you, but he doesn't want the airdrop. Someone puts forth a new split that goes to YFI holders, vault users, and a Coordinape circle that they agree to implement. yFarm likes it, but changes the proportions a bit, then they puts through the tx which the Multisig does not veto and it is executed. + +### Redelegating Veto Power + +Kitten Court (an unauthorized fork of Kleros Court on Dogecoin) comes out with a new product, the Veto Master 9000, it's an AGI that can decide on vetoes better than humans. Someone makes a YDP to move 'Veto Power' from the Multisig to the Veto Master 9000. It fails because this is obviously a skem. + +### Yearn Proposals & Delegated Powers + +Vitalik joins the dev team and people are so pumped they want him on yDev immediately. Someone writes a proposal to add Vitalik as a yDev signer and wants it to be a YIP. But YFI holders don't have that power, so the proposal can only be a YSP (Yearn Signaling Proposal). yOps has the 'Ratify yTeam Members' power, so it's up to them to decide. The YSP ends with 95% of voters signaling yes. yOps thinks this is meaningful, so they agree that if Vitalik wants the job, they will ratify him as a signer. He agrees. We all party in a space hotel. + +### Adding a Product to the Yearn Protocol + +Andre writes a new perpetual insurance product. This can be part of vaults and a stand-alone product. It's passed audits and looks great. Another community contributor, VALISfan1981, has also written a perpetual insurance product and she has deployed it already, unaudited on her own site which allows people to deposit into vaults with her insurance system. She wants yearn to adopt her product as part of the Yearn protocol. + +yDev has the 'Define Yearn Protocol' power. They review both options, discuss with the community, and decide to add Andre's code as part of yearn and use dev team resources to develop it further. VALISfan1981 can continue to offer their alternative product, of course, but it will be offered as an outside service. + +### Deciding Something Outside of Defined Powers + +Dark Ghosty decides that the Spix's Macaw[[13]](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#References) is the official bird of yearn and is telling everyone this on telegram. He's really pushing hard for it. Deciding on our official bird is not a defined power. Anyone can say that a bird is yearn's official bird, but that doesn't mean anything. But Ghosty loves that bird, so he does a proposal to adopt the Spix's Macaw as the official bird of yearn. The forum poll looks good, so he goes ahead and does a YIP, and that passes. The Spix's Macaw becomes the official bird of yearn. + +### Aggressive Attempt to Fund a New Project + +The Coordinape team wants to ask yearn for a grant to fund development. They can ask yOps since they have a set amount of money for stuff like this that they get from the treasury as determined by yBudget via their 'Set Budgets' power. yOps says no, so Coordinape decides to ask yBudget directly to allocate them some recurring funds, but they say no too. Then they go to yDev and ask to be added to the Yearn Protocol with the 'Define Yearn Protocol' power so the dev team will help them build their product, but they are too busy. + +Next option, they do a proposal to ask YFI holders to fund them. They get to the YIP but it fails. The Coordinape team is pissed. They work their asses off and have an amazing product. So they craft a devious plan... + +First they do a new proposal to ratify themselves as the yApe yTeam. The YIP passes! yOps talks to the new yApe team and together they decide who the signers should be, and yOps formalizes them with their 'Ratify yTeam Members' power. + +yApe is a yTeam but they have no power. They do a YDP to take the 'Set Budget' power from yBudget and spend thousands of dollars on a marketing campaign to convince YFI holders. But YFI holders don't buy it, they can tell something is off, and the YDP fails. yApe does a new YIP to create a new power 'Fund Coordinape' and this fails too. The community is not happy with Coordinape, so someone does a YIP to deratify their yTeam, it passes. + +After some soul searching, the team recognizes their mistake, makes an apology, and yOps decides to give them a grant. It's enough to make a sick product which changes the world. + +## Rationale + +### Constrained Delegation + +The authors of this YIP embrace the principles of creative freedom for yearn contributors set forth in what has come to be known as "the yearn manifesto"[[14]](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#References). Anyone with the requisite talent, ideas and willingness to work should be able to contribute to yearn, even if they do not hold YFI, and even if YFI holders do not authorize them to do so. Thus, we see the merits of what may be called a 'core development' philosophy of technology governance, and do not believe that yTeam members should need to be elected by or otherwise formally *accountable* to YFI holders. On the other hand, we also recognize the 'tyranny of structurelessness' that can ensue when anarchist principles of self-organization are pushed to the extreme, as well as the omnipresent threat that core-style governance can become captured through its dependence on the patronage of for-profit corporations and their proxies ('associations,' 'foundations,' 'consortiums,' etc.) + +Similarly, we recognize both the potential benefits and perils of bottom-up, DAO-style governance. YFI was disseminated as 'the governance token of yearn'. Although the meaning, scope and mechanisms of such governance were (perhaps deliberately) under-specified at the time of YFI's creation, certain emergent cultural values are fairly clear: YFI holders expect that they have a vital value-creation role in the yearn community even if they do not have technical skills and are not 'core developers' or other highly active creative participants in yearn. Furthermore, YFI holders expect that yearn contributors do not work *contrary* to YFI holders' interests. For example, it would be unacceptable for the Multisig to drain the entire treasury to give themselves unearned or excessive bonuses. But, just as creative autonomy can degenerate into the tyranny of structurelessness, so, too, DAO governance can deteriorate into "the tyranny of the masses"---bikeshedding, needless bureaucracy and populist political haggling are all apt to emerge when decision-making is driven by those who view crowdsourced governance as an end-in-itself. + +We can see the tension between creative freedom and group consensus play out at the practical level in a kind of Catch-22 faced by creators. If all decision-making authority is vested in governance token holders, then, in theory, all uses of community resources should be pre-approved by token holder voting. So, for example, if a developer needs a budget to create a new product, the developer would first need to write up a spec & get it and the budget approved by YFI holders. However, this is far from ideal, because developing such a spec itself requires effort and resources, and the approved spec may unnecessarily constrain freedom, requiring the developer to go back to governance to get re-approval for deviations from the spec that are inspired during the development process. On the other hand, a developer could self-fund the product and submit it for ratification of YFI holders and a financial reward after it is done, but this is also suboptimal: it essentially creates a negative externality on developers by requiring them to bootstrap a project that might not end up with product/market fit or an adequate reward, thus deterring new contributions. + +Because of the way the Multisig was empowered in YIP 41, the yearn community has generally skirted this governance Catch-22. Most new development has been funded at the discretion of the Multisig and, after funding but before full deployment, has been ratified to become an official part of yearn through a proposal to YFI holders. We believe this is an important part of why the yearn community is known for having some of the most capable volunteer developers with the most aggressive pace of innovation of any DeFi community. If political debates were a gating item to every new project, good devs would be deterred or hampered from contributing to yearn, yearn's progress would be slow. + +We note, however, that while this process has been effective, it has led to a muddled conception of governance that spawns many questions, e.g.: 'How meaningful can governance be if YFI holders are only asked to sign off on a new development after there are material sunk costs?' 'What does it mean for a new product to be 'accepted into yearn,' and who gets to decide that?' 'What do YFI holders govern?' + +Our modest proposal for threading the needle through these philosophical tapestries is a model we call 'constrained delegation'--in effect, YFI holders delegate their governance powers to autonomous groups like the Multisig and yTeams and thus empower them to be creative. These battle-tested, YFI-approved yTeams are privileged to be able to get funding on a more spontaneous, informal basis and have their contributions presumed to be 'yearn-official', but are still subject to being monitored by YFI holders and disenfranchised if they abuse their roles. + +In contrast to core governance (which is top-down relative to users and bottom-up relative to creators) and DAO governance (which is top-down relative to creators and bottom-up relative to users), 'constrained delegation' avoids subordinating either group to the other. Instead, we propose using a kind of checks-and-balances system that has more in common with the governance of corporations than that of *kibbutzes*, while still being more open, creative and spontaneous. Unlike with a corporation, yearn has no state charters, legal agreements or fiduciary relationships. YFI holders have not made an investment of capital into yearn, do not hold 'shares' with rights defined by a state statute, and should not expect that yTeam members will act like single-minded automatons blindly devoted to increasing YFI holders' profits at the expense of more multifarious purposes. Rather, if yearn is similar to a corporation, it is more like an idealistic version of a public benefit corporation---a public commons that exists to simultaneously benefit many different kinds of stakeholders (users, creators, students, other friendly DeFi communities, etc.) in a delicate set of tradeoffs. + +Through rough consensus, YFI holders govern *de facto* rather than *de jure* and use that socially constructed governance influence to actively monitor and, to the extent desired, modulate the behavior of contributors. When it comes to governing yTeams, this governance may often look very similar to YFI holders 'doing nothing,' because YFI holders have already endorsed the Multisig and yTeams and they are presumed to act on a selfish but incentive-aligned basis consistent with the expectations of the community. However, when the contributors stray too far, or fail to communicate adequately, YFI holders should always be waiting in the wings to intervene in the situation, revoke their endorsement and restore a positive-sum equilibrium for the yearn community. + +### The Future + +This proposal architects a powerful, flexible, and novel form of decentralized governance that satisfies two critical needs: 1) giving YFI holders clear control and 2) empowering the team to execute with the speed yearn is famous for. + +We believe that DAOs are in their infancy and there is much to learn. Although the promise of fully on-chain and trustless governance is alluring, we are not there yet. Behind every DAO implementation, there is a group of trusted contributors. Our model seeks to foreground these trusted relationships and give YFI holders the ability to modify them directly. + +This proposal provides a northstar for implementations of Gov 2.0 that can iterate and improve over time. Here are some additional ideas we would like to explore further in the future: + +- implement nested multisig-style consensus mechanisms such that each yTeam has execution power for their domain of action, flexibly reconfigurable based on delegated powers +- move away from proxy voting via either a tool like SafeSnap[[15]](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#References) or an on-chain L2 implementation with something like Compound's Governor Bravo[[16]](https://gov.yearn.fi/t/yip-61-governance-2-0/10460#References) +- tokenize decision-making powers as NFTs for improved transparency and functionality +- deprecate veto power via third-party arbitration +- utilize Coordinape for some yTeams, for example: + - budget allocation circle (yBudget) + - compensation setting circle (yPeople) +- explore using conviction voting to establish new yTeams and their membership +- migrate to on-chain voting using Colony v2, utilizing reputation for yTeams +- collaborations with Gnosis, Colony, LEGO Dao, Tally, finance.vote, and Orca Protocol +- establish practices for ratification of yTeams wielding off-chain decision-making powers on domains such as marketing, docs, and the web + +## Credit + +This proposal is the result of months of work across many teams and has benefited from the advice and feedback of dozens of brilliant people. You know who you are. Thank you. And a special shout out to the YFI Governance telegram group in particular for the regular and lively discussions. + +_Source: [Snapshot](https://snapshot.org/#/ybaby.eth/proposal/QmSMyYeKrRpnA7Xn56o2NtbCUzxmhzCupL7LxMA1reXxq4)_ + +## References + +[1] [FAQ - yearn.finance 10](https://docs.yearn.finance/faq#what-is-the-multisig-and-what-do-they-do)\ +[2] [https://gov.yearn.fi/t/yip-41-temporarily-empower-multisig](https://gov.yearn.fi/t/yip-41-temporarily-empower-multisig)\ +[3] [YIP-55: Formalize the YIP Process 8](https://gov.yearn.fi/t/yip-55-formalize-the-yip-process/7959)\ +[4] [https://gov.yearn.fi/t/yip-59-temporarily-extend-multisig-empowerment](https://gov.yearn.fi/t/yip-59-temporarily-extend-multisig-empowerment)\ +[5] [https://gnosis-safe.io/ 7](https://gnosis-safe.io/)\ +[6] [https://colony.io/ 4](https://colony.io/)\ +[7] [https://twitter.com/lego_dao 6](https://twitter.com/lego_dao)\ +[8] [https://snapshot.org/](https://snapshot.org/)\ +[9] [https://www.withtally.com/ 1](https://www.withtally.com/)\ +[10] [https://www.finance.vote/ 2](https://www.finance.vote/)\ +[11] [https://www.orcaprotocol.org/ 9](https://www.orcaprotocol.org/)\ +[12] [http://coordinape.com/ 8](http://coordinape.com/)\ +[13] [Spix's macaw - Wikipedia 10](https://en.wikipedia.org/wiki/Spix's_macaw)\ +[14] [https://gov.yearn.fi/t/how-we-think-about-yearn](https://gov.yearn.fi/t/how-we-think-about-yearn)\ +[15] [https://blog.gnosis.pm/introducing-safesnap-the-first-in-a-decentralized-governance-tool-suite-for-the-gnosis-safe-ea67eb95c34f 2](https://blog.gnosis.pm/introducing-safesnap-the-first-in-a-decentralized-governance-tool-suite-for-the-gnosis-safe-ea67eb95c34f)\ +[16] [Compound | Docs - Governance 3](https://compound.finance/docs/governance) diff --git a/docs/contributing/governance/yips/yip-62.md b/docs/contributing/governance/yips/yip-62.md new file mode 100644 index 0000000000..2ad599e0c4 --- /dev/null +++ b/docs/contributing/governance/yips/yip-62.md @@ -0,0 +1,56 @@ +--- +title: "YIP-62: Change Two Multisig Signers" +hide_title: true +sidebar_position: -62 +--- + +# YIP-62: Change Two Multisig Signers + +| Metadata | Details | +| --- | --- | +| YIP | 62 | +| Outcome | **Passed** | +| Authors | banteg, lehnberg, milkyklim, tracheopteryx | +| Created | 2021-05-24 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-62-change-two-multisig-signers/10758) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:ybaby.eth/proposal/QmddCbGYbkooZ1zp8oYnbBz6frXLRc9xbkapXcuZcdzmMF) | +| Vote result | yes, I vote for this proposal: 415.75; no, I vote against this proposal: 1.51 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-62.md) | + +## Authors + +[@banteg](https://gov.yearn.fi/u/banteg), [@lehnberg](https://gov.yearn.fi/u/lehnberg), [@milkyklim](https://gov.yearn.fi/u/milkyklim), [@tracheopteryx](https://gov.yearn.fi/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.fi/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.fi/t/yip-62-change-two-multisig-signers/10758#References). + +## Abstract + +If adopted, this proposal will: + +- remove [@Substreight](https://gov.yearn.fi/u/substreight)[[3]](https://gov.yearn.fi/t/yip-62-change-two-multisig-signers/10758#References) and [@tchitra](https://gov.yearn.fi/u/tchitra)[[4]](https://gov.yearn.fi/t/yip-62-change-two-multisig-signers/10758#References) as multisig signers +- add [@RyanWatkins](https://gov.yearn.fi/u/ryanwatkins)[[5]](https://gov.yearn.fi/t/yip-62-change-two-multisig-signers/10758#References) and [@Lumberg](https://gov.yearn.fi/u/lumberg)[[6]](https://gov.yearn.fi/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](./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) diff --git a/docs/contributing/governance/yips/yip-63.md b/docs/contributing/governance/yips/yip-63.md new file mode 100644 index 0000000000..b83e513e9f --- /dev/null +++ b/docs/contributing/governance/yips/yip-63.md @@ -0,0 +1,100 @@ +--- +title: "YIP-63: Fund Builder-First Legal Activism DAO" +hide_title: true +sidebar_position: -63 +--- + +# YIP-63: Fund Builder-First Legal Activism DAO + +| Metadata | Details | +| --- | --- | +| YIP | 63 | +| Outcome | **Passed** | +| Authors | andrecronje, tracheopteryx, lex-node, judge-jowday, Sh Brennan, Birdman Haxxor | +| Created | 2021-08-06 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-63-fund-builder-first-legal-activism-dao/11280) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:ybaby.eth/proposal/QmPK9AqeoV6v5xeuiTeFcj9Px7y87KMQ1gGhvHft2GMtqE) | +| Vote result | Yes, I support this proposal: 862.01; No, I am against this proposal: 0 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-63.md) | + +## Authors + +[@andre.cronje](https://twitter.com/andrecronjetech) [@tracheopteryx](https://twitter.com/tracheopteryx) [@lex_node](https://twitter.com/lex_node) [@judge_jowday](https://twitter.com/judge_jowday) [@sh_brennan](https://twitter.com/SH_Brennan) [@birdman_haxxor](https://twitter.com/Birdman_Haxxor) + +## Summary/Abstract + +Amidst intensifying regulatory scrutiny of DeFi, we propose that Yearn contribute to a new LeXpunK_DAO dedicated to legal advocacy for yearn and other builder-centric DeFi communities. The LeXpunK_DAO will be governed by builders from contributing communities (including yearn) and practicing lawyers from the [LeXpunK Army](https://judge-jowday.medium.com/rise-of-lexpunk-army-5afad79966f1). 5% of the current supply of L3X, the non-transferable reputational token of the LeXpunK Army, would be airdropped to YFI holders who support this proposal, to enable direct sentiment polling on relevant legal issues from the Yearn community. LeXpunK will effect additional airdrops from time to time, proportionally in line with the relative contributions of other builder communities, with the goal of forming a broad coalition to pool resources for funding shared advocacy goals. + +A similar proposal is being made to Curve governance, here: https://gov.curve.fi/t/fund-a-builder-first-legal-activism-dao/2025. We also aim to make similar proposals to other value-aligned DAOs and prominent ecosystem builders if the Curve and Yearn proposals are successful. + +### Status + +_This proposal is currently in the discussion phase_. + +🗳 [Cast your vote on Snapshot.](https://snapshot.org/#/ybaby.eth/proposal/QmPK9AqeoV6v5xeuiTeFcj9Px7y87KMQ1gGhvHft2GMtqE) + +You can learn about our voting rules in [YIP-55](https://gov.yearn.fi/t/yip-55-formalize-the-yip-process/7959). + +## Motivation/Rationale + +Growing mainstream awareness of DeFi is coinciding with institutional outrage over the "Wall St. Bets" phenomenon and political change in the United States to brew a perfect storm of aggressive legal threats against DeFi: + +- mainstream media calls DeFi a "[shadow financial market](https://www.politico.com/news/2021/07/24/shadow-financial-market-spooks-regulators-500696)" and warns that regulatory action is imminent +- new SEC Chair Gary Gensler concludes [a recent speech](https://cointelegraph.com/news/sec-chairman-says-cryptocurrency-falls-under-security-based-swaps-rules) to the American Bar Association Derivatives and Futures Law Committee with a warning that many DeFi platforms may involve securities swaps +- CFTC Commissioner Dan Berkovitz, having googled DeFi, [positioned it](https://www.cryptoglobe.com/latest/2021/06/cftc-commissioner-dan-berkovitz-is-concerned-about-decentralized-finance-defi/#:~:text=%E2%80%9CIn%20a%20pure%20'peer%2D,customers%20whole%20when%20processes%20fail.) as being squarely incompatible with the policy of 'mandatory intermediation' enshrined in CFTC regulations on leveraged retail commodities transactions and commodities swaps and referenced unfair advantages DeFi has to TradFi due to the lack of regulated intermediaries +- many blue-chip DeFi projects have already been [called in front of regulators](https://africa.businessinsider.com/markets/us-regulators-are-reportedly-meeting-with-defi-companies-as-scrutiny-of-crypto-builds/1gqq2kc) or are [receiving SEC subpoenas](https://twitter.com/arrington/status/1418314425795231754) and are forming organized political lobbying efforts which may have distinct and zero-sum goals + +DeFi is a DAO of DAOs. These DAOs have many shared goals. For instance, we all aim to build, use, and enjoy open financial technologies. However, DAOs also compete with one another and often differ in ethos and strategy. + +Existing advocacy orgs like the Blockchain Association, Coin Center, and the Uniswap-funded DeFi Education Fund have mutually overlapping membership and staff which are heavily intertwined with Silicon Valley venture capital funds and traditional crypto businesses like Coinbase. Many of the teams most directly represented by these organizations have pursued dual token/equity strategies, which means they also seek to accrue value to their equityholders through KYC-gated and censorable forks of their protocols which will cater to institutions and 'fintechs'. + +Builder-centric, bottom-up communities like Yearn, Curve, and SushiSwap have a different cultural ethos and a different story to tell. We are spontaneous, cryptonative communities of builders that have no TradFi backup plan and value openness, lack of hierarchy, and creativity above all else. Thus, we should have our own unique voice in the evolving regulatory landscape, and by doing so we may be able to make or emphasize lines of legal argument that are not as available to other kinds of projects. After all, the former head of the SEC's CorpFin division [views "sufficient decentralization" as the point where traditional regulations end](https://www.sec.gov/news/speech/speech-hinman-061418), and there is nothing more decentralized than a community of builders, users and investors that come together with no contracts or rules, no board of directors or stockholders to answer to, yet somehow build remarkable innovations together. + +We believe that cryptolaw should be done in the crypto spirit. If DeFi communities want to show regulators, lawyers, and politicians what is special about DeFi, then Orwellian-named trade associations and non-profits staffed by D.C. insiders are not the best way to go. Instead, we should present ourselves as we are--as DAOs, as token communities, as builder communities. The values underlying these modes of expression are too important to cast aside in the name of expediency when the going gets tough and there are legal threats. On the contrary, the values of openness, transparency, and decentralization are DeFi's greatest defense to traditional regulation and should be front-and-center when regulators and politicians interface with DeFi communities. This is why [LeXpunK](https://lex-node.medium.com/lexpunk-a1bb9f769ec) was created--to bring lawyers and builders together under a shared ethos that is as disruptive to law as it is to finance. + +Through a new, community-funded LeXpunK_DAO, we will not merely hire existing lawyers or fund existing traditional advocacy groups--We will bootstrap a new community of lawyers and builders working side-by-side to legitimize and protect shared creative values. This community will become a flywheel unto itself and yield benefits long after these initial donations are spent and far beyond the benefits of the specific projects these donations end up funding. + +## Specification + +### Overview + +LeXpunK_DAO will mix long-term strategic advocacy campaigns with rapid-response 'guerilla lawfare' raids. LeXpunK_DAO will be structured either as a Moloch DAO, Gnosis multisig, or other DAO implementation; in any case, with balanced representation of LeXpunK Army members and representatives of the contributing DeFi communities. Un-committed contributed funds will be 'ragequittable' at the discretion of each community's representatives. We estimate that $1M from Yearn and $1M from Curve would provide a sufficient starting point to get the ball rolling (this is far less than the massive warchest recently raised from Uniswap to fund already heavily VC-/Silicon-Valley-backed advocates). + +#### A. Campaigns + +Campaigns are major strategic initiatives, such as: + +- a landmark position paper advocating for positive analysis under securities law, commodities law or tax law of Yearn-relevant DeFi primitives such as flash loans, vault strategies, CDPs, and deposit-claim tokens (e.g., yAssets) +- a legal defense of DeFi developers against regulatory litigation; +- proposed 'safe harbor' legislation legalizing key aspects of DeFi; +- if/when the SEC files a case premised on a novel, expansive view of securities laws that could adversely affect DeFi builders (for example, that all project participants are collectively responsible as an '[unincorporated association](https://lawstreetmedia.com/tech/sec-charges-five-in-connection-with-2b-bitconnect-securities-offering/)'); the LeXpunK_DAO would file an _amicus curiae_ brief in the litigation + +Campaigns will be defined with thorough specifications and funded with pre-announced bounties. Campaign fulfillment will be by teams hand-picked by the Advocacy Fund Multisig. Relevant experts--both lawyers and developers--will be recruited from within the LeXpunK community, other DeFi communities and, if needed, from traditional law firms; these will be our 'MandDAOlorians' working for a piece of the bounty. A 'taskmaster' will be assigned from the most trusted ranks of the LeXpunK Army--typically an experienced attorney--who is not eligible for the bounty, but receives a flat fee to monitor the working group's progress, help remove blockers and make the final determination of when the project has been completed to spec and the bounty is due to be paid. Upon project completion, the team members themselves will decide how the bounty should be allocated, using another yearn ecosystem offshoot--[coordinape](https://coordinape.com/). Campaigns will be pre-checked with the LeXpunK community through L3X snapshot polls. + +#### B. Raids + +Raids are rapid-response initiatives tailored to respond to current events in realtime. Examples of raids would be: + +- a politician like Elizabeth Warren sends an [adversarial public letter](https://www.warren.senate.gov/imo/media/doc/Draft%20SEC%20Crypto%20Exchange%20Letter%2007.7.2021%20clean.pdf) regarding DeFi to a regulator; the LeXpunK_DAO funds a rapid public response detailing community views about her questions; +- a contributing DeFi protocol suffers from a hack or exploit and the team needs help coordinating with law enforcement or CEXs to help block or recover funds +- builders from a contributing community receive an informal SEC inquiry; the LeXpunK_DAO helps strategize and marshal a legal team to defend the builder + +Raids will be funded on an emergency, _ad hoc_ basis at the discretion of the LeXpunK_DAO. + +## Conclusion + +The time is now. Let's do cryptolaw the crypto way. + +![photo_2021-08-06 17.06.53](./assets/yip-63/figure1.jpeg) + +## Binding Snapshot Vote + +🗳 **Voting is live!** +https://snapshot.org/#/ybaby.eth/proposal/QmPK9AqeoV6v5xeuiTeFcj9Px7y87KMQ1gGhvHft2GMtqE + +## References + +Read up on LeXpunK: +(1) [LeXpunK: The New Legal Praxis](https://lex-node.medium.com/lexpunk-a1bb9f769ec) +(2) [Autonomous Lawyering](https://lexnode.substack.com/p/autonomous-lawyering) +(3) [Rise of LeXpunK Army](https://judge-jowday.medium.com/rise-of-lexpunk-army-5afad79966f1) diff --git a/docs/contributing/governance/yips/yip-64.md b/docs/contributing/governance/yips/yip-64.md new file mode 100644 index 0000000000..338054e507 --- /dev/null +++ b/docs/contributing/governance/yips/yip-64.md @@ -0,0 +1,82 @@ +--- +title: "YIP-64: Adjust fees on non-stablecoin yVaults" +hide_title: true +sidebar_position: -64 +--- + +# YIP-64: Adjust fees on non-stablecoin yVaults + +| Metadata | Details | +| --- | --- | +| YIP | 64 | +| Outcome | **Rejected** | +| Authors | wavey, philbert, saltyfacu | +| Created | 2021-10-21 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-64-adjust-fees-on-non-stablecoin-yvaults/11716) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:ybaby.eth/proposal/0xfe7296601d199b89a8aa53f95d6243ef935d736bea2f13109979d8d5098017d2) | +| Vote result | For: 167.03; Against: 308 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-64.md) | + +## Summary + +Experiment with introducing a new fee structure for non-stablecoin* yVaults: +- 25% performance (25% increase) +- 1% management (50% decrease) + +Some of the expected implications are: +- Improved profitability for yVaults with lower yields +- Reduced treasury income +- Unchanged incentive alignment for strategists + +**Stablecoin = fiat-pegged tokens* + +## Motivation + +In DeFi, stablecoins are often able to generate higher yields than crypto native assets. Since the heights of "DeFi Summer" yield has slowed down on the Ethereum mainnet, and it has become common for non-stablecoin crypto assets to return in the lower single-digit APRs. + +#### Opportunity Cost of High Fees +The current 2% management fee is a flat rate taken from invested assets over the course of a year. Therefore, if a strategy is earning 2.5% APR or less (after combined mgmt + performance fees), users stand to realize no profit on harvest. Yearn tries to avoid deploying funds in these situations which are unprofitable to users. The downsides to this are: +- all farms which earn between 0% - 2.5% APR become non-viable strategies +- in these situations, treasury earns no fee income +- creates additional management burden on Yearn operations to actively monitor strategy APR and react when it dips too low. + +Finding 2.5%+ APR farms for crypto assets like ETH and BTC is difficult, especially for the scale Yearn operates at. Lowering the management fees on these tokens will help improve APR while also creating access to new farms. + +#### Maintain Protocol Revenue by Shifting to Performance fee +For lower performing vaults, performance fees are a more attractive option because . to anything below 100% will not result in users earning 0% (or less) on a harvest as fees are charged from profits rather than the initial deposit. This is a straight forward way to balance the reduction of the management fee. + +#### More to come... +This proposal is viewed as a temporary measure to take action and collect data while further ideas for fee revisions are discussed by the community. + +### **Data for claims** +The image below shows sample data for 2/20 versus the proposed 1/25 fee structure across a range of yield scenarios. + +![](upload://b5JdzAbncnrNMq6VYvt2nl38mg4.png) +Source: [Fee Adjustment Calculator](https://docs.google.com/spreadsheets/d/1U66cFgymIW4Qdmo3lgCx5-lrMunBbLI_6cbxplWAE1U/edit?usp=sharing) + +**Increasing profitability for yVaults with lower yield:** + +The proposed fee structure change provides a very tangible benefit for low earning vaults, with diminishing results as APY increases. This is why it makes sense for the adjustment to be isolated to crypto native asset yVaults rather than all yVaults in general. When a vault is earning above 30% APY, this fee change actually reduces profit for users. + +**Reduce treasury income:** + +Adversely, the proposed fee change would have a greater impact on the treasury when applied to lower earning vaults. Still, percentage wise, the benefit to token holders greatly outweighs the loss of the treasury. + +Additionally, since the lower earning vaults aren’t bringing in as many fees as an equivalent TVL higher earning vault, the relative loss of treasury revenue will be negligable when compared to the benefits. + + +## Specification + +Adjustments to vault management and performance fees require transactions from the governance multisig (`ychad.eth`). If passed, the following should take effect. + +**Non-stablecoin yVaults** + +- 1% annualized management + - Full amount allocated to Treasury + - Applied only to invested funds + - Collected on each harvest +- 25% performance fee + - 15% allocated to Treasury + - 10% allocated to the Strategist + +**Stablecoin yVaults:** (unchanged) diff --git a/docs/contributing/governance/yips/yip-65.md b/docs/contributing/governance/yips/yip-65.md new file mode 100644 index 0000000000..0471bb4df5 --- /dev/null +++ b/docs/contributing/governance/yips/yip-65.md @@ -0,0 +1,196 @@ +--- +title: "YIP-65: Evolving YFI Tokenomics" +hide_title: true +sidebar_position: -65 +--- + +# YIP-65: Evolving YFI Tokenomics + +| Metadata | Details | +| --- | --- | +| YIP | 65 | +| Outcome | **Passed** | +| Authors | 0xJiji, banteg, daryllautk, HAtTip3675, onlylarping, vany365, Wot_Is_Goin_On | +| Created | 2021-12-23 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-65-evolving-yfi-tokenomics/11994) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:ybaby.eth/proposal/0x8f7417fa5565d9f46e16618503e8808c36d51b2a9e8217a68c632d7c090d69d9) | +| Vote result | Yes, I support this proposal: 908.09; No, I'm against this proposal: 2.91 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-65.md) | + +## Authors + +@0xJiji, @banteg, daryllautk, HAtTip3675, @onlylarping, @vany365, @Wot_Is_Goin_On + +## Summary + +Evolve the role YFI plays in Yearn over four distinct phases, cementing the vision of the token as the fundamental foundation of governance. + +### Status + +**Voting:** This proposal is currently in the voting phase. [Cast your vote on Snapshot](https://snapshot.org/#/ybaby.eth/proposal/0x8f7417fa5565d9f46e16618503e8808c36d51b2a9e8217a68c632d7c090d69d9). +You can learn about our voting rules in YIP-55[1]. + +## Abstract + +**If adopted**, this proposal seeks to: + +1. Direct a portion of YFI that is bought back by the Treasury as a result of BABY [[1]](#references) as rewards to those YFI token holders who actively participate in Yearn Governance. +1. Evolve the role YFI plays in Yearn Governance through four distinct components. These build on top of each other and thus come in a particular order: + - **1: xYFI.** Distribute YFI that's been bought back with Treasury tokens as rewards in a YFI vault. + - **2: Vote-locked YFI.** Introduce ve-style locking of YFI (veYFI) for up to four years (exact max duration tbd), where a longer locking duration gives a greater share of voting power and share of YFI rewards. An early exit from the lock is possible by paying a penalty that is rewarded to the other locked token holders. + - **3: Vault Gauges + Voting.** Introduce _vault gauges_ where vault depositors stake their vault tokens and earn YFI rewards according to their veYFI weight. YFI are allocated to gauges based on weekly governance votes. + - **4: "Useful work" features.** Expand the duties and responsibilities of veYFI voters, and their locked YFI, in exchange for earning additional protocol rewards. Pending the tbc v3 vault design. +1. Give the mandate to Yearn Developers to roll out the above components at their discretion as and when they become feasible. +1. Restrict the YFI eligible to vote in Yearn Governance as only those staked in xYFI (from Phase 1 and onwards) or vote-locked in Yearn (from Phase 2 and onwards). + +## Background + +This section covers general information that readers may find useful in order to better understand the motivation and specification of the proposal. Namely the community exploration of various tokenomics ideas, the source and quantity of YFI rewards proposed to be used, some general information about Curve's ve-mechanic, and what was deliberately kept out of scope of this proposal. + +### Call for tokenomics ideas + +On October 6th 2021 there was a call for tokenomics ideas on Yearn’s governance forum[[2]](#references) that attracted over 5k views. Over 200 people completed a survey aimed to express the preferences of YFI tokenholders, results of which can be found in the References section.[[3]](#references) A discord chat gave those interested an opportunity to express their views. There were also multiple independent groups created with high degree of engagement, culminating in a signalling vote[[4]](#references) which aligns with the components of this proposal. This proposal attempts to bring together the discussions that have occurred over the last 2 months. + +### State of Holdings & Buybacks + +YIP-56: Buyback and Build (BABY)[[1]](#references) was adopted in early January 2021, instructing Treasury to buy back YFI with excess Yearn treasury tokens. A few weeks later, the yvDAI vault suffered an incident[[5]](#references) where 11m DAI were lost. The Treasury compensated those affected, making vault depositors whole. Since then, the Treasury has been on a path of recovering from this expense while at the same time saving for a potential market downturn and a prolonged bear market where a runway would be required during periods of lower protocol activity. While the details can be found in the quarterly financial reports[[6]](#references) the high level summary is that Yearn has gone from $11m in debt in February to $30m+ in liquid assets in November.[[7]](#references) Despite saving more than $40m, the Treasury has still been able to buy back **~300 YFI year to date** at a cost of ~$10m equivalent.[[8]](#references) + +Now that the yvDAI debt has been paid off and the bear market buffer exists, Treasury expects to be able to direct **~$35-$45m** to YFI buy-backs on an annual run-rate basis assuming TVL and margins stay constant. + +This would equate to 1,100-1,400 YFI per year at a YFI price of ~$30k, or somewhere around **100 YFI/month**. These bought back YFI could sustainably be used in a reward system, without impacting overall Treasury health negatively. + +### Curve's ve-mechanism in a nutshell + +An incomplete and very high level description of this mechanism is as follows: + +- Users can lock CRV into veCRV for a duration of up to 4 years. +- Depending on the locking duration, users get different weights linearly: 4 years = 100% weight, 1 year = 25% weight, etc. The longer the lock, the more voting power and influence, and the more rewards can be earned. +- CRV rewards are distributed through _gauges_ in which users stake their Curve LP tokens. Each gauge gets allocated a different amount CRV to emit, based on weekly voting amongst veCRV holders. +- Based on their veCRV lock, users can boost their rewards of up to 2.5x when they claim CRV rewards from gauges. +- Unlike typical ERC-20 tokens, veCRV is non-transferable. This can be bypassed via wrapped derivatives such as the Yearn yveCRV vault or Convex's cvxCRV product. +- Each account can only have one single veCRV lock (of a certain duration). +- As the lock duration decays, so does the influence. If a user initially locked for 4 years for 100% weight, once 1 year has passed, their weight will be 75%. Users therefore have to constantly extend their locks (up to the maximum 4 years) in order to maintain their weight. + +### Out of scope + +The following topics were intentionally left outside of the scope of this proposal. Each one is potentially important and probably would be best served by its own stand alone proposal. They are also independent from what is proposed here, and could be added as extensions that build on top of the concepts covered in this proposal. + +- **New YFI Emission.** The current proposal assumes no new YFI emission or minting. Emission could be attached to the components introduced in the phases, but is not an explicit requirement at this point. +- **Liquidity Mining Program.** A new liquidity mining program, whether funded by Treasury YFI assets or by new emission, is somewhat orthogonal to the topics covered in this proposal, and could be introduced with or without the concepts covered here. There are numerous trade offs to consider, better discussed in a dedicated proposal. +- **Unit bias conversions.** +- **Detailed specs of "useful work" features.** The v3 vault specification is still in the design and discovery phase. Whilst ideas such as vault insurance, safety modules, and vault allocations are mentioned in this context, it is premature to discuss specifics as such proposals are far from being ready to go live. + +## Motivation + +### Benefits + +The following are some of the properties where the new tokenomics design is believed to improve over the previous state: + +- **Incorporates YFI buybacks.** The mandate of YIP-56 is unchanged, the new design builds on top of and integrates the bought back YFI. +- **Is a sustainable ecosystem.** The new design does not create a drain on Treasury assets. Instead there are reinforcing flywheel effects where tokenomics rewards drive more TVL, that in turn drive more fees, that in turn drive more YFI buybacks, that is then used to reinforce the tokenomics. +- **Incentivizes a long term view on Yearn.** Token holders are motivated to support the protocol over the longer term rather than to speculate in the short term. +- **Disproportionately rewards those most loyal.** Weaker conviction holders effectively become diluted over time by the stronger conviction holders. +- **Limits rent-seeking benefits.** Over time as the components are introduced, the design avoids holders being rewarded for nothing. Or letting the largest holders accumulate more at the expense of the smaller holders. +- **Makes vaults more competitive.** Additional YFI earned from vault gauges are effectively added yield for depositors, in proportion to how dedicated they are in their support. +- **Motivates 3rd party protocols and DAOs to become YFI holders.** Yearn products are used as a yield components of a broader DeFi stack, and integrated in wallets and protocols. With this design, they have incentives to direct rewards to vaults and products they are using. +- **A seamless experience for integrators.** Participation is _optional_. This maintains the simplicity integrators have come to appreciate and makes it easy to reason about vault behavior. Only those who are motivated to do so can participate. + +### Future possibilities + +The proposal also opens up doors for potential further improvements that extend or build on top of these concepts, including: + +- **yOptions program for contributors**, where contributors can acquire YFI at a discount based on how long these are locked into the protocol for. +- **Insurance/Backstop functionality**, where vaults could be insured against loss based on the amount of YFI locked, which in turn could be used to draw up stablecoin CDPs to repay users in catastrophic events. +- **New YFI Emission to veYFI holders**, where new YFI is minted according to some emission schedule and used to reward veYFI holders based on their lock duration. +- **Partnership program adopting veYFI to boost partner performance**, where partners can earn more based on their veYFI size and lock duration. + +### Risks + +- **Governance attacks,** where one or several actors accumulate sizable positions of YFI and can control rewards and decisions of the protocol. These risks exist today, and are mitigated somewhat by the limited supply of YFI and how the strong demand for YFI amongst Yearn contributors makes such attacks costly. +- **Not enough rewards to make locking attractive,** where vaults may not generate enough tokens to the Treasury to buy back enough YFI to motivate YFI holders to lock into veYFI. This has somewhat of a balancing effect, where as demand for locking decreases, so does the share of the rewards for those who actually do lock. If it's determined that the equilibrium does not lead to enough YFI being locked, additional YFI could be minted and rewarded to veYFI holders as previously mentioned in "Future possibilities". +- **YFI liquidity dries up.** Currently YFI is traded on multiple centralized and decentralized exchanges. As demand for using YFI elsewhere grows, there may be a lack of YFI/ETH LP supply in liquidity pools and lack of interest in general YFI market making, leading to YFI becoming more illiquid. In such an event, additional incentives may be required in order to ensure a healthy liquidity exists for trading in and out of YFI. The Treasury may also explore owning some of this liquidity outright. + +### Alternatives considered + +- OlympusPRO style designs +- Voters voting on fees +- YFI as a fee discount +- Distribute treasury YFI + +## Specification + +### 1. Spend bought back YFI in tokenomics rewards + +- Use a portion of bought back YFI from BABY to finance a new tokenomics program. +- The 6,666 YFI that were minted as part of YIP-57: Funding Yearn's Future[[9]](#references) are not used for this purpose. + +### 2. Evolve YFI through four components + +_In required order:_ + +#### 2.1 xYFI + +- A typical Yearn vault with YFI as a want token (potentially repurposing the existing yvYFI vault). +- Receives bought back YFI as rewards. +- Does not have any locking requirement. +- Does not charge fees. + +![xYFI diagram](assets/yip-65/01-xYFI.svg) + +#### 2.2 Vote-locked YFI + +- Locking similar to the ve-style program of Curve. +- YFI can be locked up to 4 years into veYFI, which is non-transferable. +- The maximum lock duration is still tbd, but will be in the range of min 1 year, max 4 years. +- Locking duration gives the same linear weights, so if max duration is 4 years, this is 100%, and 2 years = 50% etc. +- Weights decay as the remaining lock duration decreases, and can be extended up to the max lock duration. +- Replaces xYFI, where a user _must_ have a veYFI lock in order to continue to earn rewards. No lock leads to no rewards. Maximum lock, continuously renewed, maximizes rewards. +- It's possible to exit the lock early, in exchange for paying a penalty that gets allocated to the other veYFI holders. +- Penalty size may be fixed (i.e. 50%), or may be depending on the remaining lock duration. + +![veYFI diagram](assets/yip-65/02-veYFI.svg) + +#### 2.3 Vault gauges + Voting + +- Vault gauges allow vault depositors to stake their vault tokens and earn YFI rewards according to their veYFI weight. +- YFI are allocated to gauges based on weekly governance votes. Each gauge can get a different amount of bought back YFI to emit. +- Based on their veYFI lock, users can boost their rewards of up to 2.5x proportional to the amount of vault tokens deposited, when they claim YFI rewards from gauges. The greater the amount of veYFI, the more vault deposits can be boosted for the user. +- Inspired by Andre Cronje's initial design of Fixed Forex[[10]](#references), in order for gauge rewards to be claimed, the user must have a veYFI lock. Depending on their lock duration, they are entitled to a different share of gauge rewards: if max lock = 4 years, and user is locked for 4 years, they are entitled to 100% of their rewards, if user is locked for 2 years = 50% of rewards, if user has no lock = 0% of their rewards. The difference is paid as penalty to veYFI holders, as an additional source of yield. + +![gauges diagram](assets/yip-65/03-gauges.svg) + +#### 2.4 "Useful work" features + +- This is driven by requirements of the yearn v3 vault design (still tbd). +- veYFI holders would be able to do useful work for the protocol and earn greater rewards as a result. +- Examples of useful work could be, but does not necessarily have to be: Configuring vault parameters, vault fees, strategy allocations, providing vault insurance, protocol backstop, and many other additional functionality. +- No useful work will be introduced without consulting YFI voters beforehand through YIPs. + +### 3 Give Yearn Developers the mandate to roll out the above components + +- Components can be introduced based on the requirements as set out here, with minor modifications as deemed necessary. +- Exact setting of parameters such as max lock duration and penalty system is left to be set at the discretion of the implementers. +- There is no requirement to add all four components, but components need to be in the order outlined as they build on each other. +- Timelines are at the discretion of the contributors doing the implementation work. + +### 4 Restrict the YFI eligible to vote + +- Once xYFI is introduced, only YFI staked is eligible to vote in Yearn Governance. +- Once veYFI is introduced, only veYFI is accepted voting power in Yearn Governance. + +## Vote + +[Cast your vote on Snapshot](https://snapshot.org/#/ybaby.eth/proposal/0x8f7417fa5565d9f46e16618503e8808c36d51b2a9e8217a68c632d7c090d69d9) + +## References + +1. https://gov.yearn.fi/t/yip-56-buyback-and-build/8929 +1. https://gov.yearn.fi/t/call-for-ideas-yfi-tokenomics-revamp/11573 +1. https://px2hc2blifd.typeform.com/report/yj5p5iIo/zIj0Alc03WFWfKTg +1. https://yearn.snapshot.page/#/proposal/0x783cb3d57dd59b2827f6a42967375f06504cc947ebaa3c0e495c7b29ffd47aea +1. https://github.com/yearn/yearn-security/blob/master/disclosures/2021-02-04.md +1. https://github.com/yearn/yearn-pm/tree/master/financials/reports +1. https://twitter.com/bantg/status/1461910717494398983 +1. https://www.yfistats.com/financials/YFIBuybacks.html (Page 2) +1. https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319 +1. https://andrecronje.medium.com/fair-launches-decentralized-collaboration-and-fixed-forex-ab327a2e4fc4 diff --git a/docs/contributing/governance/yips/yip-66.md b/docs/contributing/governance/yips/yip-66.md new file mode 100644 index 0000000000..b87c678854 --- /dev/null +++ b/docs/contributing/governance/yips/yip-66.md @@ -0,0 +1,311 @@ +--- +title: "YIP-66: Streamlining contributor compensation" +hide_title: true +sidebar_position: -66 +--- + +# YIP-66: Streamlining contributor compensation + +| Metadata | Details | +| --- | --- | +| YIP | 66 | +| Outcome | **Passed** | +| Authors | 15 members of the Compensation group inc @0xJiji | +| Created | 2022-02-05 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-66-streamlining-contributor-compensation/12247) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:ybaby.eth/proposal/0x804d3765e70d6e4f0f0a225222dadd396cd328595d5fd097b732b36fdf8e6af6) | +| Vote result | Yes, I support this proposal: 476.03; No, I'm against this proposal: 1 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-66.md) | + +## 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.fi/t/yip-65-evolving-yfi-tokenomics/11994#future-possibilities-11 +1. https://coordinape.com/ +1. https://gov.yearn.fi/t/yip-52-make-strategist-skin-in-game-partner-for-make-benefit-of-glorious-brain-of-yearn/7856 +1. https://gov.yearn.fi/t/yip-54-formalize-operations-funding/7956 +1. https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319 +1. https://gov.yearn.fi/t/yearn-retention-packages/9698 +1. https://gov.yearn.fi/t/yip-61-governance-2-0/10460 diff --git a/docs/contributing/governance/yips/yip-67.md b/docs/contributing/governance/yips/yip-67.md new file mode 100644 index 0000000000..3db95fd923 --- /dev/null +++ b/docs/contributing/governance/yips/yip-67.md @@ -0,0 +1,135 @@ +--- +title: "YIP-67: Contribute $400,000 to Nomic Foundation" +hide_title: true +sidebar_position: -67 +--- + +# YIP-67: Contribute $400,000 to Nomic Foundation + +| Metadata | Details | +| --- | --- | +| YIP | 67 | +| Outcome | **Passed** | +| Authors | FrancoNomic | +| Created | 2022-03-09 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-67-contribute-to-the-nomic-foundation/12326) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:ybaby.eth/proposal/0xd1988feec955cb93d42b63b7b4845d35da8f60859f55ec18b3d5609ecd4eb9e2) | +| Vote result | Sounds good, let’s contribute!: 656.96; No, not interested: 0.36 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-67.md) | + +# Should Yearn governance contribute funding to the Nomic Foundation? +## Summary + +- Nomic Labs, the team behind Hardhat, has become the Nomic Foundation, a non-profit organization dedicated to Ethereum. Our mission is to empower developers to decentralize the world. +- The Nomic Foundation's work will be focused on Ethereum's developer platform with the objective of achieving a world-class developer experience, and generally improving Ethereum's public goods support structures. +- [Hardhat](https://hardhat.org/) is the de facto standard developer tool used to build Ethereum software, with more than 23000 Github repositories using it and tens of thousands of active users. Prominent teams relying on it include ENS, Uniswap, Optimism, OpenZeppelin, Aave, Balancer, Chainlink, Synthetix, and many more leading teams. +- The new foundation will expand the Hardhat suite of tools and, most importantly, build long-term infrastructure to catalyze organic growth in the Ethereum tooling ecosystem, decreasing Ethereum's dependence on any one organization to build and maintain core development platform components. +- Seeking $30m in total funding from the ecosystem. Donations of $15M already secured by the Ethereum Foundation, Vitalik Buterin, Coinbase, a16z, The Graph, Polygon, Chainlink, a16z, and Kaszek Ventures. +- **We're proposing to Yearn Governance to make a contribution of $400k to the Nomic Foundation to support its mission.** + +## Ethereum developer experience + +When it comes to Ethereum, which is primarily a software development platform to build decentralized systems, developer experience is a key strategic aspect for success. Ecosystem growth requires more developers to build more software on top of Ethereum. Developer adoption and learning speed, core contributors to this growth, are critically affected by developer experience. + +The rate at which the ecosystem innovates, coming up with new creations and solving difficult problems, both at the dapp layer and EVM/Solidity/Vyper layer, is also directly affected by developer productivity. + +Software development platforms aren't new, and playbooks established by the great developer experience success stories (Rust, .Net, TypeScript, etc) prove that achieving a quality developer experience requires a specialized approach paired with a long-term, big-picture strategy. The potential impact in executing a dedicated effort for Ethereum would increase the ecosystem’s pace of innovation and growth, building a powerful compounding effect over the long term for the entire industry. + +The inspiration for our vision came from our experience building Hardhat, which allowed us to see how deeply challenging it is to build sophisticated Ethereum tooling. **These challenges must be alleviated to bring about organic ecosystem-led improvement of developer experience that achieves world-class quality.** + +## Nomic Foundation + +Nomic Labs has been fully dedicated to Ethereum developer experience since 2019, and we're [now pivoting](https://medium.com/nomic-labs-blog/introducing-the-nomic-foundation-an-ethereum-public-goods-organization-31012af67df9) to a non-profit foundation formally dedicated to Ethereum. We're aiming to build a long-lasting organization that makes Ethereum's public goods support structures stronger by contributing to the Ethereum Foundation's existing efforts, and reducing the ecosystem's reliance on any one organization for development platform components. + +### Roadmap + +Given the size and innovation pace of the ecosystem, there's no way to foresee exactly what needs developers are going to have as things scale. However, we do know what engineering foundations the ecosystem will need in order to build its own solutions. + +Our overarching engineering strategy is to empower the ecosystem to build its own specialized tools. This plan is based on four strategic pillars of the stack, each of which offers an opportunity to leverage a platform to empower the ecosystem to keep building open-source infrastructure. + +For each of these pillars, we will build a platform. The four ecosystem pillars and platform opportunities we've identified are: + +1. Solidity +2. EVM tooling +3. Local development environment +4. Ethereum connector library + +## The projects + +### Slang & Rethnet + +Over the long term, these are our most important projects. Targeting the Solidity and EVM tooling pillars, Slang and Rethnet will serve as core infrastructure for the ecosystem to build new tools faster, cheaper, and better. We're essentially building the tools that would have let us build Hardhat a lot faster. We previously published a [Medium post](https://medium.com/nomic-labs-blog/slang-rethnet-2ad465fd7880) with high-level descriptions of how both projects will complement each other. + +**Slang** + +A Solidity compiler designed as a platform for tooling development, an approach also known as compiler as a service. Its top priority will be servicing tools through domain-specific APIs. Much like .Net's Roslyn, it will feature a compilation pipeline made of distinct reusable components with standalone APIs. A completely modular design guarantees that others can build on top of it by replacing the part of functionality they need to, and reusing everything else: + +1. Parser that is only concerned with producing trees from code. Usable on its own, for example, to create third-party formatters like Prettier plugins. +2. Semantic analysis (binding) is concerned only with building a type system and validating the produced trees. Usable on its own, to implement third-party type checking, security/threat models, and more advanced third-party linting. +3. Code generation. By replacing just this isolated part, the compiler can compile for different targets (e.g. non-EVM L2s). +4. Language services. These will receive an immutable representation of the above (syntax trees, bound trees, codegen settings), and will only be tasked with answering questions. Usable on its own to expose in different IDEs (same service for VSCode, IntelliJ, Vim, etc). Reusable to extend the functionality of other editor features (task runners, testing, deployment, CI, debugging). +5. Runtime observation APIs to support Rethnet. + +All of this will be reusable to create entirely new EVM programming languages, since by replacing the parser and type system, one can get an entire high-quality toolchain working from the get-go. + +**Rethnet** + +To provide a simulated environment where developers can build and test their Ethereum software, tools need to replicate many of the components that make up a full Ethereum node implementation. This is a significant engineering effort, which given the complexity of Ethereum, represents a barrier to entry to tooling development given the depth of knowledge that is required. + +Rethnet aims to make this easier by offering a native, flexible, extensible, fast, and language-agnostic EVM local development network, distributed as a Rust library, that is designed to be the underlying core in tools that provide debugging information to developers (like Hardhat, Foundry, Remix, Truffle, DappTools, etc). It will be a Rust library made to be consumed from other languages like TypeScript, Go, Python, etc as a native dependency. It will implement the baseline of essential functionality every tool should have like Solidity console.log, stack traces, and descriptive error messages, as well as implement code coverage, gas profiling, and a step debugger. At its core, it's an implementation of an Ethereum node with a layer of EVM runtime observation to provide development features. + +Building a new Hardhat, Truffle, Remix, or DappTools using Rethnet will be a much more manageable project, and Rethnet will be completely reusable for any EVM language through adapters. + +### Hardhat + +Our flagship project targets the local development environment pillar, and it's currently at an advanced level of progress and adoption. While Slang and Rethnet mature and catalyze organic growth in the tooling space, developers still have needs to be met, positioning Hardhat as our immediate-term solution to empower developers to keep decentralizing the world. + +Hardhat is an Ethereum development environment that developers use to compile, deploy, test, and debug Ethereum software. Most importantly, it's highly flexible, extensible, and designed to empower the community to build their own solutions. This strategy has been successful, and there's already [a valuable ecosystem of reusable plugins](https://hardhat.org/plugins/). + +Hardhat's roadmap is focused on becoming an extensible development environment with deep integrations across components in key areas of the tooling stack: + +- [Hardhat VSCode](https://medium.com/nomic-labs-blog/hardhat-vscode-9de29467fc26) — programming editor +- [Hardhat Ignition](https://medium.com/nomic-labs-blog/hardhat-ignition-5a34a4e3d2de) — contract deployment +- [Hardhat Network](https://hardhat.org/hardhat-network/) — local development network +- [Hardhat Runner](https://hardhat.org/getting-started/#overview) — build/testing workflow + +This roadmap leads to developers being well equipped to build powerful extensions to their workflow that increase their productivity according to their exact needs, and to then share them with the ecosystem in the form of plugins. + +Hardhat will also eventually migrate to using Rethnet and Slang, increasing its feature richness, speed, and stability while enabling dogfooding at scale for our brand new building blocks. + +### Web3.js as a frontend platform + +The OG Ethereum connector library, Web3.js, is being revitalized into a high-value project. By focusing on community and ecosystem growth, supported by an extensible architecture, it can become a great source of value, much like React represents in the front-end world, but for dapps. A website hub connecting community spaces, support spaces, educational resources, extensions, and related projects, combined with an active ecodev effort (workshops, talks, contests, and incentives), will create a source of leverage for the ecosystem. This will provide better troubleshooting, faster developer training, more reusable code, and, most importantly, the possibility of extending the library. This effort is currently spearheaded by the ChainSafe team. + +## Funding + +The Nomic Foundation aims to benefit the entire Ethereum ecosystem, which is why we’re fundraising across multiple organizations and individuals within it. + +The Ethereum Foundation is leading this round of contributions with $8M, alongside contributions from Vitalik Buterin, Coinbase, Consensys, The Graph, Polygon, Chainlink, Gnosis, a16z, a_capital, and Kaszek Ventures. These donors make up $15M, and we're aiming to raise $15M more. + +## Why Yearn? + +Generally, we think that allocating capital to the Nomic Foundation makes strategic sense for any protocol treasury that is aligned long term with the growth of Ethereum, and we've approached and will continue approaching several protocols. + +Currently, Yearn [builds](https://github.com/yearn/hardhat-monorepo/tree/main/packages) [some](https://github.com/yearn/ygift-ui/blob/master/hardhat.config.ts) of [its projects](https://github.com/yearn/stealth-txs/blob/main/hardhat.config.ts) [using Hardhat](https://github.com/yearn/strategies-keep3r/blob/main/hardhat.config.ts). While this is a signal of Hardhat’s value, the projects that the Nomic Foundation will deliver will create more value not just for Yearn, but for the entire ecosystem. We’ll provide services to the Ethereum community that will: + +1. Continue the maintenance of critical infrastructure used to build most protocols (Hardhat). +2. Increase developer productivity for every team in the ecosystem. +3. Accelerate developer onboarding to Ethereum, increasing the size of the experienced engineering hiring pool and making time-to-productivity shorter for new hires. +4. Accelerate the pace of innovation and the number of products being built. +5. Increase market volume driven by new users and new products. + +We believe this grows the market for everyone, including Yearn, and we’d love to have the **Yearn DAO contribute $400k in funding to this community effort**. + +## An ecosystem-wide effort + +We’re currently seeking funding from multiple DAOs. We’ll update with the corresponding links below as we create each forum thread. + +- [Uniswap forum thread](https://gov.uniswap.org/t/temperature-check-should-uniswap-governance-contribute-funding-to-the-nomic-foundation/16354) +- [Compound forum thread](https://www.comp.xyz/t/proposal-should-compound-governance-contribute-funding-to-the-nomic-foundation/3032) +- [ENS forum thread](https://discuss.ens.domains/t/temperature-check-should-ens-governance-contribute-funding-to-the-nomic-foundation/11148) +- [SushiSwap forum thread](https://forum.sushi.com/t/proposal-should-sushiswap-governance-contribute-funding-to-the-nomic-foundation/9658) + +## Links + +[Nomic Foundation Announcement](https://medium.com/nomic-foundation-blog/introducing-the-nomic-foundation-an-ethereum-public-goods-organization-31012af67df9) diff --git a/docs/contributing/governance/yips/yip-68.md b/docs/contributing/governance/yips/yip-68.md new file mode 100644 index 0000000000..45124449d2 --- /dev/null +++ b/docs/contributing/governance/yips/yip-68.md @@ -0,0 +1,46 @@ +--- +title: "YIP-68: Rotate multisig signers" +hide_title: true +sidebar_position: -68 +--- + +# YIP-68: Rotate multisig signers + +| Metadata | Details | +| --- | --- | +| YIP | 68 | +| Outcome | **Passed** | +| Authors | banteg | +| Created | 2022-06-16 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-68-rotate-multisig-signers/12582) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:ybaby.eth/proposal/0xc5386b7237f6c90359c56ac6dcb942b99a56a4de8ca60d109f4b999716148734) | +| Vote result | Yes: 844.37; No: 0 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-68.md) | + +## Summary + +Replace the three least active multisig signers with new people. After an [open call]( +https://twitter.com/bantg/status/1533222650838908928 +) and careful consideration, we've selected three candidates: 0xngmi, monoloco, and lefteris. + +## Motivation + +The multisig has been effectively operating as 6 of 6-7 with two signers being inactive and another one too busy with his own project. We appreciate their service, but we got to a threshold where we need another rotation. Here are the signing rates over the last two months, since 2022-04-13 till 2022-06-13. + +``` +owner +klim 100.0 +cp0x 99.0 +banteg 98.0 +daryl 91.0 +mariano 88.0 +leo 77.0 +--- cut here --- +vsh 39.0 +devops 6.0 +ryan 2.0 +``` + +## **Specification** + +Replace vsh, devops, ryan with 0xngmi, monoloco, and lefteris. diff --git a/docs/contributing/governance/yips/yip-69.md b/docs/contributing/governance/yips/yip-69.md new file mode 100644 index 0000000000..1d0f5e51c8 --- /dev/null +++ b/docs/contributing/governance/yips/yip-69.md @@ -0,0 +1,88 @@ +--- +title: "YIP-69: Reduce and cap fees through yRates" +hide_title: true +sidebar_position: -69 +--- + +# YIP-69: Reduce and cap fees through yRates + +| Metadata | Details | +| --- | --- | +| YIP | 69 | +| Outcome | **Passed** | +| Authors | banteg, flashfish, jiji, jmonteer, newmickymousse, saltyfacu, wavey | +| Created | 2022-06-17 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-69-reduce-and-cap-fees-through-yrates/12588) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:ybaby.eth/proposal/0xe4c2c990eaf4bb4a7a8031c461f5db820bae08fd7b81441d56e8cc0378c44afe) | +| Vote result | Yes: 912.03; No: 0 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-69.md) | + +## 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.fi/t/yip-51-set-vault-v2-fee-structure/ +2. https://gov.yearn.fi/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.fi/t/yip-65-evolving-yfi-tokenomics/ diff --git a/docs/contributing/governance/yips/yip-70.md b/docs/contributing/governance/yips/yip-70.md new file mode 100644 index 0000000000..57f47741b9 --- /dev/null +++ b/docs/contributing/governance/yips/yip-70.md @@ -0,0 +1,56 @@ +--- +title: "YIP-70: ApeWorX <> Yearn Partnership" +hide_title: true +sidebar_position: -70 +--- + +# YIP-70: ApeWorX <> Yearn Partnership + +| Metadata | Details | +| --- | --- | +| YIP | 70 | +| Outcome | **Passed** | +| Authors | fubuloubu, defidipshit | +| Created | 2022-09-19 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-70-apeworx-yearn-partnership/12721) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:ybaby.eth/proposal/0x1d34233f80a83c3fc4e41583ba115bfd51d3308c7b35249198cab0e49cd527f3) | +| Vote result | For: 1,019.57; Against: 0 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-70.md) | + +## **Summary** + +ApeWorX is proposing a partnership with Yearn contributors to add dedicated support for their use of the Ape open-source framework. During this partnership, ApeWorX will work closely with Yearn contributors to continue to meet their production needs for the project. + +In addition to technical support, ApeWorX will create content for our Ape Academy learning portal demonstrating how to use the Yearn template to create strategies and deploy them, and promote that content to our growing user base. We will also continue to develop Vyper tooling and integration to support the project’s focus and growth on Vyper for v3. Lastly, we will develop any requested smart contract development content to help find and onboard new contributors for protocol development and data analysis functions. + +## **Background** + +Ape is the smart contract development tool for Pythonistas, Data Scientists, and Security Professionals. ApeWorX was founded in 2021 by @fubuloubu, who designed Yearn v2, with the assistance of the creator of Brownie, based on his feedback of a redesign to that framework. Yearn contributors have been using Brownie, the predecessor of this framework, for nearly all of its smart contract and strategy development work since late 2020. + +However, Brownie has entered into a maintenance-only stage of its lifetime, while Ape is actively being developed and has been growing significantly over the last year. Looking to the future, ApeWorX plans on building out a suite of products and services around smart contract development, data exploration, and security research which are all areas Yearn contributors will benefit from with better tooling and support. + +## **Motivation** + +We've identified four ways that ApeWorX can assist Yearn contributors and the Yearn project moving forwards: + +### Support Services + +ApeWorX will provide a continuous point of contact between core contributors to Yearn and the ApeWorX team. We will collect and triage any issues with the framework, as well as collect further feature ideas and improvements, and work them into our development roadmap based on a balance of the Yearn project’s priorities and our other internal/partnership goals. With our team’s expertise and guidance, we can help support the safety and robustness of the Yearn protocol and it's continued development. + +### Prioritized Development + +We will provide two (2) dedicated engineering resources to drive the project’s priority roadmap, including development of core features and plugins to support production milestones. These resources will ensure that we are always making the progress necessary on our development roadmap to support priorities as they grow and change. + +### Best-in-class Vyper Tooling and Integrations + +For v3, Yearn contributors has decided to double-down on developing their protocol using components written in Vyper. To maintain a competitive edge, ApeWorX will continue to innovate Vyper tooling in the framework for Yearn contributors, speeding up product development and security work, in order to make Yearn v3 the most secure, scalable, and decentralized protocol yet. + +### Attracting Developer Talent + +In order to thrive, the project needs to further develop a talent pool onboarding more protocol developers, strategists, and other contributors. ApeWorX will promote these objectives by leveraging our Ape Academy product, which is a project-based learning platform for building in Web3 using Ape Framework. Through this platform we will collaborate with Yearn contributors to develop Ape Academy content for strategy creation and onboard more Vyper developers, which is a key area of improvement for the project. + +## **Specification** + +For this partnership, ApeWorX is proposing a grant totaling 100 YFI tokens. These tokens will be streamed to `wallet.apeworx.eth` using a Llamapay stream over a period of 24 months. The stream can be canceled at any time, signifying the end of any advanced collaboration between ApeWorX and Yearn contributors. At the end of the 24 month period, a renegotiation of these grant terms can occur to continue the arrangement into the future. + +The grant amount will align ApeWorX significantly with the long-term success of the Yearn project, and ensure mutual benefit from the work being provided on their behalf. diff --git a/docs/contributing/governance/yips/yip-71.md b/docs/contributing/governance/yips/yip-71.md new file mode 100644 index 0000000000..619e4d6515 --- /dev/null +++ b/docs/contributing/governance/yips/yip-71.md @@ -0,0 +1,86 @@ +--- +title: "YIP-71: Activate veYFI" +hide_title: true +sidebar_position: -71 +--- + +# YIP-71: Activate veYFI + +| Metadata | Details | +| --- | --- | +| YIP | 71 | +| Outcome | **Passed** | +| Authors | darkghosty, flashfish, jiji, saltyfacu | +| Created | 2022-11-25 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/proposal-activate-veyfi/12783) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:ybaby.eth/proposal/0xc50b60f712adb8568f10f565fc467e8c5d8fe1f4920683696f81c7920397942a) | +| Vote result | For: 1,259.81; Against: 2.69; Abstain: 0.02 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-71.md) | + +## Summary + +Replace YFI voting with vote-escrowed YFI (veYFI) voting for all future governance proposals. + +### Status + +**Discussion** +This proposal is currently in the discussion phase. As per our voting rules outlined in YIP-55, it will be in discussion for at least 3 days with a non-binding forum poll to gauge sentiment before it can be assigned a YIP number and move to Snapshot for a binding vote. + + +## Abstract + +**If adopted**, this proposal seeks to: +* Replace YFI with veYFI as the voting token in Governance +* Adopt a 2 week long moratorium on new YIPs where no proposals will be voted on + +## Background + +This proposal is the first step in the implementation of YIP-65: Evolving YFI Tokenomics[[1]](#references). YFI is time-locked up to 4 years where a longer lock increases the relative weight in relation to other locked tokens. It is strongly recommended that the reader first familiarize themselves with the concepts of YIP-65 in order to better understand this proposal. + +### Out of scope + +The following topics were intentionally not covered by this proposal: +* Yearn Tokenomics +* Gauges +* Rewards +* On-chain voting + +## Motivation + +This implements parts of what was was adopted by YFI voters in YIP-65, namely locking YFI into veYFI, managing one's lock, and using it to vote in governance. There are no YFI rewards or gauges yet. There is no advantage to locking early. + +### Future possibilities +* Deploy additional components of YIP-65 +* Transition to on-chain voting and governance + +### Risks + +* Governance attacks, mitigated by a moratorium on new YIPs being accepted +* Smart contract risk in the veYFI contracts, which have been mitigated through security reviews by Statemind, yAcademy, and ChainSecurity[[2]](#references). + +### Alternatives considered + +None + +## Specification + +1. veYFI is implemented as per the deployed contract[[3]](#references), from the veYFI github repo[[4]](#references). +2. **DO NOT INTERACT WITH THE CONTRACT TO LOCK YFI** until this proposal passes. There is **NO USE** for locking YFI until this time. There is **NO UPSIDE** in locking early. There are **NO REWARDS** at this point. +3. It's a typical veCRV style locking design: + * 1 lock per address + * Min lock: 1 week, max lock 208 weeks (4y) + * Linear decay + * Extendable lock duration +4. Immediately upon the passing of this YIP, **all subsequent YIPs are voted on using veYFI**. +5. Voting continues to be done using Snapshot. +6. To reduce the risk of governance attacks by allowing enough YFI holders to lock so as not to give small YFI balances outsize influence over the protocol, a **2 week moratorium** on YIPs are passed. Any YIP proposal submitted in this period will only be considered for voting 2 weeks after the passing of this YIP. +7. Contributor YFI is migrated into veYFI as per YIP-66: Streamlining contributor compensation[[5]](#references). +8. veYFI voters may replace this voting mechanism in the future with some other design, by submitting a YIP and voting it through. + +## References + +1. https://gov.yearn.fi/t/yip-65-evolving-yfi-tokenomics/11994 +1. https://github.com/yearn/yearn-security/pull/70/files +1. https://etherscan.io/address/0x90c1f9220d90d3966fbee24045edd73e1d588ad5#code +1. https://github.com/yearn/veYFI/commit/bb9d8ac9dd90a9a9772b9663ce4fa232fda7bce2 +1. https://gov.yearn.fi/t/yip-66-streamlining-contributor-compensation/12247 diff --git a/docs/contributing/governance/yips/yip-72.md b/docs/contributing/governance/yips/yip-72.md new file mode 100644 index 0000000000..db4f4c107b --- /dev/null +++ b/docs/contributing/governance/yips/yip-72.md @@ -0,0 +1,306 @@ +--- +title: "YIP-72: Launch yETH" +hide_title: true +sidebar_position: -72 +--- + +# YIP-72: Launch yETH + +| Metadata | Details | +| --- | --- | +| YIP | 72 | +| Outcome | **Passed** | +| Authors | 0xkorin, 0xPickles | +| Created | 2023-04-21 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/proposal-launch-yeth/13158) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0x8969cde98d5d8a7be745e442a3288ce0cf3b35bf99ab72265f66c96d117a0f78) | +| Vote result | For: 152.37; Against: 0 | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-72.md) | + +## Summary + + + +Launch yETH - a permissionless and self-governing representation of a basket of ETH Liquid Staking Tokens (LSDs). + +## Abstract + + + +**If adopted**, this proposal seeks to: +* Ratify the Design Specification of yETH and endorse its deployment. +* Specify the bootstrapping and implementation process. +* Specify parameters and initial configurations. +* Specify functionality during normal operations. + +## Background + +Yearn ETH (yETH) is minted when users deposit into a basket of various ETH Liquid Staking Tokens (LSDs). yETH enables reclaiming the deposited value and, when staked, earning the associated Ethereum PoS staking rewards with a more blended risk/reward profile through diversification of LSDs. + +With an ever-growing number of LSDs, each has different yield, risk, and decentralization profiles, as well as varying degrees of market liquidity. Diversifying and hedging staked ETH positions across these protocols to reduce the impact of one failing is challenging. Market pricing inefficiencies can lead to trading opportunities against the underlying backed ETH value of the protocol. Staked ETH in a standard liquidity pool is not ideal from a collateral perspective, as the pool is only ever as safe as the least safe LSD in it. Meanwhile, new LSDs may struggle to grow and attract enough usage and liquidity to be competitive against protocols with large market share. + +yETH is conceived as a solution to these challenges. + +### yETH in a nutshell + +* The protocol functions as a Curve-style stable asset pool containing a dynamic number of assets. Unlike a Curve pool, the pool composition can fluctuate only within predefined ranges - each asset has a target weight as a % of total pool assets and a band within which it can fluctuate. This helps protect yETH's function as collateral in severe depegging or slashing events. +* Users deposit LSDs or ETH into the pool and receive yETH. Users burn yETH to receive LSDs. +* 1 yETH corresponds to 1 ETH staked in the underlying LSDs and owned by the yETH pool. +* Vanilla yETH does not earn yield. Instead, users stake yETH as Staked yETH (st-yETH) to earn compounded yETH according to the earnings of LSDs and other protocol rewards. +* Users can swap assets with the yETH pool, paying a fee to st-yETH holders. +* st-yETH holders govern all aspects of the protocol. They decide which LSDs to include in yETH, set the target composition of the pool, and configure protocol parameters. +* LSD protocols can use yETH as a liquidity source for their protocol. They can reward st-yETH holders for whitelisting the protocol in the yETH pool, for increasing the protocol’s relative weight in the pool, or increasing uptake and usage of their LSD. + +### Design Principles + +The yETH protocol is designed to be: + +* **Self-governing.** yETH token holders (via st-yETH) control the protocol in its entirety. +* **Immutable.** yETH is not upgradable. Improvements require deploying a new version. +* **Trust-minimized.** No third-party should be able to access funds or alter the state of the protocol. Users remain in control of their own funds. +* **Autonomous.** Critical operation of yETH should not rely on any third-party individuals, group, or entity. + +### Out of scope + +Yearn contributors and YFI/veYFI token holders are not involved in: + +- ETH staking. +- Operating ETH validators, Consensus Layer clients, or Execution Layer clients. +- Evaluating LSD protocols for yETH inclusion. +- Setting asset weights or altering yETH protocol behavior. +- Yield and product performance. This is determined by the protocol's configuration, which is governed by its users. + +## Motivation + + + +### Use Case Examples + +* As a **user**, I can hold yETH to potentially achieve a better risk-adjusted yield than any single individual LSD. +* As a **searcher**, I can arbitrage yETH when price imbalances arise to earn profits. +* As a **DeFi protocol**, I can accept yETH as collateral and enjoy greater guarantees around its value compared to any single individual LSD token. +* As an **LSD protocol**, I can incentivize my token's inclusion in yETH to increase demand and usage while raising awareness of my product. + +### Future Possibilities + +* Use yETH as collateral in other smart contract systems, including Yearn. +* Deploy yETH-related vaults and strategies. +* Allow third parties to optimize asset weights and allocation permissionlessly. +* Introduce new smart contract systems/protocols for various asset types. + +### Risks + +Some potential risks include: + +* An LSD in yETH experiences severe depegging, failure, or exploitation. +* A critical flaw in yETH's design or implementation results in unintended behavior. +* Poor asset choices or incorrect protocol parameters by st-yETH voters lead to subpar performance and functionality. +* Unattractive yield due to increased competition in ETH staking, causing reduced demand. + +### Alternatives Considered + +- Creating a Yearn-themed ETH LSD: Rejected due to lack of perceived competitive advantage over existing protocols. +- Utilizing an existing pool design: Rejected as no existing designs allow stable assets to be swapped within bands while their composition is dynamically updated. +- Granting veYFI governance power: Rejected to prevent yETH from becoming reliant on third-party operation and functionality. + +## Specification + + +### 1. Design Spec + +1. Approve the yETH protocol specification described in `SPECIFICATION.md` [[#1]](#references). + +### 2. Role Assignment + +1. **Treasury:** Yearn Treasury or an autonomous splitter contract directed by yBudget. +3. **Management:** yChad, to execute st-yETH voters' decisions only. Replaced by a smart contract after successful launch. +3. **Guardian:** "yETH-guard", a Gnosis Safe with a 2-of-7 signing threshold, consisting of Yearn contributors to monitor the protocol and trigger Pause mode if needed. Guardian participation is done on a gratuitous, volunteer basis–no duty of care or ongoing monitoring is assumed or implied. + +### 3. Normal Operation Requirements + +#### 3.1 Epochs & Voting + +1. The duration of an Epoch is four weeks. +2. Epochs start every Thursday at `00:00:00 UTC`, aligning with Curve's veCRV epochs. +3. One week before the start of a new epoch is the voting period. +4. At the start of the voting period, a snapshot of st-yETH holders' voting power is taken, and st-yETH holders vote using this snapshot. +5. st-yETH voting power increases asymptotically weekly. +6. Vote weight of st-yETH tokens resets upon transfer. +7. There are three types of governance proposals: + 1. **Weight Allocations:** The distribution of yETH asset weight based on voter preferences. + 1. **Whitelisting Proposals:** The selection of assets for yETH inclusion. + 1. **General Proposals:** Suggested parameter changes and other matters. +8. Each voting period has one Weight Allocation vote and may have one Whitelisting vote (if there is at least one LSD protocol applying for inclusion), and any number of General Proposals to vote on. +9. General proposal submission occurs in a dedicated Yearn governance forum section. +10. Voting starts with Snapshot, transitioning to on-chain later. +11. No quorum requirements. +12. Fractional voting is permitted. +13. Votes are final and irreversible. +14. General proposals require a 2/3 qualified majority vote (66.66% in favor). +15. General proposals execute in submission order; later proposals override earlier ones. +16. No proposals are accepted during active voting periods. +17. At the start of each epoch, new assets are whitelisted, approved proposals are enacted, and weight votes are applied. +18. Yearn contributors may add proposal warning notes but are not required to. No proposal review process exists. + +#### 3.2 Whitelisting + +1. Whitelisting is the process of adding an asset to yETH's composition. +1. Only one new asset can be whitelisted per epoch. +1. The maximum number of assets in yETH is 32. +1. LSD protocols seeking whitelisting pay an application fee (in yETH) before the voting period starts. +1. The application fee is distributed to the POL Contract. +1. Application fees are used to seed whitelisted assets into yETH, gradually introducing them into the asset composition. +1. The yETH used for seeding is distributed by the POL Contract to st-yETH holders as yield. +1. During the voting period, st-yETH holders vote on asset inclusion (if any). +1. Voters may choose not to whitelist any assets, maintaining yETH's current composition. +1. The option with the most votes is chosen as the outcome. +1. LSD protocols may apply for whitelisting in multiple epochs, paying application fees for each attempt. +1. Whitelisted assets start with a target weight near 0%, gradually increasing to the Initial Weight parameter, adjusting other assets accordingly. +1. A Rate Provider contract must be deployed before the whitelisted asset's inclusion. + +#### 3.3 Parameters + +Default values of the parameters below can be changed by st-yETH token holders voting to pass General governance proposals: + +| Parameter | Description | Configurable Range | Default | +|---|---|---|---| +| `t_half` | Time taken to accumulate half the voting weight | 7-365 days | 60 days (180 days to reach 75% voting power) | +| Weight to be voted on | Weight allocated to each whitelisted asset for voting on reallocation per epoch | 1-33% | 10% | +| Amplification parameter `A` | Same property as in a typical Curve pool, determines the sensitivity to pool imbalances | N/A | 450 | +| Tolerance range | Permissible deviation range of assets from their target weight (configurable per asset) | +/- 100% | +/- 5% for all assets | +| Application Fee | Fee to apply for whitelisting as an LSD protocol | 0-10 yETH | 1 yETH | +| Initial Weight | Initial weight assigned to a whitelisted asset | 0.1-1.0% | 1.0% | +| Pool Swap Fee | Fee charged for swapping assets with the pool, paid to st-yETH holders | 0.00-1.00% | 0.03% | +| Protocol Fee | Performance fee paid to Yearn Treasury | 5-20% | 10% | + +#### 3.4 Incentives + +1. yETH natively supports LSD protocols offering rewards as an incentive for st-YETH holders to integrate and support their respective protocols. +2. Any asset can be offered as a reward for passing a specific outcome of a Governance proposal (Weight allocation, Whitelisting, or Governance proposal). +3. Both positive (vote in favor) and negative (vote against) incentives are accepted. +4. Inventives can be posted during the three-week interval between voting rounds. +5. Incentives are not accepted during active voting rounds. +6. If an outcome doesn't occur, the poster can claim their incentive after the voting round concludes. +7. If an outcome occurs, incentives are distributed to **all** st-yETH voters who participated, regardless of their vote. +8. A 1% fee on successful incentive rewards is paid to Yearn Treasury. + +#### Figure 1. Normal Operation Timeline +```markdown +|--week1--|--week2--|--week3--|--week4--|--week5--|... +| epoch 0 | epoch 2... +| incentives for vote 1 | vote 1 | incentives for vote 2... + x st-yETH snapshot for vote 1 + x update yETH according to vote 1 results + x distribute vote 1 incentives +``` + + +### 4. Minting Permissions + +Only three smart contracts are allowed to mint yETH: + 1. The Pool, holding LSD assets and minting yETH at a 1:1 ratio to the ETH equivalent of these assets. + 2. The Bootstrapper, used to launch yETH, with minting enabled only for a limited time period. + 3. The POL contract, providing protocol-owned liquidity in pools. + +### 5. Bootstrapping Requirements + +#### 5.1 Whitelist +1. Duration: 3 weeks +2. To be included in yETH bootstrapping, LSD protocols must pay a 1 ETH non-refundable fee, which turns into yield for st-yETH users. +3. Protocols then fill out a form with basic screening questions. +4. Yearn contributors review responses, filtering out fraudulent applications without evaluating protocol quality. They may add warnings, but their absence shouldn't imply support. +5. Screened LSD protocols are whitelisted for the bootstrap phase. + +#### 5.2 Incentives +1. Duration: 2 weeks, overlapping the final week of whitelisting. +2. Incentive reward requirements resemble Normal Operation but prioritize votes for whitelisted LSD protocols during bootstrap. + +#### 5.3 Deposit +1. Duration: 2 weeks, concurrent with the incentive phase. +2. Future yETH users deposit ETH in the Bootstrapper contract, receiving 1:1 st-yETH. +3. The contract logs its yETH debt. +4. Bootstrap st-yETH is locked for 16 weeks, unless the yETH pool is 'killed'. +5. At the deposit phase end, Bootstrapper disables deposits and yETH minting. + +#### 5.4 Vote +1. Duration: 1 week, following Incentives. +2. Voting resembles Normal Operation but focuses on selecting LSD protocols for yETH at launch. +3. The top 5 LSDs with the most votes are included. +4. No single LSD can exceed 45% of the total pool weight. +5. If fewer than 5 LSDs apply, protocols with votes are included, and pool weight is assigned based on vote share. +6. Included LSDs have tolerance ranges of +/- 5%. + +#### 5.5 Launch +1. Duration: 2 weeks (approx) +2. Incentive rewards are given to st-yETH holders who participated in voting. +3. Rate Provider contracts are deployed for each approved LSD. +4. 90% of deposited ETH buys LSDs for the initial yETH composition, as determined by voters. + 1. LSD purchases occur via yChad, using CowSwap and the Yearn SeaSolver (when possible) for best execution. + 2. Bought LSDs enter the yETH pool, minting yETH. + 3. This yETH repays the bootstrapper's debt (up to 90%). + 4. Surplus LSDs from market discounts are distributed as yield to st-yETH holders. +5. The remaining 10% of deposited ETH serves as POL. +6. A yETH/ETH Curve Pool is deployed. +7. A yETH/ETH Curve Pool Gauge is requested. +8. If a Gauge is approved, a yETH/ETH Curve yVault is deployed from the Yearn Curve Vault Factory. + +#### Figure 2. Bootstrap Timeline +```markdown +|--week1--|--week2--|--week3--|--week4--|--week5--|--week6--|--week7--|... +| Whitelist | + | Incentive | + | Deposit | + | Vote | + | Launch +``` + + +### 6. Protocol Owned Liquidity + +#### 6.1 Initialization +1. Transfer 10% of ETH acquired during Bootstrapping to the POL contract. +2. The debt owed to Bootstrapper contract is repaid during POL operations or in case of a Full Redemption. + +#### 6.2 yETH Minting and Usage +1. The POL contract can only mint yETH equivalent to its available ETH. +2. yETH minted for POL is exclusively used to provide liquidity in various protocols. +3. The POL contract burns yETH after providing liquidity. + +#### 6.3 POL Modules +1. POL operations are managed via privileged function calls through POL Modules attached to the POL Contract. +2. Function calls are executed by a Gnosis Safe multi-sig managed by the yETH yTeam. +3. The POL Contract transfers minted yETH to POL Modules for operations. +4. Call capabilities are limited to predefined operations for ongoing POL management, prohibiting arbitrary actions. +5. The POL contract and POL Module contracts are immutable. +6. POL Module contracts can be attached and detached to the POL contract with st-yETH voter approval. +7. The POL contract can be replaced via governance proposal approved by st-yETH voters. +8. At launch, there will be a yETH/ETH Curve pool POL Module and a Full Redemption Module. + +#### 6.4 Full Redemption Module +1. If yETH pool enters "Killed" state (via st-yETH vote), the POL contract accepts redemptions. +2. The POL contract unwraps LP positions and burns excess yETH. +3. Users can send yETH to the POL contract to redeem ETH. +4. Received yETH repays outstanding Bootstrapper debt. + +#### 6.5 Excess Assets +1. Unused ETH from bootstrapping may be converted into LSD tokens and deposited into yETH, to improve yield for st-yETH holders. +1. Excess resulting from POL operations can be: + 1. Divested to st-yETH holders as extra yield. + 2. Reinvested into expanded POL operations, such as additional liquidity pools or protocols to increase yETH liquidity. + +### 7. Implementation +1. After this proposal's approval, yETH begins the bootstrapping phase. +2. Yearn contributors are mandated to execute and deploy contracts according to the design specification in this section. +3. Once yETH is operational and functioning correctly, Yearn contributors are mandated to codify all operations on-chain using smart contracts, achieving full immutability. +4. The aim is to achieve full immutability within 90 days of yETH operation. + +### 8. Use at Own Risk +yETH is designed to be governed by its token holders who decide on assets to onboard and configure the protocol. Yearn contributors and YFI token holders are not involved and will not compensate users for any critical failure or loss of funds resulting from yETH usage. + +## References + +1. https://hackmd.io/@0xkorin/BJDmRreMh + +## Changelog +- _Apr 13:_ Original post +- _Apr 17:_ Explicitly permit POL to convert ETH position into yETH (6.5.1), Add changelog section diff --git a/docs/contributing/governance/yips/yip-73.md b/docs/contributing/governance/yips/yip-73.md new file mode 100644 index 0000000000..279d580d13 --- /dev/null +++ b/docs/contributing/governance/yips/yip-73.md @@ -0,0 +1,326 @@ +--- +title: "YIP-73: Activate veYFI rewards with oYFI Gauges" +hide_title: true +sidebar_position: -73 +--- + +# YIP-73: Activate veYFI rewards with oYFI Gauges + +| Metadata | Details | +| --- | --- | +| YIP | 73 | +| Outcome | **Passed** | +| Authors | veYFI Secret Admirers working group | +| Created | 2023-06-27 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-73-activate-veyfi-rewards-with-oyfi-gauges/13414) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0xcc2a5f2bad97b551a02230975def5640c6f582d64c3c42eecfb1c6c76eea3b28) | +| Vote result | For: 160.49; Against: 0 | +| Source | [Source](https://gov.yearn.fi/t/yip-73-activate-veyfi-rewards-with-oyfi-gauges/13414) | + +_Authors: The members of the “veYFI Secret Admirers” working group_ + +## Summary + +Introduce the oYFI token for use in the veYFI gauges outlined in YIP-65, define processes, deployment, and the transition towards full immutability. + +### 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 by veYFI holders. + +## Abstract + +**If approved**, this proposal will: + +- Introduce the oYFI token. +- Assign oYFI as the reward token for vault gauges. +- Establish the emission of oYFI rewards based on the veYFI lock rate. +- Detail the launch specifications for veYFI rewards. +- Define veYFI epochs and voting. +- Set up guidelines for the eventual transition to full immutability. + +## Background + +### YFI Buybacks + +The total supply of YFI tokens is 36,666, which has been completely distributed. Following the adoption of YIP-56[\[1\]](#references), YFI tokens are bought back from the open market using earnings from yearn vaults. This process is automated, and as of this writing, about $23.7 million USD equivalent has been used to purchase 1,311 YFI, averaging a price of $18,100 per token.[\[2\]](#references) + +### Tokenomics post YIP-65 + +YIP-65[\[3\]](#references) outlined a roadmap for the future of YFI tokenomics. Following this, veYFI was introduced[\[4\]](#references), enabling YFI tokens to be “vote escrowed” for up to four years. This token, veYFI, controls yearn governance. This proposal aims to activate section 2.3 of the YIP-65 spec, “Vault gauges + Voting”, using oYFI as a new type of reward token. + +### Summary of the veYFI Tokenomics Program + +Users can lock YFI as veYFI for up to four years to control yearn’s governance proportionally to the duration-weighted amount of their lock. They can exit this lock early, paying a penalty of up to 75% of their locked YFI, which is proportionally allocated to remaining veYFI lockers. + +Tokenomics rewards are in the form of oYFI, a token that allows its holder to buy back YFI at a discount. The discount rate depends on the amount of veYFI currently locked in the protocol. Rewards are distributed over epochs, with the total rewards per epoch also determined by the amount of veYFI locked in the protocol. + +In every epoch, veYFI voters allocate the distribution for the next epoch to oYFI gauges. Each gauge receives an amount of oYFI according to the votes received in the previous epoch. Yearn vault depositors stake their vault tokens into oYFI gauges to earn oYFI. The earned oYFI amount is determined by the user’s “boost”, their share of gauge TVL in relation to their share of veYFI. Users with boosts that is below the max forfeit some of their oYFI rewards to veYFI lockers. + +In summary, gauge depositors earn oYFI according to their boost. veYFI holders earn YFI from users who exit their locks early, and oYFI from gauge depositors who do not hold max boost. + +### Implementation + +A working implementation is available in the yearn/veYFI repository[\[5\]](#references) and has been audited by ChainSecurity.[\[6\]](#references) Post-audit, a configurable scaling factor `s` has been added to oYFI, and `x` has been adjusted to avoid short duration locks biasing the formula. + +### Out of Scope + +- This proposal **does not** involve minting new YFI tokens; rewards in this system consist solely of tokens purchased from the open market. +- This proposal **does not** attempt to promote YFI as an attractive investment; its purpose is to redistribute governance power to the most active community members and protocol users. +- This proposal **does not** aim to increase yearn treasury holdings; instead, it ensures bought back YFI is redistributed back to protocol users and YFI token holders. + +## Motivation + +This proposal continues Yearn’s implementation of YIP-65. Previously, the protocol was upgraded to enable YFI holders to vote-escrow their YFI and thus autonomously receive YFI rewards for committing to help govern the protocol (constantly increasing active governors’ relative share of governance power and kickstarting a decentralized governance flywheel). + +With this YIP, YIP-65 continues by boosting the governance rewards of veYFI holders (governors) who also happen to be Vault depositors—this ensures that the most committed Yearn community members increase their governance power at an even faster rate, deepening the governance flywheel and helping maximize the protocol’s autonomy. + +Approving this proposal won’t make you richer, but it will ensure that those most committed to governing and using the system will steadily increase their governance power, keeping Yearn on track to be a fully self-governing protocol. + +### Epochs + +Just like Curve Finance’s seminal veCRV design, veYFI uses epochs to redirect rewards frequently as determined by veYFI voters. This responsiveness allows the model to adapt to changing needs. + +### veYFI Rewards Emission + +The emission of bought back YFI is inspired by the Ethereum staking emission model.[\[7\]](#references) Instead of validators, the driving variable is the amount and duration of YFI locked in veYFI. + +The rationale is to act as a dampening function on both extremes of the spectrum; as more YFI is locked, the rewards per veYFI can decrease. Similarly if less YFI is locked, the rewards per veYFI increase. + +As there is no minting of new tokens, the emission model is conservative to ensure rewards last longer. + +Through blank voting, veYFI holders have the power to postpone emission slated for an epoch into the future, in order to further conserve emission and extend the runway of the tokenomics program. + +### veYFI Gauges and Boost Penalties + +The rewards we emit are to gauges where yearn vault tokens are staked, ensuring that only genuine users of yearn protocols receive rewards. + +However, we do want to discourage large depositors from monopolizing rewards unless they are actively involved in yearn governance. + +This is achieved through a modified form of boost, pioneered by Curve Finance and Michael Egorov, where gauge depositors must hold veYFI in proportion to their share of deposits in a gauge to maximize their rewards. The difference is paid as penalties to veYFI holders. + +### oYFI + +To avoid rewarding predatory users who farm tokens only to sell them off, we propose oYFI, partially inspired by a design proposed by Andre Cronje for the K3PR protocol.[\[8\]](#references) + +oYFI allows its holder to obtain bought back YFI at a discount from the current spot market price, with the discount rate varying based on the proportion of veYFI locked. + +As more veYFI is locked, the discount decreases. When veYFI decreases, discount increases to attract more locking. + +The proceeds are then routed towards more YFI buybacks, improving the sustainability and longevity of the program. + +### Considerations + +Refer to YIP-65 for additional related considerations. + +#### Future Possibilities + +- Tokenomics program could be utilized as a “liquidity for hire” model where protocols remunerate yearn users to channel liquidity into their pools. +- Introduction of incentive programs to drive specific results or emission votes. +- Usage of epochs and voting process for passing YIPs and governance proposals that aren’t related to tokenomics. +- Expansion of veYFI’s “useful work”, perhaps acting as emergency protocol backstops, parameter tuning, and operational management of vaults. +- Adding more pathways for emissions and penalties to stimulate the effective governance of the yearn protocol suite. +- Further enhancing the “skin in the game” for YFI token holders to ensure their actions and decisions deeply impact the performance of the yearn protocol suite. + +#### Risks + +- A potential flaw in the tokenomics model design or implementation could lead to unexpected reward behavior or loss of funds. +- The introduction of low-quality veYFI gauges may result in rewards being redirected there, leading to less benefit to the yearn protocol. +- The tokenomics model may not attract enough Total Value Locked (TVL) to sustain future rewards with buybacks and may need to be reassessed at some point. +- Changes to rewards and emission parameters made by veYFI voters could result in suboptimal behavior and performance. + +#### Alternatives Considered + +- Rewarding unlocked YFI: This was avoided to mitigate the risk of disbursing YFI to users who are not interested in holding the token for governance purposes. +- Directing rewards to veYFI lockers directly: This was avoided to ensure that rewards flow to active rather than passive protocol participants, i.e., users of yearn vaults. +- Restricting third-party protocols from building on top of the tokenomics program: This was avoided in favor of creating a contract-friendly, permissionless block for others to build upon. We explicitly welcome additional third parties to build on top of the yearn suite of protocols. + +## Specification + +**Note:** The spec outlines the desirable end state. Some compromises may need to be made during the rollout before the final state is reached. Refer to Section 8 below. + +### 0\. Definitions + +- YFI: Unlocked YFI token +- veYFI: YFI token locked for a duration of up to 4 years (208 weeks), where `veYFI = YFI * lock_duration_as_share_of_max`. For example, 100 YFI locked for 1 week equals 100 x (1/208) ~= 0.48 veYFI. This operates as per the contract deployed[\[9\]](#references) with the passing of the proposal to activate veYFI.[\[4\]](#references) + +### 1\. oYFI + +1. Is a token that implements the ERC-20 standard. +2. Gives its bearer the right to redeem an equivalent of YFI, in exchange for ETH. +3. oYFI is burned upon redemption. +4. The circulating supply of oYFI must not exceed the amount of YFI that is available to be redeemed as part of the tokenomics program. +5. The amount of ETH required for redemption is at a discount of the current spot price of YFI/ETH. +6. Discount calculation is an approximation of the following formula: + + ``` + discount = c/(1 + a * e^k(s*x − 1)), where + c = 1 + a = 9.9999 + k = 4.6969 + s = configurable scaling factor + x = veYFI_supply / YFI_supply + ``` + +7. ETH received from oYFI redemption is redirected to automated YFI buybacks that are handled by an immutable smart contract, like the one already in production for DAI.[\[2\]](#references) + +### 2\. Epochs + +1. veYFI epochs last for 14 days, commencing on Thursdays 00:00:00 UTC. +2. Epochs are synced to coincide with Curve’s veCRV epochs and yETH’s epochs. + +### 3\. Emission + +1. Rewards are paid as oYFI. +2. These rewards are distributed to Gauges (see below) at the beginning of each epoch. +3. The annual rewards emission is calculated as an approximation of the following formula: + + ``` + oYFI_emitted = c * sqrt(veYFI_supply), where + c = configurable scaling factor + ``` + + +### 4\. Gauges + +1. A gauge is an ERC20 token and vault that implements the EIP4626 standard. +2. Users deposit yearn vault tokens to earn oYFI rewards according to their boost. +3. Boost ranges from 1-10x and determines a user’s share of rewards. Positions with less than a 10x max boost forfeit a share of their oYFI rewards. At best, a user with a 10x boost earns 100% of their rewards; at worst, a user with a 1x boost forfeits 90% of rewards. +4. Forfeited oYFI are proportionally allocated to veYFI lockers as additional rewards. +5. The earning weight (`current_boost/max_boost`) is calculated in the same way as in Curve[\[10\]](#references), when accounted for a 10x max boost instead of Curve’s 2.5x: + + ``` + weight = min(Gauge.balanceOf(user), 9/10 * Gauge.totalSupply * veYFI.balanceOf(user)/veYFI.totalSupply + Gauge.balanceOf(user)/10) + ``` + + +### 5\. Voting + +1. veYFI holders vote on gauge emission and governance proposals. +2. Voting takes place in the second half of the epoch. +3. To discourage last-minute voting, there is a linear decay of voting weight in the final 24 hours of the epoch, reaching 0% voting weight at the last block of the epoch. + +#### 5.4 Gauge emission votes + +1. Gauge emission votes set the distribution of oYFI allocated in an epoch, determining which specific gauge should receive what portion of oYFI emissions. +2. 10% of an epoch’s total emission is allocated to specific gauges: + +- 5% of total to encourage YFI/ETH liquidity +- 5% of total to encourage oYFI/ETH liquidity + +3. veYFI holders vote on the remainder 90% allocation. +4. Voters can cast “blank” votes, which leads to this proportion of oYFI rewards being taken out of the epoch’s emission allocation. +5. The blank vote oYFI can be burned, thereby extending the runway of the tokenomics program, or moved to the immediately next epoch’s emission allocation, thereby increasing rewards in the next epoch. +6. The amount of oYFI burned vs moved is configurable by a parameter. +7. Voters can cast many votes per epoch, but any gauge can only be voted on once in a single epoch. +8. Votes reset at the start of a new epoch; there is no carry-over of votes between epochs. + +#### 5.5 Governance proposals + +1. Governance proposals include, but are not limited to: + +- Adding new gauges +- Removing existing gauges +- Changing parameters + +2. Proposals can be submitted in the first half of the epoch. +3. Proposal submission occurs in a dedicated Yearn governance forum section. +4. Any address holding 1 veYFI or more is able to submit a governance proposal. +5. Governance proposals pass by simple majority (>50% of the veYFI vote). +6. There is a configurable quorum parameter, a minimum amount of veYFI that needs to vote in favor for a governance proposal to pass, regardless of the number of votes in support. + +### Figure 1. Epoch Timeline Illustration + +``` +|------week-1------|-----week-2-----|------week-3------|-----week-4------|... +| epoch n | epoch n+1... +| proposals n+1 | vote n+1 | proposals n+2 | vote n+2... + x vote power decay + x distribute n+1 rewards to gauges +``` + +### 6\. Configurable parameters + +These are the parameters that veYFI holders can adjust via governance proposals. + +| Parameter | Description | Configurable Range | Default | +| --- | --- | --- | --- | +| Quorum | The minimum amount of veYFI needed to approve a governance proposal | 0-10\_000 veYFI | 10 veYFI | +| Blank Vote Burn | The percentage of oYFI from blank gauge emission votes that are burned instead of moving to the next epoch | 0%-100% (100% means all oYFI is burned; 0% means all oYFI transfers to the next epoch) | 50% | +| `s` | Scaling factor for oYFI discount | 1.00 - 12.00❉ | 10.00 | +| `c` | Scaling factor for oYFI emission | 4 - 64❉ | 12 | +| YFI Gauge | The gauge that gets at least 5% emission for YFI liquidity | `address` | YFI/ETH Curve LP yVault | +| oYFI Gauge | The gauge that gets at least 5% emission for oYFI liquidity | `address` | oYFI/ETH Curve LP yVault | + +❉ _Change is applied with linear scaling over the course of an epoch to prevent front-running._ + +### 7\. Launch Steps + +If this YIP is approved, the following steps will be taken to launch the programme: + +1. **Epoch 1 voting snapshot announcement:** One week in advance, a timestamp for the first Epoch’s vote is announced. This allows users to lock YFI into veYFI to participate. +2. **Deploy oYFI.** +3. **Seed oYFI/ETH:** Determine the value of oYFI (its YFI discount) based on the snapshot veYFI balance for Epoch 1. Mint $5k worth of oYFI and seed it with an equivalent amount of ETH in a Curve v2 pool. +4. **Deploy initial gauges:** Launch the initial gauges (see below) as they become available. +5. **Start epoch 1:** Seed gauges with oYFI and prepare for epoch 2 voting. +6. **Apply for oYFI/ETH CRV gauge on Curve.** Attach strategy to oYFI/ETH Curve LP yVault if approved. + +#### 7.7 Initial Gauges + +1. Gauges for the following tokens are pre-approved for deployment with this YIP: + - **YFI/ETH Curve LP yVault** + - **oYFI/ETH Curve LP yVault** + - **yCRV/CRV Curve LP yVault** (also known as “lp-yCRV”) + - **yBAL/BAL Balancer LP yVault** (also known as “lp-yBAL”) + - **yETH/ETH Curve LP yVault**. This gauge will be deployed once yETH has launched. +2. With the deployment of yearn v3 vaults expected soon[\[11\]](#references), additional higher-margin and/or strategic veYFI gauges can be considered and green-lit for deployment with the passing of veYFI Governance Proposals. + +#### 7.8 Parameters & Fine-Tuning + +1. The system launches with the default parameters above. +2. During the first **6 epochs**, yChad can adjust the system, bypassing governance proposals for parameter changes, and circumventing gradual scaling of parameter changes. +3. To bootstrap the oYFI discount curve, `s` starts at a steep `s=10`, with the explicit objective to decrease to `s=2` as the veYFI supply increases following the successful roll out of the programme. + +### 8\. Towards a Fully Immutable System + +1. Initial voting takes place via Snapshot, with yChad implementing changes according to the passed proposals and gauge emission allocations. Some features, like voting decay before epoch expiry, may not be initially implemented. +2. Initial emission is manual, with oYFI being minted and distributed to gauges. +3. From the start, ETH from oYFI redemption is automatically used for YFI buybacks. +4. The YIP instructs Yearn contributors to make the system fully immutable **before the end of the first 12 epochs**. This involves: + - Automating and making oYFI minting immutable as per the emission curve + - Ensuring oYFI supply is handled on-chain so it cannot be unbacked + - Automating on-chain gauge weight voting and gauge allocation + - Automating on-chain voting for governance proposal and parameter changes + - Minimizing yChad’s involvement or dependencies wherever possible. +5. Significant changes to the programme before it is made immutable require approval through a new YIP. + +### 9\. Incentives + +1. This YIP doesn’t cover incentives for veYFI voting, but such voting is strongly encouraged. +2. If this YIP is approved, Yearn contributors are instructed to consider launching incentive programs for veYFI voting, either on-chain or off-chain. This could be for weight allocations, parameter changes, or general governance proposals. New YIPs are not required to launch such programs. +3. Incentives should be posted during proposal submission periods, not voting periods. + +### 10\. Use at Own Risk + +Participation in the veYFI tokenomics program and Yearn governance is optional and not required to use or interact with the Yearn suite of protocols. Holding YFI or locking veYFI offers no financial gain—it’s a governance power redistribution program. Yearn contributors are not responsible for any loss from its use. No guarantees or assurances are provided, and if catastrophic events or security incidents occur, veYFI voters may determine the course of action. + +## Non-binding Forum Poll + +- Yes, I support this proposal +- No, I’m against this proposal + +0 voters + +## References + +1. [YIP-56: Buyback and Build](http://gov.yearn.fi/t/yip-56-buyback-and-build/8929) +2. [https://buyback.yearn.finance/](https://buyback.yearn.finance/) +3. [http://gov.yearn.fi/t/yip-65-evolving-yfi-tokenomics/](http://gov.yearn.fi/t/yip-65-evolving-yfi-tokenomics/) +4. [http://gov.yearn.fi/t/proposal-activate-veyfi/](http://gov.yearn.fi/t/proposal-activate-veyfi/) +5. [GitHub - yearn/veYFI: Voting YFI](https://github.com/yearn/veYFI) +6. [https://chainsecurity.com/wp-content/uploads/2023/03/Yearn-Smart-Contract-Audit-oYfi-ChainSecurity.pdf](https://chainsecurity.com/wp-content/uploads/2023/03/Yearn-Smart-Contract-Audit-oYfi-ChainSecurity.pdf) +7. [Upgrading Ethereum | 2.8.3 Issuance](https://eth2book.info/capella/part2/incentives/issuance/#overall-issuance) +8. [https://andrecronje.medium.com/keep3r-redeemable-kp3r-rkp3r-c200fb8740ef](https://andrecronje.medium.com/keep3r-redeemable-kp3r-rkp3r-c200fb8740ef) +9. [Yearn: YFI Token | Address: 0x0bc529c0...67f6ad93e | Etherscan](https://etherscan.io/address/0x0bc529c00c6401aef6d220be8c6ea1667f6ad93e#code) +10. [Boosting your CRV rewards - Curve Resources](https://resources.curve.fi/reward-gauges/boosting-your-crv-rewards#formula) +11. [V3 Protocol Team · Issue #120 · yearn/budget · GitHub](https://github.com/yearn/budget/issues/120) diff --git a/docs/contributing/governance/yips/yip-74.md b/docs/contributing/governance/yips/yip-74.md new file mode 100644 index 0000000000..ac5a2e6d42 --- /dev/null +++ b/docs/contributing/governance/yips/yip-74.md @@ -0,0 +1,127 @@ +--- +title: "YIP-74: YFI Wintermute Loan & CRV Plans" +hide_title: true +sidebar_position: -74 +--- + +# YIP-74: YFI Wintermute Loan & CRV Plans + +| Metadata | Details | +| --- | --- | +| YIP | 74 | +| Outcome | **Rejected** | +| Authors | Callen Wintermute | +| Created | 2023-08-13 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-74-yfi-wintermute-loan-crv-plans/13581) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0x3840d5b6daa3363933806c98335103c9086419b68513bd40f326f5cb0e07e9cf) | +| Vote result | For: 10.36; Against: 167.34 | +| Source | [Source](https://gov.yearn.fi/t/yip-74-yfi-wintermute-loan-crv-plans/13581) | + +# (21/8/23) Updated Proposal: + +Hi everyone, + +thanks for all the feedback in both the forum and Discord. We’d like to reach a middle ground where both sides are relatively happy but ensure we can keep it as simple as possible. + +It’s clear that the largest concern from the community is that the loan has no collateral from our side, which is fair considering the events that have happened over the past year. + +So we propose this: + +- We retain the same initial plan as before - use up to 3M CRV to buy yCRV, deploy yCRV tokens to the yCRV-CRV pool and stake this on yearn. + +- Our CRV (whether that be yCRV, st-yCRV, lp-yCRV, vl-yCRV) will be held in a 3/4 or 4/6 multisig with wintermute folks and core yearn contributors. (No transaction can be made without at least one signature from a yearn member). + +- Yearn multisig operators agree to approve anything we do as long as it’s within the Yearn + CRV ecosystem (e.g., swapping to vl-yCRV). + +- We will extend our staking duration to 12 months to match the loan duration, however, after 6 months we have the option to return the YFI and receive our collateral back. + + +This keeps both parties’ commitments rather simple and we provide collateral for our loan. + +We also want to reiterate that the loaned YFI will be used solely for our delta-neutral trading, we have no intent to sell it, and it will not be used in the YFI tokenomics ecosystem. + +## Next Steps + +We hope to gauge the community’s sentiment on our new proposal by adding a new poll that will run for 2 days. If the poll is relatively positive with the majority of votes being in favour of the new proposal, we will look to formalise this into a YIP and go to a Snapshot Vote. + +If the majority of the community is against the proposal as indicated by the poll, unfortunately, we will not move to a Snapshot vote and we thank the community for engaging with us! + +Updated Proposal Poll + +- For +- Against + +0 voters + +* * * + +* * * + +# Old Proposal: + +## Description + +Hi Yearn Community! + +Wintermute is excited to put forward this proposal which outlines the motivation, background and terms of a YFI loan to Wintermute Trading and further explains our long-term plans with respect to CRV on Yearn to the Yearn DAO. + +Specifically, we are requesting approval of a YFI loan to Wintermute Trading and authorization of a transfer of 350 YFI ($2.18M) from the DAO’s treasury to Wintermute Trading for 12 months at a 0.10% interest rate to be paid in kind at the end of the loan term. + +Separately, as part of Wintermute’s continued engagement on Yearn, Wintermute plans to utilise its funds of up to 3M CRV ($1.73M) to buy yCRV and subsequently add and deploy our assets to the yCRV-CRV Curve pool (lp-yCRV V2) on Yearn for a minimum of 6 months. + +We believe that this should help rebalance the pool which currently sits at 69%/31% yCRV/CRV, improve the yCRV peg, and increase the pool’s liquidity. + +## Motivation + +The past 2 weeks have once again tested the resilience of DeFi off the back of a bug in specific versions of Vyper. Subsequently, CRV’s largest source of on-chain liquidity vanished due to the CRV/ETH Curve pool being drained. This once again raised alarm bells for the Aave community as the price of CRV went down and the probability of insolvency inched closer due to Michael’s large CRV position on Aave V2. + +With little on-chain liquidity present and multiple loan positions to manage, a series of OTC trades were conducted with various parties across DeFi, including Wintermute Trading. We are now looking to deploy some of the CRV tokens on protocols where CRV is locked perpetually, including Yearn! + +We strongly believe in the vision of a truly decentralized world and Yearn has played an extremely positive role in empowering and advancing this vision. Therefore, we’d love to proactively engage with the Yearn community and the DAO by utilising up to 3M ($1.73M) of our CRV to purchase yCRV, and then deploy a mixture of our assets to the yCRV-CRV liquidity pool on Curve which only has [$5.25M](https://curve.fi/#/ethereum/pools/factory-v2-280/deposit) in TVL. + +**Wintermute’s Basic Background:** + +Wintermute Trading is a leading crypto-native algorithmic trading firm, specializing in creating efficient markets across centralized and decentralized exchanges. Wintermute was founded in July 2017 by three Optiver veterans. Evgeny Gaevoy, founder and CEO, was previously head of ETFs (screen and OTC) at Optiver Europe, one of the largest ETF market-making desks. Since our inception, we have traded over $3T and expanded our presence across 80+ (de)centralized exchanges and various (non)EVM chains, continuously supporting the ecosystem for our partners and their communities. + +Alongside our trading arm, Wintermute Ventures and Wintermute Governance support and work with leading crypto projects with the goal of truly adding value, enabling partnerships, and helping shape a positive outcome for the ecosystem. Importantly, we do not target large ownership stakes; decentralized ownership is an important prerequisite to transitioning to a robust future. + +## Specification + +**Wintermute’s plans:** + +- Borrowed YFI will be used exclusively for trading purposes. No farming, lending, voting, etc. + +- Use up to 3M CRV ($1.73M) to buy yCRV (depending on the ratio of yCRV-CRV in the liquidity pool). + +- Deploy yCRV tokens to the yCRV-CRV pool which we believe will help rebalance the pool and stake this on Yearn for a minimum of 6 months. + +- Has the optionality to swap the lp-yCRV to vl-yCRV for active participation in the Curve Wars. + + +**Our Ask:** + +Wintermute Trading is requesting approval for a 12-month loan of 350 YFI ($2.18M) at a 0.10% interest rate from the DAO’s treasury. + +**Loan Repayment:** + +Wintermute Trading agrees to return the full 350 YFI loan amount and 0.10% interest paid in kind to the DAO’s treasury at the end of the 12-month period. + +## Implementation + +If approved by the Yearn DAO, 350 YFI will be sent from the DAO’s treasury to Wintermute’s address: + +- 0xDBF5E9c5206d0dB70a90108bf936DA60221dC080 + +## Next Steps + +Following community discussion and feedback after 7 days, we will look to initiate a Snapshot Vote with voting options: + +1. For - Approve and transfer a loan of 350 YFI to Wintermute Trading. +2. Against - Reject the proposal. + +## Previous Poll + +- For +- Against + +0 voters diff --git a/docs/contributing/governance/yips/yip-75.md b/docs/contributing/governance/yips/yip-75.md new file mode 100644 index 0000000000..7abdce720d --- /dev/null +++ b/docs/contributing/governance/yips/yip-75.md @@ -0,0 +1,260 @@ +--- +title: "YIP-75: Launch V3" +hide_title: true +sidebar_position: -75 +--- + +# YIP-75: Launch V3 + +| Metadata | Details | +| --- | --- | +| YIP | 75 | +| Outcome | **Passed** | +| Authors | V3 Protocol Team, V3 Secret Admirers Group | +| Created | 2023-08-15 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-75-launch-v3/13591) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0xdb02fe93b77c6addfa9b197bb47f5b6d7779f69000210cffe54ea1fb35b91eec) | +| Vote result | For: 193.61; Against: 38.34 | +| Source | [Source](https://gov.yearn.fi/t/yip-75-launch-v3/13591) | + +# YIP-XX: Launch V3 + +## Authors + +V3 Protocol Team & V3 “Secret Admirers” Group + +## Summary + +Launch the full V3 system - making the latest generation of yield generating vaults and strategies permissionlessly deployable by anyone. + +## Abstract + +If adopted, this proposal seeks to: + +- Ratify the Design Specification of V3 and endorse its deployment. +- Specify parameters and initial configurations. +- Specify the bootstrapping and implementation process. +- Accept Governance roles. + +## Background + +From the outset, the core goal of V3 development has been to be _a significant upgrade to V2_. The end state of V3 should be a fully decentralized protocol that provides the most secure and trusted infrastructure for on-chain capital allocation. + +To achieve this Yearn contributors outlined four key requirements for V3 to fulfill: + +- Further decentralization at launch and enable progressive decentralization over time. +- Simplify strategy writing. +- Better than Yearn’s V1 single vault/strategy offering. +- Better than Yearn’s V2 managed vaults. + +#### **Vision**: + +Yearn V3 attempts to commoditize what Yearn Vaults V2 does. Management and strategy writing becomes easy for anybody to do. Effectively creating an open marketplace of V3 Vaults and strategies that can be operated by any third party, individual or entity without any involvement from Yearn contributors. Our goal is to provide the base infrastructure that all on chain capital allocators use. + +The open design of Yearn V3 creates little reason to launch a full fork. Instead encouraging others to build on top of the Yearn stack. We envision the next generation of yield aggregators will be strategists and vault managers in the Yearn marketplace. Integrating their own tokens and using their marketing, risk management, and developer expertise to attract capital. + +The high standards Yearn puts on its own vaults has long been the main growth constraint for the protocol. V3 takes these brakes off. Now anyone both within Yearn and outside can build, deploy and manage their own vaults and strategies with any risk profile they desire. While Yearn contributors may certainly choose to continue running V3 versions of our popular very safe single asset vaults or deploying factory vaults. No gate keeping means V3 allows the flexibility to properly experiment and grow the range of strategies and vaults offered. + +Perhaps a protocol with a large idle USDC position in their treasury wants to deploy some of those funds to generate returns. They can manage their own vault picking and choosing which strategies from the marketplace are within their risk profile. + +This creates opportunities for new and improved Yearn teams to arise and become even more decentralized. For example a yTeam could become a rating agency where vault managers or strategists pay to be reviewed and get rated. Like a very specialized audit firm. + +In V3 strategists can now simply write and deploy strategies fully autonomously and people can start using it immediately. Want it to be included in vault? You can apply for a rating and pitch it to vault managers. + +Different vault managers can have different requirements. Perhaps a Yearn vault will require your strategy to be at or above some specific rating threshold. While a 3rd party vault can have entirely different and unique requirements. Above or below the Yearn standard. + +With all this commoditization one might wonder about the impact this will have on Yearn earnings. The unique nature and exclusivity of the V2 design generated significant revenues from vault fees that flowed directly to the Yearn treasury. However, in this commoditized future Yearn can not only generate revenue from vault management but also firmly positions our future to be in market technology capture. + +Why spend the incredible amount of time and money it takes to build, audit and launch your own vault system when you can immediately and cheaply leverage the proven and trusted Yearn stack. + +We see this to be a positive shift for the Yearn suite of protocols. We will become more resilient to the swings in the crypto markets, and no longer tied to the success of a few other protocols. Key teams can transition into independent, peripheral and fully autonomous entities. This evolution opens up possibilities for healthy competition and innovation, leading to a reduction in protocol expenses while cementing its market position no matter what direction the market goes in or which specific applications lead the way. + +### Definitions + +#### Universal Terms + +- Vault - A tokenized representation of a yield bearing position. +- ERC4626 - A standard for a yield bearing vault. + +#### Yearn Terms + +- V3 Vault - A yearn-branded ERC4626 “meta vault” that is a debt allocator between multiple different strategies. +- Strategy - A term that V3 uses to refer to any ERC4626 compliant contract that a V3 Vault balances debt between. A strategy can be another Yearn vault but doesn’t need to be. It can be anything that implements the same API as an ERC4626 Vault (e.g. sfrxETH). +- V3 Tokenized Strategy - A technical implementation of a Strategy that is also a stand-alone ERC4626 compliant Vault. These are the yield generators in the V3 ecosystem. + +### In Depth + +**TLDR**: In V3 both Vaults and Strategies are fully stand alone 4626 compliant vaults. The relationship between a V3 Vault and its strategies is entirely changed and are now fully independent. Meaning not only can a vault deploy capital to many strategies. But now, a strategy can accept capital from many different vaults (as well as non-vault sources, like direct deposits from users). + +[Vault Spec](https://github.com/yearn/yearn-vaults-v3/blob/master/TECH_SPEC.md) +[Tokenized Strategy Spec](https://github.com/yearn/tokenized-strategy/blob/master/SPECIFICATION.md) + +## The Basic Structure + +[![](https://europe1.discourse-cdn.com/flex013/uploads/yearn/optimized/2X/c/c1cf462ebbb39326336349b397cdfe0c6c85e420_2_690x322.png) + +921×431 47.8 KB + +](https://europe1.discourse-cdn.com/flex013/uploads/yearn/original/2X/c/c1cf462ebbb39326336349b397cdfe0c6c85e420.png) + +**V3 Vaults[\[1\]](#references)** are debt managers. They approve strategies which they may balance debt between. Users will pay a fee for that debt management. In these ways, a V3 Vault acts exactly the same as a V2 Vault, but will come with much more flexibility and improvements. + +By becoming 4626-compliant, a strategy’s interface is instantly standardized with many protocols across DeFi. This allows any 4626-compliant protocol to instantly be attached to a V3 vault with no new strategy code or deployments necessary. This allows significant complexity to be stripped from the vault accounting as well as reducing gas costs. + +#### Notable Improvements: + +- Composability: Being ERC-4626 means V3 is more composable with DeFi as a whole, and also with the yearn suite of products. +- Decentralization: V3 introduces “Roles”. Each permissioned function now has its own role, that can be held by an EOA, a multisig, a smart contract, or any combination. +- Customization: Roles and periphery add ons such as “Accountants” mean that while the base remains immutable and secure, management can continue to iterate with new ideas and implementations. +- Efficiency: Both debt updates and profit reporting have been entirely redesigned to both increase capital efficiency as well as reduce gas costs. +- Profit Locking: V3 introduces a new profit locking mechanism that will allow users to continuously earn yield slowly over time rather than just at specific post “harvest” intervals, while also allowing the full capital to always remain deployed. + +**V3 Strategies[\[2\]](#references)** As mentioned before, any 4626 vault is instantly a valid strategy. For everything else, V3 provides a “Tokenized” strategy template designed to make strategy writing dead simple. It abstracts away core security features and the 4626 implementation, allowing the developer to focus soley on their yield farming logic. + +Tokenized Strategies provide many benefits over the V2 model. + +- Immutability: If built correctly V3 strategies can become fully immutable vaults with no trust assumptions of the management. +- Increase Total Addressable Market: With Tokenized Strategies, yield generation opportunities that were not feasible in V2, because they would never be added to our vaults, can now be developed and thrive on their own. They also make it much easier to bootstrap and launch on new chains. +- Developer Experience: A V3 strategy can be developed with only needing to implement as few as 3 functions, and only 1 accounting variable. And due to the design, Tokenized Strategies are significantly smaller contracts than their V2 counterparts meaning lower deployment costs. + +**V3 Periphery[\[3\]](#references)[\[4\]](#references)** + +The base V3 contracts were built as an un-opinionated base that allows the vault and strategy managers to build their own unique vision on top of it. To make customization even easier a series of periphery contracts have been developed and will continue to be improved on to make the full V3 stack as customizable as possible while also being as easy as possible to build on. + +Some examples of periphery contracts that have already been developed are: + +**[Accountant](https://github.com/yearn/vault-periphery/tree/master/contracts/accountants)**: Accountants are stand alone contracts that are attached to a vault and charge the fees for a vault when strategies report profits or losses. An accountant can charge any fees that can be codified as well as give refunds back to the vault. Accountants will also be able to serve as a Junior Tranche to the vault. +**4626 Router[\[5\]](#references)**: To make integration with any V3 vault or strategy as easy as possible. The router also utilizes permit and multicall to make user tx’s as simple and cheap as possible. +**[Custom Registries](https://github.com/yearn/vault-periphery/tree/master/contracts/registry)**: Each team, protocol, UI etc. can deploy and manage their own registry to easily track on chain the vaults and strategies they work with. +**[Swappers](https://github.com/yearn/tokenized-strategy-periphery/tree/master/src/swappers)**: Strategists can simply inherit a contract that has their preferred method of token swapping to easily integrate with any dex or swapping method they want. + +## Fee Structure + +**TLDR**: Because strategies are now themselves stand alone vaults, fees in V3 will be charged at both the meta vault level as well as through the Tokenized Strategies. V3 also introduces a “Protocol Fee”. The Protocol Fee is set by Yearn Governance and is applied as a percent of the total fees charged when any V3 vault or strategy reports. + +#### Example with a 20% Protocol Fee charged on a vault that is charging a total fee of 1,000 tokens and a strategy that is charging 500 tokens. + +[![](https://europe1.discourse-cdn.com/flex013/uploads/yearn/optimized/2X/b/bdaff2fd984051d620edab1389a7f98ca00146cb_2_690x411.png) + +2231×1329 100 KB + +](https://europe1.discourse-cdn.com/flex013/uploads/yearn/original/2X/b/bdaff2fd984051d620edab1389a7f98ca00146cb.png) + +\*NOTE: It is possible that the ‘Vault Accountant’ and ‘Strategy Fee Recipient’ are also the Yearn Treasury. + +### Yearn Managed Multistrategy Vault Fees + +V3 Vaults have no fee by default. Rather an external “Accountant” must be added to the the vault that will hold custom logic to charge any types of fees that management can dream up. + +There has been a “Generic Accountant” contract developed for vault managers, to use if desired, to manage accounting for vaults upon launch. + +In the future Vault managers can experiment with different fee structures such as re-introducing management fees, capped fees, tiered performance fees based on returns or any combination. Accountants can also serve as Junior Tranches and not only charge specialized fees but also give “refunds” (negative fees) back to the vault. + +### Tokenized Strategy Fees + +Tokenized strategies are built to only charge performance fees. Since they are now stand alone vaults we must also report, lock profit and charge fees at the strategy level as well. + +It is expected that strategy fees will fluctuate depending on strategy complexity as well as due to market dynamics. + +The Tokenized Strategy implementation has both minimum and maximum fees hard coded that strategists must abide by. The minimum fee disincentives a race to zero. The maximum fee reassures depositors by guaranteeing managers can’t raise their fees to something exploitative downstream. + +### Protocol Fees + +With the hope for V3 to commoditize the yield aggregation stack allowing the further decentralization of ownership and power over vaults and strategies not all vaults will be accruing fees directly to the Yearn Treasury. + +In order to assure the Yearn Treasury continues to earn revenue and fees, V3 implements a “Protocol Fee” that will earn revenue no matter who runs the vault or strategy. + +The protocol fee is a configurable amount that is taken out of the fees charged during any V3 vault or strategy report based on the fees charged. It serves as a “tax” on fees earned by using the Yearn stack while still allowing each individual vault and strategy manager to set their own fee structure . + +Example: + +``` +profit = 100 +performance_fee = 10% +protocol_fee = 10% + +total_fees = profit * performance_fee = 10 +protocol_fees = total_fees * protocol_fee = 1 +performance_fees = total_fees - protocol_fees = 9 + +9 is payed to the vault/strategy specific performance fee recipient +1 is payed to the protocol fee recipient (Yearn) +``` + +Protocol fees are configurable by the Governance of the VaultFactory for each specific API version across all Vaults and Strategies of that API. + +Governance can also set a custom protocol fee for individual vault and strategies both higher or lower than the default fee. + +* * * + +NOTE: The fee structure is not dictated by this YIP and should adjust to meet market conditions based on the desires of vault managers, strategists and veYFI holders. + +* * * + +## Specification + +**1\. Relevant Contracts**: + +The first release “3.0.0” has been deployed on Ethereum Mainnet, Polygon, Optimism and Avalanche. + +Contract Addressses (Constant across all chains): + +_Vault BluePrint_ (To use EIP-5202) : 0xfC49ca826f8C68c0345410fcA0c7d1e0550d9ee9v + +_VaultFactory_ : 0xD1736eBbdefae37503F3eD8D718b61a494F24c1D + +_TokenizedStrategy_ : 0xAE69a93945133c00B9985D9361A1cd882d107622 + +**2\. Configuration**: + +2.1 Vault Blueprint: + +- n/a + +2.2 Vault Factory: + +- MAX\_FEE\_BPS (constant): 50% +- default protocol fee : 20% +- protocol fee recipient : Chain specific V3/Treasury Splitter Contract. +- governance : yChad or equivalent +- Mainnet will have all V3 vaults that have a V2 equivalent have a custom protocol fee set at 40% of the default fee. + +2.3 Tokenized Strategy: + +- MIN\_FEE (constant): 5% +- MAX\_FEE (constant) : 50% + +## Plan + +The initial rollout plan for V3 is designed to start in places that V2 has little or no presence in order to immediately increase Yearn’s market share. + +While the contracts have been deployed on multiple chains, focus will initially be placed on Polygon for the first public push of V3. + +This will establish a Yearn presence and source TVL on a new chain, as well as battle test the V3 code before beginning TVL migration on Ethereum. + +In order to bootstrap the V3 ecosystem on any new chain, focus will be initially placed on the development and deployment of Tokenized Strategies for that specific chain. This should lead to a significant improvement over V2. It means cutting down on the amount of contracts that need to be deployed, the governance roles we need filled and the need for overlapping opportunities in any specific asset we want to launch a vault for. Tokenized strategies can also be built and deployed easily by anyone so it allows for the immediate inclusion of 3rd parties to work with V3. + +When the launch on Polygon has proven itself and stabilized we will then continue to publicly push on other chains such as Arbitrum, AVAX and Optimism and of course Ethereum. + +As stated in the [Specification](#specification) section, the ownership over the VaultFactory that sets the protocol fee config should initially be held by yChad or its equivalent on that chain. + +Once established or possible governance rights of the Vault Factories should be moved to veYFI where applicable. And all future deployments should have governance given to veYFI + +* * * + +### Use at Your Own Risk + +The V3 system is offered as is. Yearn contributors and YFI token holders provide no guarantee of safety of funds in **ANY** vault or strategy built on top of the core contracts and will not compensate users for any critical failure or loss of funds resulting from usage of the system. + +## References + +1. [GitHub - yearn/yearn-vaults-v3](https://github.com/yearn/yearn-vaults-v3) +2. [GitHub - yearn/tokenized-strategy: Contains the Contracts for the Yearn V3 Tokenized Strategy Implementation](https://github.com/yearn/tokenized-strategy) +3. [GitHub - yearn/vault-periphery](https://github.com/yearn/vault-periphery) +4. [GitHub - yearn/tokenized-strategy-periphery](https://github.com/yearn/tokenized-strategy-periphery) +5. [GitHub - yearn/Yearn-ERC4626-Router: ERC4626 Router for Yearn V3 vaults.](https://github.com/Schlagonia/Yearn-ERC4626-Router) + +- For +- Against + +0 voters diff --git a/docs/contributing/governance/yips/yip-76.md b/docs/contributing/governance/yips/yip-76.md new file mode 100644 index 0000000000..33c77b6964 --- /dev/null +++ b/docs/contributing/governance/yips/yip-76.md @@ -0,0 +1,228 @@ +--- +title: "YIP-76: Launch yPools" +hide_title: true +sidebar_position: -76 +--- + +# YIP-76: Launch yPools + +| Metadata | Details | +| --- | --- | +| YIP | 76 | +| Outcome | **Passed** | +| Authors | 0xkorin, 0xPickles, 0xValJohn | +| Created | 2024-02-16 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-76-launch-ypools/13926) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0xa07123d5f6d3eb236969c798c024098be32231d2c3a205bd197200c955baa10c) | +| Vote result | For: 320.65; Against: 0; Abstain: 5.27 | +| Source | [Source](https://gov.yearn.fi/t/yip-76-launch-ypools/13926) | + +_Authors: 0xkorin, 0xPickles, 0xValJohn_ + +## Summary + +We propose using the design of the yETH protocol to create new, self-governing pools for various assets, called yPools. These pools will be permissionless and self-managed. + +### 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 by veYFI holders. + +## Abstract + +**If adopted**, this proposal will: + +- Define the general functionality and design of yPools. +- Outline how to bootstrap and deploy these pools. +- Set initial parameters and configurations. +- Describe how the pools will function under normal conditions. + +## Background + +YIP-72[\[1\]](#references) launched yETH, a self-governing pool representing a mix of ETH Liquid Staking Tokens. As of now, yETH has been running smoothly for six months, holding around $18.8m[\[2\]](#references) in TVL and operating without issues. + +yETH offers a managed risk exposure to LSTs, controlled entirely by its users. We recommend reading YIP-72 fully to understand this proposal better. + +This proposal suggests extending the yETH model to other yield-generating assets, benefiting from diversified exposure. + +The core principles of yETH, which will apply to yPools, include: + +- **Self-governing.** yPools token holders (via the staked st- version) control the protocol in its entirety. +- **Immutable.** yPools are not upgradable. Improvements require deploying a new version. +- **Trust-minimized.** No third-party should be able to access funds or alter the state of the protocol. Users remain in control of their own funds. +- **Autonomous.** Critical operation of yPools should not rely on third-party individuals, groups, or entities. + +### Out of scope + +- Yearn contributors and YFI/veYFI token holders will not be involved in: + - Choosing assets for yPools or setting their weights. yPool users will make these decisions. + - The performance of yields and products. This is up to yPool users. +- There are no plans for a related token or airdrop. Any future token launch would need approval from each yPool’s group of users. + +## Motivation + +### Use Case Examples + +- **User:** By owning a yPool token, you can aim for higher, risk-adjusted returns compared to individual assets in the pool. +- **Searcher:** If a yPool token’s price becomes imbalanced, you search for profit opportunities through arbitrage. +- **DeFi Protocol:** Accepting yPool tokens as collateral offers a more reliable value guarantee than individual assets. +- **yPool Asset Protocol:** Promoting your token’s inclusion in yPools can boost demand and visibility for your project. + +### yPool Asset Examples + +- Yearn re-staked Ether +- Yearn Bitcoin +- Yearn Dollar +- Yearn Euro +- Yearn Yen + +### Future Possibilities + +- Utilizing yPool tokens as collateral in other smart contracts, including Yearn. +- Creating Yearn vaults and strategies related to yPools. +- Allow third parties to optimize asset weights and allocation permissionlessly. +- Consolidating all pools under some unified protocol framework. + +### Risks + +Potential risks include: + +- An asset within a yPool severely depegs, fails, or faces an exploit. +- A critical flaw in the design or implementation causes unexpected behavior. +- Poor asset selection or protocol settings by yPool voters result in below-average performance. +- Low yields leading to diminished interest in the pool. + +## Specification + +### 1\. tl;dr + +1. Follow yETH’s launch and operational blueprint closely. +2. Adapt the audited yETH codebase with minimal changes. +3. Deploy yPools with on-chain governance from the start. +4. Run a bootstrap process for each new pool. +5. Run yETH’s Protocol Owned Liquidity (POL) operations for each pool. + +### 2\. General requirements + +#### 2.1 Asset Guidelines + +1. To be considered for a yPool assets, + 1. SHOULD: + - Generate real yield. + - Report yield on-chain regularly (the more frequent, the better). + - Ideally be redeemable for the underlying asset through the protocol directly, not just via AMMs. + - Be permissionless for holding and interaction. + - Be a non-Rebasing Token; Native rebasing tokens are not supported, instead a wrapped version must be used. + 2. SHOULD NOT: + - Stem from private credit sources; Owing to a lack of transparency and a higher risk of default. + - Consist of Basket or Index Tokens; They represent composites of other assets. +2. The underlying asset, i.e. the equivalent of what ETH is to yETH, is determined by the yPool team as they see appropriate. + +#### 2.2 Airdrop & Points programs + +1. yPools may be eligible for airdrops, can accumulate points redeemable for tokens, or receive other similar types of rewards. +2. Due to the immutable nature of the pool contract rewards typically cannot be claimed directly. Instead, the issuer must route them to an alternative recipient address. +3. When this occurs, the yPool’s earned rewards will be accessible for redemption directly by st-yPool token holders based on time-weighted balances. +4. Users wishing to auto-compound rewards, are recommended to use the yPool via a higher abstraction level, such as depositing into designated Yearn v3 vaults. + +### 3\. yPool Requirements + +#### 3.1 General Design + +1. yPool design adheres to the latest yETH specifications from the main yETH repository[\[#3\]](#references). +2. yPool governance is on-chain from the outset, following the latest specifications and contracts from the yETH-periphery repository[\[#4\]](#references). +3. Incorporate all post-launch governance modifications made to yETH by st-yETH voters into the new yPools. +4. Continuously evaluate yETH and yPool contract improvements for potential inclusion. +5. Apply process improvements to yPools as appropriate, aiming for consistency across all yPools. + +#### 3.2 Role Assignment + +1. **Treasury:** Yearn Treasury or an autonomous splitter contract directed by yBudget. +2. **Management:** On-chain governance contract with multiple roles. +3. **Guardian:** A Gnosis Safe with a 2-of-7 signing threshold, consisting of Yearn contributors to monitor the protocol and trigger Pause mode if needed. Guardian participation is done on a gratuitous, volunteer basis–no duty of care or ongoing monitoring is assumed or implied. + +#### 3.3 Normal Operation Requirements + +##### 3.3.1 Epochs & Voting + +1. Epoch start times and durations can be adjusted by the yPools team, aiming to align with yETH unless a specific reason suggests otherwise. +2. Voting mechanisms and asset weights follow the yETH model. + +##### 3.3.2 Whitelisting + +1. Asset whitelisting for yPools mirrors the yETH process. +2. The yPools team can adapt the process for the specific needs of each yPool. +3. Whitelisting application fees are set based on the asset and may be waived. +4. Only staked yPool token holders vote on asset inclusions. + +##### 3.3.3 Parameter Pre-sets + +Adjustments to the following parameters require governance proposals by staked yPool voters: + +_Set by yPools = Set by the yPools team upon deployment._ + +| Parameter | Description | Configurable Range | Default | +| --- | --- | --- | --- | +| `t_half` | Time for half the voting weight to accumulate | 7-365 days | 60 days | +| Voting Weight Allocation | Allocation for each whitelisted asset per epoch | 1-33% | 10% | +| Amplification Parameter `A` | Influences pool sensitivity to imbalances | N/A | Set by yPools | +| Tolerance Range | Allowed deviation of asset weights | +/- 100% | Set by yPools | +| Application Fee | Fee for whitelisting as an LSD protocol | Set by yPools | Set by yPools | +| Initial Weight | Starting weight for a whitelisted asset | 0.1-1.0% | 1.0% | +| Pool Swap Fee | Fee for asset swaps, paid to st-yETH holders | 0.00-1.00% | Set by yPools | +| Protocol Fee | Yearn Treasury performance fee | 5-20% | 10% | + +##### 3.3.4 Incentives + +1. Incentive structures are the same as yETH’s. +2. No fees are charged on posted incentives. + +#### 3.4 Minting Permissions + +Only four smart contracts are allowed to mint any specific yPool asset: + +1. The Pool, holding LSD assets and minting the yPool asset against the deposited asset(s). +2. The Bootstrapper, used to launch the yPool, with minting enabled only for a limited time period. +3. The POL contract, providing protocol-owned liquidity in pools. +4. The deposit facility, allowing minting of the yPool asset at 1:1 upon deposit of the underlying asset + +#### 3.5 Bootstrapping Requirements + +1. Bootstrapping yPools follows yETH’s proven process. +2. The yPools team has discretion to adjust the process based on the included asset, which could among other affect duration, fees, criteria, and weights. + +#### 3.6 Protocol Owned Liquidity + +1. The approach is the same as yETH’s. +2. The yPools team can modify this to better fit specific yPool liquidity needs. + +### 4\. Implementation + +Upon this proposal’s acceptance, the yPools team will proceed with deploying yPools and starting the bootstrapping phases as outlined above. + +### 5\. Use at Own Risk + +yPools are designed to be governed by their token holders who decide on assets to onboard and configure the protocol. Yearn contributors and YFI token holders are not involved and will not compensate users for any failure or loss of funds resulting from yPools usage. + +## Vote + +### Non-binding signaling poll + +Proceed with this proposal in its current form? + +- Yes +- No + +0 voters + +## References + +1. [https://gov.yearn.fi/t/yip-72-launch-yeth/](https://gov.yearn.fi/t/yip-72-launch-yeth/) +2. [https://yeth.yearn.fi/](https://yeth.yearn.fi/) +3. [GitHub - yearn/yETH · GitHub](https://github.com/yearn/yeth) +4. [GitHub - yearn/yETH-periphery · GitHub](https://github.com/yearn/yeth-periphery) + +## Changelog + +- Feb 16: First version +- Feb 20: Reworking section 2 of spec, adding airdrops section diff --git a/docs/contributing/governance/yips/yip-77.md b/docs/contributing/governance/yips/yip-77.md new file mode 100644 index 0000000000..b73abde1e1 --- /dev/null +++ b/docs/contributing/governance/yips/yip-77.md @@ -0,0 +1,160 @@ +--- +title: "YIP-77: Launch new yLockers Staking" +hide_title: true +sidebar_position: -77 +--- + +# YIP-77: Launch new yLockers Staking + +| Metadata | Details | +| --- | --- | +| YIP | 77 | +| Outcome | **Passed** | +| Authors | wavey | +| Created | 2024-02-26 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-77-launch-new-ylockers-staking/13944) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0xe79fb2ef4f21ef1e9cc30dd1522c9751c74b631c4782bccbbeb25185d4ddae1d) | +| Vote result | For: 254.86; Against: 0 | +| Source | [Source](https://gov.yearn.fi/t/yip-77-launch-new-ylockers-staking/13944) | + +# \[Proposal\] Launch new yLockers Staking + +## Overview + +This proposal aims to implement a new staking experience for Yearn liquid locker users, including yCRV, yPRISMA, and any future Yearn liquid locker tokens (hereinafter collectively referred to as “yLocker tokens”). + +The design offers users the choice to earn yield in stablecoins and enhance their earning potential within the system the longer they stake, all without imposing lock-ups or penalties. + +## Abstract + +If adopted, this proposal will trigger Yearn to complete development on contracts, a custom-built UI for yLockers users, and begin the deployment of the new staking system described below. As such, the following steps will be taken: + +1. Establish a new staking system based on the novel `YearnBoostedStaker` contract and an accompanying yield distribution contract. +2. Submit the contracts for a final audit. +3. Launch new staking setup for yPRISMA immediately. +4. Enable staking-time weighted rewards distribution to users. This mechanism is described in more detail below. +5. Enable users’ ability to self-elect their reward allocations. Specifically, users will have an ability to select between any mix of the two available rewards tokens: the respective yLocker token, and its ecosystem’s primary stablecoin, wrapped in a Yearn auto-compounding vault. +6. After 5 weeks of production operation, launch same new staking setup for yCRV. + +These changes will not deprecate st-yCRV nor (future) st-yPRISMA products. They will continue operating as autocompounding vaults, but with new strategies designed to farm the new staking contracts. Users should consider the following actions depending on their personal goals: + +- For users who prefer to continue passively auto-compounding yLocker tokens, no action is required. +- Users who wish to take advantage of the new staking features should plan to withdraw and stake their yCRV or yPRISMA directly. + +## Background + +Yearns liquid locker products (a.k.a. “yLockers”) serve as a convenient means by which users may choose to gain exposure to various veToken governance systems while keeping their position entirely liquid. + +Today, Yearn has two main yLocker products: yCRV and yPRISMA. Both allow users to earn any protocol-generated revenue by depositing their yLocker tokens into a vault contract which receives yield from Yearn’s overall position. + +yLockers are designed with a goal of being easy to understand, and enforce no lock-ups nor penalties. + +Given the competitive landscape for similar locker products, it is important that yLockers evolve to meet new market demands. + +## Motivation + +The motivation for this change is to address a number of popular use cases that the current yCRV product cannot serve. Specifically: + +1. **Allow users to claim yield as stablecoins** + Though Yearn has seen significant adoption of the st-yCRV autocompounding product (current TVL ~47M yCRV), there is clear market demand for preserving user optionality to earn their veToken yield in the form of stablecoins. We’ve seen a similar model employed with great success by [Convex Finance](https://docs.convexfinance.com/convexfinance/guides/depositing/crv). At time of writing, the market on Convex is currently pricing in a >20% premium for receiving yield as stablecoins vs governance tokens. + +2. **Introduce mechanism for enhanced incentives based on staking time** + The mechanic for staking-time weights allows the yLocker protocol to allocate higher yield, and other incentives to users who commit to longer staking times. This has the effect of incentivizing longer-term stakers by giving them a larger share of total weekly rewards. + + +## Design + +#### YearnBoostedStaker + +- Users can deposit and withdraw full balance at any time with no lock-ups and no penalties. +- Each depositor maintains a _**weight**_ which is a function of their staking amount and duration +- A user’s _**weight**_ increases on a once-weekly schedule. Once on initial deposit, and again each until the maximum amount of growth weeks is reached. +- Users may make partial withdrawals. If user has amounts actively growing in different weeks, the withdrawal is made from the least-weighted amounts first. +- Each staking uses may also set an **election**. This value can be anywhere between 0% - 100% to express their preference for yLocker token yield vs. stablecoin yield (where 0% indicates all yield as yLocker tokens, 100% as all yield as stablecoins, and 50% as a relative split between the two). +- The contract produces the following data: + - user election: user’s yield preference + - user weight: user’s time-weighted score + - user balance: sum of user deposited tokens + - global weight: total time-weighted score of all users + - total supply: sum of deposited tokens + +Each of these values can be consumed by any other contract within the system (yield distributors, voting, etc.) and even by integrators to generate weight-based reward distributions. + +Let’s demonstrate an example of how weights work. In this example… + +- YearnBoostedStaker is deployed with `maxGrowthWeeks = 4` +- A user deposits 100 yLocker tokens + +| week | balance | weight | boost multiplier | +| --- | --- | --- | --- | +| 0 _(deposit week)_ | 100 | 50 | 0.5x boost | +| 1 | 100 | 100 | 1x boost | +| 2 | 100 | 150 | 1.5x boost | +| 3 | 100 | 200 | 2x boost | +| 4 _(final growth week)_ | 100 | 250 | 2.5x boost | +| 5 _…n_ | 100 | 250 | 2.5x boost | + +To keep it simple, the example above does not address what happens when a user makes a deposit or withdraw while weight growth is still in progress. If a user deposits 100 tokens every week for 4 weeks, they will then have 4 independent weight groups traveling through the system. + +A withdraw will always retrieve tokens from the most recent (least weighted) deposit, leaving the higher weight tokens to continue along. + +A user’s total weight is equal to the sum of each of their deposit’s weight. And the total system weight is the sum of all user weight. + +#### Yield Processing and Distribution + +Yield will be distributed on a weekly basis in the form of exactly two tokens: + +1. Target yLocker token +2. Target vault-wrapped stablecoin. + +It is important to note that raw yield (captured from protocol fees, bribes, etc.) will still arrive in an assortment of different tokens. These tokens are classified and converted into their respective target tokens. + +Determining the yield classifications, and therefore weekly amounts is simple: + +- All yield collected during the week from core protocol fee revenue (i.e. core fee distributor contracts) will go into the stablecoin bucket. +- All yield that arrives from bribes or other outside sources will go into the yLocker token bucket to be converted to the yLocker token. + +As yield arives throughout the week, it will be converted to target tokens and deposited directly into the Yearn yield distributor contract according to its classification. + +If, for example, a user elects for 100% of their yield in stablecoins, and the stablecoin bucket had $50,000 deposited for the week, that user will earn their entire weekly distribution as a portion of that $50,000. The exact portion depends on that user’s weight relative to the election-adjusted weight of all other users in the system. + +#### Yield Claiming + +A custom yield distribution contract is required to govern distribution according to the weights and weekly rhythms as `YearnBoostedStaker` (week transitions occur every Thursday morning at 00:00 UTC). + +- A user’s yield accrues week over week, and **is never lost if unclaimed**. +- Yield tokens received by Yearn’s position will be deposited over the course of the week. +- Deposited yield tokens are not claimable in the current week but become claimable as soon as the week flips. +- Stablecoin yield will be claimed directly to a user’s wallet. +- Optionally, users may elect to have their governance tokens “auto-staked” to the staking contract. +- At launch, claimaints who choose to “auto-stake” will have that claimed amount allocated directly into the maximum boosted position. This serves as a way to build upon one’s weight in the system while also being gas efficient. + +## Specification + +#### Configuration + +- Deploy `YearnBoostedStaker` with a `MAX_STAKE_GROWTH_WEEKS` of 4. +- Deploy Yield Distributor contract with auto-staking configured to deposit claimed yTokens back into the staker at max boost. +- Migrate the current st-yCRV strategy to a new strategy to farm rewards from the new staking system. Vault token remains the same. +- Deploy st-yPRISMA vault and strategy to auto-compound the new staker. + +#### Fees + +- A 10% performance fee will be charged at the time of weekly yield deposits. + +#### Next Steps and Cut-over details + +- Acquire consensus for this proposal +- Following deployments, an announcement will be made to cue users to migrate. +- As users (optionally) migrate from st-yCRV to direct staking, there will be no weight-earning advantage won by any individual depositors as long as they migrate on the first week. I.e. Every staker’s weight (including st-yCRV strategy) begins at 0.5x boost, and therefore their relative system weight is still maximized. + +## Vote + +#### Non-binding signaling poll. + +Proceed with this proposal in its current form? + +- Yes +- No + +0 voters diff --git a/docs/contributing/governance/yips/yip-78.md b/docs/contributing/governance/yips/yip-78.md new file mode 100644 index 0000000000..638cf175f9 --- /dev/null +++ b/docs/contributing/governance/yips/yip-78.md @@ -0,0 +1,108 @@ +--- +title: "YIP-78: Partial Compensation Sonne Hack Victims" +hide_title: true +sidebar_position: -78 +--- + +# YIP-78: Partial Compensation Sonne Hack Victims + +| Metadata | Details | +| --- | --- | +| YIP | 78 | +| Outcome | **Rejected** | +| Authors | Yearninger | +| Created | 2024-07-25 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-78-partial-compensation-sonne-hack-victims/14103) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0x47c2883308fafd286697c391748c1381cf374b98cfa3af9d23d2fe79d31df6fb) | +| Vote result | For: 214.59; Against: 235.57 | +| Source | [Source](https://gov.yearn.fi/t/yip-78-partial-compensation-sonne-hack-victims/14103) | + +# \[Proposal\]: Partial Compensation for yvUSDT and yvDAI Vault Users Affected by Sonne Finance Exploit + +## Summary + +This proposal aims to provide partial compensation to users of yvUSDT and yvDAI vaults affected by the Sonne Finance exploit. It suggests Yearn cover 80% of the remaining losses, with affected users accepting a 10% write-down. This approach demonstrates Yearn’s commitment to users while balancing the interests of YFI holders. + +## Background + +On May 15, 2024, Sonne Finance, where Yearn had allocated significant portions of yvUSDT and yvDAI vault assets, was exploited for $20 million \[1\]. This occurred despite a prior audit by Yearn-assigned auditors \[2\]. The exploit targeted a vulnerability in a new governance timelock introduced by Sonne Finance. + +On May 24, 2024, an increased rate of OP rewards was announced by a Yearn contributor \[3\]. For 4 weeks, these rewards were paid out and mitigated some of the occurred losses. The remaining losses are as follows: + +Affected vaults and losses: + +1. yvUSDT Vault (Optimism) \[4\]: + + - Total Gross Loss: 356,996.37 USDT \[6\] + - Compensation in OP already received: $171,704.76 (76,195.19 yvOP which is 78,404 OP at a TWAP price during the rewards period of $2.19) + - Net Loss: 185,291.61 USDT +2. yvDAI Vault (Optimism) \[5\]: + + - Total Gross Loss: 294,283.36 DAI \[6\] + - Compensation in OP already received: $149,086.44 (66,157.90 yvOP which is 68,076 OP at a TWAP price during the rewards period of $2.19) + - Net Loss: 145,196.92 DAI + +Total Net Loss of vaults (after subtracting already received yvOP rewards): $330,488.53 + +## Motivation + +This proposal addresses three key issues: + +1. Trust Maintenance: Compensating affected users demonstrates our commitment to depositor safety, crucial for retaining and attracting users. + +2. Long-term Benefits: The goodwill generated will likely outweigh short-term costs, potentially leading to increased deposits and protocol growth. + +3. Acknowledging Risk Management Shortcomings: The incident highlights an overweighted allocation to a protocol where yAudit had identified potential security risks. By approving this proposal, we signal our commitment to improving risk assessment and management practices, thereby better protecting user funds in stablecoin vaults going forward. + + +## Specification + +We propose the following compensation structure: + +1. Total remaining loss: $330.488,53 +2. Affected users to bear 10% of the loss: $33,048.85 +3. Requested compensation from Yearn: $297.439,67 (in YFI equivalent, which represents as of August, 15 2024, a total of 58.86 YFI) +4. Users will assign all future recoveries provided by Sonne Finance to the Yearn DAO. +5. Users receive compensation in the form of YFI tokens. Despite Users having originally invested in stablecoin vaults Users are willing to align themselves with Yearn and agree to the YFI compensation being subject to a vesting schedule. +6. The vesting schedule releases lineary one-sixth (1/6) of the total tokens each month over a period of 6 months. One-sixth of 58.86 YFI amounts to approximately 9.8 YFI potentially sold by users per month, which should have no impact on the YFI price as several thousand YFI are traded on various exchanges daily + +Users are then fully aligned with the objective of Yearn. + +Yearn’s Financial Position: +As of August 16, Yearn’s financial position is as follows: + +Total liquid assets: $32.7M + +The proposed compensation of $297.439,67 represents approximately 0.9% of Yearn’s total liquid assets as of August 16, 2024, a manageable amount that won’t jeopardize Yearn’s financial stability. + +\[Note: Following Yearn’s recovery efforts and yvOP compensation, affected WETH and USDC vaults suffered total losses of 1% or less. Hence, they are excluded from this proposal, since the losses lie underneath the accepted loss of 10%.\] + +Process of executing the proposal if voted “yes”: + +A. full list of depositors → [https://gist.github.com/anyOldDev/b410c4ae27a4e1c3f3de37245205f62f](https://gist.github.com/anyOldDev/b410c4ae27a4e1c3f3de37245205f62f) +It’s a balance snapshot of the vault and the rewards contract combined done using the graph. +B. smart contracts → [https://github.com/pandadefi/merkle-distributor-with-vesting/blob/master/contracts/MerkleDistributor.sol](https://github.com/pandadefi/merkle-distributor-with-vesting/blob/master/contracts/MerkleDistributor.sol) +The contract is a merkle-distributor forked from uniswap wich has been modiifed to create a vesting contract using llamapay contracts. +C. merkle proof → Yearn will have to create based on the price of YFI and the full list of depositors as disclosed in the link above. +D. Yearn (or alternatively the Team behind the proposal) will have to convert the USD amount to YFI amount, generate the merkle proof based on the information provided in the shared links and deploy the contract +E. The team behind the proposal will help if necessary to create the merkle proof once the YFI price for compensation has been decided. + +## Voting + +- YES! For partial compensation +- no + +0 voters + +## Resources + +\[1\]: [https://reports.yaudit.dev/reports/05-2023-Sonne/](https://reports.yaudit.dev/reports/05-2023-Sonne/) +\[2\]: [https://rekt.news/sonne-finance-rekt/](https://rekt.news/sonne-finance-rekt/) +\[3\]: ⁠⁠[Yearn Talk⁠](https://discord.com/channels/734804446353031319/734862139386232902/1243331990015443024) +\[4\]: [https://yearn.fi/vaults/10/0xFaee21D0f0Af88EE72BB6d68E54a90E6EC2616de?tab=strategies](https://yearn.fi/vaults/10/0xFaee21D0f0Af88EE72BB6d68E54a90E6EC2616de?tab=strategies) +\[5\]: [https://yearn.fi/vaults/10/0x65343F414FFD6c97b0f6add33d16F6845Ac22BAc?tab=strategies](https://yearn.fi/vaults/10/0x65343F414FFD6c97b0f6add33d16F6845Ac22BAc?tab=strategies) +\[6\]: [Screen\_Shot\_2024-07-17\_at\_4.48.16\_PM.png](https://media.discordapp.net/attachments/1242905752440410162/1263235946338582548/Screen_Shot_2024-07-17_at_4.48.16_PM.png?ex=66a01727&is=669ec5a7&hm=d07d4c5cc35fa23adb06cf3fd4bc7ed40b9f8da2ded25b9cda36224984ec3942&format=webp&quality=lossless&width=1292&height=290&) +\[7\]: [https://debank.com/profile/0x93A62dA5a14C80f265DAbC077fCEE437B1a0Efde](https://debank.com/profile/0x93A62dA5a14C80f265DAbC077fCEE437B1a0Efde) +\[8\]: [https://debank.com/profile/0xFEB4acf3df3cDEA7399794D0869ef76A6EfAff52](https://debank.com/profile/0xFEB4acf3df3cDEA7399794D0869ef76A6EfAff52) +\[9\] full list of depositors → [https://gist.github.com/anyOldDev/b410c4ae27a4e1c3f3de37245205f62f](https://gist.github.com/anyOldDev/b410c4ae27a4e1c3f3de37245205f62f) +\[10\] smart contracts → [https://github.com/pandadefi/merkle-distributor-with-vesting/blob/master/contracts/MerkleDistributor.sol](https://github.com/pandadefi/merkle-distributor-with-vesting/blob/master/contracts/MerkleDistributor.sol) diff --git a/docs/contributing/governance/yips/yip-79.md b/docs/contributing/governance/yips/yip-79.md new file mode 100644 index 0000000000..4d8c45cf63 --- /dev/null +++ b/docs/contributing/governance/yips/yip-79.md @@ -0,0 +1,67 @@ +--- +title: "YIP-79: Multisig Compensation and Rotation" +hide_title: true +sidebar_position: -79 +--- + +# YIP-79: Multisig Compensation and Rotation + +| Metadata | Details | +| --- | --- | +| YIP | 79 | +| Outcome | **Passed** | +| Authors | wavey | +| Created | 2024-09-26 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-79-multisig-compensation-and-rotation/14179) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0xc7ded2863a10154b6b520921af4ada48d64d74e5b7989f98cdf073542b2e4411) | +| Vote result | For: 456.54; Against: 0 | +| Source | [Source](https://gov.yearn.fi/t/yip-79-multisig-compensation-and-rotation/14179) | + +### Proposal to rotate multisig signers and provide compensation + +## Overview + +Yearn’s main multisig, [ychad.eth](https://etherscan.io/address/0xFEB4acf3df3cDEA7399794D0869ef76A6EfAff52), is a 6 of 9 multisig which has key powers within the protocol including ownership over the treasury. For more information, including the current list of signers, please refer to [the docs](https://docs.yearn.fi/developers/security/multisig). + +This proposal aims to: + +- outline a YFI compensation plan for signers +- rotate 3 multisig signers + +## Compensation + +Currently, ychad.eth signers earn no compensation. If passed, this proposal will: + +- retroactively reward all current signers (including outgoing, excluding incoming) 1 YFI each to compensate for past efforts. +- reward all on-going signers (including incoming, excluding outgoing) with 1 YFI. + +In summary, all signers who are part of both the past and present state will receive a transfer of 2 YFI. Signers who were part of only past or future state will receive a transfer of 1 YFI. + +## Signer Rotation + +A transaction to rotate the first two signers will be queued to execute immediately upon passage of this proposal. Due to prior commitments, the final seat will be rotated at the start of December of this year. + +replace the following outgoing signers: + +| | | +| --- | --- | +| cp0x | `0x74630370197b4c4795bFEeF6645ee14F8cf8997D` | +| milkyklim | `0x0Cec743b8CE4Ef8802cAc0e5df18a180ed8402A7` | +| \*\*banteg | `0x7A1057E6e9093DA9C1D4C1D049609B6889fC4c67` | + +with the following incoming signers: + +| | | +| --- | --- | +| cryptoharry (Inverse Finance) | `0x962228a90eaC69238c7D1F216d80037e61eA9255` | +| michwill (Curve Finance) | `0xFe45baf0F18c207152A807c1b05926583CFE2e4b` | +| \*\*tapir (Yearn Finance) | `0x700F1a984C962b447CcDb95c4c2D8074C65098a3` | + +\*\* _To be executed in December_ + +## Poll + +- Yes - in favor +- No - not in favor + +0 voters diff --git a/docs/contributing/governance/yips/yip-8.md b/docs/contributing/governance/yips/yip-8.md new file mode 100644 index 0000000000..227dcd0e5a --- /dev/null +++ b/docs/contributing/governance/yips/yip-8.md @@ -0,0 +1,60 @@ +--- +title: "YIP-8: Halving YFI weekly supply the same as bitcoin" +hide_title: true +sidebar_position: -8 +--- + +# YIP-8: Halving YFI weekly supply the same as bitcoin + +| Metadata | Details | +| --- | --- | +| YIP | 8 | +| Outcome | **Rejected** | +| Authors | steamer.eth | +| Created | 2020-07-22 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/proposal-8-halving-yfi-weekly-supply-the-same-as-bitcoin/263/) | +| Snapshot vote | Not recovered | +| Vote result | No Snapshot vote recovered. | +| Source | [Source](https://github.com/yearn/YIPS/blob/master/YIPS/yip-8.md) | + +## Simple Summary + +Currently the weekly supply increase of YFI is 30,000 per week. Vote under proposal #0 is if more YFI tokens should be minted. + +I’m voting “FOR” on proposal #0 16 as continuous incentivization of LPs is important for growth of the platform. Most of reasons are the same with proposal 5. + +**More Reasons:** + +1. The YFI mining will be end in 3 days, while the whole crypto community needs more time to understand this complex mechanism. In such a short period of time, YFI cannot generate an effective market pricing. +2. To stop the YFI mining will instantly result to a huge amount remove of the liquidity, this will be a huge negative to the YFI price because of the decreasing of fee rewards. + +This is a proposal for reducing the weekly issuance rate with a model the same as BTC. Two months is enough to educate the crypto community while finishing the YFI generate event. + +**The pros of the bitcoin halving model:** + +1. Halving every week is quite easy to be understood in the crypto community, and effective. +2. Easy to make memes of YFI - “ YFI is the Bitcoin in Defi ” for virus spreading. +3. Enough time for the markets to reach the equilibrium. (liquidity provider’s YFI revenue is halved every week while taking the same risks, will result in a steady change in liquidity) + +[Modeling of 3 Pools](https://docs.google.com/spreadsheets/d/1ORG5UJUc2kKyjkemeskbpfpAfbDZ9Wk7GSEUc4RG2O0/edit?usp=sharing) + +![Model](assets/yip8.png) + +In summary. If proposal #0 passes the issuance model should be altered as described above. + +**FOR**: Support the new issuance model. + +**AGAINST**: Do not support the new issuance model. + +## Metadata + +| Name | Value | +| ------------------- | ------------------------------------------ | +| Proposed by | 0xe2ca7390e76c5A992749bB622087310d2e63ca29 | +| Total for votes | 3527868.1621 (80.25%) | +| Total against votes | 867838.6309 (19.74%) | +| Quorum | 9.73% 𐄂 | +| Start block | 10508388 | +| End block | 10525668 | + +Source: [yieldfarming.info YFI Governance Information](https://yieldfarming.info/yearn/vote/) diff --git a/docs/contributing/governance/yips/yip-80.md b/docs/contributing/governance/yips/yip-80.md new file mode 100644 index 0000000000..4eef15aa00 --- /dev/null +++ b/docs/contributing/governance/yips/yip-80.md @@ -0,0 +1,95 @@ +--- +title: "YIP-80: Sonne Hack Victims Revised Proposal" +hide_title: true +sidebar_position: -80 +--- + +# YIP-80: Sonne Hack Victims Revised Proposal + +| Metadata | Details | +| --- | --- | +| YIP | 80 | +| Outcome | **Rejected** | +| Authors | Yearninger | +| Created | 2024-09-17 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-80-sonne-hack-victims-revised-proposal/14173) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0x2a9ecea04244b83ed8f1ef6b4f62e9ee9a31d16c5ef3b52d00e3a185e78df78e) | +| Vote result | For: 0; Against: 838.86 | +| Source | [Source](https://gov.yearn.fi/t/yip-80-sonne-hack-victims-revised-proposal/14173) | + +**\[Proposal\]: One-Time Emergency Fund for Partial Compensation of yvUSDT and yvDAI Vault Users Affected by Sonne Finance Exploit (No Precedent)** + +**Summary** + +This proposal establishes a **One-Time Emergency Fund** to provide partial compensation to users of the yvUSDT and yvDAI vaults affected by the Sonne Finance exploit. Yearn will cover 70% of the remaining losses, with affected users accepting a **30% haircut**, which is **3x larger** compared to the last compensation proposal. Compensation will be provided in **YFI tokens**, with a **6-month vesting schedule** to minimize selling pressure on the market to only 7.14 YFI per month in case all victims would even sell and not just hold. + +**Background** + +On May 15, 2024, Sonne Finance, where Yearn decided to allocate significant portions of its managed yvUSDT and yvDAI vault assets (especially yvUSDT), was exploited for $20 million. Despite a prior audit by Yearn-assigned auditors, the exploit targeted a vulnerability in a new governance timelock introduced by Sonne Finance. Beefy Finance was reportedly able to withdraw their liquidity from Sonne Finance before Yearn Finance did, which led to Yearn vaults facing higher significant losses compared to Beefy vaults. + +#### Affected vaults and losses: + +- **yvUSDT Vault (Optimism)**: Net Loss: 185,291.61 USDT +- **yvDAI Vault (Optimism)**: Net Loss: 145,196.92 DAI +- **Total Net Loss** (after subtracting yvOP rewards): $330,488.53, of which users will bear 30%. + +### Motivation + +1. **Maintaining Trust**: Compensation is crucial for maintaining user trust in the protocol. +2. **Balanced Approach**: This proposal sets clear expectations without creating future precedents. +3. **One-Time Emergency**: The exploit justifies an exceptional response given the significant exposure of Yearn’s funds. + +**Specification** + +We propose the following compensation structure: + +1. **Total remaining loss**: $330,488.53 +2. **Users’ 30% haircut**: $99,146.56 (3x larger than the previous proposal). +3. **Requested Yearn compensation**: $231,341.91, paid in **YFI tokens** (~42.8 YFI as of October 1, 2024) or 7.14 YFI token per month according to the 6 month vesting schedule. This amounts to only **0.7% of Yearn’s treasury** ($32.72 M) or less than 2 weeks of Yearn’s monthly treasury yield-farming revenue\*\* (Source “Cryptonews”) +4. **One-Time Emergency Fund:** This compensation is categorized as a “**One-Time Emergency Fund**” specific to this incident, designed to address the exceptional nature of the Sonne Finance exploit. It is not intended to create a precedent for future compensation requests. +5. **Future Recovery Assignment:** Users will assign all future recoveries provided by Sonne Finance to the Yearn DAO to offset the compensation provided. +6. **Reimbursement Clause:** Any future recoveries through legal actions or third-party settlements will be reimbursed to Yearn, potentially offsetting the cost of this compensation. +7. **Exclusion of Minor Losses:** Vaults with losses of less than 1% are excluded from this compensation proposal, aligning with Yearn’s approach to focus on significant losses. + +Users are then fully aligned with the objective of Yearn. + +**Conclusion** + +By approving this proposal, Yearn will compensate affected users, while implementing a large 30% haircut and ensuring no future compensation expectations are set. The 6 month vesting schedule of YFI reduces the sell pressure of YFI significantly to only 7.14 YFI token per month which is neglectable. +The significant allocation to Sonne Finance justifies this one-off response to mitigate the impact on Yearn users. Furthermore, Yearn’s treasury strength and monthly yield-farming revenue strengthens its ability to support such one-time emergency compensation without jeopardizing its long-term sustainability. + +**Process for Execution if Voted “Yes”** + +A. **Full list of depositors** → [Data on Sonne Depositors and compensation amounts · GitHub](https://gist.github.com/anyOldDev/b410c4ae27a4e1c3f3de37245205f62f) +A balance snapshot of the vault and the rewards contract combined, done using The Graph. + +B. **Smart contracts** → we will use the code from [GitHub - Uniswap/merkle-distributor: 📦 A smart contract that distributes a balance of tokens according to a merkle root](https://github.com/Uniswap/merkle-distributor) + +C. **Merkle proof:** Yearn chooses between DAI, USDC or USDT and will generate the Merkle proof based on the price of the chosen stablecoin and the full list of depositors as disclosed in the link above. + +D. **Execution:** Yearn (or alternatively the team behind the proposal) will generate the Merkle proof based on the information provided and deploy the contract. + +E. **Assistance:** The team behind the proposal will assist if necessary to create the Merkle proof and execute the in the chosen stablecoin. + +## Voting + +- YES! For partial compensation +- no + +- YES! For partial compensation of victims +- No + +0 voters + +**Resources** + +\[1\]: ⁠⁠[Yearn Talk⁠](https://discord.com/channels/734804446353031319/734862139386232902/1243331990015443024) +\[2\]: [Yearn Vault](https://yearn.fi/vaults/10/0xFaee21D0f0Af88EE72BB6d68E54a90E6EC2616de?tab=strategies) +\[3\]: [Yearn Vault](https://yearn.fi/vaults/10/0x65343F414FFD6c97b0f6add33d16F6845Ac22BAc?tab=strategies) +\[4\]: [Screen\_Shot\_2024-07-17\_at\_4.48.16\_PM.png](https://media.discordapp.net/attachments/1242905752440410162/1263235946338582548/Screen_Shot_2024-07-17_at_4.48.16_PM.png?ex=66a01727&is=669ec5a7&hm=d07d4c5cc35fa23adb06cf3fd4bc7ed40b9f8da2ded25b9cda36224984ec3942&format=webp&quality=lossless&width=1292&height=290&) +\[5\]: [DeBank | Your go-to portfolio tracker for Ethereum and EVM](https://debank.com/profile/0x93A62dA5a14C80f265DAbC077fCEE437B1a0Efde) +\[6\]: [DeBank | Your go-to portfolio tracker for Ethereum and EVM](https://debank.com/profile/0xFEB4acf3df3cDEA7399794D0869ef76A6EfAff52) +\[7\] full list of depositors → [Data on Sonne Depositors and compensation amounts · GitHub](https://gist.github.com/anyOldDev/b410c4ae27a4e1c3f3de37245205f62f) +\[8\] smart contracts → [https://github.com/pandadefi/merkle-distributor-with-vesting/blob/master/contracts/MerkleDistributor.sols](https://github.com/pandadefi/merkle-distributor-with-vesting/blob/master/contracts/MerkleDistributor.sols) +\[9\]: [yAudit Reports](https://reports.yaudit.dev/reports/05-2023-Sonne/) +\[10\]: [Rekt - Sonne Finance - Rekt](https://rekt.news/sonne-finance-rekt/) diff --git a/docs/contributing/governance/yips/yip-81.md b/docs/contributing/governance/yips/yip-81.md new file mode 100644 index 0000000000..1cfdf9893c --- /dev/null +++ b/docs/contributing/governance/yips/yip-81.md @@ -0,0 +1,144 @@ +--- +title: "YIP-81: Prepare for Full On-Chain Governance" +hide_title: true +sidebar_position: -81 +--- + +# YIP-81: Prepare for Full On-Chain Governance + +| Metadata | Details | +| --- | --- | +| YIP | 81 | +| Outcome | **Passed** | +| Authors | 0xPickles | +| Created | 2024-11-22 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-81-prepare-for-full-on-chain-governance/14282) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0x6f3082db2cef3e0c254e569580d063cb14130a92d0bf1729bef342a386e419f2) | +| Vote result | For: 733.97; Against: 0 | +| Source | [Source](https://gov.yearn.fi/t/yip-81-prepare-for-full-on-chain-governance/14282) | + +## Summary + +This proposal outlines the preparatory steps for implementing on-chain governance (OCG). By formalizing processes, parameters, and roles while governance is still off-chain, we aim to iterate and refine the system before its deployment. + +### Status + +**Discussion** +This proposal is in the discussion phase. Following the voting rules in YIP-55, it will remain open for at least 3 days, accompanied by a non-binding forum poll to gauge sentiment. Afterward, it may be assigned a YIP number and progress to Snapshot for a binding vote by veYFI holders. + +## Abstract + +**If adopted,** this proposal will: + +1. Extend the veYFI system to cover all governance proposals, beyond gauge emissions and parameter changes. +2. Formalize yChad’s role as protocol Guardian. +3. Establish percentage-based voting requirements for Liquid Locker Protocols (LLPs). +4. Enable optional extensions like veYFI delegation and budget requests. + +The goal is to ensure a smooth transition to full OCG while addressing potential design flaws during this preparatory phase. + +## Background + +YIP-65 [\[1\]](#references) introduced the veYFI system for governance, and YIP-73 [\[2\]](#references) further formalized it with gauges, epochs, and a voting process. This proposal expands veYFI’s scope to include all governance proposals, facilitating the DAO’s move away from Snapshot voting. + +### Out of Scope + +- Governance of yPools (e.g., yETH, yUSD), which remains with respective staked token holders. +- Governance of yTeams, managed by their contributors. +- No new tokens or airdrops are proposed. + +## Motivation + +Refining the governance system during the off-chain phase enables us to identify and address flaws, ensuring a robust foundation before the full OCG deployment. + +### Future Possibilities + +- Directing protocol income dynamically during epochs via OCG. +- Allocating YFI dynamically during epochs via OCG. +- Appointing governance bodies or councils with specific powers. + +### Risks + +- Design or implementation flaws causing unexpected behavior. +- Low veYFI lock rates, voter apathy, and/or lack of attention/incentives leading to limited participation. +- Domination by a single Liquid Locker Protocol, posing systemic risks. + +## Specification + +### 1\. tl;dr + +1. Apply YIP-73’s operational framework to all governance proposals, including Yearn Improvement Proposals (YIPs). +2. Formalize yChad’s role as protocol Guardian. +3. Enforce percentage-based voting for LLPs. +4. Enable optional extensions where technically feasible. + +### 2\. Apply YIP-73 Framework to All Governance Proposals + +1. Use the 2-week epoch pattern from YIP-73: proposals are submitted in the first half and voted on in the second half of a veYFI epoch. +2. Require a minimum of 1 veYFI for proposal submission. +3. Proposals pass with a simple majority (>50% of veYFI votes). +4. Apply the quorum and vote decay parameters from YIP-73 to all proposals. +5. Snapshot voting remains the venue for voting until OCG is active. + +### 3\. Formalize Protocol Guardian Role + +1. yChad’s role as protocol Guardian is formalized and encoded in the protocol. +2. The Guardian can nullify a proposal or governance decision but cannot make proposals. +3. Guardian powers are implemented before OCG and persist after deployment. +4. The Guardian role can be reassigned via a YIP vote. + +### 4\. Liquid Locker Percentage-Based Voting + +1. Define LLPs as protocols that lock veYFI on behalf of users and aggregate dYFI boosts. +2. Require LLPs to support percentage-based voting, ensuring user preferences are accurately reflected. + - Example: If an LLP’s users vote 55% FOR and 45% AGAINST, the LLP votes 55% FOR and 45% AGAINST. +3. LLPs failing to comply may have their votes rescinded by the Guardian. + +### 5\. Optional Extensions + +#### 5.1 veYFI Delegation + +- Enable delegation of veYFI voting power to external addresses or smart contracts, similar to the mechanism already used via the Snapshot system. + +#### 5.2 Budget Requests + +1. Allow budget requests and funding proposals to be submitted via veYFI governance. +2. Ensure on-chain execution for approved proposals. +3. Maintain Guardian oversight to rescind adopted requests. + +### 6\. Implementation + +1. Changes take effect immediately where feasible. +2. Features not supported by Snapshot remain disabled until OCG is live. +3. Contributors are authorized to deploy necessary smart contracts post-design, development, and audits. + +### 7\. Iterative Improvements + +1. Run the system as a public beta to identify friction points or flaws. +2. Significant changes require additional YIPs for approval. +3. veYFI voters can propose design adjustments through new proposals. + +### 8\. Use at Own Risk + +Yearn protocols are governed by veYFI holders, who make strategic decisions. Contributors are not liable for failures or losses resulting from veYFI or governance usage. + +## Vote + +### Non-binding signaling poll + +Proceed with this proposal in its current form? + +- Yes +- No + +0 voters + +## References + +1. [YIP-65: Evolving YFI Tokenomics](https://gov.yearn.fi/t/yip-65-evolving-yfi-tokenomics/11994) +2. [YIP-73: Activate veYFI Rewards with dYFI Gauges](https://gov.yearn.fi/t/yip-73-activate-veyfi-rewards-with-dyfi-gauges/13414) + +## Changelog + +- Initial draft +- Assigning YIP# diff --git a/docs/contributing/governance/yips/yip-82.md b/docs/contributing/governance/yips/yip-82.md new file mode 100644 index 0000000000..99e03343d8 --- /dev/null +++ b/docs/contributing/governance/yips/yip-82.md @@ -0,0 +1,194 @@ +--- +title: "YIP-82: The BIP YIP, Bearn Finance" +hide_title: true +sidebar_position: -82 +--- + +# YIP-82: The BIP YIP, Bearn Finance + +| Metadata | Details | +| --- | --- | +| YIP | 82 | +| Outcome | **Rejected** | +| Authors | The yBera Boyzzzz | +| Created | 2025-01-21 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-82-the-bip-yip-bearn-finance/14359) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0x24ae3413fcf92bcb92cbbe8845d0684a4e8d36c7f164b4afee6c45c629f16f83) | +| Vote result | For: 506.27; Against: 576.04 | +| Source | [Source](https://gov.yearn.fi/t/yip-82-the-bip-yip-bearn-finance/14359) | + +[![bearn](https://europe1.discourse-cdn.com/flex013/uploads/yearn/optimized/2X/f/f80a5084db802701126ab04e3ca0817b28dfb1f5_2_500x500.jpeg) + +bearn1024×1024 252 KB + +](https://europe1.discourse-cdn.com/flex013/uploads/yearn/original/2X/f/f80a5084db802701126ab04e3ca0817b28dfb1f5.jpeg "bearn") + +## Authors + +The yBera Boyzzzz + +## Summary + +Fund and endorse “Bearn” aka “The Blue Bear” aka “The Big Bad Bearn’n Bananza”, a new sub DAO focused on building and launching products on Berachain. + +Are you ready to feel the Bearn? + +## Abstract + +If adopted, this proposal seeks to: + +- Endorse Bearn as an official sub DAO of Yearn +- Fund the new sub DAO and kick off development +- Specify the goals, structure and launch specifications +- Make Yearn Great Again + +## Background + +[Berachain](https://www.berachain.com/) is a new EVM equivalent layer 1 network launching with a novel consensus mechanism called [Proof of Liquidity](https://docs.berachain.com/learn/what-is-proof-of-liquidity) (POL). POL is meant to unlock many new types of structures for apps to gain traction and interact with both users and the validators of the network. Given that the main focus of Berachain is to revitalize yield farming in DeFi, it makes perfect sense for Yearn to focus on building on Berachain. + +However, due to the novel nature of POL, the products that will make the most sense for Berachain will different enough than the current Yearn products to motivate a entirely new sub DAO that utilizies existing Yearn products and infrastrucutre where possible but builds new parts where needed. + +The sub DAO is structured so that the success of Bearn will be able to contribute greatly both to the success of existing Yearn products as well as return new sources of revenue to the treasury. + +## **Vision** + +Bearn will start with two main products, a stable coin and a BGT liquid locker, that will work together to create one of a kind offerings made possible due to Berachain’s unique design. + +#### **Stable coin**: + +Bearn will launch a Bera native, over collateralized, demand driven stable coin whose entire backing will be deposited into Yearn vaults. + +Yearn vaults greatest strengths have always been its use by other protocols to outsource the yield generation needs to power unique use cases such as with Alchemix and Abra. The Bearn stable coin is the next iteration of this. At launch the stable coin will only be mintable using approved stable coins, such as USDC, USDT and USDS. All of these coins will then be deposited into the main Yearn “1” vaults on ETH mainnet to earn Yield. + +Bearn will then utilize the veYFI system for both bribing veYFI holders and staking the vault tokens to earn additional dYFI to help boost the yields of the stable coin backing as well. + +The yield earned by these deposits will be periodically “harvested”, bridged to Berachain and then used to bribe on Bera for BGT emissions to be directed towards positive sum behavior to encourage use of the stable. + +For example, it can be used to direct BGT emissions to the STABLE/HONEY LP token, a yvSTABLE savings vault, or even lending positions in custom lending markets for other stables such as HONEY, to allow yvSTABLE users to leverage their positions. + +The increased efficiency of stable coin bribes for both veYFI emissions and for BGT from a continuous flow of sustainable real yield to encourage positive sum behavior means it can continuously create real demand for its use and existence by being one of the highest yielding native stable coins on the market, bringing in new demand and thus more deposits for Yearn vaults. + +\*\*If successful the stable coin model could be expanded to other assets such as ETH for Berachain as well as any L2’s. + +#### **yBGT**: + +yBGT is a liquid locker and reward compounder, similar to yCRV, for users to stake their BGT eligible tokens and earn either yBGT or have their positions auto-compounded. + +#### Earn BGT + +- User deposits BGT eligible tokens in a Bearn vault that stakes them. +- All BGT earned is kept locked and an equal amount of yBGT is minted. +- Users then can claim any earned BGT for their position (minus a small fee) as yBGT. +- yBGT can be sold through certain secondary markets. Or staked to earn share of revenues from Bearn’s ever expanding BGT position. + +#### Compounders: + +- Users deposit their BGT eligible tokens to a vault that stakes them to earn BGT. +- All the BGT minus a fee get redeemed for BERA, sold and compounded into more of the underlying asset deposited. +- The remaining BGT is minted as yBGT to the protocol. +- Users get a simple classic Yearn compounder product and yBGT becomes more attractive cause it controls more BGT overall. + +yBGT combines both of Yearn’s longest standing products, a liquid locker and auto compounding vaults to give users a unique product that allows them to get to full benefits of the Berachain designs easily by abstracting away the complexity + +## Motivation + +By itself each product offers a unique value for users, but still has significant competition for other similar products. However, launching them together creates an extra layer of synergy that puts the benefits to users above what they can get elsewhere. + +To List a few examples of the positive synergies: + +- yBGT compounders will be listed as collateral in custom lending markets where the STABLE is the borrow token. This gives an immediate competitive advantage to the BGT compounders, since they can be collateral, as well as gives an immediate real use case for the STABLE to generate even more demand that does not put the backing of the coin at risk. +- The lowest risk compounders such as the native gauges, will be used as collateral in a CDP to mint the stable coin +- Fees from the secondary lending markets will be used to help bribe the lending positions of those markets thus increasing the viability and attractiveness of yBGT compounders and the stable. +- Bearn can be fully vertically integrated having both money to bribe with, BGT to bribe and potentially our own future validator’s to delegate BGT to which will increase effeciencies and profitability at every layer. +- Autocompounders of the Stable’s bribed tokens (ex: yvSTABLE) give a much better product for users as well as creating perpetual buy pressure for the stable coin and help the protocol accumulate Protocol owned BGT. + +For a perfect example of the synergy consider the yvSTABLE vault, whose goal is to give users a simple very high yielding place to deposit the STABLE and create demand to hold the coin. + +EX: + +- The majority of bribes from STABLE backings yield is used to direct BGT emissions to a reward vault for yvSTABLE. +- yBGT launches an autocompounder for the yvSTABLE reward vault giving users a simple high yielding bearing stable coin product. +- All extra BGT earned from the autcompounder taken as fees makes the yBGT and BEARN token more attractive +- yvSTABLE will be able to deploy the capital deposited into the vault into the secondary markets to be used by other yBGT users to leverage their positions creating both more yield for yvSTABLE depositors as well as a better use case and more TVL for the yBGT products. Both of which generate more fees for the protocol. + +The new governance token earning revenues from both products also make it a much more attractive token to hold and stake. + +## Token + +A new governance token $BEARN will be issued in conjunction with the launch of the sub DAO that will be in charge of needed operational decisions regarding the protocol as well as returning revenues earned by the protocol back to owners (such as the Yearn Treasury). + +#### Controls: + +- STABLE bakcing composition, limits and fees +- Minter and Burner whitelist’s for STABLE +- Secondary Market operations such as collateral’s to add, LTV’s etc. +- Future CDP deployment collaterals and LTV’s. +- STABLE bribes +- keepBGT rates for the rewards vaults. +- Fees for reward vaults. +- BGT delegations +- Grant funding + +### Revenues + +- PSM fees (yield and burning) +- Secondary Market fees +- Future CDP fees or interest +- keepBGT and fees from reward vault deposits. +- Protocol owned yBGT yield +- yvSTABLE performance fees +- Potential future validator revenue + +#### Allocations + +Yearn - 10% (Staked and vests linearly over 3 years) +Team - 15% (Staked and vests linearly over 3 years with a 1 year cliff) +Treasury - 15% (Future Grants) +veYFI Holders: 2% (Optional vest or immediate unlock for reduced amount) +Pre-Launch Boints program - 8% +Post launch Incentives - 50% + +* * * + +## Overview + +[![image](https://europe1.discourse-cdn.com/flex013/uploads/yearn/optimized/2X/e/ed1fabec9e80cd66702f42fd1446c16218f16fb4_2_690x365.jpeg) + +image4984×2638 566 KB + +](https://europe1.discourse-cdn.com/flex013/uploads/yearn/original/2X/e/ed1fabec9e80cd66702f42fd1446c16218f16fb4.jpeg "image") + +## Proposal + +Request is for $600k in exchange for 10% of the initial token supply to be distributed as a staked version on Bera Chain to the Yearn Treasury. The governance rights over the tokens will be delegated to the yLockers team. The yield earned from the the tokens from protocol revenue and yBGT yield will be periodically bridged back to mainnet as a stable coin to either return to the treasury or distribute to veYFI holders. + +This serves as a one time grant as the funding for the expected full cost of development and launch of the protocol, including audit, dev costs etc. Once launched the team will earn income based on the revenues earned from the protocol as well as future token grants from the treasury allocation. + +Yearn receives the full value of the tokens as they vest based on the current market rate as well as the continuous revenue payed out to stakers, of which it will be the largest single owner. + +Yearn should see a drastic increase in TVL in its mainnet single asset vaults that are used as the stable coins backing since 100% of the TVL backing the coin at launch will be deployed to the vaults on mainnet and thus increase fees to the DAO. + +veYFI holders will see an increase in the effective yield of their positions due to the presence of a new bribe market for the directing of dYFI emmisions. + +An additional 2% of the token supply will be airdropped to veYFI holders to give them the ability for immediate direct governance in the new protocol. + +In addition we request another $1m in liquidity to be deployed by the Yearn DAO to be the initial farmer of the system. These funds will be delegated to the yLockers team, once the pre-launch Boints program is launched, so they do not leave the control of the DAO and will unlock after 1 year for the DAO to either leave deposited or remove. All farming proceeds, including earned BEARN can be immediately claimed/sold and bridged back to mainnet or continuously compounded. + +**TOTALS**: +\- **GRANT**: $600k for 10% of BEARN supply. Payment will be split into 3 equal parts +\- 1) On approval of the YIP +\- 2) Once contracts go to Audit +\- 3) Once contracts complete the audits +\- **Liquidity**: $1m locked for 1 year. +\-Sent to ylockers msig on mainnet once pre-launch Boints campaign begins. + +\*\*NOTE: It is the hope that the initial grant will be enough to launch the product. If not, the team will be required to either find additional outside funding or create an additional YIP for another grant in exchange for more tokens. + +Ooga Fuckin Booga! + +Follow the twitter for more update: [https://twitter.com/Bearnsucks](https://twitter.com/Bearnsucks) + +- For +- Against + +0 voters diff --git a/docs/contributing/governance/yips/yip-83.md b/docs/contributing/governance/yips/yip-83.md new file mode 100644 index 0000000000..4b48c8a8ad --- /dev/null +++ b/docs/contributing/governance/yips/yip-83.md @@ -0,0 +1,191 @@ +--- +title: "YIP-83: Bearn BIP YIP #2" +hide_title: true +sidebar_position: -83 +--- + +# YIP-83: Bearn BIP YIP #2 + +| Metadata | Details | +| --- | --- | +| YIP | 83 | +| Outcome | **Passed** | +| Authors | Schlag | +| Created | 2025-03-31 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-83-bearn-bip-yip-2/14456) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0x872f23d57eea829e5fb0a5e0868f805efdb231d8a3c9e39820dd33432ccd629c) | +| Vote result | For: 298.79; Against: 0 | +| Source | [Source](https://gov.yearn.fi/t/yip-83-bearn-bip-yip-2/14456) | + +# The BIP YIP + +[![bearn](https://europe1.discourse-cdn.com/flex013/uploads/yearn/optimized/2X/f/f80a5084db802701126ab04e3ca0817b28dfb1f5_2_500x500.jpeg) + +bearn1024×1024 252 KB + +](https://europe1.discourse-cdn.com/flex013/uploads/yearn/original/2X/f/f80a5084db802701126ab04e3ca0817b28dfb1f5.jpeg "bearn") + +After the last Bearn proposal was voted down through governance, we engaged with veYFI and Yearn’s major stakeholders and have reworked the proposal based on the feedback received. + +A full diff of the original can be found here: [BIP Diff](https://www.diffchecker.com/YQ2bxKmM/) + +TLDR: The amount we are asking for was reduced to only cover audit costs and the initial token allocations were changed based on this. + +## Authors + +The yBera Boyzzzz + +## Summary + +Fund and endorse “Bearn” aka “The Blue Bear” aka “The Big Bad Bearn’n Bananza”, a new sub DAO focused on building and launching products on Berachain. + +Are you ready to feel the Bearn? + +## Abstract + +If adopted, this proposal seeks to: + +- Endorse Bearn as an official sub DAO of Yearn +- Fund the new sub DAO and kick off development +- Specify the goals, structure and launch specifications +- Make Yearn Great Again + +## Background + +[Berachain](https://www.berachain.com/) is a new EVM equivalent layer 1 network launching with a novel consensus mechanism called [Proof of Liquidity](https://docs.berachain.com/learn/what-is-proof-of-liquidity) (POL). POL is meant to unlock many new types of structures for apps to gain traction and interact with both users and the validators of the network. Given that the main focus of Berachain is to revitalize yield farming in DeFi, it makes perfect sense for Yearn to focus on building on Berachain. + +However, due to the novel nature of POL, the products that will make the most sense for Berachain will different enough than the current Yearn products to motivate a entirely new sub DAO that utilizies existing Yearn products and infrastrucutre where possible but builds new parts where needed. + +The sub DAO is structured so that the success of Bearn will be able to contribute greatly both to the success of existing Yearn products as well as return new sources of revenue to the treasury. + +## **Vision** + +Bearn will start with two main products, a stable coin and a BGT liquid locker, that will work together to create one of a kind offerings made possible due to Berachain’s unique design. + +#### **Stable coin**: + +Bearn will launch a Bera native, over collateralized, demand driven stable coin whose entire backing will be deposited into Yearn vaults. + +Yearn vaults greatest strengths have always been its use by other protocols to outsource the yield generation needs to power unique use cases such as with Alchemix and Abra. The Bearn stable coin is the next iteration of this. At launch the stable coin will only be mintable using approved stable coins, such as USDC, USDT and USDS. All of these coins will then be deposited into the main Yearn “1” vaults on ETH mainnet to earn Yield. + +Bearn will then utilize the veYFI system for both bribing veYFI holders and staking the vault tokens to earn additional dYFI to help boost the yields of the stable coin backing as well. + +The yield earned by these deposits will be periodically “harvested”, bridged to Berachain and then used to bribe on Bera for BGT emissions to be directed towards positive sum behavior to encourage use of the stable. + +For example, it can be used to direct BGT emissions to the STABLE/HONEY LP token, a yvSTABLE savings vault, or even lending positions in custom lending markets for other stables such as HONEY, to allow yvSTABLE users to leverage their positions. + +The increased efficiency of stable coin bribes for both veYFI emissions and for BGT from a continuous flow of sustainable real yield to encourage positive sum behavior means it can continuously create real demand for its use and existence by being one of the highest yielding native stable coins on the market, bringing in new demand and thus more deposits for Yearn vaults. + +\*\*If successful the stable coin model could be expanded to other assets such as ETH for Berachain as well as any L2’s. + +#### **yBGT**: + +yBGT is a liquid locker and reward compounder, similar to yCRV, for users to stake their BGT eligible tokens and earn either yBGT or have their positions auto-compounded. + +#### Earn BGT + +- User deposits BGT eligible tokens in a Bearn vault that stakes them. +- All BGT earned is kept locked and an equal amount of yBGT is minted. +- Users then can claim any earned BGT for their position (minus a small fee) as yBGT. +- yBGT can be sold through certain secondary markets. Or staked to earn share of revenues from Bearn’s ever expanding BGT position. + +#### Compounders: + +- Users deposit their BGT eligible tokens to a vault that stakes them to earn BGT. +- All the BGT minus a fee get redeemed for BERA, sold and compounded into more of the underlying asset deposited. +- The remaining BGT is minted as yBGT to the protocol. +- Users get a simple classic Yearn compounder product and yBGT becomes more attractive cause it controls more BGT overall. + +yBGT combines both of Yearn’s longest standing products, a liquid locker and auto compounding vaults to give users a unique product that allows them to get to full benefits of the Berachain designs easily by abstracting away the complexity + +## Motivation + +By itself each product offers a unique value for users, but still has significant competition for other similar products. However, launching them together creates an extra layer of synergy that puts the benefits to users above what they can get elsewhere. + +To List a few examples of the positive synergies: + +- yBGT compounders will be listed as collateral in custom lending markets where the STABLE is the borrow token. This gives an immediate competitive advantage to the BGT compounders, since they can be collateral, as well as gives an immediate real use case for the STABLE to generate even more demand that does not put the backing of the coin at risk. +- The lowest risk compounders such as the native gauges, will be used as collateral in a CDP to mint the stable coin +- Fees from the secondary lending markets will be used to help bribe the lending positions of those markets thus increasing the viability and attractiveness of yBGT compounders and the stable. +- Bearn can be fully vertically integrated having both money to bribe with, BGT to bribe and potentially our own future validator’s to delegate BGT to which will increase effeciencies and profitability at every layer. +- Autocompounders of the Stable’s bribed tokens (ex: yvSTABLE) give a much better product for users as well as creating perpetual buy pressure for the stable coin and help the protocol accumulate Protocol owned BGT. + +For a perfect example of the synergy consider the yvSTABLE vault, whose goal is to give users a simple very high yielding place to deposit the STABLE and create demand to hold the coin. + +EX: + +- The majority of bribes from STABLE backings yield is used to direct BGT emissions to a reward vault for yvSTABLE. +- yBGT launches an autocompounder for the yvSTABLE reward vault giving users a simple high yielding bearing stable coin product. +- All extra BGT earned from the autcompounder taken as fees makes the yBGT and BEARN token more attractive +- yvSTABLE will be able to deploy the capital deposited into the vault into the secondary markets to be used by other yBGT users to leverage their positions creating both more yield for yvSTABLE depositors as well as a better use case and more TVL for the yBGT products. Both of which generate more fees for the protocol. + +The new governance token earning revenues from both products also make it a much more attractive token to hold and stake. + +## Token + +A new governance token $BEARN will be issued in conjunction with the launch of the sub DAO that will be in charge of needed operational decisions regarding the protocol as well as returning revenues earned by the protocol back to owners (such as the Yearn Treasury). + +#### Controls: + +- STABLE bakcing composition, limits and fees +- Minter and Burner whitelist’s for STABLE +- Secondary Market operations such as collateral’s to add, LTV’s etc. +- Future CDP deployment collaterals and LTV’s. +- STABLE bribes +- keepBGT rates for the rewards vaults. +- Fees for reward vaults. +- BGT delegations +- Grant funding + +### Revenues + +- PSM fees (yield and burning) +- Secondary Market fees +- Future CDP fees or interest +- keepBGT and fees from reward vault deposits. +- Protocol owned yBGT yield +- yvSTABLE performance fees +- Potential future validator revenue + +#### Allocations + +Yearn - 5% (Staked and vests linearly over 3 years) +Team - 20% (Staked and vests linearly over 3 years with a 1 year cliff) +Treasury - 15% (Future Grants) +Pre-Launch Boints program - 10% +Post launch Incentives - 50% + +* * * + +## Overview + +[![image](https://europe1.discourse-cdn.com/flex013/uploads/yearn/optimized/2X/e/ed1fabec9e80cd66702f42fd1446c16218f16fb4_2_690x365.jpeg) + +image4984×2638 566 KB + +](https://europe1.discourse-cdn.com/flex013/uploads/yearn/original/2X/e/ed1fabec9e80cd66702f42fd1446c16218f16fb4.jpeg "image") + +## Proposal + +Request is for a maximum of $200k to cover the audit costs of yBGT, the stable coin and any needed governance audits in exchange for 5% of the initial token supply to be distributed as a staked version on Bera Chain to the Yearn Treasury. The governance rights over the tokens will be delegated to the yLockers team. The yield earned from the the tokens from protocol revenue and yBGT yield will be periodically bridged back to mainnet as a stable coin to either return to the treasury or distribute to veYFI holders. + +Yearn receives the full value of the tokens as they vest based on the current market rate as well as the continuous revenue payed out to stakers, of which it will be the largest single owner. + +Yearn should see a drastic increase in TVL in its mainnet single asset vaults that are used as the stable coins backing since 100% of the TVL backing the coin at launch will be deployed to the vaults on mainnet and thus increase fees to the DAO. + +veYFI holders will see an increase in the effective yield of their positions due to the presence of a new bribe market for the directing of dYFI emmisions. + +In addition we request another $1m in liquidity to be deployed by the Yearn DAO to be the initial farmer of the system. These funds will be delegated to the yLockers team, once the pre-launch Boints program is launched, so they do not leave the control of the DAO and will unlock after 1 year for the DAO to either leave deposited or remove. All farming proceeds, including earned BEARN can be immediately claimed/sold and bridged back to mainnet or continuously compounded. + +**TOTALS**: +\- **Audit Costs**: Up to $200k sent directly to yAudit as invoiced +\- **Liquidity**: $1m locked for 1 year sent to 0x4444444455bF42de586A88426E5412971eA48324 for management + +Ooga Fuckin Booga! + +[https://x.com/Bearnsucks](https://x.com/Bearnsucks) + +- For +- Against + +0 voters diff --git a/docs/contributing/governance/yips/yip-84.md b/docs/contributing/governance/yips/yip-84.md new file mode 100644 index 0000000000..ef90a8ac27 --- /dev/null +++ b/docs/contributing/governance/yips/yip-84.md @@ -0,0 +1,49 @@ +--- +title: "YIP-84: Proposal to rotate multisig signer" +hide_title: true +sidebar_position: -84 +--- + +# YIP-84: Proposal to rotate multisig signer + +| Metadata | Details | +| --- | --- | +| YIP | 84 | +| Outcome | **Passed** | +| Authors | wavey | +| Created | 2025-04-13 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-84-proposal-to-rotate-multisig-signer/14469) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0xeecd2a9ca79f9b22071d79d436a7e5ccc56593eb4c3bc8ef1b57c8389809a101) | +| Vote result | For: 318.69; Against: 0 | +| Source | [Source](https://gov.yearn.fi/t/yip-84-proposal-to-rotate-multisig-signer/14469) | + +## Overview + +If enacted, this proposal replaces multisig signer Monoloco with new signer Ephy and transfers 1 YFI to Ephy as compensation. Additionally, it will update active signer Lumberg’s address to reflect a routine personal key rotation. + +## Background + +Yearn’s main multisig, [ychad.eth](https://etherscan.io/address/0xFEB4acf3df3cDEA7399794D0869ef76A6EfAff52), is a 6 of 9 multisig which has key powers within the protocol. For more information, including the current list of signers, please refer to [the docs](https://docs.yearn.fi/developers/security/multisig). + +As established in [YIP-79](https://gov.yearn.fi/t/yip-79-multisig-compensation-and-rotation/14179), signers who rotate on to the multisig shall receive 1 YFI compensation. + +This rotation was initiated at the request of Monoloco, who has stepped back from active involvement in DeFi. We extend our gratitude to him for his contributions and dedicated service. + +The proposed incoming signer is **Ephy**, Dewiz.xyz co-founder, a well-regarded contributor in the [Maker / Sky](https://forum.sky.money/u/0x3phemeralsoul/summary) ecosystem and a former MakerDAO Core Unit contributor. You can find more about Ephy on [X](https://x.com/0x3phemeralsoul) and [GitHub](https://github.com/0x3phemeralsoul). + +## Specification + +1. Replace the following signer: + - outgoing: `0x1496546f89fc1605880e556c9a1d6c5e2409fb0a` (Monoloco) + - incoming: `0x5Db9926c93085a92F14A85daBF6FF27b07362Cae` (Ephy) +2. Transfer 1 YFI from ychad.eth to Ephy’s signer address. +3. Rotate Lumberg’s key: + - outgoing: `0x7321ED86B0Eb914b789D6A4CcBDd3bB10f367153` (Lumberg old) + - incoming: `0xeA6c0837fef621E77329f85820F503cA09f2B3a9` (Lumberg new) + +## Poll + +- Yes - in favor +- No - not in favor + +0 voters diff --git a/docs/contributing/governance/yips/yip-85.md b/docs/contributing/governance/yips/yip-85.md new file mode 100644 index 0000000000..59796007fd --- /dev/null +++ b/docs/contributing/governance/yips/yip-85.md @@ -0,0 +1,70 @@ +--- +title: "YIP-85: Disable Protocol Fees on Yearn V3" +hide_title: true +sidebar_position: -85 +--- + +# YIP-85: Disable Protocol Fees on Yearn V3 + +| Metadata | Details | +| --- | --- | +| YIP | 85 | +| Outcome | **Passed** | +| Authors | V3 Protocol Team | +| Created | 2025-05-05 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-85-disable-protocol-fees-on-yearn-v3/14484) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0xa3223b388c484ea8a81b60bb88cda99f23d6d06b4b9798b4d0acafaa2207b686) | +| Vote result | Yes: 543.15; No: 0 | +| Source | [Source](https://gov.yearn.fi/t/yip-85-disable-protocol-fees-on-yearn-v3/14484) | + +## Authors + +V3 Protocol Team + +## Summary + +This proposal seeks approval from the Yearn community to disable all protocol-level fees within the Yearn V3 vault system across all deployed chains. This change aims to enhance growth, simplify the user experience, and foster greater adoption among third-party protocols. + +## Abstract + +The Yearn V3 system has seen encouraging adoption by partners, but the revenue generated from protocol-level fees has proven insignificant in terms of Yearn’s overall financial performance. These fees, while nominal, introduce unnecessary complexity, confusion, and friction, ultimately limiting the adoption and growth potential of Yearn’s infrastructure. Eliminating the protocol fees will simplify integration and incentivize more third-party protocols to leverage Yearn’s V3 infrastructure, thereby extending Yearn’s ecosystem and reinforcing its position as the preferred standard for ERC-4626 yield vaults. + +## Motivation + +The Yearn V3 vault system was developed with a vision of simplifying yield generation and providing a robust, standardized foundation (ERC-4626) for DeFi protocols. While usage metrics indicate a positive reception among partner protocols, the collected fees have had minimal impact on Yearn’s bottom line. Conversely, the existence of these fees has introduced: + +- Increased complexity in vault deployment and management. +- User confusion around fee structures +- Hesitancy from third-party protocols to fully integrate Yearn’s vaults due to perceived competitive disadvantages or increased operational complexity. +- Those that have integrated have tended to use it in a way that avoids the protocol fee, with a few teams choosing to fork the code instead of use the official releases. + +## Specification + +If approved, Yearn’s protocol fee parameters for the V3 vault factories will be set to 0. + +This action will not impact existing performance or management fees collected by individual vaults. + +## Benefits + +- Reduces operational complexity for Yearn and integrating partners. +- Clarifies and streamlines fee structures for end-users. +- Increases competitiveness of Yearn’s V3 vault infrastructure. +- Potentially expands Yearn’s ecosystem through increased adoption and usage of its technology. +- Indirectly boosts Yearn’s brand visibility and establishes greater industry influence. + +## Risks + +- Short-term reduction in nominal protocol fee revenues. +- Possible perception that fee-free infrastructure is less sustainable, though mitigated by maintaining existing management and performance fees on Yearn-managed vaults. + +## Voting + +Voting will occur through the standard Yearn governance platform: + +- **Yes:** Approve proposal to set V3 protocol fees to 0% across all chains. +- **No:** Reject proposal and maintain existing protocol fee structure. + +- For +- Against + +0 voters diff --git a/docs/contributing/governance/yips/yip-86.md b/docs/contributing/governance/yips/yip-86.md new file mode 100644 index 0000000000..a8378d2c36 --- /dev/null +++ b/docs/contributing/governance/yips/yip-86.md @@ -0,0 +1,64 @@ +--- +title: "YIP-86: Resupply Bad Debt Repayment Loan" +hide_title: true +sidebar_position: -86 +--- + +# YIP-86: Resupply Bad Debt Repayment Loan + +| Metadata | Details | +| --- | --- | +| YIP | 86 | +| Outcome | **Passed** | +| Authors | dudesahn | +| Created | 2025-07-09 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-86-resupply-bad-debt-repayment-loan/14516) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0xe2fc56f50b1c434ca2f80d07542b66b5ff035b22891c8d6ebb79afca62664d02) | +| Vote result | For: 571.39; Against: 0 | +| Source | [Source](https://gov.yearn.fi/t/yip-86-resupply-bad-debt-repayment-loan/14516) | + +## Summary + +- This proposal outlines a $1.13M loan agreement between Yearn and its sub-DAO, Resupply, to cover outstanding reUSD bad debt following a recent exploit. +- Yearn agrees to forego its staking revenue throughout the duration of the loan. +- The loan will be repaid in full, with 6% interest. + +## Background + +- Following a [$10M hack](https://mirror.xyz/0x521CB9b35514E9c8a8a929C890bf1489F63B2C84/ygJ1kh6satW9l_NDBM47V87CfaQbn2q0tWy_rtp76OI), Resupply is seeking a loan from Yearn treasury to clear remaining bad debt and return the protocol to profitability. +- Resupply has generated **$140k** in stablecoin revenue via Yearn’s permastaker since launching in March (approx. **$46k/mo**). +- Yearn currently owns **11.58%** of the DAO via its staked RSUP. +- Of the original $10M debt, a significant amount has already been eliminated: + - $6M was covered by Resupply’s Insurance Pool + - $1.4M [donated](https://etherscan.io/tx/0x18884d0a608f6431fb4d5efa308afc1920d0f09d9691e5e22e849de61719b626/advanced) by c2tp.eth + - $818k [donated](https://etherscan.io/tx/0x1c6c24cbe0d090a953dc1df7ecae8403f6d5b317e0127048f9aacf22e2e5336e/advanced) by Convex Finance + - $643k [donated](https://etherscan.io/tx/0x7225c1e2793368234c6f133924906e9bea336dabbc363c7513f886eaa812c55c/advanced) by Resupply treasury +- The remaining **~$1.13M** of reUSD bad debt is to be offset via protocol revenue (Yearn and Convex permastakers) +- In order to fully erase the bad debt from Resupply’s markets and help restore user confidence in reUSD solvency ASAP, we are proposing Yearn front this future revenue via a loan to be repaid over time, with interest. + +## Specification + +### Loan Terms + +- **Principal**: 1.13M crvUSD +- **Interest**: 6% APR +- **Total Repayment**: Principal + interest accrued on outstanding balance at 6% APR, 100% of repayment as crvUSD +- Repayments will be tracked via smart contract and automatically sent back to Yearn’s treasury as yvcrvUSD-2 + +### Repayment Structure + +- Both Yearn and Convex agree to reclassify its permastaker revenue as loan repayments, and direct 100% of it as weekly payments toward loan repayments. +- Repayments will be transferred on an automated basis from Yearn and Convex permastakers +- These sources comprise **34.6% of total protocol revenue** + - Pre-hack: ~$31,446/week (~$1.64M/year) +- The aim is to have a full repayment within one year. If after 4 months, repayment is off-track, Resupply team will commit to voting in favor of adding a new protocol-level weekly revenue split as an additional source of revenue to help speed up the repayment process. +- As a part of this tracking, Resupply will provide monthly updates to Yearn DAO regarding repayment progress + +**For**: Yes, provide the loan with these terms. + +**Against**: No, do not provide the loan. + +- For +- Against + +0 voters diff --git a/docs/contributing/governance/yips/yip-87.md b/docs/contributing/governance/yips/yip-87.md new file mode 100644 index 0000000000..aa1d83b7c6 --- /dev/null +++ b/docs/contributing/governance/yips/yip-87.md @@ -0,0 +1,121 @@ +--- +title: "YIP-87: Convert ychad.eth into a BORG" +hide_title: true +sidebar_position: -87 +--- + +# YIP-87: Convert ychad.eth into a BORG + +| Metadata | Details | +| --- | --- | +| YIP | 87 | +| Outcome | **Passed** | +| Authors | MetaLeX | +| Created | 2025-08-14 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-87-convert-ychad-eth-into-a-borg/14540) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0x4726de81255b4be972e0b7bb9f03fac222cfbcef9bd1e148e647be4b8b1fb47d) | +| Vote result | For: 564.97; Against: 0 | +| Source | [Source](https://gov.yearn.fi/t/yip-87-convert-ychad-eth-into-a-borg/14540) | + +## **Summary** + +This is a proposal by [MetaLeX 1](https://x.com/metalex_labs), prepared in informal consultation with ychad.eth signers and other Yearn contributors, to convert ychad.eth into a cybernetic organization ([BORG 2](https://delphilabs.medium.com/assimilating-the-borg-a-new-cryptolegal-framework-for-dao-adjacent-entities-569e54a43f83)) by: + +- “wrapping” ychad.eth’s multisignature smart contract and signers into an ownerless Cayman Islands Foundation Company to create legal personhood for ychad.eth, achieve jurisdictional clarity for purposes of taxes and regulations, and achieve limited liability for ychad.eth signers; +- adding BORGs OS smart contracts to ychad.eth and connecting them to Yearn DAO in order to create clear onchain checks/balances between ychad.eth and Yearn DAO; and +- creating a bespoke web application for managing information flows and relationships between Yearn DAO and ychad.eth and conveniently executing onchain check/balance dynamics. + +The BORGification project would be managed by MetaLeX, and Initial fees/costs would be covered out of Yearn’s prior contribution to the LeXpunK Builder Defense initiative in 2021 (see [https://snapshot.box/#/ybaby.eth/proposal/QmPK9AqeoV6v5xeuiTeFcj9Px7y87KMQ1gGhvHft2GMtqE](https://snapshot.box/#/ybaby.eth/proposal/QmPK9AqeoV6v5xeuiTeFcj9Px7y87KMQ1gGhvHft2GMtqE)) . + +## **Background - About Ychad.ETH** + +Ychad.eth is a 6/9 SAFE multisig smart contract on Ethereum mainnet (0xFEB4acf3df3cDEA7399794D0869ef76A6EfAff52) with a longstanding involvement in the Yearn ecosystem. Its current roles consist of: + +- executing proposals approved by Yearn DAO (since Yearn DAO voting currently uses veYFI-based-snapshot and lacks intrinsic executory power onchain), though this is currently done as a matter of custom and social consensus rather than a binding legal obligation or onchain mechanism; +- serving as the “Protocol Guardian” with a veto role over Yearn DAO proposals (formalized by YIP-61 and YIP-81)—in effect, this legitimizes optionality Ychad would have anyway _not_ to execute proposals approved by Yearn DAO, and expresses this option as the possibility of a conscious “veto”; +- having certain ministerial, coordination, or emergency powers relating Yearn end-user smart contracts (e.g., vaults) or over assigning such powers to other multisigs; and +- receiving, holding and managing fees generated by Yearn end-user smart contracts (e.g., vaults) for the benefit of the Yearn ecosystem including by funding new R&D with grants, etc. + +The Ychad signers (except for one signer sourced from the contributor team) are ‘independent’ reputable DeFi community members with an interest in the Yearn community. There is also a ‘proposer’ role recognized by ychad.eth, which can propose actions to Ychad but not sign them and is held by a full-time Yearn contributor. Ychad.eth signer membership changes are supposed to be approved by Yearn DAO, but currently there is no legal or software mechanism to enforce this convention. + +For more on Ychad, see [https://docs.yearn.fi/developers/security/multisig](https://docs.yearn.fi/developers/security/multisig) + +## **Background - About BORGs OS and MetaLeX** + +MetaLeX is made up of MetaLeX Labs, a venture-backed U.S. technology company, and MetaLeX Pro, a U.S. law firm, who together focus on delivering hybrid legal/tech solutions for crypto projects. + +MetaLeX’s offerings include designing, deploying and maintaining DAO-sponsored entities which we term ‘cybernetic organizations’, aka “BORGs”. BORGs are more modular, centralized entities than DAOs, but like DAOs are onchain and thus more transparent, efficient, accountable, and trust-minimized than traditional black-box legal entities. A deeper review of the general nature and raison d’etre of BORGs can be found at the links at the end of this proposal. + +Each MetaLeX BORG consists of the following components: + +- a tax-optimized, limited-liability legal entity (typically a Cayman Islands foundation company); +- a standard SAFE multisignature smart contract owned by the entity and staffed by the entity’s personnel as signers, which holds any tokens owned or managed by the BORG (usually received from a DAO); +- a set of entity Bylaws legally requiring that the SAFE and its assets to be managed in accordance with specific DAO-approved policies; +- additional smart contract components engineered by MetaLeX, known as “implants” that, connect to the SAFE multisig to enforce the BORG policies onchain; +- various offchain failsafe mechanisms, such as an authorized supervisor, to monitor and legally enforce any BORG policies that cannot be solely enforced onchain; and +- a custom mini-app on metalex.tech, serving as a convenient hub for utilizing and monitoring the BORG. + +Every custom BORG deployed by MetaLeX receives the personal attention of a team of engineers and attorneys to ensure a seamless blend of law and technology which balances the BORG’s need for rapid and agile action against a DAO’s expectations for mission consistency and integrity. Our team has advised and assisted with mission-critical BORGs for the zkSync, Lido, Curve, Everclear, MetaCartel and Neutron communities. + +We utilize the highly respected and battle tested SAFE ‘smart account’ core code, without modification, which is currently responsible for over 127M transactions and $100B of value of assets stored on EVM chains. Our smart contract ‘implants’ plug into SAFE’s pre-defined ‘module’ and ‘guard’ hooks to safely constrain or expand the SAFE’s capabilities, and are open-source, audited and available for review at [MetaLex-Tech · GitHub](https://github.com/MetaLex-Tech). + +## **Motivation** + +- Without a legal entity “wrapper:” + + - It is unclear what type of ‘legal thing’ ychad.eth is and what role the ‘signers’ play on it. It could be an “unincorporated association,” a “partnership,” a “tenancy of property in common,” a “joint venture” or something else. Most of the potential ‘implied classifications’ have much worse legal implications than being a Foundation company. + - It is unclear what jurisdiction ychad.eth is “in” and therefore what laws apply, including tax laws. Arguably, without picking a specific jurisdiction, ychad could be subject to the laws of any/all jurisdictions where a signer resides. + - It is unclear what the duties and liabilities of the ychad.eth signers are. For example, if ychad.eth is a common law partnership, ychad.eth signers could have “joint and several personal liability” in certain scenarios if they were sued. Ychad signers could arguably have implied “fiduciary duties” to users, tokenholders, governance participants, etc.—but such duties are more suited for the offchain TradFi world, and, even then, have largely been eroded through exculpation and insurance schemes that are unavailable to ychad. + - It is unclear who owns the ychad.eth “treasury”—this could raise issues under MSB/VASP laws (rules are different for an entity managing its own money vs. managing on behalf of others), as well as ordinary property laws (do all ychad.eth signers own the ychad.eth treasury as ‘tenants in common’—one would hope not, but without an entity there could be gray areas!). + - There is no clear ability to hold or manage “offchain assets” such as domain names, github accounts, etc.—an entity can own these kinds of things, it is not clear that a ‘multisig’ per se can. +- Currently, important yearn-related domain names, social media accounts ([x.com](http://x.com)), server accounts, and SaaS subscriptions related to the yearn ecosystem are held by heterogenous Yearn contributors with handshake arrangements about how they are to be used in relation to Yearn. These types of assets need to be registered in the name of a particular entity as their ownership is ‘registered’ rather than ‘bearer’. With the Yearn BORG, we can work on getting all these assigned to the legal entity and making them clearly subject to general rules about being used for the Yearn community’s benefit. + +- Ychad.eth signers largely serve a ‘community service’ for the Yearn community. They should not be exposed to personal liability at all, unless they commit crimes or similar (more on that below)—no less potentially unlimited/uncapped personal liability. Wrapping ychad.eth in a legal entity and having each signer enter into an agreement saying they act for this entity will typically mean the entity is liable for any issues, not the individuals. + +- Yearn DAO and ychad.eth have a putative understanding of their respective roles and check/balance relationship: + + - Ychad.eth serves as “Guardian” and may veto proposals approved by the DAO. + - Ychad.eth membership changes should be subject to DAO approval. + - The DAO uses snapshot voting and does not directly control any onchain smart contracts or resources, therefore Ychad.eth must effectively co-approve DAO proposals (as the DAO cannot actually fulfill a proposal without Ychad.eth’s execution/implementation, which amounts to an implicit co-approval). + + However, this understanding is not formalized in any legal agreement or software. With a BORG, we can implement this understanding _**both**_ in code _**and**_ legal agreements. For example, any membership changes to Ychad will require both Ychad and DAO co-approval, and this rule will be embedded in the code modules (“BORG implants”) installed into Ychad’s SAFE. + +- Yearn governance is intended to move to be more onchain but currently is not set up well for this transition. (See YIP 81—Prepare for Full On-Chain Governance). By putting the ruleset into code and legal agreements through the BORG approach, we can pave the way for full onchain governance. + + +## **Specification** + +The Ychad.eth BORG would continue with the same SAFE multisig smart contract, ychad.eth signers, and relationship to the DAO. + +_Legal Details_ + +- Tax-free non-profit Cayman Islands foundation company with no “members” or “beneficiaries”. + +- The purposes of the Foundation are to support the Yearn smart contract systems and related community, in light of the principles (decentralization/autonomy principles together with the Yearn Manifesto and Yearn BluePill). The Foundation is not permitted to pursue any unrelated purposes or to operate for the personal benefit of ychad.eth signers. + +- The company is legally required to perform its operations through specific smart contracts—the ychad.eth multisig and BORGs OS implants into it that give powers to the DAO—as well as a specific snapshot configuration honoring veYFI voting power (the “Mandatory Autonomous Systems”). Material changes to the Mandatory Autonomous Systems would require both ychad.eth approval and Yearn DAO approval. + +- Each ychad.eth signer executes a “BORG Participation Agreement” (onchain) so that the actions they undertake on ychad.eth are “wrapped” in the foundation company. + +- For compliance reasons, there is a single professional director (currently being hired) who will be identified by name in the Cayman registrar and has very limited authorities and almost no unilateral authorities: + + - required to approve a liquidation of the entity (but cannot unilaterally approve such a liquidation—ychad.eth and Yearn DAO must also approve it); and + - would be authorized to sign legal documents, government filings, etc. on behalf of the entity. +- For compliance reasons (since the Foundation company has no legal owners or beneficiaries), there is a “supervisor” who is empowered to monitor the adherence of the BORG to its own rules. In practice, this is a passive role, because the rules are largely embedded in the Mandatory Autonomous Systems and thus effectively cannot be violated. However, in case the DAO believes an egregious violation of the BORG’s rules or applicable criminal law has occurred, the DAO may pass a vote to temporarily give the Supervisor “Emergency Powers,” which can include ordering multisig member changes, hiring/firing directors, initiating lawsuits, participating in lawsuits, etc. This is a ‘nuclear option’ not to be used lightly. MetaLeX would be the Supervisor. + +- The meta-rules set forth in the Foundation company bylaws require that any material changes to material provisions require the approval of both ychad.eth and the DAO—this prevents changing fundamental rules (such as the rule that ychad must use the Mandatory Autonomous Systems). + +- Updated 8.13.2025–key yearn web2 accounts would be handled by a single ‘custodian’ during 3-month contracts with the BORG, see [Offchain Accounts Admin Terms - HackMD](https://hackmd.io/G5U6MuDKSrmKAFWW57ntvQ?view) + + +_Onchain/Code Details:_ + +- onchain-enforced rules through the Mandatory Autonomous Systems: + + - ychad.eth membership changes require approval of both ychad and the DAO, except for unilateral resignation by a ychad member (no resignation allowed if doing so would drop membership below signature threshold) + - DAO proposals are subject to ychad veto +- Due to yearn DAO currently using snapshot (an offchain voting solution), the configuration cannot be completely decentralized/autonomous. The DAO voting ruleset is measured by an oracle that points to the current snapshot space for veYFI, and in theory this oracle could be changed to point to some other ruleset, since it is centralized. However, we seek to trust-minimize it as much as possible as follows: + + - MetaLeX (as relatively neutral third party) maintains the oracle to listen to the standard veYFI snapshot space for DAO proposals made on our webapp (example—a proposal to remove a ychad.eth signer). + - There is a transferOracle function in the snapShotExecutor smart contract that needs to be approved by both ychad.eth and the Yearn DAO to transfer to a new oracle in the typical case—e.g., an agreed-upon transition to purer onchain governance. + - There is a ‘heartbeat’ function such that if the oracle is inactive too long ( 14 days), ychad.eth can set a new oracle unilaterally. This scenario is unlikely but could occur due to some security incident with MetaLeX (loss of keys) or adverse corporate event of MetaLeX. diff --git a/docs/contributing/governance/yips/yip-88.md b/docs/contributing/governance/yips/yip-88.md new file mode 100644 index 0000000000..242fbd9dac --- /dev/null +++ b/docs/contributing/governance/yips/yip-88.md @@ -0,0 +1,518 @@ +--- +title: "YIP-88: Governance Overhaul" +hide_title: true +sidebar_position: -88 +--- + +# YIP-88: Governance Overhaul + +| Metadata | Details | +| --- | --- | +| YIP | 88 | +| Outcome | **Passed** | +| Authors | 0xPickles, governance team contributors | +| Created | 2025-09-28 | +| Forum discussion | [View discussion 1](https://gov.yearn.fi/t/yip-88-governance-overhaul-dao-restructuring/14553), [View discussion 2](https://gov.yearn.fi/t/yip-88-governance-overhaul-styfi/14552), [View discussion 3](https://gov.yearn.fi/t/yip-88-governance-overhaul-incentives/14551) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0x9b3a40326411eea6c51ec389a802ed695de53961fa49f6d3525e256513d0a7f9) | +| Vote result | For: 631.46; Against: 0 | +| Source | [Source 1](https://gov.yearn.fi/t/yip-88-governance-overhaul-dao-restructuring/14553), [Source 2](https://gov.yearn.fi/t/yip-88-governance-overhaul-styfi/14552), [Source 3](https://gov.yearn.fi/t/yip-88-governance-overhaul-incentives/14551) | + +## ⓵ DAO Restructuring + +_Authors: 0xPickles and the governance team contributors_ + +### 1\. Summary + +This proposal outlines the operational and financial restructuring of the Yearn DAO to focus all efforts on revenue generation and on-chain accountability. + +**IMPORTANT NOTE:** This proposal is the first of three interconnected parts of a single initiative designed to overhaul Yearn’s operations, tokenomics, and contributor incentives. + +- **Part I: Operations & DAO Restructuring (This Proposal)** +- [Part II: stYFI Tokenomics & Migration](https://gov.yearn.fi/t/yip-88-governance-overhaul-styfi/) +- [Part III: Contributor & Team Incentives](https://gov.yearn.fi/t/yip-88-governance-overhaul-incentives/) + +All three parts will be discussed in parallel on the forum but will be voted on as a single, all-or-nothing package in one Snapshot vote for **YIP-XX**. If the unified proposal passes, all three parts will be implemented. If it fails, none will be. + +#### 1.1 Status + +**Discussion** +This proposal is in the discussion phase. As per YIP-55, it will remain here for at least 3 days with a non-binding forum poll. If sentiment is positive, it can move to Snapshot for a binding vote by veYFI holders on the combined three parts (see Summary above). + +### 2\. Abstract + +**If the complete YIP-XX initiative is adopted**, this part of the proposal will: + +- Reorganize Yearn contributors around revenue-earning teams, except for a minimal DAO operations team. +- Require all teams to use on-chain revenue splitters for transparent accounting. +- Mandate on-chain financial reporting to justify all future budget requests. + +### 3\. Background + +Yearn’s current operational framework is the product of a multi-year evolution aimed at increasing decentralization and contributor autonomy. The foundational shift occurred with the passage of **YIP-61: Governance 2.0**[\[1\]], which dissolved a centralized operational group in favor of empowering smaller, independent teams (yTeams). + +Initially, budget approvals were handled by a dedicated **yBudget** team. Over time, this process evolved further to decentralize decision-making, leading to the current **yBudget II council process**. In this system, all yTeams vote on contributor budget requests (BRs), with revenue-generating teams wielding outsized influence proportional to the revenue they contribute. + +This model proved highly effective at instilling fiscal discipline and reducing operational overhead. By giving revenue-generating teams a stronger voice, the DAO successfully aligned its spending with its earnings, leading to significant cost reductions over the past year, essentially cutting the budget in half. + +| Metric | yBudget II Epoch 1 (May-Jul 2024) | yBudget II Epoch 5 (May-Jul 2025) | Change | +| --- | --- | --- | --- | +| **Total Contributor Expenses** | $1,740,000 | $858,000 | **\-50.7%** | +| **Average Monthly Expenses** | $580,000 | $286,000 | **\-50.7%** | + +However, as the DAO has matured, this structure has presented a new set of second-order challenges that now impede our efficiency and focus: + +- **Organizational Misalignment:** The system has seen an increase of non-revenue-earning teams relative to revenue-earning ones. While these teams perform necessary functions, it gives greater influence to initiatives that do not directly impact the bottom line, diluting the focus on profitability. +- **The Free-Rider & Attribution Problem:** It is difficult to measure and attribute the value created by non-revenue teams. This creates a potential “free-riding” effect by Revenue Teams, where they benefit from the efforts of non-revenue teams, without this being attributed to the right place. This makes it difficult to assess true net profitability of efforts. +- **Coordination Inefficiency:** The proliferation of many small yTeams, often with overlapping contributors, makes cross-team coordination complex and inefficient. This fragmentation hinders our ability to execute large, cohesive strategic initiatives. + +These challenges indicate that while the `yBudget II` process was a successful evolutionary step for instilling fiscal discipline, the next phase of Yearn’s growth requires a more streamlined, explicitly revenue-focused operational model. This proposal builds on the successes of the past while directly addressing its emergent limitations. + +### 4\. Motivation + +The primary driver for this proposal is to reorient the entire Yearn DAO towards sustainable **growth and operational excellence**. The idea is to create a transparent and accountable framework that directly supports the value accrual mechanisms detailed in Part II and justifies the incentive structures in Part III. + +The motivation for this specific operational model is rooted in several key principles: + +- **Center the org around autonomous, revenue-generating units:** The fundamental principle of this reorg is that teams should be structured as self-sufficient units focused on generating revenue. Each team should encompass all critical functions (e.g., development, strategy, marketing) needed to operate its products. This “full-circle” structure is essential for enabling clear Profit & Loss (P&L) attribution, allowing the DAO to accurately track all earnings and costs associated with each team. +- **Move accountability on-chain:** Moving from off-chain tracking and manual reporting to on-chain revenue splitters and automated tracking provides unimpeachable, data in real-time. This empowers the DAO to make objective, data-driven decisions about resource allocation, ensuring that we fund what works and that every team’s contribution to the bottom line is clear. +- **Maintain a lean and accountable support system:** Certain core functions are necessary for the DAO to operate. By defining a minimal, well-scoped DAO Operations (DAO-ops) team, we ensure this essential back-office work is supported. Crucially, this team remains fully accountable to the DAO, which can regularly review and justify its scope and budget, preventing operational bloat. +- **Establish guidelines:** The transition to this new operational model will have complexities. This YIP intentionally avoids micromanaging that process. Instead, it establishes the foundational ground rules and clear end-state goals, empowering the teams themselves to collaborate and forge the most effective paths to implementation. + +#### 4.1 Alternatives Considered + +In developing this proposal, we evaluated several alternative paths for restructuring the DAO. These were considered and rejected for the following reasons: + +- **Merge into a single “Mono-Team”:** We considered dissolving all yTeams and consolidating contributors into a single, hierarchical organization. This was rejected as it introduces significant centralization vectors, creates single points of failure in management, and runs counter to the decentralized, autonomous ethos of Yearn. If the management of a mono-team fails, the entire DAO fails with it. +- **Splinter the DAO completely:** We also considered breaking up the DAO entirely, allowing individual teams or products to spin out as independent entities. This was rejected because it would be massively value-destructive. The Yearn brand carries immense weight, trust, and recognition in the ecosystem, these are assets that have been built over years. Throwing that away would be a disservice to the protocol and all YFI holders. + +#### 4.2 Out of Scope + +- The specific tokenomics of stYFI and revenue distribution mechanics (covered in Part II). +- The allocation of treasury YFI for contributor and team incentives (covered in Part III). + +### 5\. Specification + +The following numbered requirements will be implemented to execute the operational and financial restructuring of the DAO. + +#### 5.1 General Principles + +1. **Revenue-Centric Model**: All Yearn teams, with the exception of the DAO Operations (DAO-ops) team, will be reorganized to focus on specific, measurable revenue-generating activities. +2. **Team Autonomy**: Revenue-earning teams will operate with a high degree of independence and self-reliance. They are responsible for managing their own product strategy, operations, and budgets to achieve their goals. + +#### 5.2 Team Structure & Transition + +3. **Transition Process**: Existing yTeams are required to self-organize, merge, and restructure into cohesive, revenue-generating teams. +4. **Transition Deadline**: The current yBudget II epoch concludes on **October 31, 2025, 23:59:59 UTC**. After this date, no BRs from non-revenue-earning teams will be approved for funding. +5. **Hard Cutoff**: Contributors not formally part of an approved revenue-earning team or the DAO-ops team by the transition deadline will no longer be funded on a recurring basis. +6. **One-Off Project Funding**: Non-recurring (and potentially non-revenue earning) work may still be funded via a direct BR. Such proposals must be for a specific project with a defined scope and end date, and not for ongoing contributor roles. + +#### 5.3 DAO Operations (DAO-ops) Team + +7. **Scope Definition**: A single, non-revenue team, DAO-ops, will be maintained with a minimal scope, limited to: + - Create and Maintain DAO smart contracts (governance, treasury, rate providers, auctions, YFI tokenomics, etc.). + - Build and Maintain DAO governance and reporting infrastructure (budgets, proposals, treasury, voting, etc.). + - Performing essential administration directly related to the above tasks, like tweaking parameters, kicking auctions, and optimizing performance of these systems. +8. **Technical Focus**: The DAO-ops team mandate is strictly technical and administrative. It does not manage community, marketing, social media, or communications, nor does it influence the strategy of revenue-earning teams. +9. **Budget Approval**: The DAO-ops team must submit a formal Budget Request (BR) for approval following the passage of this YIP to secure funding and commence its work, and will need to continue to submit BRs on an ongoing basis as any other team. + +#### 5.4 Revenue & Financial Reporting + +10. **On-Chain Revenue Splitters**: All team-generated revenue must be sent to designated splitter contracts on Ethereum mainnet. Teams are responsible for bridging funds to Ethereum mainnet in order to send to splitter contracts. +11. **Initial Routing**: Initially, all splitters will be configured to route 100% of incoming revenue to the Yearn Treasury. This will be updated per the routing rules in Part II. +12. **Approved Revenue Tokens**: Revenue must be sent in a format pre-approved by the DAO-ops team (e.g., stablecoins, WETH). +13. **Mandatory On-Chain Reporting**: All budget requests must be justified by on-chain financial reporting that tracks total revenue contributed versus total budget utilized for that team. +14. **On-Chain Budget Requests**: All team budget requests will ultimately be submitted on-chain using a standardized format to be defined by the DAO-ops team. + +#### 5.5 Budgeting Process & Governance + +15. **Proposing New Revenue Teams**: Any group may propose a new revenue-earning team, which must commit to the mandatory on-chain reporting framework. +16. **Budget Request (BR) Cadence**: As already is in place, team BRs will continue to be approved for a maximum duration of **three months**. +17. **Fund Streaming**: Approved budgets will by default be streamed using existing contracts. There will be an option to request up-front payment as part of the BR. +18. **Safeguard Mechanism**: yChad, and subsequently the DAO, will retain the ability to halt fund streams in clear cases of underperformance, malicious activity, or misuse of funds. + +##### 5.5.1 Discretionary & Fast-Track Funding + +19. **Establishment of a Discretionary Fund**: A dedicated, on-chain fund will be established for urgent, sensitive, or unforeseen expenses that cannot go through the standard public proposal process (e.g., critical security audits, stealth projects). +20. **Initial Funding**: The fund will be initialized with **$250,000** worth of stablecoins from the Treasury. +21. **Management and Delegation**: The fund will be managed by yChad, who has the discretion to delegate its management to another designated multi-sig (or the YBC as described in Part III). +22. **Accountability via Top-Up**: The fund can only be replenished via a formal proposal to the DAO. Such proposals must be accompanied by a report justifying past expenditures and are subject to a DAO vote. + +##### 5.5.2 Transition to On-Chain Governance + +23. **Interim Budget Governance**: Following the transition deadline, budget approvals for the new revenue teams, the DAO-ops team, and any other proposal will continue to be decided by the existing yBudget II council process. +24. **Transition to on-chain governance**: The DAO-ops team is responsible for designing, proposing, and implementing the final on-chain governance system for budget approvals. +25. **Checks and Balances**: The transition to this final system is not automatic. It will occur only when the DAO-ops team deploys the necessary contracts, and yChad provides the final, binding sign-off, acting as a crucial backstop to prevent a premature or flawed rollout. The DAO-ops team’s continued funding during the interim period is contingent on making demonstrable progress, as judged by the yBudget II council. +26. **Final Governance Structure**: Once the on-chain system is active, the yBudget II council will be dissolved. All budget decisions will be made via binding votes by stYFI holders. The concept of “team influence” will cease to exist; voting power will derive solely from an individual’s or entity’s stYFI stake (see part II). + +#### 5.6 Governance System Implementation + +27. **System Design Mandate**: The DAO-ops team is delegated with the final implementation of the governance system. +28. **Core Design Philosophy**: The guiding principles for development must be **simplicity and security**. Contracts should be as simple and immutable as possible to minimize attack surface. +29. **Modularity**: While individual components should be immutable, the overall system must be modular, allowing for specific components to be replaced or upgraded over time via governance. +30. **stYFI Compatibility**: The voting system must be designed to natively support the specific mechanics of stYFI outlined in Part II (e.g., time-weighted voting). +31. **Leverage, Don’t Replicate**: The DAO-ops team should avoid over-complicating the system. It should leverage principles from battle-tested frameworks (e.g., Aragon[\[2\]], Ajna[\[3\]], Curve[\[4\]], yETH[\[5\]]) where possible but is not expected to be 1:1 compatible, prioritizing a simple and secure implementation that meets the core requirements. +32. **Flexible Cadence**: The specific timing of governance epochs and voting rounds is left to the implementation phase and can be iterated on over time. + +### 6\. Vote + +This poll is for non-binding sentiment gauging on this specific part of the initiative. The final, binding vote will occur on Snapshot for the entire YIP-XX package. + +#### Non-binding signaling poll + +Do you support Part I (Operations & DAO Restructuring) as a component of the full proposal? + +- Yes +- No + +0 voters + +### 7\. References + +1. [YIP-61: Governance 2.0](https://gov.yearn.fi/t/yip-61-governance-2-0/10460) +2. [Aragon VE Governance - Aragon Docs](https://docs.aragon.org/ve-governance/1.0.0/index.html) +3. [Grants | Ajna Protocol](https://faqs.ajna.finance/faqs/grants) +4. [Curve.finance](https://www.curve.finance/dao/ethereum/proposals) +5. [yETH](https://yeth.yearn.fi/vote) + +### 8\. Changelog + +- **Aug 21, 2025:** First draft circulated with Yearn contributors and the governance team for initial feedback. +- **Sep 03, 2025:** Contributor feedback incorporated. Second draft circulated to key governance participants and liquid locker teams (StakeDAO, Cove, 1UP) for feedback. +- **Sep 25, 2025:** Revisions made based on comprehensive feedback from key stakeholders. +- **Sep 28, 2025:** Proposal published on the Yearn governance forum. + +## ⓶ stYFI + +_Authors: 0xPickles and the governance team contributors_ + +### 1\. Summary + +This proposal introduces stYFI, a new liquid governance and revenue-sharing token designed to replace veYFI, capture 90% of protocol revenue for stakers, and provide a clear migration path for current YFI stakeholders. + +**IMPORTANT NOTE:** This proposal is the second of three interconnected parts of a single initiative designed to overhaul Yearn’s operations, tokenomics, and contributor incentives. + +- [Part I: Operations & DAO Restructuring](https://gov.yearn.fi/t/yip-88-governance-overhaul-dao-restructuring/14553) +- **Part II: stYFI Tokenomics & Migration (This Proposal)** +- [Part III: Contributor & Team Incentives](https://gov.yearn.fi/t/yip-88-governance-overhaul-incentives/) + +All three parts will be discussed in parallel on the forum but will be voted on as a single, all-or-nothing package in one Snapshot vote for **YIP-XX**. If the unified proposal passes, all three parts will be implemented. If it fails, none will be. + +#### 1.1 Status + +**Discussion** +This proposal is in the discussion phase. As per YIP-55, it will remain here for at least 3 days with a non-binding forum poll. If sentiment is positive, it can move to Snapshot for a binding vote by veYFI holders on the combined three parts (see Summary above). + +### 2\. Abstract + +**If the complete YIP-XX initiative is adopted**, this part of the proposal will: + +- Introduce stYFI as the new governance token with liquid staking/unstaking. +- Route 90% of future protocol revenue to stYFI stakers. +- Sunset the veYFI system and provide an opt-in migration path for holders. +- Establish a redemption facility for existing Liquid Locker tokens. +- Implement a yield backstop to de-risk the transition for early participants. + +### 3\. Background + +The existing veYFI tokenomics model was the result of a series of ambitious proposals designed to secure Yearn’s long-term success. To understand the need for change, it’s essential to first understand the original vision and then contrast it with the practical reality of its performance and technical limitations. + +#### 3.1 The Vision for veYFI + +The foundation for the current system was laid by **YIP-65: Evolving YFI Tokenomics**[\[1\]], with subsequent proposals like YIP-73[\[2\]] and YIP-81[\[3\]] building upon it. The vision was to create a powerful economic engine with three primary goals: + +1. **Promote long-term alignment** by requiring users to lock YFI for up to four years. +2. **Enable strategic capital incentives** via gauges to direct dYFI emissions and attract TVL. +3. **Secure Governance and provide yield** from protocol revenue buybacks. + +#### 3.2 The Reality & Technical Failure of veYFI + +Despite its well-intentioned design, the veYFI system has failed to achieve its objectives and is built on a technically flawed foundation, making a migration a necessity. + +- **Critically Low Participation:** Only **~3.8%** of the YFI supply is locked[\[4\]], a figure that is in decline. This demonstrates a fundamental lack of interest in the model. +- **Fragile Foundation:** A low lock rate leaves governance overly exposed to manipulation. Moving to on-chain governance under these conditions would amplify the risk rather than reduce it. +- **Imminent End of Rewards:** The gauge system is not only ineffective, but its rewards are nearly exhausted. Of the YFI bought back for the program, only **~230 YFI** remains for future emissions after accounting for all outstanding dYFI redemptions[\[5\]]. The program is on a mathematically certain path to ending, with or without this proposal. +- **Ineffective, Self-Referential Incentives:** Over the past 10 epochs, **69% of dYFI emissions were directed to YFI-related pools**[\[5\]], creating a closed loop rather than attracting new capital to core products. +- **Excessive Complexity:** The interplay between YFI, veYFI, dYFI, and gauges has been a significant barrier to entry for the broader community. + +Crucially, _“doing nothing”_ is not an option. While the most severe bugs in the immutable veYFI contract have been temporarily mitigated, they remain unfixable at the contract level and pose material risks going forward: + +1. **Loss of Rewards for Relocking Users** + This bug, which blocks future rewards for users who let their lock expire and then re-lock, has been patched at the front-end level to prevent it from occurring. But it still lives in the contract and represents a hard failure for our most loyal users should the safeguard ever fail or be bypassed. + +2. **Reward Misaccounting & Vote Weight Corruption** + This timestamp handling bug (`block.timestamp % WEEK`) could cause misaccounting of rewards, DoS in claims, and, most critically, corruption of veYFI balances, leading to incorrect voting weights. It has not yet been triggered because Ethereum block times remain constant. However, with renewed community discussions about reducing block times, the likelihood of activation is increasing. + + +**In short:** these bugs have been held at bay, not fixed. What was once dormant risk is becoming live risk. With potential protocol-level changes on Ethereum, we must act proactively now rather than wait for a forced crisis. + +Because these contracts cannot be patched, any attempt to “top up” veYFI or extend its life would be reckless. The only responsible path forward is a migration to a new, secure system. + +### 4\. Motivation + +The motivation for stYFI is to establish a new engine for Yearn’s growth, guided by a philosophy of simplicity, powerful incentives, and clear alignment between all stakeholders. This proposal aims to create a superior user experience and increased participation in Yearn Governance. + +- **Simplicity and Accessibility:** stYFI is simple: stake YFI, receive stYFI, earn revenue. A 14-day cooldown replaces the four-year lock, encouraging broad participation. +- **Powerful, Real-Yield Incentives:** stYFI earns a direct share of protocol revenue, paid in a high-quality, yield-bearing stablecoin (e.g., yvUSDC). This creates positive economic reflexivity: as YFI’s price falls, the stablecoin APR rises, creating a natural demand floor. +- **Secure and Aligned Governance:** Time-weighted voting power protects against flash loan attacks without sacrificing liquidity, while APR boosts for voting incentivize active participation. +- **A New Social Contract:** This proposal creates a new deal. 90% of future revenue goes to stYFI holders, empowering them. Contributors are funded from the existing treasury (Part III), approved by DAO voters, and making them accountable to the same. +- **A Fair Transition for veYFI Holders:** The migration plan is designed to recognize the commitment of early veYFI adopters, offering them an upgrade to a superior system with tangible benefits like a reward boost. Those that used liquid locker protocols will additionally have an optional exit path via the redemption facility. + +### 5\. Specification + +The following numbered requirements will be implemented to introduce the stYFI token, define its mechanics, and manage the transition from the veYFI system. + +#### 5.1 Implementation Priority + +1. **Top Priority for DAO-ops**: The design, development, and deployment of the stYFI system as described in this Part II is the top priority for the DAO-ops team following the approval of this YIP. + +#### 5.2 stYFI: The New Governance & Yield Token + +##### 5.2.1 Staking & Unstaking Mechanics + +2. **Staking**: Users stake YFI on a 1:1 basis to receive the stYFI token. +3. **Unstaking Cooldown**: Initiating an unstake begins a **14-day cooldown period**. No rewards or voting power accrue to YFI in cooldown. +4. **Linear Streaming**: During the cooldown, the underlying YFI is streamed linearly, becoming progressively available for the user to claim. +5. **Cooldown Reset**: If a user initiates a new unstake while a previous is in progress, the 14-day timer resets for the _entire_ remaining unstaking balance. + +##### 5.2.2 Governance Rights & Voting Power + +6. **Sole Governance Token**: stYFI is the sole token for participating in Yearn governance. +7. **Time-Weighted Voting Power**: A staker’s voting power scales up over four phases of continuous staking. (Phase duration tbd.) + + | Phase | Voting Power Multiplier | + | --- | --- | + | 0 (initial stake) | 0% | + | 1 | 25% | + | 2 | 50% | + | 3 | 75% | + | 4+ | 100% | + +8. **Governance Epochs**: Governance will operate in epochs of a duration to be determined by the DAO-ops team, but these epochs **cannot be shorter than 14 days**. +9. **Initial Platform**: Snapshot may be used for binding votes initially, until an on-chain system is deployed. + +##### 5.2.3 Revenue Distribution & Yield Boost + +10. **Revenue Share**: stYFI holders are entitled to a share of Yearn’s protocol revenue. +11. **Reward Asset**: Rewards will be paid out in a single, pre-determined Yearn vault token (e.g., yvUSDS). The specific vault may be changed at the discretion of the DAO-ops team’s multi-sig. +12. **Provisional APR Boost:** To encourage governance participation, DAO-ops is authorized to design and implement a gas-efficient and robust mechanism that increases yield for stYFI holders who are active in governance voting. The specific mechanism is not fixed in this proposal and may vary based on feasibility and security considerations. A key constraint is that stYFI holders who do not participate in governance at all **cannot have their yield reduced by more than 60%** compared to those who do. + +##### 5.2.4 Protocol Revenue Routing + +13. **Treasury/stYFI Split**: Revenue will be split with a default of **90%** to stYFI Stakers and **10%** to the DAO Treasury. This split is a DAO-configurable parameter. +14. **Definition of Revenue for Splitting:** The revenue split applies exclusively to **protocol revenue** (e.g., vault fees). It **does not apply** to assets already held within the DAO Treasury. +15. **Token Conversion**: Revenue tokens will be converted to the reward asset via Yearn’s existing automated and permissionless treasury auction system. + +#### 5.3 veYFI Migration & Integration Plan + +##### 5.3.1 veYFI Holder Integration + +16. **Snapshot:** A snapshot of all veYFI balances will be taken from Ethereum block **23460759**, falling around the time this proposal is published. +17. **Opt-In Migration**: To be eligible for rewards in the new system, existing veYFI holders (both direct and via liquid lockers) must **actively migrate** via a dedicated contract. This ensures rewards are concentrated among engaged participants. +18. **veYFI Reward Boost**: To reward their long-term commitment, migrating veYFI holders will receive a **decaying reward multiplier** on their stYFI yield. + 1. A 4-year lock (at the time of snapshot) will begin with a **2x multiplier**. + 2. The multiplier will decay linearly to 1x as the lock approaches its expiry date. + 3. Governance voting power is not affected by the reward boost. +19. **No Lock Extensions**: This program is only applicable to existing lock durations. Extending a lock will have no impact on rewards earned and will not result in any additional compensation, it only extends the period YFI is locked for the user in the old defunct system. +20. **Forfeiture on Early Exit**: If a user breaks their veYFI lock early, they forfeit all rights under this program. +21. **Action Required at Lock Expiry:** Once a veYFI lock reaches its natural expiry date, it will no longer be eligible for this program. The holder must then withdraw their YFI and stake it directly into the stYFI contract to continue participating in governance and earning revenue share. + +##### 5.3.2 dYFI and Gauges + +22. **Gauge Shutdown**: All active dYFI gauges will be shut down. +23. **dYFI Deprecation**: This proposal deprecates the dYFI token. +24. **dYFI Redemptions**: dYFI will remain redeemable for YFI under existing rules. + +##### 5.3.3 Liquid Locker Redemption Facility + +25. **Precondition**: A Liquid Locker protocol must **permanently disable the minting of new locker tokens** and **permanently disable lock extensions** to become eligible for the redemption facility. +26. **Redemption Mechanism**: The Yearn Treasury will allocate **up to a maximum of 600 YFI** to facilitate a redemption mechanism, allowing users to swap their liquid locker tokens back to YFI, and vice versa, at will, with deep liquidity and no slippage. +27. **Fee Structure**: The redemption fee starts at **10%** and decreases linearly to **0.25%** over a four-year period. +28. **Two-way conversion:** The redemption facility will also allow swapping YFI back to a liquid locker token of a user’s choice, at **no fee**. +29. **Facility Duration:** The redemption facility will remain open for each protocol until the final expiry date of its underlying veYFI lock (or 4 years, whatever is shorter). +30. **Final Wind-Down**: Upon the final expiry of a liquid locker’s veYFI lock, the redemption facility will serve as the primary mechanism for the protocol to redeem any remaining underlying YFI and distribute it back to its token holders, facilitating an orderly wind-down. + +#### 5.4 Yield Backstop + +31. **Establishment of a Yield Backstop**: To de-risk the transition, the DAO will establish a yield backstop program specifically for migrated veYFI holders. +32. **Duration and Cap**: The program will run for **3 years** or until a total of **$5 million** equivalent in rewards have been distributed to stYFI in total, whichever comes first. +33. **Top-Up Mechanism**: Top-ups are calculated annually. If the total protocol revenue distributed to stYFI in a given year is less than **$1.67 million** equivalent, the Treasury will cover the shortfall. +34. **Top-Up Asset and Recipient**: The top-up will be paid in **YFI** and distributed exclusively to **migrated veYFI holders**, streamed linearly over the 3 months following the year-end calculation. + +### 6\. Vote + +This poll is for non-binding sentiment gauging on this specific part of the initiative. The final, binding vote will occur on Snapshot for the entire YIP-XX package. + +#### Non-binding signaling poll + +Do you support Part II (stYFI Tokenomics & Migration) as a component of the full proposal? + +- Yes +- No + +0 voters + +### 7\. References + +1. [YIP-65: Evolving YFI Tokenomics](https://gov.yearn.fi/t/yip-65-evolving-yfi-tokenomics/11994) +2. [\[YIP-73\] Activate veYFI rewards with oYFI Gauges](https://gov.yearn.fi/t/yip-73-activate-veyfi-rewards-with-oyfi-gauges/13414) +3. [YIP-81: Prepare for Full On-Chain Governance](https://gov.yearn.fi/t/yip-81-prepare-for-full-on-chain-governance/14282) +4. [Yearn Wars](https://www.defiwars.xyz/wars/yearn) +5. [dYFI Gauge Voting - Google Sheets](https://docs.google.com/spreadsheets/d/12KXbdJDsH1I5L3P0kgwKdIBBpyYtdwiGc5EnoxYlWFI/edit?gid=0#gid=0) + +### 8\. Changelog + +- **Aug 21, 2025:** First draft circulated with Yearn contributors and the governance team for initial feedback. +- **Sep 03, 2025:** Contributor feedback incorporated. Second draft circulated to key governance participants and liquid locker teams (StakeDAO, Cove, 1UP) for feedback. +- **Sep 25, 2025:** Revisions made based on comprehensive feedback from key stakeholders. Major changes include: + - Added in-depth details of veYFI contract flaws. + - Generalized voting APR boost design, delegated implementation to DAO-ops + - Added opt-in migration for veYFI holders. + - Added a 2x decaying reward multiplier for veYFI holders. + - Added a 3-year, $5M yield backstop for the stYFI program migration. +- **Sep 28, 2025:** + - Proposal published on the Yearn governance forum. + - Added block cut off for snapshot. + +## ⓷ Incentives + +_Authors: 0xPickles and the governance team contributors_ + +### 1\. Summary + +This proposal allocates a portion of treasury-held YFI to create powerful, long-term incentive programs for core contributors and revenue-generating teams, directly aligning their success with the protocol’s profitability. + +**IMPORTANT NOTE:** This proposal is the third of three interconnected parts of a single initiative designed to overhaul Yearn’s operations, tokenomics, and contributor incentives. + +- [Part I: Operations & DAO Restructuring](https://gov.yearn.fi/t/yip-88-governance-overhaul-dao-restructuring/) +- [Part II: stYFI Tokenomics & Migration](https://gov.yearn.fi/t/yip-88-governance-overhaul-styfi/14552) +- **Part III: Contributor & Team Incentives (This Proposal)** + +All three parts will be discussed in parallel on the forum but will be voted on as a single, all-or-nothing package in one Snapshot vote for **YIP-XX**. If the unified proposal passes, all three parts will be implemented. If it fails, none will be. + +#### 1.1 Status + +**Discussion** +This proposal is in the discussion phase. As per YIP-55, it will remain here for at least 3 days with a non-binding forum poll. If sentiment is positive, it can move to Snapshot for a binding vote by veYFI holders on the combined three parts (see Summary above). + +### 2\. Abstract + +**If the complete YIP-XX initiative is adopted**, this part of the proposal will: + +- Formalize a plan to deploy the remaining ~1,700 YFI already approved for strategic contributor incentives, alongside the remainder (~230 YFI) of the bought back YFI previously used for veYFI incentives. +- Launch a second season of core contributor vests with a transparent “Accountability Package”. +- Create a capped performance bonus program rewarding teams for net profit generation. +- Establish a long-term contributor retention pool, The Yearn Builder’s Collective. + +### 3\. Background + +To execute the ambitious revenue-focused strategy in Part I and maximize value for stYFI holders in Part II, Yearn must attract, retain, and motivate top-tier talent. This proposal outlines a transparent and accountable plan for deploying existing treasury assets to achieve that goal. + +#### 3.1 A Tale of Two Treasury Assets + +The YFI held by the Yearn Treasury comes from two distinct sources: + +1. **The YIP-57 Strategic Operations Mint (~1,700 YFI):** YIP-57, passed nearly five years ago, gave the DAO an explicit mandate to use this YFI for strategic purposes, with contributor retention being a primary example[\[1\]]. This proposal does not ask for new YFI; it provides a transparent framework for deploying this already-approved asset. +2. **The veYFI Program Remainder (~230 YFI):** The veYFI rewards program was funded by market buybacks. After accounting for all outstanding dYFI redemptions (~780 YFI)[\[3\]], only **~230 YFI** remains[\[2\]]. With the program sunsetting, this proposal seeks to repurpose this small remainder for productive use in the new incentive system. + +This YIP therefore formalizes a plan for a total of **~1,930 YFI** (~1,700 + ~230). Approximately **88% of this allocation already has a clear mandate** for contributor incentives. We are bringing this unified plan to the DAO for a vote to ensure full transparency and to create a holistic, performance-driven system for its use. + +#### 3.2 The Current Model: Stable Payments with Limited Alignment + +For the past several years, contributors have been compensated primarily in stablecoins, based on their peers’ assessment of long-term value creation. This ensures predictable compensation but limits the direct link between contributors and the protocol’s growth. The proposed change does not replace stable payments as the main form of compensation; instead, it introduces YFI as an additional alignment mechanism. Revenues will flow more directly to teams holding YFI, reducing reliance on centralized assessment while tying contributors more closely to protocol performance. + +### 4\. Motivation + +The incentive programs in this proposal are designed to make contributors aligned partners in the success of the protocol, creating a flywheel of alignment where contributor success directly translates to stYFI holder yield. Key motivations include: + +- **Responsible Treasury Management:** This proposal provides a clear, accountable, and DAO-approved plan for deploying fragmented treasury assets, turning passive holdings into an active catalyst for growth. +- **Elevating Ownership:** The ownership mindset is already central to how Yearn contributors operate. YFI rewards linked to performance build on this strength and give it lasting impact. +- **Retaining Critical Talent:** The Core Contributor Vests are a direct tool to retain Yearn’s top talent in a highly competitive market. +- **Driving Profitability:** The Team Performance Bonus creates a direct, meritocratic link between a team’s financial contribution and their compensation, maximizing efficiency and revenue growth. +- **Ensuring Long-Term Alignment:** The Yearn Builder’s Collective (YBC) creates a powerful incentive for contributors not just to earn YFI, but to _hold and stake it_ for the long term. + +### 5\. Specification + +The following numbered requirements will be implemented to create the contributor and team incentive programs. + +#### 5.1 Implementation Priority + +1. **DAO-ops Responsibility**: The DAOps team is responsible for the design, deployment, and implementation of all contracts and processes necessary for this incentive program. +2. **Implementation Timeline**: This work is the top priority for the DAO-ops team immediately following the successful launch of the stYFI system described in Part II. + +#### 5.2 YFI Incentive Allocation + +3. **Total Incentive Pool**: A total of **~1,930 YFI** is allocated for these programs. This comprises ~1,700 YFI from the strategic operations mint (YIP-57) and ~230 YFI from the veYFI program remainder. +4. **Program Allocation**: This pool will be allocated as follows: + - Up to **1,111 YFI** for Season 2 Core Contributor Vests. + - Up to **600 YFI** for the Liquid Locker Redemption Facility (Part II) + - The remainder, initially **200-400 YFI**, will seed the Performance Bonus Program. +5. **Redemption Facility Wind-Down:** Upon the conclusion of the Liquid Locker Redemption Facility, any unused YFI from its allocation will be transferred to the Performance Bonus Program. + +#### 5.3 Core Contributor Vests (Season 2) + +6. **Allocation**: A fixed maximum of up to **1,111 YFI** is allocated for a second season of vests. +7. **Vesting Terms**: Vests will have a **3-year linear duration** with a **6-month cliff**, upholding the successful precedent set by YIP-57. +8. **Clawback**: Unvested portions can be clawed back to the treasury, a function initially controlled by yChad. +9. **Accountability Package**: To ensure transparency, the volunteer compensation committee **must** publish a document on the governance forum detailing the following _before_ any vests are distributed: + - A pre-set **minimum and maximum number of recipients**. + - Clear, pre-defined **vesting criteria**. + - Clear, pre-defined **vesting tiers** (e.g., amounts per tier). +10. **Community Review**: The publication of the Accountability Package will serve as a final sense-check, allowing the community to provide feedback before yChad gives the final sign-off to deploy the vesting contracts. + +#### 5.4 Performance Bonus Program + +11. **Mechanism**: Revenue-generating teams are rewarded quarterly with YFI based on the net profit they generate, defined as `Revenue Contributed - Budget Utilized`. +12. **Bonus Calculation**: The YFI reward is calculated as `total_profit / bonus_yfi_price`. +13. **Bonus YFI Price**: The effective price of YFI is adjusted based on Yearn’s global quarter-over-quarter revenue growth: `bonus_yfi_price = yfi_market_price * (1 - revenue_growth_rate)`. +14. **Configurable Growth Rate Cap**: The `revenue_growth_rate` is capped (default +/- 25%, max +/- 80%) and is a DAO-configurable parameter. +15. **Bonus Cap**: The total market value of a team’s quarterly YFI bonus, calculated at the time of distribution, **cannot exceed 50% of the net profit** the team generated during that quarter. +16. **Universal Bonus Split**: All YFI rewards from this program are subject to a governance configurable split: **67%** (default) to the team and **33%** (default) to the Yearn Builder’s Collective (as stYFI). +17. **Bonus YFI**: Bonus YFI is unrestricted and can be used at the team’s full discretion. + +#### 5.5 Yearn Builder’s Collective (YBC) + +18. **Purpose**: A long-term incentive pool for all whitelisted contributors, funded by a portion of all team performance bonuses. +19. **Initial Whitelist**: The initial whitelist of YBC members will consist of all Season 2 Vest recipients as well as any yChad signer who wish to participate. +20. **Bootstrap Seeding**: To bootstrap the pool’s weighting system, each initial member will be granted **0.01 stYFI** upon opting into participate in the pool. The pool itself will be seeded with up to **200 stYFI**, from the Performance Bonus Program. +21. **Permanent Staking**: All YFI in the pool is permanently staked as stYFI to earn a share of protocol revenue. The underlying YFI can only be withdrawn back to the treasury by yChad, but may eventually become permanently locked in the future if the program proves successful. +22. **Weighting**: A contributor’s claim on the pool’s yield is determined by the amount of stYFI they personally hold in their whitelisted address. They are free to top up, subject to cooldown to prevent abuse. +23. **Pool Governance**: The whitelist of eligible contributors is governed by the members themselves, voting with their stYFI-based weight. +24. **Yearn Governance Participation**: The stYFI held by the pool will be actively used to vote on Yearn governance proposals. +25. **Principle of Good Faith**: The pool operates on a system of trust, where a member’s influence is based on their personal, long-term stake in the ecosystem. Actions that undermine this principle, such as borrowing YFI from third parties to temporarily inflate one’s weight, are considered a serious breach of trust. +26. **Expulsion Process**: To protect the integrity of the pool, members can vote to expel (blacklist) another member for demonstrating bad faith. +27. **Voting Requirement**: A proposal to blacklist a member requires a **two-thirds (66.7%) qualified majority vote** of the participating pool members to pass. +28. **Vote Exclusion**: The stYFI weight of the member subject to the expulsion vote **will not** be counted in the vote’s tally. +29. **Consequences**: If a member is expelled, their address is permanently removed from the whitelist and they forfeit the right to claim any future yield from the pool. + +#### 5.6 Contributor Delegation Vault, the new yvYFI + +21. **Purpose**: To provide a simple, gas-efficient way for all YFI holders to maximize their stYFI yield. +22. **Functionality**: The vault will automatically stake YFI into stYFI and vote on all governance proposals to ensure its depositors receive the maximum APR boost. +23. **Voting Direction**: Voting decisions for the vault will be directed by the weighted vote of the members of the Yearn Builder’s Collective. + +### 6\. Vote + +#### Non-binding signaling poll + +Do you support Part III (Contributor & Team Incentives) as a component of the full proposal? + +- Yes +- No + +0 voters + +### 7\. References + +1. [YIP-57: Funding Yearn's Future](https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319) +2. [https://dune.com/tobytiger/yfi-buyback](https://dune.com/tobytiger/yfi-buyback) +3. [ERC-20 Token | Address: 0x41252e86...b6797a275 | Etherscan](https://etherscan.io/token/0x41252e8691e964f7de35156b68493bab6797a275) + +### 8\. Changelog + +- **Aug 21, 2025:** First draft circulated with Yearn contributors and the governance team for initial feedback. +- **Sep 03, 2025:** Contributor feedback incorporated. Second draft circulated to key governance participants and liquid locker teams (StakeDAO, Cove, 1UP) for feedback. +- **Sep 25, 2025:** Revisions made based on comprehensive feedback from key stakeholders. Major changes include: + - Updated to clarify the total YFI allocation, reflecting a more accurate breakdown of treasury assets and pre-existing mandates under YIP-57. + - Capped the team performance bonus at 50% of net profit. + - Added an “Accountability Package” for contributor vests, requiring public disclosure of recipient numbers, tiers, and criteria. +- **Sep 28, 2025:** Proposal published on the Yearn governance forum. diff --git a/docs/contributing/governance/yips/yip-89.md b/docs/contributing/governance/yips/yip-89.md new file mode 100644 index 0000000000..776e427069 --- /dev/null +++ b/docs/contributing/governance/yips/yip-89.md @@ -0,0 +1,51 @@ +--- +title: "YIP-89: Proposal to Rotate Multisig Signers" +hide_title: true +sidebar_position: -89 +--- + +# YIP-89: Proposal to Rotate Multisig Signers + +| Metadata | Details | +| --- | --- | +| YIP | 89 | +| Outcome | **Passed** | +| Authors | wavey | +| Created | 2025-12-13 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-89-proposal-to-rotate-multisig-signers/14574) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0x02ac9f5cc91ad090938195c37e17fd24941a668082b2b6b58f20e11e32d73003) | +| Vote result | For: 531.6; Against: 0 | +| Source | [Source](https://gov.yearn.fi/t/yip-89-proposal-to-rotate-multisig-signers/14574) | + +# YIP-89: Proposal to Rotate Multisig Signers + +## Summary + +This proposal seeks to rotate a Yearn multisig signer by removing Daryl Lau and adding Omnifient as a replacement. As part of the signer onboarding process, 1 YFI will be transferred to the new signer. + +* * * + +## Motivation + +The Yearn multisig is responsible for executing approved governance actions on behalf of the protocol, as outlined in the Yearn governance documentation: +[https://docs.yearn.finance/governance/overview](https://docs.yearn.fi/developers/security/multisig) + +Omnifient is a founding member of Katana and was previously part of the Polygon DeFi team and has worked with Yearn on multiple initiatives, including: + +- Launching the Katana pre-deposit vaults +- Supporting the deployment of Yearn vaults on Katana + +* * * + +## Specification + +If approved, the following actions will be taken by the Yearn multisig ([ychad.eth](https://etherscan.io/enslookup-search?search=ychad.eth)): + +- Remove Daryl Lau as a multisig signer `0x99BC02c239025E431D5741cC1DbA8CE77fc51CE3` + +- Add Omnifient as a multisig signer`0x70aF5a3368606c6557D2B3ce2EEC8796B914EAa3` + +- Transfer 1 YFI to the newly added signer + + +No changes to the multisig signing threshold or configuration are proposed. diff --git a/docs/contributing/governance/yips/yip-90.md b/docs/contributing/governance/yips/yip-90.md new file mode 100644 index 0000000000..3937aeda60 --- /dev/null +++ b/docs/contributing/governance/yips/yip-90.md @@ -0,0 +1,210 @@ +--- +title: "YIP-90: yETH Optimistic Recovery Plan" +hide_title: true +sidebar_position: -90 +--- + +# YIP-90: yETH Optimistic Recovery Plan + +| Metadata | Details | +| --- | --- | +| YIP | 90 | +| Outcome | **Passed** | +| Authors | 0xPickles | +| Created | 2025-12-12 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-90-yeth-optimistic-recovery-plan/14573) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:veyfi.eth/proposal/0xe76f57663ce9311eb830ef097812702cbbb55fccbb280d254cdfc1f2c11c261a) | +| Vote result | For: 627.75; Against: 140.2 | +| Source | [Source](https://gov.yearn.fi/t/yip-90-yeth-optimistic-recovery-plan/14573) | + +_Author: 0xPickles_ + +## tl;dr + +- **Zero Principal Spend:** No Treasury principal is spent or distributed. Treasury principal is never impaired and remains fully owned by Yearn. +- **Balance Sheet Neutral & Runway Safe:** Treasury deploys its **existing ETH holdings (currently ~1,600 ETH)** toward recovery. No new ETH is purchased, exposure remains unchanged, and funds remain fully unwindable via governance. +- **Immediate Recovery Boost:** Treasury forfeits its own **~334 ETH ($1M)** recovery claim, instantly boosting the user recovery floor from ~25% to **~30.38%**. +- **Shared Investment:** stYFI holders opt-in to contribute 10% of protocol revenue temporarily, accelerating recovery and increasing stYFI’s long-term value flow. +- **Voluntary:** Users opt-in voluntarily and can exit at any time. Early exits reduce the liability and speed up recovery for those who stay. +- **No Solvency Risk:** This proposal does not impact Yearn solvency risk. + +## 1\. Summary + +This proposal establishes a **voluntary, DAO-wide recovery mechanism** for users affected by the yETH exploit. It combines the strength of the **Yearn Treasury’s balance sheet** with the cashflow power of **stYFI token holders** to provide a credible path to 100% recovery without spending Treasury principal. + +This represents a **Unified Framework** where every stakeholder contributes proportionally in the recovery: + +1. **The Treasury** provides the capital base (principal protected). +2. **stYFI Holders** provide the revenue stream (accelerant). +3. **Users** provide the time and patience. + +### 1.1 Status + +**Discussion** +This proposal is in the discussion phase. As per YIP-55, it will remain here for at least 3 days with a non-binding forum poll. If sentiment is positive, it can move to Snapshot for a binding vote. + +## 2\. Abstract + +If adopted, this proposal will: + +- Authorize the deployment of the **yETH Recovery Vault**. +- Allocate **the Treasury’s existing ETH holdings** (~1600 ETH) toward recovery, with the intent to match net user losses over time through yield, recovered assets, early exits, and protocol revenue redirection. The principal remains under yChad multisig custody. +- Authorize the **forfeiture of the Treasury’s claim** on recovered assets (~334.7 ETH), redistributing it to users to boost the immediate recovery floor. +- Implement a temporary **Protocol Revenue Redirection**: adjusting the revenue split to **80% stYFI / 10% Treasury / 10% Recovery** until the debt is paid. +- Establish a **90-day opt-in process** for users to claim their recovery tokens. +- Delegate strategy management to the **Yearn Curation / SAM team**. + +## 3\. Background + +On Ethereum block **23,914,086**, the yETH weighted stableswap pool was exploited due to a vulnerability in the invariant solver logic.[\[1\]](#references) With the rapid assistance and collaboration by the **Dinero** and **Plume** teams, Yearn contributors were able to successfully recover approximately **857 pxETH** (~25% of the total loss). + +**YIP-72 §8**[\[2\]](#references) explicitly protects the protocol from being _required_ to reimburse users. This clause was designed for existential-scale scenarios where reimbursement would threaten the protocol’s survival. However, this incident is not existential. The scale of the net deficit is within Yearn’s capacity to address through a coordinated, DAO-wide response, without spending Treasury principal or drawing down Treasury assets. + +While Yearn is not obligated to act, this proposal posits that **user trust is a strategic imperative**. Future growth relies on the market knowing that Yearn aligns with its depositors. Unlike an external downstream failure (e.g., an LST in yETH de-pegging or being hacked), this issue originated within the yETH protocol logic itself. Consistent with previous responses to the **yvDAI incident**[\[3\]](#references) and the **Resupply incident**[\[4\]](#references), this proposal offers a recovery path that supports our users, protecting the “security-first” premium of the brand, without crossing the line into a principal-spending bailout. + +### 3.1 Loss Breakdown (Summary Table) + +| Component | Amount (ETH) | Notes | +| --- | --- | --- | +| Total Exploit Loss | 3,157.401 | Based on post-mortem data | +| Recovered assets | 857.490 | Already secured | +| Treasury Forfeiture | 334.807 | Boosts user floor to ~30.38% | +| Total Net User Loss | 1,965.104 | Loss minus recovered assets and minus Treasury forfeiture | + +## 4\. Strategic Rationale + +### 4.1 Why this is NOT a Bailout + +This is a **mechanism**, not a bailout. The Treasury does not distribute funds; it simply allows its capital to generate yield for users. The protocol offers the engine; users choose their recovery timeline. + +- **Users who want immediate certainty** can exit around 30.38% of their pre-hack position. +- **Users who want full recovery** stay and earn yield over time, paying with Time and Opportunity Cost. +- **Treasury pays** with Yield (opportunity cost), not Principal. +- **Protocol gains** by converting a liability into fee-generating TVL. + +### 4.2 Positive Game Theory Mechanics + +This structure creates a “Dissolving Debt Pool” with a self-reinforcing flywheel: + +- Users can exit immediately with ~30.38% of assets. +- When users exit, the total debt liability decreases, but the Treasury’s yield-bearing capital remains. +- As a result, the _Capital-to-Debt ratio improves_, and the recovery timeline for remaining users accelerates. + +This transforms a static deficit into a dynamic, self-healing system where rational early exits enhance the recovery prospects for those who stay. + +### 4.3 Why Treasury Guardians Should Support This + +This proposal **does not lock the runway**. + +- **Market Exposure Neutrality:** The Treasury is already long ETH in Yearn vaults. Whether these vault tokens sit in Treasury or in a controlled recovery vault, market exposure is identical. +- **Liquidity Flexibility:** If Yearn ever faces operational or runway needs, governance can unwind the position or parts of it as needed and return Treasury capital. This ensures the deposit never becomes a hard commitment and cannot threaten protocol solvency. + +### 4.4 Why stYFI Holders Should Support This + +The temporary 10% redirection is a **capital investment** into Yearn’s trust premium, to directly increase future stYFI revenue. + +- **Capital Recirculation:** The 10% redirected revenue is recycled through Yearn strategies, generating performance fees that flow back to stYFI. stYFI holders temporarily give up yield to grow future revenue. +- **Positive ROI:** This turns a reputational hit into a credibility boost. Depositors gain confidence that Yearn stands behind them, a signal to support future TVL growth. +- **Temporary:** This redirection is **explicitly temporary and self-terminating**: once users are made whole (`SharePrice = 1.0`), the full 90% revenue share automatically reverts to stYFI. + +### 4.5 Long-term Benefits to Yearn + +1. **Revenue Growth:** Restoring trust accelerates TVL recovery, increasing protocol revenue long-term. +2. **Brand Premium:** Reinforces Yearn as a security-first protocol, justifying its premium position versus competitors. +3. **Governance Defense:** Pre-empts potential governance proposals that could force less capital-efficient bailouts or recoveries. + +### 4.6 Scope Definition + +**Out of Scope:** This framework applies **only** to the yETH exploit. It does not create any precedent or expectation of recovery for prior or future incidents on unrelated products (e.g., external integrations). It should not be interpreted as a standing commitment for future incidents. + +## 5\. Mechanics & Specification + +### 5.0 Immediate Post-Approval Actions + +To avoid unnecessary delays and begin recovery as early as possible, the following actions will occur immediately upon proposal approval: + +1. **Recovered Asset Withdrawal:** All recovered apxETH will be processed through the Beacon Chain withdrawal queue as soon as technically possible. +2. **Treasury Earmarking:** The Treasury’s ETH allocation for recovery will be explicitly earmarked at approval, even prior to Recovery Vault deployment. +3. **Early Yield Accrual:** Once withdrawn, recovered ETH and earmarked Treasury ETH may begin generating yield for the benefit of users under existing Treasury controls. +4. **Vault Migration:** Once the yETH Recovery Vault is deployed, all earmarked assets will be migrated into the vault, preserving continuity of yield. + +### 5.1 Treasury Allocation & Principal Protection + +1. **Capital Match:** The Treasury allocates its existing ETH holdings toward the recovery mechanism. At the time of proposal, this represents approximately ~1,600 ETH. No new ETH is purchased for this purpose. +2. **Principal Preservation:** This allocation is a **deposit**, not a payment. The Treasury retains full claim to all allocated principal, under the ultimate control of the **yChad multisig**, until users are made whole or governance elects to unwind the position. +3. **Liquidity Escape Hatch:** This allocation remains **callable**. If the DAO faces a liquidity crisis, a governance proposal may be passed to withdraw the Treasury’s principal. + +### 5.2 Treasury Forfeiture (The Boost) + +4. **Claim Forfeiture:** The Treasury forfeits its claim on the recovered assets (~334.7 ETH). +5. **Effect:** This effectively makes the Treasury the **First-Loss Tranche**, immediately boosting the user recovery floor to **~30.38%** (roughly **$1M** in value transferred). This incentivizes early exits. + +### 5.3 Protocol Revenue Redirection + +6. **New Split:** The revenue split[\[5\]](#references) is temporarily adjusted to: **80% stYFI / 10% Treasury / 10% Recovery**. +7. **Cadence:** The revenue redirection follows the existing YIP-88 accounting cadence. Revenues continue to accrue to the Treasury and are distributed once stYFI emissions are live, and continues to be in line with the stYFI distribution model thereafter. +8. **Duration:** This split remains active until users are made whole (`SharePrice = 1.0`), at which point the 10% reverts to stYFI holders. +9. **Yield Backstop:** For the purpose of the veYFI yield backstop calculations established in YIP-88[\[6\]](#references), the 10% revenue redirected to the Recovery Vault will be treated as revenue distributed to stYFI. This ensures stYFI holders do not lose eligibility for any future backstop adjustments while the temporary redirection is active. +10. **Optionality:** Like the Treasury capital, this redirection can be modified or ceased via governance if protocol needs change. + +### 5.4 Vault Logic & Exit + +11. **Tokenization:** Users receive a transferable **ERC-20 token**, representing their pro-rata share of the recovery, that can be bought and sold on AMMs. +12. **Yield:** 100% of yield (from Treasury deposit, recovered funds, and redirected revenue) flows to recovery token holders. **The Recovery Vault itself charges no fees**; only underlying strategies charge their standard performance/management fees (which flow to stYFI). +13. **User Exit:** Users remain in **full control**. They may burn their tokens at any time to withdraw their share of the underlying assets (`SharePrice * Amount`). +14. **Treasury Exit:** The Treasury withdraws its principal once users are made whole (`SharePrice = 1.0`) or via the Escape Hatch. + +### 5.5 Snapshot & Integrator Claims + +15. **Snapshot Block:** Eligibility is based on `yETH` and `st-yETH` balances at the block immediately preceding the exploit (`23914085`). +16. **Holder-is-Owner:** Claims are attributed to the address holding the tokens at the snapshot. For integrators and lending markets, the protocol contract is treated as the owner; they are responsible for downstream distributions. This ensures Yearn does not mediate internal accounting among third-party lenders and borrowers; integrators must resolve these allocations according to their own governance. +17. **Verification Window:** A review period (7 days) will allow integrators to coordinate appropriate claim addresses via making public Pull Requests to the snapshot repo before distribution begins. +18. **Passthrough Expectations:** For integrator-held positions, the intent of this framework is that recovery value ultimately accrues to the underlying economic beneficiaries. Integrators claiming recovery tokens are therefore encouraged to publicly disclose their passthrough methodology and timelines, and to distribute recovery principal and accrued yield on a pro-rata basis according to their own governance and accounting processes. Yearn contributors do not adjudicate downstream claims but will make reasonable efforts to provide technical assistance and coordination to integrators implementing such distributions. + +### 5.6 Opt-In Process + +19. **Claim Window:** A Merkle Distributor will be deployed with a **90-day claim window**. +20. **Active Yield:** Unclaimed funds remain in the pool during the window and generate yield, benefitting active participants. +21. **Late Claims:** Users claiming after the window must submit a manual request. They will receive their portion of the recovered **principal only** (no accrued yield). + +### 5.7 Yield Strategy + +22. **Delegation:** The **Yearn Curation / SAM** team is authorized to manage the underlying yield strategies. +23. **Mandate:** Provide the best risk-adjusted yield without exposing Treasury capital to excessive risk. +24. **Transparency:** Strategy allocations and changes will be announced to contributors for monitoring. +25. **Candidates:** Yearn-Curated Morpho vaults, yvWETH-1 (V3), or diversified ETH-native baskets. + +## 6\. Financial Impact + +This proposal requires **no expenditure of Treasury principal**. The costs are solely the opportunity cost of yield on the matched ETH and a temporary investment of stYFI revenue. + +In exchange, the protocol resolves a major incident, preserves its reputation, and demonstrates a unified front where all stakeholders contribute to the solution. + +## 7\. Vote + +This poll is for non-binding sentiment gauging. The final, binding vote will occur on Snapshot. + +### Non-binding signaling poll + +Do you support the proposal as it is written? + +- Yes +- No + +0 voters + +## References + +1. **Incident Disclosure:** [yearn-security/disclosures/2025-12-01.md at master · yearn/yearn-security · GitHub](https://github.com/yearn/yearn-security/blob/master/disclosures/2025-12-01.md) +2. **YIP-72 §8:** [YIP-72: Launch yETH](https://gov.yearn.fi/t/yip-72-launch-yeth/13158#p-33602-h-8-use-at-own-risk-37) +3. **yvDAI incident:** [yearn-security/disclosures/2021-02-04.md at master · yearn/yearn-security · GitHub](https://github.com/yearn/yearn-security/blob/master/disclosures/2021-02-04.md) +4. **YIP-86:** [https://gov.yearn.fi/t/yip-86-resupply-bad-debt-repayment-loan/](https://gov.yearn.fi/t/yip-86-resupply-bad-debt-repayment-loan/) +5. **YIP-88 Revenue split:** [YIP-88: Governance Overhaul: ⓶ stYFI](https://gov.yearn.fi/t/yip-88-governance-overhaul-styfi/14552#p-35807-h-524-protocol-revenue-routing-14) +6. **YIP-88 Yield backstop:** [YIP-88: Governance Overhaul: ⓶ stYFI](https://gov.yearn.fi/t/yip-88-governance-overhaul-styfi/14552#p-35807-h-54-yield-backstop-19) + +## Changelog + +- **Dec 11, 2025:** First draft +- **Dec 13, 2025:** Added section 5.0, updated loss breakdown and treasury amounts +- **Dec 15, 2025:** Added point 5.18, Passtrough Expectations +- **Dec 16, 2026:** Assigned YIP-90 diff --git a/docs/contributing/governance/yips/yip-91.md b/docs/contributing/governance/yips/yip-91.md new file mode 100644 index 0000000000..398905daf8 --- /dev/null +++ b/docs/contributing/governance/yips/yip-91.md @@ -0,0 +1,186 @@ +--- +title: "YIP-91: yTranche" +hide_title: true +sidebar_position: -91 +--- + +# YIP-91: yTranche + +| Metadata | Details | +| --- | --- | +| YIP | 91 | +| Outcome | **Active** | +| Authors | Vaults Team | +| Created | 2026-07-06 | +| Forum discussion | [View discussion](https://gov.yearn.fi/t/yip-91-ytranche/14659) | +| Snapshot vote | [View vote](https://snapshot.org/#/s:styfi.eth/proposal/0xa348d353b66f46c6957a938a42fbf860eaffc855cd9163d8042780f65ea72612) | +| Vote result | For: 182.73; Against: 0; Abstain: 0 | +| Source | [Source](https://gov.yearn.fi/t/yip-91-ytranche/14659) | + +_Authors: Vaults Team_ + +## Summary + +This proposal seeks endorsement to deploy yTranche across three underlying’s (USD, ETH, and BTC) and asks the Yearn Treasury to seed each system with initial capital in each of the tranches. + +yTranche is a generalized, CLO-inspired tranching framework purpose-built for the next generation of Yearn vaults. It lets Yearn run a small number of trusted multi-strategy V3 vaults, doing what Yearn does best, earning the best verifiable risk-adjusted onchain yield, while splitting and structuring that yield into distinct risk/return profiles for different users. + +## 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 by stYFI holders. + +## Abstract + +**If adopted**, this proposal will: + +- Endorse the yTranche framework as a tranching layer over Yearn V3 vaults. +- Authorize the deployment of three initial yTranche systems on USD, ETH, and BTC. +- Specify the initial tranche configuration (targets and excess-profit shares) for each system. +- Authorize the Yearn Treasury to seed each system with protocol-supplied capital, including explicit equity tranche deposits. +- Confirm that fee flow and operational covenants match existing V3 vaults, with the Treasury additionally exposed to equity-tranche performance. + +## Background + +DeFi is changing, and Yearn needs to adapt in order to stay at the front of it. + +yvUSD has shown product-market fit for Yearn’s new, more risk-on, multi-chain, multi-asset allocator vaults. But a one-size-fits-all vault will never be compelling to the entire market. There are different users with different risk profiles and different return expectations: protocols and conservative allocators that want a safe, protected, and predictable source of yield, and risk-on users willing to take on loss exposure in exchange for higher potential returns. + +Running a tranching system on top of our vaults lets Yearn simplify the operational work of doing what we do best, earning the best risk-adjusted onchain yield, in a verifiable way, while structuring the resulting yield in compelling ways for distinct audiences. The same trusted, audited V3 vault sits underneath; yTranche only changes how the yield and risk on top of it are divided. + +More of the market is demanding explicit, protocol-supplied first-loss capital and visible skin in the game. Yearn has always been the anchor depositor in its own vaults and new products, and has historically tried, wherever possible, to cover losses realized by those vaults. However, over time it has become clear that implicitly backstopping every product is neither sustainable nor desirable, it creates open-ended liability and misaligned expectations and Yearn has not been properly compensated for this implicit risk. + +Launching these systems lets us do this explicitly, thereby giving depositors and the DAO a clearer expectation of how losses are handled if they arrive. The tranching system gives the Yearn treasury larger upside returns when the vaults perform well and demonstrate that we are willing to put our own capital on the line in a defined, transparent way. This is not feasible to do across dozens of vaults, which is why we are continuing the consolidation of our offerings into a few select primary choices. + +yTranche is a generalizable system that sits on top of any ERC-4626 vault, and allows fully configurable parameterization for intended outcomes. Each tranche is configured with both a “target rate” and an “excess split” allowing for any mix and match of the two for traditional Senior/Junior setups as well as more custom ones as explained below by combining into fixed, levered and equity style vaults. + +## Motivation + +### Why tranching, and why now + +- **A small, focused vault set, many products.** Consolidating into a few primary vaults concentrates liquidity, audit surface, and operational attention, while tranching restores the product variety the market wants on top. +- **Explicit skin in the game.** Protocol-supplied equity tranche converts Yearn’s historic implicit backstop into a defined, onchain commitment with levered upside. This improves DAO alignment and clarifies depositor risk assumptions. +- **Reaching new audiences.** A protected, predictable fixed tranche is suitable for protocols and conservative allocators that cannot or will not sit in a raw risk-on vault. A levered/equity tranche serves users who want amplified exposure to the same underlying yield. +- **Generalizability.** One framework spans USD, ETH, and BTC today and can extend to new underlying’s as the market evolves, without re-architecting the vault layer. + +### Future possibilities + +- Additional yTranche systems on new underlying’s as demand emerges. +- Use of fixed-tranche positions as predictable collateral or treasury instruments by integrating protocols. +- Migration of protocol seed capital from fixed/levered tranches into equity as each system matures and third-party TVL grows. + +### Risks + +These new systems will take on more risk than Yearn’s earlier primary “1” style V3 vaults. They will operate in the same way as we currently see with yvUSD; with the tranching allowing the lowest risk versions to meet or exceed the “1” risk levels. As with everything at Yearn, this will be done in a targeted way and only where the returns justify the risk. Potential risks include: + +- The underlying vault realizes a loss large enough to consume the equity position and impair the other tranches. +- A flaw in the tranching contracts or their configuration causes unintended waterfall behavior. +- Demand for one or more tranches is weaker than expected, reducing the efficiency of the structure. +- Protocol capital placed in equity tranche is, by design, the first to absorb losses and can be partially or fully lost. + +## Specification + +### 1\. System overview + +Each yTranche system is a set of ERC-4626 tranche strategies sharing a single Yearn V3 multi-strategy vault. Users deposit into a tranche rather than the vault directly. A controller keeps the economic accounting, priority order, target accrual, profit sharing, loss absorption, and an optional reserve buffer. Profit and loss move through a waterfall: targets accrue to each tranche in priority order, surplus is shared after the targets are hit, and any losses are absorbed first by any protocol-supplied buffer and then most junior to senior. + +[![image](https://europe1.discourse-cdn.com/flex013/uploads/yearn/optimized/2X/1/152cff5e5df891410356949b0fdb4170c0c0b9bb_2_690x450.png) + +image1440×940 55.2 KB + +](https://europe1.discourse-cdn.com/flex013/uploads/yearn/original/2X/1/152cff5e5df891410356949b0fdb4170c0c0b9bb.png "image") + +The system comes with built-in rate limits, global risk and emergency controls, shared authorization parameterization, report health checks and other features making sure Yearn continues to stay at the front of security and risk controls. + +The three initial systems share this same structure and differ only in their underlying assets and parameters. + +### 2\. Tranche configuration — initial deployments + +While the tranching system itself is generic enough to hold any n number of tranches with infinite configuration options, only three systems are proposed at launch, on USD, ETH, and BTC. + +The USD and ETH systems have three tranches, a fixed tranche, a levered tranche, and an equity tranche. + +The BTC system launches with two tranches, a fixed tranche and an equity tranche, where the equity tranche carries the full excess share. + +Each senior “fixed” tranche is built to be atomically liquid for both deposits and withdrawals, to give those users the classic Yearn vault experience. Then, the lower-tiered tranches will come with their own configurable “cooldown” and “withdraw window” periods for withdrawals. + +Expected starting parameters are: + +[![image](https://europe1.discourse-cdn.com/flex013/uploads/yearn/optimized/2X/b/b55390396c2e881e0ea832e57bd709c21e9de6f2_2_690x276.png) + +image1440×578 41.6 KB + +](https://europe1.discourse-cdn.com/flex013/uploads/yearn/original/2X/b/b55390396c2e881e0ea832e57bd709c21e9de6f2.png "image") + +**NOTE: All parameters are configurable and will be adjusted as needed according to market conditions or needs.** + +**Note: Due to lower overall yields BTC will only have two tranches to start.** + +### 3\. Funding + +This proposal asks the Yearn Treasury to seed each system, placing protocol capital explicitly into the tranches below. + +| System | Equity | Levered | Fixed | Source | +| --- | --- | --- | --- | --- | +| USD | $500k | $250k | $250k | Reallocated from the Treasury’s existing yvUSD position (no new deposit) | +| ETH | $500k | $250k | $250k | yETH recovery vault (reuses already-deployed WETH) | +| BTC | $250k | n/a | $250k | BTC (some may need to be acquired) | + +Notes on the ask: + +- **USD** is funded entirely by restructuring the Treasury’s existing yvUSD position into the three USD tranches. Net Treasury exposure is unchanged; the same dollars are simply moved from sitting directly in yvUSD into the yTranche-USD strategies, which themselves sit in the vault. +- **ETH** is funded through new strategies on the yETH recovery vault. All DAO-owned ETH is currently in this vault earning yield for the yETH recovery. This reuses the already-deployed WETH, and because the recovery vault’s capital earns the structured (and presumably higher) returns of the ETH system, it should see better net returns, increasing the rate of recovery. +- **BTC** is funded with net new BTC, a portion of which may need to be acquired. The equity tranche carries the 100% excess share and acts as the system’s first-loss layer. + +While the system allows for a specific protocol-supplied reserve buffer, that is not what the funds described above will be used for. A reserve buffer would take on all of the risk of first loss capital but hold none of the upside. Rather, we request Yearn to be the anchor depositor in the equity buckets. And while the equity layer does take on losses first, it also participates in the upside of the vaults when gross returns exceed the required minimums for the target rates. + +An example of expected returns of each tranche at different net vault returns. + +[![image](https://europe1.discourse-cdn.com/flex013/uploads/yearn/optimized/2X/1/100b9b64c6b8efd0a6ca5e89c8b6ed0fe981b0f1_2_690x380.png) + +image1440×794 91.8 KB + +](https://europe1.discourse-cdn.com/flex013/uploads/yearn/original/2X/1/100b9b64c6b8efd0a6ca5e89c8b6ed0fe981b0f1.png "image") + +**Maturation path.** As each product matures and third-party TVL grows, the expectation is that the protocol’s fixed and levered positions can be rolled into the equity tranche, freeing fixed/levered capacity for newer, higher TVL and concentrating Yearn’s exposure where its skin-in-the-game and potential upside is most meaningful. + +### 4\. Fee flow and protocol return mechanics + +Covenants and fee flow for the tranching systems match all existing V3 vaults: new revenue earned from these vaults flow directly to the staked-YFI splits, exactly as today. + +In addition, Yearn earns the returns of the equity tranche positions themselves. At times when the systems outperform their expected target rates, the equity portion captures outsized returns; when they underperform, it absorbs outsized losses. The net effect is that Yearn earns a normal vault-level management/performance fee and holds additional, asymmetric skin in the game through the equity position. This keeps the protocol motivated to pursue the best yields while discouraging moving too far out on the risk curve. + +### 5\. Roles and governance + +Role assignment matches the current Yearn V3 vault setups. The tranching systems use the same management, keeper, guardian/emergency, and treasury role structure already in place for V3, rather than introducing a new governance surface. + +## Implementation + +The tranching contracts are currently in audit. Once the audit is complete, the systems will be deployed and configured over the coming weeks to months. Upon this proposal’s approval, Yearn contributors are authorized to deploy the three systems and seed the tranches as specified above. + +Yearn contributors will continue to monitor and adjust the configuration parameters as needed based on market demands. + +## Use at Own Risk + +yTranche systems take on defined, structured risk on top of Yearn V3 vaults. Protocol-supplied equity tranches are explicitly first-loss and may be partially or fully lost. Yearn contributors and YFI/stYFI token holders are not obligated to compensate users for any failure or loss of funds resulting from the use of these systems. + +## Vote + +### Non-binding signaling poll + +Proceed with this proposal in its current form? + +**For**: Proceed with deployment and funding. + +**Against**: Do not proceed with funding and eployment + +**Poll**: + +- For +- Against + +0 voters + +## References + +1. yTranche implementation — [GitHub - Schlagonia/ytranche · GitHub](https://github.com/Schlagonia/ytranche) diff --git a/docusaurus.config.js b/docusaurus.config.js index 00becbbbd7..d661d61eb6 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -120,7 +120,7 @@ export default { }, { label: 'Snapshot Voting', - href: 'https://snapshot.org/#/veyfi.eth', + href: 'https://snapshot.org/#/s:styfi.eth', }, ], }, diff --git a/sidebars/sidebarsContributing.js b/sidebars/sidebarsContributing.js index cc0e3122d3..92d0f86519 100644 --- a/sidebars/sidebarsContributing.js +++ b/sidebars/sidebarsContributing.js @@ -20,6 +20,20 @@ module.exports = { label: 'Governance', items: [ 'governance/proposal-process', + { + type: 'category', + label: 'Proposal Repository', + link: { + type: 'doc', + id: 'governance/proposal-repository', + }, + items: [ + { + type: 'autogenerated', + dirName: 'governance/yips', + }, + ], + }, 'governance/yfi', { type: 'category',