Project & Team
Description of Project
Provide a concise narrative that clearly states each of (a)–(e) below.
- (a) Problem the project solves — The problem the project is solving.
- (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time.
- (c) High-level project overview — How the project works at a high level.
- (d) Primary token functions — The primary functions of the token (e.g. gov participation).
- (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
(a) Problem the project solves
Yearn's core vault contracts are designed to give depositors a simple way to generate returns on deposited assets through lending protocols, liquidity pools, and any other viable source of yield on Ethereum mainnet and other EVM chains (source: https://github.com/yearn/yearn-vaults-v3; source: https://gov.yearn.fi/t/how-we-think-about-yearn/7137; source: https://yearn.fi/vaults).
(b) Operational priorities
Yearn's operational priorities center on developing and maintaining robust, open, and permissionless financial infrastructure that anyone in the world can use to curate the best risk-adjusted returns available on Ethereum-based markets.
Operations are funded by fees from smart contract development and deployment of core products like Yearn Vaults V3.
(c) High-level project overview
Yearn is a Full Stack DeFi yield aggregator that automates capital allocation and market curation across lending and liquidity protocols through smart contract Vaults. Since creating the first Vault in 2020, it has grown into one of DeFi's most battle-tested yield infrastructures, with over $8B in lifetime deposits and more than $300M in net profits.
(d) Primary token functions
The YFI token is a tool for coordination between Yearn's contributors, community and associated protocols. It was created to decentralize the management and development of yearn products while providing an environment for fast-paced innovation.
In 2025, stYFI was created, enabling token holders to receive 90% of Yearn revenue (source: https://gov.yearn.fi/t/yip-88-governance-overhaul-styfi/14552; source: https://styfi.yearn.fi/).
(e) Control surface reliance
Yearn's public control surface relies on constrained delegation rather than a single centralized operator. YFI holders retain ultimate authority over governance powers and signer changes, yTeams hold delegated operational powers, and the multisig retains execution and veto powers over onchain actions until a more decentralized implementation is adopted (source: https://docs.yearn.fi/contributing/governance/governance-and-operations/; source: https://gov.yearn.fi/t/yip-61-governance-2-0/10460; source: https://gov.yearn.fi/t/yip-79-multisig-compensation-and-rotation/14179).
Known Project Team
For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: (a) full names, (b) official titles, (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.
Labs / DevCo
Full Name | Official Title | Prior Experience |
|---|---|---|
No labs or devco entity exists | N/A | N/A |
Foundation
Full Name | Official Title | Prior Experience |
|---|---|---|
Jefferson Mong'are | Director | Lawyer |
DAO / Onchain Governance
Full Name | Official Title | Prior Experience |
|---|---|---|
Ephy (public identifier) | Proposed ychad.eth multisig signer | Dewiz.xyz co-founder, contributor in the Maker/Sky ecosystem, and former MakerDAO Core Unit contributor |
CryptoHarry (public identifier) | Proposed ychad.eth multisig signer | Affiliated with Inverse Finance (source: https://docs.yearn.fi/developers/security/multisig) |
Michael Egorov | Proposed ychad.eth multisig signer | Curve founder |
tapir (public identifier) | Proposed ychad.eth multisig signer | Yearn security engineer |
Mariano Conti | Proposed ychad.eth multisig signer | ex-MakerDAO |
Leo Cheng | Proposed ychad.eth multisig signer | ex-C.R.E.A.M. Finance |
omnifient (public identifier) | Proposed ychad.eth multisig signer | Katana |
0xngmi (public identifier) | Proposed ychad.eth multisig signer | DeFiLlama founder |
Lefteris Karapetsas | Proposed ychad.eth multisig signer | Rotki founder |
DAO Structure
Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).
- (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
- (b) Contract/admin powers — List on-chain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
- (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
- (d) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
- (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., on-chain vote threshold, board resolution of a legal wrapper).
(a) IP ownership & control
Yearn V3 Core Vault Logic has AGPL 3.0 license (https://github.com/yearn/yearn-vaults-v3) Yearn V3 Strategy Logic has AGPL 3.0 license (https://github.com/yearn/tokenized-strategy)
(b) Contract/admin powers
Yearn uses a constrained-delegation governance model. The powers expressly retained by token-holder governance are: creating, assigning, or revoking delegated powers; changing or interacting with the YFI token contract, including minting authority; setting protocol fee structures; changing yChad multisig signers; ratifying or removing yTeams; changing yOps signers; approving expenditures of Treasury funds; and deciding any matter outside an already-delegated power through a YIP. Current governance voting power is held by stYFI holders.
The operational powers delegated under Governance 2.0 are: Execution Power and Veto Power to yChad; Emergency Powers to yGuard to intervene in an attack or bug and shut down or roll back affected vaults or strategies; Manage Strategies to yBrain; Define Yearn Protocol, Manage Protocol, and Add Strategies to yDev; Delegate Transactions to yTx; Pay Team to yPeople; Set Budgets to yBudget; Farm Treasury, including management of airdrops, to yFarm; and Ratify yTeam Signers to yOps. yChad executes applicable onchain decisions and can veto them.
(c) Locked-token rights (conditional)
Yearn governance staking is centered on stYFI and stYFIx.
stYFI: stake YFI, earn 90% of Yearn revenue, 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).
Unstaking starts a 14-day linear cooldown:
funds unlock linearly over time and holders can withdraw the currently unlocked amount at any point during the stream
(source: https://docs.yearn.fi/contributing/governance/styfi)
(d) Value accrual & holder rights
stYFI and stYFIx holders earn 90% of Yearn revenue (source: https://styfi.yearn.fi/)
(e) Dissolution authority
Operationally, spinning down the Yearn DAO would require a governance proposal approved by YFI token holders. The proposal would authorize a series of on-chain governance actions, such as revoking or transferring privileged roles, disabling contributor funding, winding down or migrating vaults, defining treasury disposition, and making governance contracts immutable or otherwise minimizing administrative authority. Execution would occur through Yearn's governance contracts and timelock, with each approved action carried out according to the protocol's governance process.
stYFI token holders govern the Yearn ecosystem through offchain proposals and votes via Snapshot. 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 is then empowered to execute all related transactions after their own review. The members of the multi-signature wallet are voted in by YFI holders and are subject to change via future governance votes (source: https://docs.yearn.fi/contributing/governance/proposal-process).
Primary Foundation
For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
Ychad.Eth Yearn BORG, a foundation company limited by guarantee without any share capital
c/o International Corporation Services Ltd, PO Box 472, 2nd Floor, North Wing, Harbour Place,103 South Church Street, George Town, Grand Cayman KY1-1106, Cayman Islands
(b) IP ownership & control
No IP exists for the Foundation.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
The professional BORG Director does not independently exercise Yearn governance, treasury, token, emergency, or reward-setting powers and does not have a key to unilaterally operate yChad. The Director's affirmative authority is limited principally to signing legal documents and government filings on behalf of the Foundation and participating in a liquidation of the Foundation; liquidation cannot be approved by the Director alone and additionally requires yChad and Yearn DAO approval.
The relevant operational powers instead sit with Yearn's governance system and multisigs. yChad is a 6-of-9 Safe, so an ordinary transaction requiring yChad approval requires six of the nine yChad signers. Binding DAO proposals are approved by a majority of voting stYFI and, where onchain execution is required, are implemented through the multisig.
For emergency powers, Governance 2.0 delegates authority to yGuard to immediately intervene in an attack or bug, including shutting down or rolling back affected vaults or strategies. Yearn's emergency procedures contemplate actions such as revoking strategies, activating emergency shutdown, changing debt ratios, and placing strategies into emergency-exit mode. Where execution requires yChad, the execution threshold is 6-of-9; some contract-specific emergency actions may instead be performed through separately delegated operational multisigs.
For Treasury distributions, the general power to spend Treasury funds remains with token-holder governance. A binding governance decision requires majority support from stYFI voters, and a yChad transaction requires 6-of-9 signatures for execution. YIP-88 additionally created a $250,000 discretionary fund managed by yChad for urgent or sensitive expenditures; yChad may spend from that approved envelope, but replenishing it requires a new formal DAO proposal and vote.
For YFI token administration, authority over the YFI token contract remains with token-holder governance rather than the Director or yChad acting unilaterally. Actions such as changing minting authority therefore require a governance decision; if an onchain yChad execution is required, the Safe threshold is 6-of-9.
For reward and revenue parameters, YIP-88 establishes a default protocol-revenue split of 90% to stYFI stakers and 10% to the DAO Treasury, with the split expressly designated as a DAO-configurable parameter. The reward asset itself may be changed by the DAO-ops multisig, and DAO-ops was delegated implementation authority over the governance-participation APR boost subject to the limits adopted in YIP-88. These are not unilateral powers of the BORG Director.
There is one additional BORG-specific threshold worth stating: changes to yChad's signer set, yChad's signing threshold, Safe modules, or Guards require bilateral approval by both the DAO and yChad, rather than yChad acting alone. On the yChad side that means the normal 6-of-9 threshold; on the DAO side it means the applicable binding governance vote.
(d) Powers over DevCo
No powers over the DAO exist for the Foundation.
(e) Contract/admin powers
Per YIP-81, the Yearn Multisig (AKA yChad) serves in the Guardian role to steward and protect the Yearn Protocol and its participants. The Guardian role is defined as being able to "nullify a proposal or governance decision but cannot make proposals".
These operational powers include:
- YFI holders can vote to create, assign, or revoke discrete powers to or from yTeams
- 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 the standard fee structures in the Yearn Protocol
- As the Multisig will continue to hold critical powers over the near term, only YFI holders can vote to change its signers
- Formally ratify or deratify yTeams to control which yTeams can hold delegated powers
- As yOps has the power to change signers of other yTeams, this is a special power to change the signers of yOps
- Spend funds from the treasury
- YFI Holders have the power to propose a YIP on anything not already delegated
Additional information about Governance and Operations can be found here: https://docs.yearn.fi/contributing/governance/governance-and-operations
(f) Current economic arrangements and distribution policies
The Yearn BORG does have a limited governance-approved mechanism for paying its ongoing operating costs. Under YIP-87, initial formation costs and the first two years of the MetaLeX web application/supervisor service were funded from Yearn's pre-existing LeXpunK Builder Defense contribution. Thereafter, recurring expenses are funded from the yChad/Yearn Treasury: approximately $12,000 per year to maintain the Cayman Foundation in good standing, beginning in year two, and approximately $5,000 per year for the non-U.S. professional Director, beginning in year one.
The 1 YFI payments to yChad signers under YIP-79 were separately governance-approved one-time compensation, not an automatic annual or recurring funding mechanism. YIP-79 granted 1 YFI to ongoing signers and a separate 1 YFI retroactive payment to the then-current signers for past service.
Separately, yChad receives, holds, and manages Yearn Treasury assets and protocol fees for the benefit of the Yearn ecosystem, and YIP-88 establishes a default routing of 10% of protocol revenue to the DAO Treasury. Those assets are DAO/Treasury assets and are not a revenue share, fee entitlement, reward stream, or compensation entitlement belonging to the Foundation, its Director, or its signers. Other than the expressly approved operating costs above and separately approved compensation such as YIP-79, there is no standing contractual or programmatic mechanism that automatically directs a percentage of Yearn fees, revenue, rewards, emissions, or token distributions to the Foundation or its contributors as compensation.
Primary Dev Co
For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
DevCo does not exist
(b) IP ownership & control
DevCo does not exist
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
DevCo does not exist
(d) Powers over Foundation
DevCo does not exist
(e) Contract/admin powers
DevCo does not exist
(f) Current economic arrangements and distribution policies
DevCo does not exist
Token Supply & Allocations
Initial Allocation
Ticker | Date | Allocation Category Name | Recipient Type | Allocation % | Allocation Tokens | TGE Unlock % | TGE Unlock Tokens | Cliff Months | Cliff Unlock % | Linear Vesting Months | Cadence Months | Circulating Treatment | Notes on what each category is used for | If applicable: Contract / Wallet address |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
YFI | July 17, 2020 | Fair Launch | n/a | 100 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Yes | n/a | 0x0bc529c00C6401aEF6D220BE8C6Ea1667F6Ad93e |
Airdrop Process
Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.
- (a) Planned but not yet executed airdrop — If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, generally state the possible target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (b) Executed airdrop — If the project has already airdropped, point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count. Additionally, clearly state covered user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (c) No airdrop planned or conducted — If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one").
(a) Planned but not yet executed airdrop
YFI has been in circulation for over 6 years. No airdrops occurred or are planned for.
(b) Executed airdrop
None
(c) No airdrop planned or conducted
None
Transactions & Market Structures
Market Maker Agreements & Deals
Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table: (a) Market maker's name — the market maker's name; (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply; (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable, (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.
Market Maker Name | Token Allocation Committed | Term Duration | Structure Name |
|---|---|---|---|
No native tokens were loaned or allocated to market makers | N/A | N/A | N/A |
CEX / DEX Agreements & Deals
Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table: (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair); (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply; (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable, (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership. If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.
Exchange Name | Token Allocation Committed | Term Duration | Native Token Listing Fees |
|---|---|---|---|
No agreements or deals with CEX or DEX | N/A | N/A | N/A |
Financial Disclosures & Risks
Prior Token Sales & Fundraising
Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide: (a) Series Name; (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.); (c) Date of sale (at least month & year); (d) Number of tokens sold (or % of total supply); (e) Vesting schedule. If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").
Series Name | Investment Vehicle | Date Of Sale | Number of tokens sold | Vesting Schedule |
|---|---|---|---|---|
No prior fundraising, OTC, or discounted MM sales have occurred. | N/A | N/A | N/A | N/A |
Previous Exploits Affecting The Native Token
If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").
- (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
- (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
- (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
- (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
- (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
- (f) References (optional) — Link(s) to post-mortem/advisory/PR.
(a) Date & component affected
- 2021-02-04, Yearn v1 yDAI vault
- 2025-11-30, yETH exploit (yETH weighted stableswap pool, different product than a standard Yearn vault)
(b) Exploit vector summary
- yDAI exploit: The exploiter created exchange-rate imbalances in Curve's 3pool, causing the yDAI vault to deposit and withdraw at unfavorable rates (source: https://github.com/yearn/yearn-security/blob/master/disclosures/2021-02-04.md).
- yETH exploit: The disclosure states that the attacker forced the pool's internal solver into a divergent state, over-minted yETH LP tokens, drained underlying LSTs, then re-entered the initialization branch and minted approximately 2.3544 × 10^56 yETH LP tokens to drain the yETH/ETH Curve pool (source: https://github.com/yearn/yearn-security/blob/master/disclosures/2025-12-01.md).
(c) Quantified impact
- yDAI exploit: The disclosure states that 11 million DAI of vault deposits were lost, while 24 million DAI out of 35 million DAI deposits were saved; exploiter profit was estimated at 2.7 million DAI (source: https://github.com/yearn/yearn-security/blob/master/disclosures/2021-02-04.md).
- yETH exploit: The forum discussion described the incident as affecting yETH depositors, and the security disclosure states that 857.49 pxETH was recovered; the same disclosure states that Yearn v2/v3 vaults and other Yearn products were not affected and that impact was isolated to yETH and direct integrators (source: https://gov.yearn.fi/t/yeth-exploit-discussion; source: https://github.com/yearn/yearn-security/blob/master/disclosures/2025-12-01.md).
(d) Remediation/response taken
- yDAI exploit: Yearn's security team and multisig acted in roughly 11 minutes, and mitigation included applying setMin(0) to disable deposits into the strategy (source: https://github.com/yearn/yearn-security/blob/master/disclosures/2021-02-04.md).
- yETH exploit: Publicly described response included coordinated recovery efforts, pro rata redistribution of recovered assets to affected depositors, continued postmortem publication, and ongoing evaluation of governance-constrained remediation options (source: https://gov.yearn.fi/t/yeth-exploit-discussion; source: https://github.com/yearn/yearn-security/blob/master/disclosures/2025-12-01.md).
(e) Current status
- yDAI exploit: Exploit was detected while it was in progress and a majority of funds at risk were saved thanks to rapid response time (source: https://github.com/yearn/yearn-security/blob/master/disclosures/2021-02-04.md).
- yETH exploit: Recovery efforts are ongoing and recovered assets are slated for redistribution to affected depositors (source: https://gov.yearn.fi/t/yeth-exploit-discussion; source: https://github.com/yearn/yearn-security/blob/master/disclosures/2025-12-01.md).
(f) References (optional)
- yDAI: https://github.com/yearn/yearn-security/blob/master/disclosures/2021-02-04.md
- yETH: https://gov.yearn.fi/t/yeth-exploit-discussion and https://github.com/yearn/yearn-security/blob/master/disclosures/2025-12-01.md
Material Risk Factors (Regulation, Technology, Token Economics)
Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.
- (a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:
- Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
- Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
- Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
- Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?
- (b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:
- Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
- Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?
- (c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:
- Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
- Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?
(a) Regulatory, Legal & Tax Risks
YFI, stYFI, and stYFIx token holders need to evaluate their own regulatory and tax position without project-specific public guidance.
(b) Protocol, Technology & Security Risks
Yearn's vault system depends on smart contracts and strategy integrations that can fail in ways that lead to depositor losses. The 2021 yDAI disclosure shows that exchange-rate imbalances in Curve's 3pool were sufficient to make the vault transact at unfavorable rates and lose 11 million DAI before mitigation (source: https://github.com/yearn/yearn-security/blob/master/disclosures/2021-02-04.md). The 2025 yETH disclosure shows a different class of design and implementation risk in which the attacker forced the pool into a divergent state, over-minted LP tokens, and drained assets, while the incident was isolated to yETH and direct integrators rather than Yearn v2/v3 vaults generally (source: https://github.com/yearn/yearn-security/blob/master/disclosures/2025-12-01.md). Yearn focuses resources toward security audits of smart contract code, secure deployment, and operational security work, but those measures do not fully eliminate all exploit risks (source: https://gov.yearn.fi/t/yip-36-system-rewards-as-operational-capital/2311).
(c) Token Economics, Unlocks & Incentive Risks
Yearn's token economics have changed through governance and can change again. Proposal 0 set a 30,000 YFI launch supply, but YIP-57 later minted 6,666 additional YFI for contributor retention and treasury capitalization, showing that supply is governed rather than permanently fixed (source: https://gov.yearn.fi/t/proposal-0-yfi-supply/24; source: https://gov.yearn.fi/t/yip-57-funding-yearns-future/9319). Yearn's public governance framework also leaves YFI holders with power over the token contract, treasury spending, multisig signer changes, and governance delegation, while YIP-65 contemplates governance-linked reward systems built on bought-back YFI and veYFI locking (source: https://docs.yearn.fi/contributing/governance/governance-and-operations/; source: https://gov.yearn.fi/t/yip-65-evolving-yfi-tokenomics/11994). veYFI has now been deprecated and is replaced by stYFI, while the live stYFI interface includes a delegated-voting stYFIx mode and yvUSDC as the Reward Token (source: https://legacy-veyfi.yearn.fi/; source: https://styfi.yearn.fi/). These governance-controlled monetary and reward decisions could affect tokenholder dilution, treasury deployment, and the balance between governance utility and economic rewards. Disclaimer: This Token Transparency Filing is prepared by YFI and is provided for general informational purposes only. Blockworks makes no representations or warranties, express or implied, regarding the accuracy, completeness, or timeliness of the information provided (including any external links to third-party content), and Blockworks is not liable for any errors or omissions in the content or for any actions taken in reliance on this content.
This Token Transparency Filing is provided for general informational purposes only. Blockworks reviews completeness only and does not verify or warrant the accuracy of individual answers. yearn.finance is solely responsible for the content, accuracy, and legality of its disclosures.