Beefy Finance

Multichain yield-optimizer / autocompounder (Beefy-class): thousands of automated ERC-20 vaults ('mooTokens') that wrap and autocompound external-protocol LP and staking positions across ~34 EVM chains. Original protocol, not a fork. BIFI governance token (80,000 cap) uses xERC-20 lockbox with four independent third-party bridge adapters (LayerZero, Axelar, Chainlink CCIP, canonical Optimism bridge). Core governance: off-chain Snapshot (beefydao.eth) + dev multisig execution (3-of-6). No on-chain Governor and no standalone governance timelock; vault-level 6-hour strategy-upgrade delay only.

Sector evm_yield

TVL $119.7M

Reviewed May 16, 2026

Factors 184

Categories 13

Risk score 33.1

DeploymentsEthereum · $67.3M

Risk profile at a glance

0 red · 5 yellow · 7 green

25 24 17 13 15 22 16 10 13 12 8 5 4

Categories & evidence

184 factors · 13 categories

Code & audits Yellow 24 25 of 25

RD-F-009 red Formal verification coverage No formal verification engagement found. Certora conducted a CLM 'audit' (2024-06-30) but Certora's SecurityReports portfolio (their FV engagement archive) does not list Beefy Finance, and Certora's blog has no Beefy entry — strongly indicating this was a standard manual audit by Certora staff, not a Certora Prover FV engagement. No FV spec files (.spec) found in beefy-contracts. Zero declared critical invariants covered by FV proof. RD-F-001 yellow Audit scope mismatch No audit report covers BeefyVaultV7 or BeefyVaultV7Factory at their current deployed bytecode. The 2021 CertiK/DefiYield audits predate BeefyVaultV7 architecture entirely. The 2023-2025 audits (Zellic x3, OZ, Cyfrin, Certora, Sherlock, Electisec) cover only specific non-core modules: ERC-4626 wrapper, BIFI xERC-20 token, Zap, CLM strategy suite, beS. Scope gap (no audit of core vault) rather than confirmed bytecode mismatch; scored yellow not red because no audit falsely purports to cover BeefyVaultV7. RD-F-002 yellow Audit recency Most recent audit of any deployed Beefy contract: Electisec beS, April 2025 (~31 days ago) — but covers only the beS liquid-staking module. Most recent audit of core BeefyVaultV7: none (CertiK 2021 predates V7 architecture). Aggregate: yellow because recent audits exist for peripheral modules but the highest-TVL surface (core vault) has no post-2021 coverage. RD-F-003 yellow Resolved-without-proof findings Zellic CLM audit (2024-02-28) found 1 critical (TWAP tick-math), 2 high, 2 medium, 5 low, 1 informational. Profiler context: critical was fixed pre-deployment. Cyfrin CLM audit (2024-04-06) found 1 critical, 1 high, 4 medium including missing TWAP check on owner functions and unlimited router approvals not cleared on update. Resolution not independently verified via on-chain bytecode diff (PDF not accessible). Yellow pending curator verification. RD-F-004 yellow Audit count 8 distinct audit firms across 12 engagements (DefiYield, CertiK x2, Zellic x3, OpenZeppelin, Cyfrin, Certora, Sherlock, Electisec). However, 0 firms cover BeefyVaultV7 (core vault, majority of TVL) at current version. Green on breadth (≥2 firms) but yellow due to zero coverage of highest-TVL surface. RD-F-006 yellow Audit-to-deploy gap Exact audit-to-deploy gap not independently confirmed for 2023-2025 modules. 2021 audits predate V7 architecture entirely (gap irrelevant for current vault). For CLM audits (Feb-Jul 2024), CLM was actively deployed around audit period — likely within 60-day green threshold but unverified. Scored yellow due to inability to confirm deploy timestamps for all audited module releases. RD-F-007 yellow Bug bounty presence & max payout Active Immunefi bug bounty program, max payout $75,000 for critical smart contract vulnerabilities. 244 assets in scope. Live since July 2021. Max payout of $75K is below the $500K green threshold; scored yellow. RD-F-014 yellow Reentrancy guard on external-calling functions BeefyVaultV7.deposit() has nonReentrant. BeefyVaultV7.withdraw() does NOT have nonReentrant despite calling want().safeTransfer() to caller. BeefyVaultV7Native.depositBNB() has nonReentrant; both withdrawal functions lack it. BaseAllToNativeStrat neither deposit() nor withdraw() have reentrancy guard. Pattern risk exists in withdrawal paths; CEI mitigates but is not audited. RD-F-015 yellow ERC-777/1155/721 hook without reentrancy guard BeefyVaultV7 accepts arbitrary ERC-20 as want. If a vault wraps an ERC-777 token, the tokensReceived hook on withdrawal could trigger reentrancy given withdraw() lacks nonReentrant. No specific ERC-777 vault confirmed with live TVL, but architecture permits it. Risk is structural. RD-F-016 yellow Divide-before-multiply pattern Core vault share math uses multiply-before-divide pattern (correct). No divide-before-multiply found in vault source. Cyfrin CLM audit noted token accumulation from rounding during division in CLM strategies — adjacent indicator. Strategy contracts (hundreds) not individually checked via Slither. Yellow pending tool run on strategy layer. RD-F-017 yellow Mixed-decimals math without explicit scaling Vault layer: single-token want, no cross-decimal arithmetic. CLM strategies involve two-token positions (e.g., USDC/WETH) requiring decimal normalization in tick/price math. Zellic CLM critical finding (tick math: multiplicative vs additive TWAP deviation) indicates scaling errors were present in CLM. Core vault: green; CLM strategy: yellow-aggregate. RD-F-023 yellow Constructor calls _disableInitializers() BeefyVaultV7 has no constructor (EIP-1167 clone) — no _disableInitializers() call. BeefyVaultV7Factory constructor deploys `new BeefyVaultV7()` as implementation template without calling _disableInitializers() or initialize() on it. The uninitialized implementation template is a recognized attack surface for cloning patterns. StratFeeManagerInitializable has no constructor and no _disableInitializers(). BaseAllToNativeStrat: same. Yellow — OZ initializer modifier provides first-call lock, but the implementation contract itself can be initialized by any caller (known best-practice violation; mitigated by factory pattern in practice but non-zero risk). RD-F-024 yellow Code complexity vs audit coverage BeefyVaultV7 core vault is ~200 LOC — simple. Strategy base contracts add ~300-500 LOC each. Hundreds of individual strategy implementations across 34 chains. Only CLM strategy suite has multi-firm 2024 audit coverage; core vault and strategy base have had no audit coverage since 2021. The LOC-per-audit-day ratio for the full protocol codebase is very high. Docs confirm no mandatory strategy audit requirement. RD-F-183 yellow Bug bounty scope gap on highest-TVL contracts Immunefi program active with 244 assets in scope. Docs state Beefy 'generally honours the bounty in respect of live operational products' — non-binding language. Scope page accessible content showed only a sample of 12 polygon contracts; BeefyVaultV7 or BeefyVaultV7Factory not explicitly confirmed in/out-of-scope from accessible page content. Max payout $75K is below peer-protocol norms ($150K-$250K) for comparable TVL. Score: yellow — scope appears broad but implicit, payout cap low. RD-F-010 gray Static-analyzer high-severity count No published Slither/Mythril static analysis output found for BeefyVaultV7 or strategy contracts. Tool run not performed in this assessment. MixBytes blog analyzed an older vault architecture and found harvest swap slippage (AmountOutMin=0) and deflationary token handling issues but these are a published secondary source, not a formal static analysis of deployed bytecode. Needs tool run. RD-F-018 gray Signed/unsigned arithmetic confusion Core vault uses uint256 throughout; no signed/unsigned confusion found in source inspection. CLM strategies use int24 ticks (Uniswap v3) requiring careful signed/unsigned handling. Zellic critical finding is adjacent to this. Symbolic analysis not performed. Marked gray pending tool run. RD-F-021 n/a UUPS _authorizeUpgrade correctly permissioned BeefyVaultV7 uses EIP-1167 minimal proxy (clone) pattern via BeefyVaultV7Factory, NOT UUPS. No _authorizeUpgrade() function exists. Factor applies only to UUPS proxy pattern contracts.

RD-F-005 green Audit firm tier Tier-1 firms engaged: Zellic (CLM + ERC-4626 wrapper), OpenZeppelin (Zap), Certora (CLM). At least one Tier-1 audit of deployed code exists (Zellic 2023-08 ERC-4626 wrapper is deployed; Zellic 2024-02 CLM is deployed). Green per methodology threshold (≥1 Tier-1 audit of deployed code).

RD-F-008 green Ignored bounty disclosure No evidence in public post-mortems or OSINT that a bounty-disclosed vulnerability was ignored pre-exploit. Rekt leaderboard shows 0 direct Beefy incidents. 2021 Bunny coding error was a development mistake, not an ignored disclosure.

RD-F-011 green SELFDESTRUCT reachable from non-admin path Source inspection of BeefyVaultV7.sol, BeefyVaultV7Factory.sol, BeefyVaultV7Native.sol, BeefyWrapper.sol, StratFeeManagerInitializable.sol, BaseAllToNativeStrat.sol: no SELFDESTRUCT opcode found. Factory uses ClonesUpgradeable (EIP-1167 clone), not CREATE+selfdestruct pattern.

RD-F-012 green delegatecall with user-controlled target No delegatecall with user-controlled target found in vault contracts. BeefyVaultV7Factory uses ClonesUpgradeable.clone() which delegates to a fixed implementation address (not user-supplied). No Parity-class pattern identified in vault layer.

RD-F-013 green Arbitrary call with user-controlled target No arbitrary external call with user-controlled target+data in vault contracts. BeefyVaultV7 calls only named interfaces (strategy, want token). inCaseTokensGetStuck() calls IERC20(_token).safeTransfer with onlyOwner gate and want-token safety check. No LIFI-class pattern identified.

RD-F-019 green ecrecover zero-address return unchecked No ecrecover usage found in BeefyVaultV7, BeefyVaultV7Factory, or BeefyWrapper source inspection. BIFI token is ERC20Upgradeable (standard OZ 4.9.3) without direct ecrecover calls. LayerZero bridge adapter uses LZ signature framework, not raw ecrecover.

RD-F-020 green EIP-712 domain separator missing chainId No EIP-712 domain separator in vault contracts. BIFI token uses OZ 4.9.3 ERC20 which includes chainId in DOMAIN_SEPARATOR by default when EIP-2612 permit is active. OZ 4.9.3 standard implementation includes chainId. N-A for vault contracts; green for BIFI token.

RD-F-022 green Public initialize() without initializer modifier BeefyVaultV7.initialize() signature: `public initializer`. The OZ initializer modifier locks the function after first call via _initialized flag. BeefyVaultV7Native.initialize() also uses `public initializer`. BeefyWrapper.initialize() uses `external initializer`. No unprotected initialize() found in vault layer. RD-F-022 is green.

Governance & admin Yellow 24 24 of 24

RD-F-041 red Rescue/emergencyWithdraw without timelock CRITICAL: (1) panic() in strategy contracts is callable by owner OR keeper (onlyManager modifier) with NO timelock — immediately withdraws all staked funds from external farm to strategy contract and removes all allowances. (2) inCaseTokensGetStuck(address _token) in BeefyVaultV7 is callable by owner (onlyOwner) with NO timelock — immediately transfers all balance of specified non-want token to owner. The 6h vault-level delay covers only upgradeStrat(), not these rescue paths. Strategy contracts owned by dev multisig (3-of-6) can execute panic immediately; vault contracts also owned by dev multisig can rescue non-want tokens immediately. RD-F-028 yellow Low-threshold multisig vs TVL Dev multisig controlling all vault upgrades across $119.7M TVL is 3-of-6 (50% threshold). While not below the absolute red floor (2-of-3 or lower), 3-of-6 is below peer norm for $100M+ TVL protocols (3-of-5 or 4-of-7 is standard). Three signers could collude or be compromised to control vault upgrades across ~34 chains. Treasury multisig is 4-of-7 (57%) but controls no protocol functions. RD-F-032 yellow Timelock duration on upgrades No standalone protocol-level governance timelock (timelock_address=null in cache). The only delay is a vault-level 6-hour approvalDelay (21,600 seconds) embedded in each BeefyVaultV7 for strategy switches via upgradeStrat(). This vault-level delay is NOT a classical TimelockController. It does not apply to panic(), inCaseTokensGetStuck(), fee config changes, keeper changes, or any non-strategy-switch actions. RD-F-033 yellow Timelock on sensitive actions Strategy upgrades (upgradeStrat): YES, 6h vault-level delay. panic(): NO timelock, immediate by onlyManager. inCaseTokensGetStuck(): NO timelock, immediate by onlyOwner. setKeeper(): NO timelock, immediate by onlyManager. Fee config setters: NO timelock. BIFI token: no admin-callable sensitive functions remain. Multiple sensitive actions lack timelock coverage. RD-F-034 yellow Guardian/pause-keeper distinct from upgrader Strategy contracts define onlyManager = owner OR keeper. Keeper can call panic(), pause(), unpause() and managerHarvest() — the pause/emergency role is partially separate from upgrade role (only owner can upgradeStrat). However, keeper is set by the manager (owner or keeper), so the keeper role is not fully independent. No distinct guardian multisig separate from the dev multisig exists. RD-F-035 yellow Role separation: upgrade ≠ fee ≠ oracle Dev multisig (owner) can set fee config, unirouter, fee recipient, and also upgrade strategies — conflating upgrade and fee configuration authority. The strategist role is distinct (can update own address, receives fees) but the owner controls the rest. Some separation exists between strategist fee collection and upgrade authority, but upgrade and fee-config are held by the same owner. RD-F-038 yellow Proposal execution delay < 24h Snapshot governance results are advisory; execution requires the dev multisig to manually implement. No automated on-chain execution path with enforced delay. The 6-hour vault-level delay applies only to strategy switches. For non-strategy governance outcomes (e.g., fee changes, keeper changes), there is effectively no enforced proposal-to-execution delay — the dev multisig can act immediately. RD-F-040 yellow Emergency-veto multisig present No documented emergency-veto or governance-guardian multisig distinct from the dev multisig. The dev multisig serves as both proposer and executor. No separate guardian contract or emergency-pause DAO found. The keeper role in strategy contracts can panic/pause but is appointed by the dev multisig itself. RD-F-047 yellow Governance token concentration (Gini) BIFI supply is 80,000 tokens total. No formal quorum. Voting power based on held/staked BIFI. Supply historically concentrated (all minted to treasury at deployment, then distributed). No Gini coefficient computed. Effective governance power is concentrated: the dev multisig controls execution regardless of Snapshot outcome, as Core team is the self-declared executive wing. RD-F-167 yellow Deprecated contract paused but pause reversible by live admin Dev multisig retains ownership of deprecated strategy contracts that are paused after vault migrations. Strategy deprecation via retireStrat() is irreversible once called (transfers want tokens to vault). Allowance tool (allowance.beefy.finance) exists to help users revoke stale approvals from deprecated routers — its existence implies acknowledged stale-approval surface on deprecated contracts. Old BIFI token on BSC (0xCa3F508B8e4Dd382eE878A314789373D80A5190A) is deprecated but still on-chain. RD-F-029 gray Multisig signers co-hosted Dev multisig has 6 distinct owner addresses. Signer custody model (hardware vs software wallet, co-hosted infrastructure) cannot be determined from public data. Team is pseudonymous; no public attestation of hardware wallet usage found. RD-F-030 gray Hot-wallet signer flag Cannot determine from public data whether any of the 6 dev multisig signers use hot wallets vs hardware wallets. No on-chain hot-wallet heuristics available without programmatic RPC access to signer transaction history. RD-F-031 gray Signer rotation recency Most recent signer-set change date not determinable without on-chain Safe event enumeration (AddedOwner, RemovedOwner, ChangedThreshold events). Last dev multisig transaction: 2026-04-20. No documented threshold reduction or signer removal found in public research. No DPRK-pattern threshold reduction event identified. RD-F-037 n/a Quorum achievable via single-entity flash loan Snapshot-only governance with no on-chain quorum and no formally adopted quorum. Flash-loan quorum manipulation requires on-chain vote mechanism which does not exist. Factor not applicable to this governance architecture. RD-F-039 n/a delegatecall/call in proposal execution without allowlist No on-chain Governor contract or proposal execution path exists (governor_address=null in cache). Governance is Snapshot off-chain only; execution is direct multisig transactions. No proposal executor contract exists that could use delegatecall with proposal-supplied targets. Factor structurally not applicable. RD-F-044 gray Admin wallet interacts with flagged addresses Would require Chainalysis-style watchlist feed or on-chain hop analysis for all 6 dev multisig signer addresses. Cache contains no OFAC/watchlist flag data. Not assessed. RD-F-045 gray Constructor args match governance proposal BeefyVaultV7Factory deploys EIP-1167 clones permissionlessly (no governance proposal required). Snapshot governance is advisory only — no on-chain constructor-arg encoding in proposals. No formal mechanism exists for individual vault deployments to be specified in a governance proposal. Cannot verify constructor-arg match for thousands of individual vault clones.

RD-F-025 green Admin key custody type Dev multisig 3-of-6 Safe holds all protocol-function authority; Treasury multisig 4-of-7 Safe holds treasury assets only with no protocol function access. Vault-level 6h approvalDelay embedded in BeefyVaultV7 for strategy switches only. No standalone protocol-level governance timelock.

RD-F-026 green Upgrade multisig signer configuration (M/N) Dev multisig: 3-of-6 (0x34fEf5DA92c59d6aC21d0A75ce90B351D0Fb6CE6). Treasury multisig: 4-of-7 (0xc9C61194682a3A5f56BF9Cd5B59EE63028aB6041). Per-chain treasury Safes (Arbitrum, BSC, Optimism, Base, Polygon) all 4-of-7. Thresholds confirmed by data cache Safe API returns (api_status=found for all).

RD-F-027 green Single admin EOA Dev multisig is 3-of-6 Safe (not an EOA). Treasury multisig is 4-of-7 Safe. Deployer EOA 0x4fed5491 transferred ownership to multisigs by September 2021. Dev multisig last transacted 2026-04-20 confirming it is active and controlling protocol functions.

RD-F-036 green Flash-loanable voting weight Governance is Snapshot-only (beefydao.eth) with off-chain voting. No on-chain Governor contract (governor_address=null in cache). Voting power is locked at proposal snapshot block — flash loans cannot influence already-snapshotted votes. Fixed 80,000 BIFI supply with no permissionless minting eliminates flash-loan supply manipulation. Docs confirm voting power is locked from time of posting.

RD-F-042 green Admin has mint() with unlimited max BIFI token has a fixed supply of 80,000 tokens minted entirely at deployment initialization. No post-deployment mint function exists. Docs explicitly state no further ability to mint. xERC-20 bridge minting is within-supply (burns native BIFI for cross-chain representation; no new tokens created). Etherscan confirms contract is verified with no admin mint function callable post-deploy.

RD-F-043 green Admin = deployer EOA after 7 days Deployer EOA 0x4fed5491693007f0cd49f4614ffc38ab6a04b619 (Beefy: Deployer) transferred ownership to multisigs by September 2021, confirmed by documented treasury history. Protocol launched October 2020; multisig transition well beyond 7-day window. Dev multisig 0x34fEf5DA92c59d6aC21d0A75ce90B351D0Fb6CE6 is current admin, last transacted 2026-04-20.

RD-F-046 green Contract unverified on Etherscan/Sourcify Core contracts verified: BIFI token (0xb1f1ee...) confirmed Exact Match verified on Etherscan. Treasury Safe and Dev Safe proxies confirmed as Safe 1.3.0 Singleton (verified bytecode). BeefyVaultV7 and factory source accessible on GitHub and match Etherscan verified source. No unverified core protocol contract found at launch.

Oracle & external dependencies Yellow 38 17 of 17

RD-F-054 red TWAP window duration CLM onlyCalmPeriods: 60-second Uniswap V3 TWAP window — materially below the 30-minute (1800-second) safe threshold and below the red threshold of 10 minutes (600 seconds). 60 seconds = 1 minute. BeefySwapper DEX-TWAP periods: configurable per token with NO minimum period enforced in validateData() — zero or sub-60-second periods are technically acceptable in the contract. RD-F-056 red Single-pool oracle (no medianization) BeefyOracle: each token maps to ONE sub-oracle with no medianization or cross-venue aggregation (source: 'each token maps to one SubOracle containing one oracle address'). CLM: single Uniswap V3 pool's TWAP with no cross-validation. No multi-source aggregation at any level in the BeefyOracle system. RD-F-059 red Oracle staleness check present BeefyOracleChainlink.sol: calls latestAnswer() only — confirmed NO updatedAt check, no staleness validation. BeefyOracleChainlinkEthBase.sol: same — latestAnswer() without updatedAt comparison. BeefyOraclePyth.sol: calls getPriceUnsafe() which explicitly skips freshness validation. This is a systemic gap across all Chainlink and Pyth adapters — stale prices can be accepted. DEX-TWAP adapters (UniV2/V3/Solidly/Algebra) are inherently time-based but have no max-staleness check on the observation data itself. RD-F-049 yellow Oracle role per asset BeefyOracle maps each token to a single SubOracle — one oracle per token, no primary/secondary/fallback distinction. CLM uses single Uniswap V3 pool TWAP as sole calm-period oracle. No multi-oracle per-asset design anywhere in the system. RD-F-050 yellow Dependency graph (protocols depended upon) Dominant dependency: each vault wraps one external protocol (hundreds across ~34 chains: Aave, Curve, Balancer, Uniswap v3, Compound, Convex, PancakeSwap, etc.). Failure of any wrapped protocol impairs that vault but not others — diffuse aggregate risk with isolation by design. BeefySwapper depends on BeefyOracle sub-providers. BIFI token depends on four bridge adapters and XERC20Lockbox. Dependency graph is architecturally sound in isolation design but scale (hundreds of protocols) creates aggregate exposure. Yellow because at least one confirmed upstream failure causing partial user impact (Sonne Finance 2024). RD-F-051 yellow Fallback behavior on oracle failure BeefyOracle uses single sub-oracle per token with no fallback — if sub-oracle fails (success=false), stale price remains. BeefySwapper returns (0, false) on price failure with no documented secondary source fallback. CLM reverts deposits if TWAP unavailable (fail-safe behavior). No secondary oracle configured for any asset in the system. Yellow because CLM has fail-safe revert (better than accepting bad data) but no positive fallback. RD-F-052 yellow Breakage analysis per dependency Partial breakage analysis available: CLM TWAP manipulation risk documented (deposits revert on manipulation; Zellic critical tick-math finding was fixed pre-deployment). BeefySwapper oracle stale price risk: harvest quality degrades but vault principal unaffected. Wrapped protocol failure: vault-specific panic() available; documented in SAFU practices. BIFI bridge adapter failure: other three paths remain. Full enumeration of all wrapped protocols not available without programmatic sweep. Yellow because major dependencies are covered but not exhaustive. RD-F-053 yellow Oracle source = spot DEX pool (no TWAP) [★ CRITICAL] Core vaults use NO oracle — no spot DEX exposure for share pricing. BeefySwapper uses DEX-TWAP adapters (UniV2 TWAP, UniV3 TWAP, Solidly TWAP, Algebra TWAP) with TWAP present but NO minimum period enforced in validateData(). CLM uses 60-second Uniswap V3 TWAP for onlyCalmPeriods — below 30-minute safe threshold but not zero-TWAP spot. Chainlink and Pyth adapters available as alternatives. Yellow not red because TWAP is present (not raw spot), but 60-second window is materially short. RD-F-057 yellow Circuit breaker on price deviation BeefySwapper: no circuit breaker on oracle price deviation — no maxDeviation check in BeefySwapper or BeefyOracle adapters. CLM's onlyCalmPeriods modifier acts as a circuit breaker specifically for deposits when current tick deviates from 60-second TWAP — partial mitigant for CLM product only. No protocol-wide circuit breaker. Yellow because CLM does implement a partial deviation-based guard. RD-F-060 yellow Chainlink aggregator min/max bound misconfig BeefyOracleChainlink.sol and BeefyOracleChainlinkEthBase.sol both use latestAnswer() — the adapter code adds no min/max bounds check on top of the Chainlink aggregator's own bounds. The 19 Chainlink feeds in the data cache (ETH/USD heartbeat 3600s 0.5%, BTC/USD 3600s 0.5%, etc.) appear to be legitimate established Chainlink mainnet feeds with standard parameters, but Beefy's adapter layer does not verify minAnswer/maxAnswer. Yellow because the underlying Chainlink aggregators themselves have their own bounds, but the Beefy code provides no additional protection. RD-F-055 gray Oracle pool depth (USD) CLM positions deployed across hundreds of Uniswap V3 pools on ~34 chains. Pool depths vary widely by deployment and cannot be assessed at protocol level without a programmatic on-chain sweep. No systematic pool-depth floor check in the BeefyOracle system or CLM deployment process. Assessment gap is structural — not assessable via WebFetch for a protocol with this many pool interactions. RD-F-058 gray Max-deviation threshold (bps) CLM calm threshold bps value not publicly documented. BeefySwapper slippage is a per-swap parameter, not a deviation circuit breaker with a specific bps value. No publicly accessible deviation threshold for BeefyOracle adapters. Cannot determine bps values without reading the CLM contract state or audit findings directly. RD-F-181 n/a Permissionless-pool lending oracle Beefy Finance is a yield optimizer/autocompounder — not a lending protocol. Factor RD-F-181 defines 'lending protocol accepts spot prices from a DEX where any user can permissionlessly create new pools.' No borrow/lend functionality in Beefy. The Rhea Finance class attack (fake pool oracle for lending) has no equivalent attack surface in Beefy's architecture.

RD-F-048 green Oracle providers used Core vaults (BeefyVaultV7) use no price oracle — share pricing is balance()/totalSupply() ratio only, confirmed by source inspection and docs ('Beefy's contracts do not use external oracles'). BeefySwapper uses the BeefyOracle system (configurable sub-oracle per token: Chainlink, Pyth, UniV3 TWAP, UniV2 TWAP, Solidly TWAP, Algebra TWAP, FixedOracle). CLM uses Uniswap V3 60-second TWAP for onlyCalmPeriods deposit guard. Multiple established oracle providers accessible though quality varies by adapter.

RD-F-061 green LP token balanceOf used for pricing BeefyVaultV7 uses balance() = strategy.balanceOf() + token.balanceOf(strategy) for share pricing. This is the actual underlying asset balance (LP tokens/want tokens held by strategy), not a derived price from balanceOf of an LP token for price manipulation. The share price reflects real holdings, not a manipulable market price derived from token balances. Not the donation-manipulation pattern.

RD-F-062 green External keeper/relayer not redundant Beefy strategies include a keeper address for harvest/panic but harvest is functionally permissionless — anyone can call harvest() in many strategy implementations. Dev multisig can also panic vaults. StrategyFactory configures keeper as a single address but the system does not halt if keeper is unavailable; permissionless harvest prevents single-keeper dependency. The panic() fallback (withdraws from farm to strategy) provides emergency redundancy even if keeper fails.

RD-F-180 green Immutable oracle address [★ CRITICAL — graded GREEN] BeefySwapper stores oracle as IBeefyOracle public oracle (regular state variable, not immutable); configurable via setOracle(address _oracle) external onlyOwner with no timelock. BeefyOracle.sol per-token oracle assignments also configurable via setOracle(address _token, address _oracle, bytes calldata _data) external onlyOwner. No immutable keyword on any oracle address variable. Admin (dev multisig 3-of-6 per profile §6) can update oracle configurations without delay. Beefy is not a lending protocol so the depeg-immutable-oracle scenario is not the primary risk context, but the mechanism for oracle address replacement exists and functions. Counted as ★ per T-14 promotion.

Economic risk Yellow 22 13 of 13

RD-F-063 green TVL (current + 30d trend) TVL $119.7M as of 2026-05-16 (DefiLlama API + data cache). 30-day change -15.95%; 90-day CoV 0.057 (low volatility). Current value is 14% below 90-day mean of $139.2M; downward trend consistent with broad DeFi TVL compression. No acute withdrawal event in 90-day daily series. Crosses coverage threshold (>$100M current). All-time peak ~$1.09B (2021-10). Protocol TVL is real and well-supported by data.

Operational history Green 18 15 of 15

RD-F-081 yellow Post-exploit response score No direct Beefy exploit occurred, but the May 2024 Sonne Finance upstream exploit is the primary analog: some Beefy Optimism vault users suffered partial losses when Sonne Finance was drained for $20M. Response quality: (1) Speed — Beefy paused 9 Sonne-dependent vaults 'within minutes,' which is rapid; however Optimism vaults partially drained before the pause was executed, resulting in user losses despite the speed. (2) Transparency — Beefy communicated via X post on the day of the incident; no structured post-mortem from Beefy's perspective was published. Sonne published its own post-mortem. (3) Compensation — Beefy directed affected users to monitor Sonne's recovery process; Beefy treasury did not top up partial losses for the 2024 event. (4) Re-audit — not triggered for Beefy contracts (root cause was in Sonne's contracts). Overall response quality ~3/5: rapid operational action, weak post-mortem depth from Beefy's own perspective, no direct user compensation for losses. Yellow. Hi RD-F-082 yellow Post-mortem published within 30 days For the BUNNY internal coding error (2021-04-22): a structured post-mortem was published the same week on Medium — green for that event. For the Sonne Finance upstream exposure (2024-05-15): Beefy published only an X thread (brief announcement), not a structured post-mortem with root cause, affected contracts, timeline, and remediation. Sonne Finance published its own post-mortem but Beefy did not supplement it with a Beefy-perspective post-mortem. Yellow — the most recent event with partial user impact lacks a 30-day structured post-mortem from Beefy. RD-F-085 yellow Incident response time (minutes) For the 2020-11-03 PancakeSwap incident: response timeline is documented — PancakeSwap announcement at 13:07 UTC, Beefy vault pause at 14:04 UTC (~57 minutes), rescue contract live at 17:38 UTC (~271 minutes). For the 2024-05-15 Sonne Finance event: Beefy describes response as 'within minutes' but no exact on-chain pause transaction timestamp with minute-level precision is published in available sources. [?] Exact on-chain pause tx timestamp for Sonne vaults not confirmed. The fact that Optimism vault users suffered partial losses despite the rapid response suggests the effective response window was insufficient to fully protect all users. Yellow — fast response in both cases but incomplete documentation of the 2024 event and confirmed partial user losses despite speed. RD-F-087 yellow Pause > 7 consecutive days The Balancer V2 product suspension (November 2024) resulted in an extended pause of Beefy's Balancer V2 integrations. Balancer Labs shut down following the ~$137M exploit, meaning Beefy's Balancer V2 vault suspension is effectively permanent. This is a pause exceeding 7 consecutive days within the trailing 12-month window (Balancer exploit Nov 2024 is within 12 months of the 2026-05-16 assessment date). The extended pause is a protective response to upstream protocol failure, not a Beefy operational failure — context matters. Yellow rather than red because the suspension is proactive risk management, not a Beefy malfunction. RD-F-089 yellow Insurance coverage active Nexus Mutual provides protocol cover for Beefy across multiple chains, and Beefy's own docs link to the insurance page. Multiple Nexus Mutual claims have been processed with $5M payout approvals per Nexus Mutual reports. However, the insurance is user-purchased (individuals buy cover, not Beefy as a protocol backstop). Current Beefy TVL is $119.7M; no single insurance contract covers the full TVL. No Sherlock protocol-level cover confirmed for Beefy. Yellow — insurance coverage exists at the individual-user level via Nexus Mutual but is not protocol-funded and does not proportionally cover protocol TVL. RD-F-166 yellow Deprecated contracts still holding value The original BSC BIFI token (0xCa3F508B8e4Dd382eE878A314789373D80A5190A) and the pre-migration Ethereum BIFI token (0x5870700f1272a1adbb87c3140bd770880a95e55d) are officially deprecated per BIP-71 (September 2023 BIFI Migration Plan) but remain live and circulating on-chain. BSCscan shows ~$249.82 per token with active trading. The deprecated contracts are governance tokens, not vault contracts; they hold no privileged Beefy admin functions and no user deposit TVL. The residual risk is: (a) users who did not migrate still hold the old token and (b) the old token may create confusion or be subject to deprecated-contract attack vectors. Yellow — deprecated surface with residual material circulating value, but the risk profile is limited (no admin key, no vault TVL, no rescue function in the deprecated tokens). RD-F-078 n/a Chronic-exploit flag (≥3 incidents) Chronic flag requires ≥ 3 direct protocol exploits. Beefy has 0 direct exploits in its history; threshold is unreachable by definition. Factor scores not_applicable. RD-F-079 n/a Same-root-cause repeat exploit Same-root-cause repeat exploit requires ≥ 2 incidents with the same root cause cluster. Beefy has 0 direct exploits; the factor cannot apply. RD-F-080 n/a Days since last exploit Days-since-last-exploit metric requires at least one prior exploit to compute. Beefy has experienced 0 direct exploits; this factor produces no meaningful value. RD-F-083 n/a Auditor re-engaged after last exploit This factor asks whether an auditor was re-engaged after the last exploit. Beefy has no direct exploits in its history. The Sonne Finance 2024 event was an upstream protocol exploit in Sonne's contracts; Beefy's response was operational (vault suspension), and no re-audit of Beefy's contracts was required. Factor is not_applicable: no Beefy-native exploit occurred that would trigger a re-audit obligation.

RD-F-076 green Protocol age (days) Beefy Finance first vaults went live on BNB Chain on 2020-10-08. As of 2026-05-16 the protocol has been live for approximately 2,047 days (~67 months), well above any 12-month A-grade live-time threshold. Active development continues with the most recent audit in April 2025.

RD-F-077 green Prior exploit count Zero direct Beefy-native exploits confirmed across 67 months of operation. Hacksdatabase grep for 'beefy' and 'bifi' returned only grim-finance.md (a Beefy fork, not Beefy itself) and steadefi-rekt.md (Beefy mentioned as peer only). Rekt leaderboard returns 0 incidents (00-data-cache.json rekt.incidents = []). Five adjacent events documented in profile §10 involved upstream protocol failures or protective defensive actions by Beefy; none constitute a direct Beefy contract exploit. The 2021-04-22 BUNNY coding error was an internal operational failure (not an external exploit attack) fully resolved with user compensation.

RD-F-084 green TVL stability (CoV over 90d) TVL coefficient of variation (σ/μ) over trailing 90 days = 0.057 per 00-data-cache.json tvl_cov_90d. This is a low-volatility reading indicating stable depositor behavior despite a directional downward trend (−15.95% 30-day change). The 90-day mean is $139.2M vs. current $119.7M. The low CoV reflects orderly TVL compression, not panic exits. Green (CoV well below 0.15 yellow threshold).

RD-F-086 green Pause activations (trailing 12 months) Beefy has activated its pause/emergency mechanisms multiple times across its history, each in response to upstream threats rather than Beefy malfunctions. In the trailing 12 months (May 2025–May 2026), the Balancer V2 product suspension (November 2024) is within scope. Beefy's vault-level panic() function and dev-multisig-controlled pause are documented in SAFU practices and contracts-and-timelocks docs. The pattern of protective pauses demonstrates a functioning and repeatedly-tested emergency mechanism. Green.

RD-F-088 green Re-deployed to new addresses in last year No evidence of a full Beefy core-protocol redeploy to new contract addresses in the trailing 12 months (May 2025–May 2026). The BIFI token migration (September 2023) is outside the 12-month window. Beefy's normal operation involves deploying new vault+strategy contract pairs continuously (that is the product design), but no wholesale TVL migration to a new address set occurred in the window. Green.

Real-time signals Green 2 22 of 22

RD-F-103 yellow Bridge signer-set change proposed/executed T-09 v1 production signal (tier-A). BIFI xERC-20 uses four bridge adapters: LayerZero OApp (0xdddaEc9c267dF24aD66Edc3B2cBe25dB86422051, deployed ~2023-10-21 by Beefy Deployer), Axelar, Chainlink CCIP, canonical Optimism bridge. No signer-set change event detected on any adapter at assessment date. Yellow because: (1) LayerZero DVN configuration is unresolved — data-cache shows dvn_configs:[] as a FALSE NEGATIVE; the actual DVN threshold could be 1-of-1 (catastrophic, Kelp DAO class) and this cannot be confirmed or denied from available public data; (2) Axelar and CCIP adapter addresses not resolved. The signal is applicable and production-live; current quiescence is assessed but full bridge security posture is unverified. RD-F-090 gray Mixer withdrawal → protocol interaction T-09 phase-2 advisory-only signal (tier-C). Beefy vaults are permissionless — any wallet including mixer-funded wallets can interact. No licensed attribution feed (Chainalysis/TRM) available for static assessment. Public Etherscan data does not surface labeled Tornado Cash addresses in core contract top-interactors, but a full 30-day lookback mixer-attribution scan requires production TI feed. Cannot confirm or deny without licensed feed. RD-F-096 gray New ERC-20 approval to unverified contract from whale T-09 phase-2 signal. User-level signal — requires monitoring of top-TVL depositor wallets for new ERC-20 approvals to unverified contracts. Not assessable in static posture without live user-wallet monitoring. Beefy's vault share model (mooTokens, deposit/withdraw pattern) differs from standard approval-based DeFi interactions, limiting the signal's applicability, but it cannot be ruled out. Pipeline gap: no user-level approval monitoring implemented. RD-F-101 n/a Large governance proposal queued T-09 v1 production signal (tier-B). Signal requires on-chain ProposalCreated/ProposalQueued events on a tracked Governor contract. Beefy has no on-chain Governor (governor_address: null; governance type: snapshot_only per data-cache). Governance is purely Snapshot-based; all execution goes through the dev multisig (3-of-6) manually. There is no on-chain proposal queue to monitor. The malicious-pattern sub-checks (flash-loanable quorum, delegatecall in calldata, role-change selectors via Governor calldata) are all architecturally moot. RD-F-107 gray Admin EOA signing from new geography/device T-09 phase-2 signal. Requires off-chain signing telemetry (MPC session data, device fingerprint from hardware signing) that is not publicly accessible. Cannot assess admin EOA signing geography/device consistency from public OSINT. Beefy dev multisig is a Gnosis Safe — signing can be done from any device without leaving a public device fingerprint. Assessment is structurally not possible without access to signing infrastructure telemetry. RD-F-109 gray Social-media impersonation scam spike T-09 phase-2 signal. Beefy is a recognized brand ($119.7M TVL, 5.6 years operational) — social-media impersonation is a persistent background risk for any recognized DeFi brand. No specific scam-spike event found in public OSINT at assessment date. Systematic assessment requires a social-listening feed monitoring Discord/Telegram/X for account impersonation spikes. Production pipeline gap. RD-F-110 n/a Unusual pending/executed proposal ratio T-09 phase-2 signal. Signal requires an on-chain pending/executed governance proposal ratio derived from on-chain Governor events. Beefy uses Snapshot-only governance (no on-chain Governor, governor_address: null per data-cache). There is no on-chain pending/executed proposal event stream for Beefy. Signal is architecturally not applicable for Snapshot-only governance.

RD-F-091 green Partial-drain test transactions T-09 phase-2 signal. No partial-drain test transaction pattern detected on Beefy core vault contracts in available public records. Beefy's distributed architecture (thousands of vaults, chain-local TVL) makes a coordinated pre-drain probe pattern distinctive if it occurred. Beefy's demonstrated defensive-pause monitoring capability (Sonne 2024, Balancer V2 2025) suggests pre-drain probes would be identified internally.

RD-F-092 green Unusual mempool pattern from deployer wallet T-09 phase-2 signal. Deployer wallet 0x4fed5491693007f0cd49f4614ffc38ab6a04b619 (Etherscan label: Beefy: Deployer) shows no anomalous deployment sequence or unusual approval patterns in publicly observable data. Baseline mempool pattern not established (requires production monitoring). No public evidence of unusual deployer activity at assessment date.

RD-F-093 green Abnormal gas-price willingness from attacker wallet T-09 phase-2 signal. No attacker-wallet-level abnormal gas premium detected on Beefy contract interactions at assessment date. No known MEV-race pattern targeting Beefy vault contracts. Signal requires production mempool monitoring with 5x EMA baseline comparison — not available in static assessment, but no current public evidence of this pattern.

RD-F-094 green New contract with similar bytecode to exploit template T-09 phase-2 signal. No exploit-template-resembling bytecode known to target BeefyVaultV7 architecture. Beefy is an original protocol (not a fork of Compound or Aave), so standard fork-targeting exploit templates do not apply. The CLM TWAP critical finding (Zellic 2024-02-28) was fixed pre-deployment; no active exploit template derived from it is known.

RD-F-095 green Known-exploit function-selector replay T-09 phase-2 signal. No known exploit replay template exists for the specific Beefy vault architecture (BeefyVaultV7, original design). Rekt leaderboard returns 0 direct Beefy incidents (data-cache rekt.incidents=[]) meaning no historical exploit with a replayable selector pattern exists for this protocol.

RD-F-097 green Sybil surge of identical-pattern transactions T-09 phase-2 signal. No sybil surge pattern (multiple identical-pattern transactions from coordinated new EOAs) observed in publicly available data for Beefy vault contracts. Permissionless vault architecture is theoretically susceptible but no current evidence of active sybil coordination.

RD-F-098 green TVL anomaly — % drop in <1h T-09 v1 production signal (tier-A, instant grade flip). Threshold: TVL_now / TVL_baseline_30d < 0.70 over 60-minute window. Current TVL $119.7M; 30d change -15.95% is gradual and sector-correlated (broad DeFi compression Q1-Q2 2026), not an intra-hour anomaly. 90d CoV = 0.057 (low volatility). No rapid drain pattern. Beefy's distributed vault architecture (thousands of vaults, chain-local TVL) means a single-point drain is structurally harder to achieve than for concentrated protocol TVL. Signal would not fire today.

RD-F-099 green Oracle price deviation >X% from secondary T-09 phase-2 signal. Beefy core vaults use no price oracle for share accounting (internal totalSupply/balance model). CLM module uses a TWAP tick comparison (onlyCalmPeriods) as a manipulation guard, not a price-critical oracle. No oracle deviation against a secondary source is meaningful for core Beefy vault TVL. Individual strategy contracts may consume Chainlink feeds for harvest slippage protection, but these are not protocol-state-critical reads (no liquidation, no borrow). Signal is architecturally of very limited applicability at the Beefy protocol level. No oracle deviation detected on any associated Chainlink feed at assessment date.

RD-F-100 green Flash loan >$10M targeting protocol tokens T-09 phase-2 signal. Beefy uses Snapshot-only governance with no on-chain Governor contract (governor_address: null per data-cache). Flash-loan quorum manipulation is architecturally impossible — no on-chain quorum threshold exists. Flash loans could still be used against individual wrapped external protocols (e.g., Curve), but that is a Cat 3 dependency risk, not a Beefy-protocol signal. No flash loan targeting Beefy vault contracts or governance detected at assessment date.

RD-F-102 green Admin/upgrade transaction in mempool T-09 phase-2 signal (tier-B). Dev multisig (3-of-6, 0x34fEf5DA92c59d6ac21d0a75ce90b351D0Fb6CE6) executes admin/upgrade txs via Gnosis Safe execTransaction — these would appear in the mempool. There is no protocol-level timelock (timelock_address: null per data-cache), so any admin tx from the multisig could execute without a pre-queued delay. No anomalous admin or upgrade transactions detected in publicly observable data at assessment date.

RD-F-104 green Stablecoin depeg >2% on shared-LP venue T-09 v1 production signal (tier-B). Beefy vaults wrap external protocols with stablecoin LP positions. At 2026-05-16: USDC approximately $1.0001 (within 0.01% of peg), USDT approximately $0.9996 (within 0.04%), DAI approximately $1.0002. No stablecoin depeg above 2% observed. Signal threshold (>2% depeg sustained 30+ min AND protocol exposure >=5% TVL) not met. Beefy's diffuse stablecoin exposure across hundreds of vaults means no single stablecoin depeg would necessarily breach the 5% TVL threshold.

RD-F-105 green DNS/CDN/frontend hash drift T-09 phase-2 signal (tier-A). Primary frontends: app.beefy.finance and beefy.finance. No documented DNS hijack, CDN compromise, or frontend hash drift in 2024-2026 public records. Scamadviser returns no suspicious flags for beefy.finance. No baseline JS bundle hash has been established by the production pipeline (pipeline gap noted separately). At assessment date no anomaly detected. Note: frontend hash baseline must be established before production signal can be made operational.

RD-F-106 green Cross-chain bridge unverified mint pattern T-09 phase-2 signal. BIFI xERC-20 uses a lockbox model (native BIFI locked in Ethereum lockbox before minting on destination) plus LayerZero DVN verification. BIFI has a hard supply cap of 80,000 tokens — an unverified mint would be detectable by supply comparison. No unverified cross-chain mint pattern detected in available public data. Rekt incidents = 0 for direct Beefy exploits.

RD-F-108 green GitHub force-push to sensitive branch T-09 phase-2 signal. beefyfinance/beefy-contracts is a public GitHub repository. No force-push or unauthorized sensitive-branch push detected in available public GitHub data at assessment date. Data-cache coverage_flag github_private: true may be inaccurate for the main beefy-contracts repo (it is public per profile §9). No anomalous repository events detected via web search.

RD-F-182 green Security-Council threshold reduction (RT) Batch-24 Cat 6B RT signal (T-09 v1.1 candidate). Threshold: Security-Council-equivalent multisig threshold reduction (e.g., 3-of-6 to 2-of-6) or timelock removal within 14 days. Beefy dev multisig current state: 3-of-6 (confirmed per data-cache safe_multisigs[1] threshold=3, owner_count=6; verified against docs.beefy.finance/safety/contracts-and-timelocks). Treasury multisig: 4-of-7. No threshold reduction event detected on any of the six Safe instances (Ethereum dev, Ethereum treasury, Arbitrum, BSC, Optimism, Base, Polygon) at assessment date. Beefy has no protocol-level timelock (timelock_address: null), so any future threshold reduction would be uninhibited in effect — this makes the signal especially load-bearing for Beefy. Drift precedent (3/5 to 2/5 reduction + timelock removal 6 days before $285M exploit) is the reference case. Current posture: stable; no reduction observed.

Dev identity & insider risk Green 13 16 of 16

RD-F-111 yellow Team doxx status Predominantly pseudonymous team. Core developers (Weso, roman-monk, kexleyBeefy, DefiDebauchery) operate under consistent pseudonyms with multi-year track records. One contributor (Jack Gale / jackgale.eth) is fully doxxed with real name, employer (Staworth Ltd; Walker Morris LLP solicitor), and location (Teesside, UK) confirmed across GitHub bio and LinkedIn. Beefy's own documentation explicitly states dev multisig signers are 'not doxxed or identity checked.' Classification: consistent-pseudonym-with-track-record for named public contributors; pseudonym-no-track-record for founding multisig signers. RD-F-112 yellow Team public accountability surface Public accountability surface is uneven across contributors. Jack Gale: high surface — LinkedIn profile (solicitor, Staworth director, KPK contributor), GitHub bio with real name/employer, Mirror.xyz articles, active X account (@iamjackgale), conference attendance. Weso: medium surface — 5+ year consistent handle, conference speaker (Blockchain Futurist Conference 2022), multiple podcast appearances, well-known in DeFi community. Roman-monk, kexleyBeefy: GitHub-only trail with @beefyfinance org membership, no LinkedIn or conference presence found. Multisig signers: zero public accountability surface per explicit Beefy policy. Overall accountability surface is partial — strong for one contributor, moderate for one, minimal for remaining team. RD-F-117 yellow ENS/NameStone identity bound to deployer ENS binding on the protocol deployer (0x4fED5491...) is inconclusive from available tools — ENS domain lookup page references the address but the actual reverse record name could not be confirmed. One core contributor (Jack Gale) has strong ENS binding: jackgale.eth resolves to a verifiable public identity (GitHub bio, LinkedIn, Mirror.xyz) — but Jack Gale is a contributor, not the protocol deployer. The protocol deployer itself does not have a publicly confirmed ENS reverse record linking to a verifiable identity based on available OSINT evidence. Score: Yellow — partial ENS binding at contributor level; deployer ENS binding not confirmed. RD-F-121 yellow Contributor OSINT depth score Curator OSINT depth scores per identified contributor: Jack Gale 4/5 (LinkedIn with employer history, GitHub real name + employer bio, ENS jackgale.eth, Mirror.xyz articles, active X); Weso 3/5 (consistent 5-year handle, conference appearances, podcast track record, no real name/employer found); roman-monk 2/5 (GitHub history with @beefyfinance membership only); kexleyBeefy 2/5 (GitHub + sustained commits); DefiDebauchery 2/5 (GitHub + X/@DefiDebauchery). Average across identified named contributors: 2.6/5. Dev multisig signer group: effectively 1/5 (zero public trail per policy). Composite score: Yellow given the average is below 3/5 and the signing authority is non-assessed. RD-F-123 yellow Sudden admin-rescue/ACL change without discussion Historical evidence: The 2021 Bunny vault coding error recovery involved an emergency admin action (strategy upgrade via dev multisig) executed without a documented prior GitHub issue, PR, or formal governance discussion. The Medium post-mortem ('funds recovery successful closure') describes a reactive '5 page recovery plan' deployed under time pressure with no mention of preceding community governance discussion. This is the canonical admin-rescue-without-discussion pattern that RD-F-123 targets. HOWEVER, mitigating factors: (1) The 3-of-6 dev multisig requires 3 independent signers for any admin action — not a single-EOA unilateral change; (2) Current 2023-2026 commit history shows no ownership-transfer or ACL-change commits without PR context; (3) GitHub issues search for 'admin OR ACL OR ownership OR rescue' in beefy-contracts returns 0 matches; (4) The 180-day window (Nov 2025 – May 2026) shows no unannounced admin rescue in commit history; (5) The team publicly disclosed the 2021 RD-F-119 gray Commit timezone consistent with stated geography GitHub API returns commit timestamps in UTC (stripped of local timezone offsets per GitHub documented behavior). The observed commit hour distribution (07:00-23:00 UTC) across the 26 recent beefy-contracts commits is a 16-hour window too wide to support any geographic inference. Beefy has not publicly stated a team geography. Raw git-log output with author timezone offsets would be needed for this factor — not obtainable via WebFetch. Factor cannot be assessed reliably with available tooling. RD-F-122 gray Contributor paid to DPRK-cluster wallet Contributor wallet addresses are not publicly mapped to team member pseudonyms. Contributors are likely compensated via treasury multisig Safe transactions, off-chain payroll, or BIFI token distributions — none of which are individually traceable to contributor wallets without internal access. The deployer funding chain (3-hop Etherscan trace) shows no DPRK-labeled cluster. F122 is M-only OSINT by definition and cannot be assessed for protocols with off-chain payroll and undisclosed contributor wallet addresses. RD-F-184 gray Real-capital social-engineering persona Factor requires a curator-flagged 'team contributor' or 'external integrator' persona with documented >=1M USD attributed real-capital deposits to the target protocol or peer protocols used to build credibility ahead of a social-engineering attack (Drift/UNC4736 reference pattern: 6-month conference and in-person build-up, real capital deposited). No such pattern has been flagged for any Beefy contributor or integrator in any public source. Factor is M-only OSINT, P1 priority. Per process-learnings: 'F184 — mark GRAY + note the Drift comparator as the reference pattern. Don't spend time trying to confirm absence of something that by design leaves no public trace.' No curator flag exists for this protocol.

RD-F-113 green Team other-protocol involvement history No prior rug or exit-scam affiliation found for any identified Beefy team member. Weso and founding team launched Beefy in October 2020 as their first notable DeFi protocol per docs. Jack Gale also contributes to KPK (formerly Karpatkey), a reputable on-chain asset manager — positive signal. RugDoc assessed Beefy as Grey risk (standard vault product risk, not a rug risk indicator). Web search across multiple rug/exit-scam query combinations returned no adverse team-member history. Rekt.news returns zero direct Beefy Finance exploit entries. Grim Finance ($30M exploit, December 2021) was a Beefy fork — not counted as a Beefy team incident.

RD-F-114 green Deployer address prior on-chain history Deployer 0x4fED5491693007f0CD49f4614FFC38Ab6A04B619 has 1,930 transactions consistent with multi-year active deployment operations. Transaction types include vault clones, strategy creation, and ownership transfers to multisig — a normal developer deployment pattern. No prior-rug-linked contracts appear in Etherscan label or public record. Address is labeled 'Beefy: Deployer' on Etherscan. Funding chain traces to August 2020 unlabeled wallets consistent with project origin. No adverse prior on-chain history identified.

RD-F-115 green Prior rug/exit-scam affiliation No prior rug or exit-scam affiliation for any identifiable team member found across multiple OSINT searches. RugDoc: Grey risk classification (standard vault risk class, not a rug risk signal). Rekt.news: zero direct Beefy Finance exploit entries (data cache rekt.incidents = []). Scamadviser: 'very likely not a scam but legit and reliable' for app.beefy.finance. No named team member (Weso, roman-monk, kexleyBeefy, DefiDebauchery, Jack Gale) linked to a prior rug-labeled protocol in any indexed source.

RD-F-116 green Contributor tenure at admin-permissioned PR Most recent admin-permissioned commits to beefy-contracts are by roman-monk (Apr 27, 2026 — 'Add path decoding'; sustained committer through 2024-2026 with @beefyfinance org membership and 13 Beefy-related repos reflecting multi-year tenure). kexleyBeefy PR #198 (BeefyFeeConfigurator, merged Aug 2, 2022) was authored by a long-standing contributor (kexleyBeefy has @beefyfinance org membership and sustained commit history). No new contributor with < 30-day tenure authored a recent admin-permissioned PR.

RD-F-118 green Handle reuse across failed/rugged projects No evidence found of any core team handle (weso / wesobeefy, roman-monk, kexleyBeefy, DefiDebauchery, jackgale.eth / iamjackgale, ReflectiveChimp, Pablo) being previously associated with a failed or rugged project under a different alias. Web searches return only Beefy Finance-associated results for all identified handles. No cross-alias rug pattern identified.

RD-F-120 green Video-off/voice-consistency flag Weso has appeared in public video content: conference talk at Blockchain Futurist Conference 2022 ('DeFi is not SAFU, and it's your fault') is publicly indexed on YouTube. CoinMarketCap Capital conference speaker listing exists. Multiple podcast appearances (ApeTV, Apple Podcasts, Spotify) are publicly indexed with Weso identified as speaker. No documented video-off, voice-inconsistency, or timezone-inconsistency flag appears in any public source. Jack Gale maintains active public X/Twitter engagement. Marking green for absence of adverse signals — no curator-observed inconsistency on record.

RD-F-124 green Deployer wallet mixer-funded within 30 days 30-day window analysis on Ethereum deployer 0x4fED5491693007f0CD49f4614FFC38Ab6A04B619: 'Funded By' label points to 0x010dA5FF62b6e45f89fa7b2d8ced5a8b5754eC1b approximately 3 years 193 days ago (circa January 2021). The deployer's first known Ethereum mainnet contract deployments (BIFI xERC-20 lockbox October 2023, LayerZero bridge October 2023) mean the 30-day pre-deploy window is October 2023 — the January 2021 funding predates this by over 2 years, outside the 30-day window entirely. For the BSC-origin deployment (October 2020), the funding chain (0x010dA5FF → 0x65685579, first tx August 2020) shows no mixer labels; 0x65685579 has 2 transactions total, first in August 2020, with no Tornado Cash or Railgun interaction label on Etherscan. No mixer label appears at 1-hop or 2-hop in the funding chain. Web search 'Beefy Finance deployer Tornado Cash mixer' returns no adverse results.

RD-F-125 green Deployer linked within 3 hops to DPRK/Lazarus No OFAC SDN designation found for any Beefy team address or the deployer's funding chain. Web search 'Beefy Finance team DPRK Lazarus North Korea sanctioned' returned zero adverse results — results cover general DPRK/Lazarus information with no Beefy mention. No Chainalysis-published report links any Beefy address to a DPRK-labeled cluster. Arkham returned 403 (no access). Deployer funding chain 2-hop trace shows only unlabeled August-2020 wallets with minimal DeFi activity — no DPRK proximity. Attacker routing through Beefy vaults (Sonne Finance 2024) does not constitute team DPRK linkage per rubric standing rule (U4). No escalation required.

Fork / dependency lineage Gray 0 10 of 10

RD-F-126 n/a Is-a-fork-of Beefy Finance is an original protocol, not a fork of any upstream. GitHub repo README contains no fork declaration. beefyfinance/beefy-protocol (archived Oct 2021) and beefyfinance/beefy-contracts are original works. No bytecode similarity to any known upstream detected. RD-F-127 n/a Upstream patch not merged No upstream fork source exists. Factor not applicable to original protocols. RD-F-128 n/a Upstream vulnerability disclosure (last 90d) No upstream fork source exists. Factor not applicable to original protocols. RD-F-129 n/a Code divergence from upstream (%) No upstream exists to compute code divergence against. Factor not applicable to original protocols. RD-F-130 n/a Fork depth (generations from original audit) Original protocol; no fork chain exists. Fork depth is structurally N/A. RD-F-131 n/a Fork retains upstream audit coverage No upstream audit to inherit or retain. Original protocol. RD-F-132 n/a Fork has different economic parameters than upstream No upstream economic parameters to compare against. Original protocol. RD-F-133 n/a Dependency manifest uses unpinned versions Cat 8 fork-lineage factor; not applicable to original protocols. Factual note: package.json pins @openzeppelin/contracts-upgradeable 4.9.3 (exact), @openzeppelin-4/contracts 4.7.2 (exact), but @openzeppelin-5/contracts is 'latest' (unpinned) — relevant context for any future Cat 8 hygiene expansion. RD-F-134 n/a Dependency had malicious-release incident (last 90d) Cat 8 fork-lineage factor; not applicable to original protocols. No malicious-release advisories found for OZ 4.9.3 in GHSA as of 2026-05-16. RD-F-135 n/a Shared-library version with known-vuln status Cat 8 fork-lineage factor; not applicable to original protocols. Factual: OZ contracts-upgradeable 4.9.3 has no active high/critical advisory. The UUPSUpgradeable advisory (GHSA-q4h9-46xg-m3x9) affected versions <4.3.2 — not applicable to 4.9.3.

Post-deploy hygiene & change mgmt Yellow 41 13 of 13

RD-F-139 red Post-audit code changes without re-audit CRITICAL: BeefyVaultV7 (released August 2022) and all modern base strategy contracts (BaseAllToNativeStrat.sol, BaseAllToNativeFactoryStrat.sol, StratFeeManagerInitializable.sol) have NO audit coverage in the beefy-audits repository (12 engagements, last core audit 2021-CertiK/DefiYield). All 2023-2025 audits cover only specific modules: ERC-4626 Wrapper, BIFI token (xERC-20), Zap contract, CLM module, beS liquid staking token. Hundreds of individual strategy variants deployed continuously without audit. This constitutes large-scale ongoing post-audit code deployment without re-audit coverage on the core vault and strategy infrastructure. RD-F-143 red Reinitializable implementation (no _disableInitializers) CRITICAL: BeefyVaultV7 uses OZ upgradeable initialize() with initializer modifier but NO _disableInitializers() call in any constructor. Confirmed by raw source inspection of BeefyVaultV7.sol and BaseAllToNativeFactoryStrat.sol — neither contract calls _disableInitializers(). Implementation contracts used as templates by BeefyVaultV7Factory are therefore re-initializable. An attacker who calls initialize() on the implementation address directly can claim ownership. While EIP-1167 clones have independent storage from the implementation, the implementation contract itself can be taken over if not locked. RD-F-137 yellow Upgrade frequency (per 90 days) Beefy deploys new strategy contracts continuously across ~34 chains (multiple per week plausible given vault count). upgradeStrat() events are emitted for each strategy switch after 6-hour delay. Exact count in trailing 90 days not determined (requires on-chain event enumeration across all chains). SAFU practices confirm this is a frequent, ongoing operational practice. RD-F-138 yellow Hot-patch deploys without timelock (last 30 days) The 6-hour vault-level delay is the only timelock in place. panic() and inCaseTokensGetStuck() execute without timelock by design. Dev multisig last transacted 2026-04-20 (35 days before assessment). Nature of that transaction not determined. No specific timelock-bypass event in last 30 days identified, but the structural absence of a protocol-level timelock means hot-patch-style deploys are architecturally possible without any delay. RD-F-146 yellow New contract deploys in last 30 days Beefy continuously deploys new vault and strategy contracts across ~34 chains. Given the volume of vaults and ongoing new launches (thousands of vault+strategy pairs active), new deploy activity in last 30 days is near-certain. Exact count not determined without on-chain enumeration of ProxyCreated events from BeefyVaultV7Factory across all chains. RD-F-168 yellow Stale-approval exposure on deprecated router Beefy operates allowance.beefy.finance to help users revoke stale token approvals to deprecated Beefy routers and strategy contracts — existence of tool implies acknowledged stale-approval surface. 2023 Multichain migration deprecated multiple bridge contracts. Old BIFI token on BSC (0xCa3F508B8e4Dd382eE878A314789373D80A5190A) is deprecated but still on-chain. Multiple chains have deprecated legacy strategy contracts. Active monitoring and revocation tooling is a positive, but the hygiene gap exists. RD-F-185 yellow Bridge rate-limiter / chain-pause as positive mitigant Beefy vault operations are chain-local — no cross-chain bridge surface for vault TVL. The panic() function in strategy contracts serves as a vault-level emergency-withdraw mechanism (withdraws from external farm to strategy) but is not a rate-limiter. BIFI xERC-20 bridge uses four external adapters (LayerZero, Axelar, Chainlink CCIP, canonical Optimism bridge) — rate-limiting is governed by upstream bridge providers, not Beefy. No Beefy-specific rate-limiter or chain-pause capability confirmed. Partial credit for panic() as a vault-level emergency mechanism. RD-F-136 gray Deployed bytecode matches signed release tag BeefyVaultV7 and base strategy contracts accessible on GitHub. No formal signed release-tag to deployed-bytecode matching performed due to the volume of deployments (thousands of vault+strategy clones across ~34 chains). Cache confirms last_commit_date=null (pipeline could not read). Factory deploys EIP-1167 clones from fixed implementation; implementation bytecode should be deterministic but not verified per clone. RD-F-140 gray Fix-merged-but-not-deployed gap No specific instance of a fix merged but not deployed identified. However, given volume of deployments and lack of formal release-tag-to-bytecode tracking across thousands of contracts, this cannot be ruled out. Would require diffing deployed bytecode across all vault/strategy instances against latest GitHub commit. RD-F-144 gray CREATE2 factory permits same-address redeploy BeefyVaultV7Factory uses ClonesUpgradeable. Standard clone() uses CREATE (not CREATE2), making same-address redeploy impossible. If cloneDeterministic() is used with reusable salts, redeploy risk could exist. Exact clone method variant not determined from available sources without deeper source inspection. RD-F-145 gray Deployed bytecode reproducibility beefy-contracts GitHub repo is public with verified source code. Cache confirms foundry_toml_present=false and hardhat_config_present=false — build toolchain unclear, making reproducible build verification harder. Raw source is available but no build manifest for deterministic bytecode reproduction confirmed.

RD-F-141 green Test-mode parameters in deploy approvalDelay is a deployment parameter (not hardcoded); docs confirm 6-hour default is standard. SAFU practices confirm mandatory pre-launch testing including panic/unpause scenarios. No evidence of test-mode parameters in production vaults. The 2021-05 Bunny vault coding error (incident) involved a strategy logic error, not test-mode parameters left in production.

RD-F-142 green Storage-layout collision risk across upgrades BeefyVaultV7 uses EIP-1167 minimal proxy clones — each clone has independent storage; implementation is a logic-only contract. Strategy upgrades (upgradeStrat) deploy entirely new strategy contracts and transfer via retireStrat() — not an in-place storage-migrating proxy upgrade. No OZ upgrades plugin needed; no storage-layout collision risk from in-place upgrade pattern.

Cross-chain & bridge Green 11 12 of 12

RD-F-148 yellow Bridge validator count (M) Four independent bridge adapters providing routing-layer redundancy. Per-adapter validator architectures: (1) LayerZero v1: built-in LZ relayer + oracle pair — centralized LZ Labs operation in v1, not a user-configurable validator set; (2) Axelar: decentralized PoS validator network with many independent validators; (3) Chainlink CCIP: Decentralized Oracle Network with multiple independent Chainlink nodes; (4) Canonical Optimism bridge: inherits Ethereum finality. Heterogeneous validator architectures with no single controlling validator set. Yellow because LZ v1 is the weakest link with centralized LZ Labs relayer/oracle. RD-F-149 yellow Bridge validator threshold (k-of-M) LZ v1 per-adapter security model: single LZ Oracle + Relayer pair (both operated by LayerZero Labs — effectively 1-of-2 entities controlled by one operator). Axelar: PoS majority threshold (>2/3). CCIP: DON threshold (multiple Chainlink nodes, exact threshold not public). Canonical Optimism: Ethereum finality. The 4-adapter design means BIFI bridging is not halted if one adapter fails — routing redundancy compensates for per-adapter threshold weakness. Yellow because LZ v1 1/1 single-operator effective threshold per adapter is below safe standards even though compensated by redundancy. RD-F-156 yellow Bridge uses same key custody for >30% validators LZ v1: both relayer and oracle operated by LayerZero Labs — single entity controls both functions for the LZ adapter path (>30% of that adapter's validator functions by one custodian). Axelar and CCIP have distributed validators but specific custodian-share data is not assessable without infrastructure tools. The 4-adapter architecture limits blast radius: LZ Labs single-custodian risk affects only one of four bridge paths. RD-F-150 gray Bridge validator co-hosting LZ v1: both relayer and oracle operated by LayerZero Labs (single entity for that adapter path). Axelar and CCIP validators are geographically distributed by design but specific ASN/data-center co-hosting is not assessable via available WebFetch tools without infrastructure analysis APIs. Cannot determine whether Axelar or CCIP validators share ASN or custodian. RD-F-155 gray Bridge validator-set rotation recency LZ v1 adapter: trustedRemote configurations changeable by Beefy dev multisig (3-of-6) via setTrustedRemote(). Most recent change date not captured in cache. Adapter deployed circa 2023-10-21 (lockbox creation date). Axelar and CCIP external validator set rotation dates not assessable without external data sources. Gap: cannot confirm rotation recency without event log inspection. RD-F-179 n/a LayerZero OFT DVN config (count, threshold, diversity) The BIFI LZ bridge adapter (0xdddaEc9c267dF24aD66Edc3B2cBe25dB86422051) is LayerZero v1 — confirmed by NonblockingLzApp inheritance and ILayerZeroEndpoint v1 interface. DVN (Decentralized Verifier Network) is a LayerZero v2 concept; LZ v1 uses Oracle+Relayer pair model. F179 measures DVN count, threshold, and diversity for LZ v2 OFT integrations — not applicable to LZ v1 adapters. Cache data (dvn_addresses=[], dvn_threshold=null, dvn_configs=[]) accurately reflects the v1 architecture despite the layerzero_bridge=false false negative (U6).

RD-F-147 green Protocol has bridge surface Yes — BIFI token uses xERC-20 lockbox design with four independent bridge adapters: LayerZero v1 (0xdddaEc9c267dF24aD66Edc3B2cBe25dB86422051), Axelar ITS, Chainlink CCIP, and canonical Optimism bridge. Vault TVL is chain-local with no bridge surface. Bridge surface is limited to BIFI token cross-chain transfers.

RD-F-151 green Bridge ecrecover checks result ≠ address(0) [★ CRITICAL — GREEN] XERC20Lockbox (0xc6e3d0CAF52E057Fb8950ae9d07aE67602919AcD): NO ecrecover anywhere in the lockbox source — uses ERC-20 deposit/withdraw and xERC-20 mint/burn mechanics only (source confirmed Etherscan). LayerZero v1 bridge adapter: NO ecrecover in message validation path — uses trustedRemoteLookup for message source validation (bytes path comparison per chain), not signature-based verification. The Wormhole-class ecrecover-zero-address bug does not apply to this lockbox+trusted-remote architecture.

RD-F-152 green Bridge binds message to srcChainId LZ v1 adapter: trustedRemoteLookup mapping keyed by LZ chain ID (uint16 _remoteChainId). Messages validated per source chain via setTrustedRemote(uint16 _remoteChainId, bytes calldata _path). lzReceive() receives _srcChainId parameter and validates against trusted remote for that specific chain. Per-chain isolation is inherent to LZ v1 trusted-remote design. chainIdToLzId/lzIdToChainId mappings provide bidirectional chain binding.

RD-F-153 green Bridge tracks nonce-consumed mapping LZ v1 endpoint handles nonce tracking at the infrastructure layer — monotonically increasing nonces per (srcChainId, srcAddress, dstChainId, dstAddress) path prevent replay. Messages delivered out of order or replayed are rejected at the LZ endpoint. The retryMessage() function handles legitimately failed delivery only for packets from trusted remotes. Replay protection is architecturally inherent to LZ v1.

RD-F-154 green Default bytes32(0) acceptable as valid root [★ CRITICAL — GREEN] No Merkle root mechanism in XERC20Lockbox or LZ v1 adapter. XERC20Lockbox operates on direct ERC-20 deposits and xERC-20 minting — no root-based proof system. LZ v1 uses trustedRemoteLookup (bytes path comparison) for message source validation. The Nomad bytes32(0) default-root bug class is architecturally inapplicable: there is no Merkle root acceptance code path in either the lockbox or the LZ bridge adapter.

RD-F-157 green Bridge TVL per validator ratio XERC20Lockbox holds approximately $969K mooBIFI (confirmed Etherscan as of assessment). Four independent adapter paths. Effective TVL-per-validator at the per-path level: $969K / 4 paths = ~$242K. Low absolute value relative to DeFi bridge averages. Even if one adapter path is compromised, the other three provide redundancy. The BIFI lockbox value is governance-token related, not the $119.7M vault TVL which is chain-local.

Threat intelligence & recon Green 0 8 of 8

RD-F-158 gray Known-threat-actor cluster has touched protocol T-09 phase-2 advisory-only signal (tier-C). No public Chainalysis/TRM/OFAC report links a known threat-actor cluster to Beefy vault interactions. The 2024 Sonne Finance exploit involved attackers potentially routing funds through Optimism — Beefy suspended its 9 Sonne vaults defensively; any attacker routing through Beefy constitutes indirect pass-through (Cat 11 U4: attacker routing through protocol is NOT team contamination). No DPRK-attributed cluster interaction with Beefy core contracts found in public data. Cannot confirm or deny without licensed Chainalysis private cluster feed. RD-F-159 gray Attacker wallet pre-strike probe (low-gas failing txs) T-09 phase-2 signal. No public evidence of systematic low-gas failing transactions to Beefy core contract addresses. Pre-strike probing is not detectable from public records alone — requires mempool monitoring with threat-actor cluster filtering. Not implementable in static assessment. RD-F-164 gray Leaked credential on paste/sentry site T-09 phase-2 signal. No public paste-site or credential-dump reference to Beefy Finance infrastructure found via public OSINT. Production monitoring requires a dedicated paste-site feed (Pastehunter, HaveIBeenPwned API, equivalent). No known credential leak affecting Beefy's on-chain deployment or multisig key material reported. Pipeline gap: paste/credential-dump monitoring not implemented. RD-F-165 gray Protocol social channel has scam-coordinator flag T-09 phase-2 signal. Beefy operates a Discord server (discord.gg/beefyfinance) and X/Twitter presence. No public report of a Beefy Discord admin or community manager being flagged as a scam-coordinator. Systematic assessment requires a curator social watchlist — not assessable via standard OSINT. Cannot confirm or deny without curator-maintained watchlist.

RD-F-160 green GitHub malicious-dependency incident touching protocol deps T-09 phase-2 signal. Beefy contracts use OpenZeppelin libraries (ERC20Upgradeable, OwnableUpgradeable, ClonesUpgradeable). No GitHub security advisory (GHSA) or npm security advisory for OpenZeppelin or other Beefy dependencies filed within the last 90 days as of 2026-05-16. The beefy-contracts repo uses standard OZ dependencies. No known malicious-release incident on Beefy's dependency chain at this date.

RD-F-161 green Protocol-impersonator domain registered (typosquat) beefy.finance domain registered approximately 6 years ago (consistent with October 2020 launch per profile §2). No typosquat domain registered within the last 90 days (window: 2026-02-14 to 2026-05-16) identified in public domain-reputation sources (Scamadviser, IPQualityScore). No specific typosquat or brand-impersonation incident reported for Beefy in 2024-2026 public OSINT. Note: assessment is 'no evidence found' — production pipeline requires DomainTools or equivalent WHOIS monitoring for systematic detection.

RD-F-162 green Known-exploit-template selector deployed by any address T-09 phase-2 signal. No known exploit-template specifically targeting BeefyVaultV7 architecture deployed by any address. Beefy is an original protocol (not a fork); standard Compound-fork or Aave-fork exploit templates do not apply. The CLM TWAP critical (Zellic 2024-02-28) was fixed pre-deployment; no active exploit template derived from it is publicly known. Rekt incidents = 0 for Beefy (no historical exploit to derive a replay template from).

RD-F-163 green Avg attacker reconnaissance time for peer-class protocols Cat 11 static reconnaissance metric. No documented pre-strike reconnaissance activity for any known threat actor against Beefy core contracts. Beefy's historical incident record shows external exploits affecting upstream wrapped protocols (Sonne 2024, Balancer V2 2025) — Beefy was not the reconnaissance target in these events. Beefy's demonstrated defensive-pause monitoring capability (multiple proactive pauses across 5.6 years) indicates active monitoring that would surface USPD-class 78-day reconnaissance indicators. For yield-optimizer protocols, reconnaissance would focus on upstream wrapped protocols, not the vault aggregator layer. Class-average reconnaissance time: 30-78 days based on DeFi incident DB.

Tooling / compiler / AI Green 0 5 of 5

RD-F-171 n/a Bytecode similarity to audited upstream with behavior deviation Original protocol with no audited upstream to compare against. AI-copy risk pattern (bytecode similarity to audited upstream with behavioral deviation) does not apply to original codebases. BeefyVaultV7 design predates major LLM code-generation tools.

RD-F-170 green Solc version used (known-bug versions flagged) Primary compiler: Solidity 0.8.23 (foundry.toml + hardhat.config.ts); secondary: 0.8.19 (hardhat.config.ts). BIFI token deployed at 0.8.19+commit.7dd6d404 (Etherscan verified). Per etherscan.io/solcbuginfo: 0.8.23 has only VerbatimInvalidDeduplication (Low severity, Yul-only). 0.8.19 same. Neither on high/critical bug list for standard Solidity compilation without viaIR or transient storage. TransientStorageClearingHelperCollision (High) affects 0.8.28-0.8.33 — not applicable to 0.8.23 or 0.8.19.

RD-F-172 green Repo shows AI-tool co-authorship in critical files Reviewed 13 recent commits (Feb-Apr 2026) on beefyfinance/beefy-contracts master: authors roman-monk, MirthFutures, kexleyBeefy. No Co-authored-by: GitHub Copilot or similar AI-tool co-authorship trailer detected in any commit message. Commits are routine protocol integrations (BalancerV3, Morpho, UniV4) and dependency bumps.

RD-F-173 green Team self-disclosure of AI-generated Solidity No public disclosure (blog, X/Twitter, docs) from Beefy Finance team claiming AI-generated Solidity in production contracts. Beefy SAFU practices doc describes manual testing procedures with no AI disclosure.

RD-F-174 green Dependency tree uses EOL Solidity version Solidity 0.8.23 and 0.8.19 are both actively supported non-EOL versions in the 0.8.x line. Solidity project actively maintains 0.8.x. No EOL version detected in core contracts or dependencies.

Response & disclosure hygiene Green 8 4 of 4

RD-F-176 yellow Disclosure SLA public No explicit acknowledgment-time SLA (e.g., '72-hour acknowledgment', '5-day response commitment') is published in Beefy's docs or on the Immunefi program page. The Immunefi program implies an embargo process (public disclosure of unpatched vulnerability is prohibited) but does not specify a formal SLA for researcher acknowledgment. No response-time commitment was found in SAFU practices or bug-bounty docs. Yellow — disclosure channel exists but SLA transparency is absent.

RD-F-175 green Disclosure channel exists Beefy has maintained an active Immunefi bug bounty program since July 2021. The program is live at immunefi.com/bug-bounty/beefyfinance/ with 244 assets in scope. Discord is listed as secondary contact channel in docs. The disclosure channel is publicly discoverable and has been active for approximately 59 months at assessment date. Green.

RD-F-177 green Prior known-ignored disclosure No post-mortem or incident record documents a disclosed vulnerability that was reported to Beefy and then ignored or not actioned before an exploit. The five adjacent events in the incident register were not preceded by ignored bug reports. The 2021-04-22 BUNNY coding error was detected internally by the team, not by an external reporter who was ignored. The 2024 Sonne Finance event was rooted in Sonne's contracts, not Beefy's. Green — no evidence of prior known-ignored disclosure.

RD-F-178 green CVE/GHSA advisory issued against protocol No CVE or GHSA (GitHub Security Advisory) has been issued against Beefy Finance. Searches across 2023–2026 found no CVE or GHSA filing against Beefy's codebase. No direct protocol exploit has occurred that would typically generate a CVE filing. This is the desired negative finding for this factor. Green.

rubric_version v1.7.0 graded_at 2026-05-16 22:00:01 factors 184 protocol beefy