Beefy Token Transparency Filing

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

Beefy addresses the challenge of optimizing yield across the DeFi ecosystem. As a decentralized, multichain yield optimizer, Beefy enables users to earn compound interest on their crypto holdings through Vaults that use smart-contract-enforced investment strategies to automatically maximize rewards from liquidity pools and other yield farming opportunities, compounding farm reward tokens back into the initially deposited asset.

(b) Operational priorities

Beefy's operational model is centered on Vaults, its main product, as part of a decentralized, multichain yield optimizer. Vault strategies are secured and enforced by smart contracts and are designed to automatically maximize user rewards by compounding farm reward tokens back into the initially deposited asset. Alongside Vaults, Beefy operates Cowcentrated Liquidity Manager (CLM) products, which manage concentrated liquidity positions on V3-style decentralized exchanges by automatically rebalancing the position around the current price and harvesting trading fees.

Governance support is provided through the BIFI token, whose holders are entitled to vote in important Beefy DAO governance decisions.

Beefy is maintained and further developed by Core Contributors, funded by the protocol treasury through quarterly budgets approved by DAO members.

(c) High-level project overview

Beefy is a decentralized, multichain yield optimizer that allows users to earn compound interest on their crypto holdings. Its main product is Vaults, which use smart-contract-secured investment strategies to automatically maximize user rewards from liquidity pools, automated market making projects, and other DeFi yield opportunities. The Vault strategies compound farm reward tokens from decentralized exchanges back into the initially deposited asset.

Beefy also offers Cowcentrated Liquidity Manager (CLM) products, which manage concentrated liquidity positions on V3-style decentralized exchanges. CLM automatically rebalances the position around the current price and harvests trading fees, so users get concentrated liquidity exposure without manually managing ranges.

Funds are never locked in any Beefy contract, users can withdraw at any time, and users remain 100% in control of their crypto while funds are staked in a vault.

(d) Primary token functions

BIFI is the governance token of the Beefy DAO and serves as the central asset connecting stakeholders across the Beefy project. Tokenholders are entitled to vote on important DAO governance decisions. BIFI also functions in tokenholder incentive programs: a portion of revenue generated by Beefy platform is directed to tokenholder incentives, which are regularly paid through the BIFI Pool and BIFI Vault; tokenholders must deposit BIFI to participate in those programs.

(e) Control surface reliance

No anticipated or possible evolution of the protocol’s governance/control model

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/Devco exists.

Foundation

Full Name	Official Title	Prior Experience
No Foundation exists. Beefy has no foundation or other legal entity in any jurisdiction.

DAO / Onchain Governance

Full Name	Official Title	Prior Experience
armads	Core Contributor
chebiN	Core Contributor
DefiDebauchery	Core Contributor
GPMS	Core Contributor
Eren	Core Contributor
frondoto	Core Contributor
jackgale.eth	Core Contributor
Pablo	Core Contributor
Power	Core Contributor
Chimp	Core Contributor
Roman Monk	Core Contributor
TBC	Core Contributor
Weso	Core Contributor
YR	Core Contributor

DAO Structure

Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so for each sub question. Even if there is no DAO, there must be an answer to (d). Address the lettered items below.

(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) Current tokenholder governance rights and economic arrangements — If any, describe the current governance rights of tokenholders and any presently operative rights or arrangements relating to treasury actions, fee-routing, rewards, buybacks, or other protocol-controlled resources. If none, state that explicitly.
(e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
(f) 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

the DAO owns or controls no IP

(b) Contract/admin powers

Beefy has no foundation or legal entity. Contract and administrative powers are held by Core Contributors through multisig wallets on each chain. These powers include pausing vaults and strategies, upgrading or retiring strategies, and adjusting protocol parameters such as fees. Every action requires majority approval from 4 of 7 multisig signers, so no single contributor can act alone. Strategy changes and upgrades also pass through a 6-hour timelock, and scheduled timelock transactions are published live on the Beefy Discord. Vault funds cannot be withdrawn or seized by any admin role.

Governance-executor authority: BIFI holders vote on proposals through Snapshot, and these votes are not executed on-chain automatically. Core Contributors act as the executive body. They carry out approved proposals and hold delegated authority over day-to-day operations. Any Core Contributor decision can be put to a token holder vote. Core Contributors also moderate governance and may remove proposals that are malicious, unfair, impossible to execute, unclear, or that allow too little time to vote. Token holders have no on-chain veto over multisig actions.

(c) Locked-token rights (conditional)

Tokenholders are entitled to vote in important Governance decisions for the DAO. A part of all revenue generated by vaults within the Beefy Protocol is directed towards tokenholder Incentive Programmes, and incentives are regularly paid out through the BIFI Pool and BIFI Vault. Tokenholders must deposit their BIFI tokens to participate in the BIFI Pool and BIFI Vault. It adds no voting rights. Depositors cannot set incentive rates or fee routing.

(d) Current tokenholder governance rights and economic arrangements

BIFI is the governance token of the Beefy DAO. Tokenholders are entitled to vote on Snapshot to approve quarterly Core Contributor budgets, treasury spending, the revenue share paid to holders, and any other protocol decision put to a vote. A portion of all revenue generated by vaults within the Beefy Protocol is directed toward token holders.
Token holders must deposit their BIFI in the BIFI Pool or BIFI Vault to receive a share of protocol revenue.
BIFI Vaults buys BIFI on market with fee revenue

(e) Control surface reliance

No anticipated or possible evolution of the protocol’s governance/control

(f) Dissolution authority

No single party has authority to dissolve or wind up Beefy. The protocol is governed by BIFI token holders, so dissolution could only happen through the standard governance process: a proposal submitted on Beefy's Snapshot by a holder of at least 1 BIFI and passed by a simple majority of votes cast. Beefy has never adopted a formal quorum, so none applies. No individual, core contributor, or legal entity can unilaterally dissolve the DAO. No dissolution proposal has been made to date.

Primary Foundation

For the Primary Foundation do the following independently. If a Foundation does not exist, state so for each sub question. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definition: The primary Foundation can be explained as the entity which is 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)
(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).
(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.

(a) Entity

No such entity exists.

(b) IP ownership & control

No such Primary Foundation exist

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

No Primary Foundation or current powers of a Primary Foundation over DAO governance

Governance sits solely with BIFI token holders

(d) Powers over DevCo

No such Primary Foundation exist

(e) Contract/admin powers

No such Primary Foundation exist

(f) Current economic arrangements and distribution policies

A part of all revenue generated by vaults within the Beefy Protocol is directed toward tokenholder Incentive Programmes. Incentives are regularly paid out through the protocol’s BIFI Pool and BIFI Vault, and tokenholders must deposit their BIFI tokens to participate in those programs. The Beefy DAO does not issue BIFI tokens and does not trade in BIFI tokens.

Primary DevCo

For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly across each sub-question. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definition: The primary DevCo can be explained as the entity which is 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)
(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

No such entity exists

(b) IP ownership & control

No such entity exists

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

No such entity exists

Governance sits solely with BIFI token holders

(d) Powers over Foundation

No such entity exists

(e) Contract/admin powers

Pause and upgrade authority is held by Beefy's core developer contributors through a multisig wallet, requiring majority approval from 4 of 7 signers for any action.

(f) Current economic arrangements and distribution policies

Beefy is maintained and further developed by Core Contributors, funded by the protocol treasury through quarterly budgets approved by DAO members.

Token Supply & Allocations

Initial Allocation

Download the Worksheet, enable macros, complete the Initial Allocation sheet, then use Convert To CSV to export the file for import here. To make edits after importing, update the worksheet, use Convert To CSV again, then re-import the new CSV.

Ticker	Date	Allocation Category Name	Recipient Type	Allocation %	Allocation Tokens	Cliff Months	Cliff Unlock %	Linear Vesting Months	Cadence Months	Circulating Treatment
BIFI	9/22/20	Governance Pool 1 (wBNB)	Community	0.175	14000	0	0	2	1	Yes
BIFI	9/22/20	Governance Pool 2 (ETH)	Community	0.175	14000	0	0	2	1	Yes
BIFI	9/22/20	Governance Pool 3 (LINK)	Community	0.175	14000	0	0	2	1	Yes
BIFI	9/22/20	Governance Pool 4 (CREAM)	Community	0.175	14000	0	0	2	1	Yes
BIFI	9/22/20	Governance Pool 5 (BNB-BUSD)	Community	0.1	8000	0	0	2	1	Yes
BIFI	9/22/20	Governance Pool 6 (BNB-SPARTA)	Community	0.1	8000	0	0	2	1	Yes
BIFI	9/22/20	Original Team Timelock 1	Team	0.025	2000	0	1	0	1	Yes
BIFI	9/22/20	Original Team Timelock 2	Team	0.025	2000	3	1	0	1	Yes
BIFI	9/22/20	Original Team Timelock 3	Team	0.025	2000	9	1	0	1	Yes
BIFI	9/22/20	Original Team Timelock 4	Team	0.025	2000	21	1	0	1	Yes

Airdrop Process

State the project's airdrop status plainly, and back it up:

Never conducted and none planned for TGE: state so plainly.
Planned but not yet executed: state the target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to balance or net position), and commit to publishing a recipient wallet list in a public channel and providing it to Blockworks quarterly until the initial TGE airdrop is fully completed.
Already executed: state the covered user segments and the allocation method, and 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.

Never conducted and none planned for TGE

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

If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for (b).

Market Maker Name	Token Allocation Committed	Term Duration	Structure Name
Beefy has no current agreements with Market Makers.

Exchange 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
Beefy has no current agreements with exchanges.

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 Instrument	Date Of Sale	Number of tokens sold	Vesting Schedule
No prior fundraising, OTC, or discounted market-maker sales have occurred. BIFI's entire circulating supply was distributed in September 2020 through a liquidity mining program, with no tokens sold to investors.

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 — Link(s) to post-mortem/advisory/PR.