Yield Basis — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Yield Basis, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 4
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 4 closed, publicly disclosed Yield Basis reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Governance attack, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against Yield Basis
- Governance attack findings disclosed against Yield Basis
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Yield Basis: LiquidityGauge is not compliant with EIP-4626 due to MIN_SHARES constraint
The Yield Basis LiquidityGauge implements the ERC-4626 view functions maxWithdraw and maxRedeem without accounting for the MIN_SHARES invariant that the actual withdraw/redeem paths enforce via the _check_min_shares guard. Under conditions where total supply is above zero but the remaining supply after redemption would fall below MIN_SHARES, these view functions report a maximum that the corresponding operation will reject. This violates the EIP-4626 requirement that view functions underestimate rather than overstate the true redeemable amount. The inconsistency does not directly expose user funds but can break downstream integrators that trust the reported maximum.
Yield Basis: Emergency withdrawal fails to update the guage when the contract is not killed
Yield Basis's LT vault calls an internal `_checkpoint_gauge()` before normal `deposit` and `withdraw` operations specifically to prevent flash-loan-driven reward manipulation against the gauge controller. That checkpoint is missing from `emergency_withdraw` when the system is not killed, even though that path still recalculates and rewrites liquidity values via `_calculate_values`. An attacker can borrow funds, inflate apparent activity, and exit through `emergency_withdraw` without ever syncing the gauge, enabling unfair reward claims or dilution against legitimate stakers. The flaw was reported by multiple finders, acknowledged by the protocol, and fixed in commit 4b15e6293d1b3c9469c533c18a1049975d512736 by adding the checkpoint call to the emergency withdrawal path.
Yield Basis: The incorrect initialize of `specific_emissions_per_gauge` in `GaugeController::add_gauge()`
Yield Basis's GaugeController initializes a newly added gauge's per-gauge emission baseline from the controller's global specific_emissions value, which can be stale if the prior gauge checkpoint predates the addition. Because _checkpoint_gauge() skips the per-gauge bookkeeping when called in the same block as add_gauge() (the block.timestamp > t guard fails), the new gauge's baseline never advances past the older timestamp. On the next checkpoint the gauge is credited emission-weighted value for the entire stale window, letting it capture excess YB emissions it did not earn. The judge ruled this a medium-severity accounting flaw, and the fix is to initialize the new gauge with the current, updated specific_emissions.
Yield Basis: InflationaryVest.vy: Missing update of self.claimed allows infinite multiple claims by the recipient
InflationaryVest.vy exposes a claim() path whose payout is computed from an accounting field, self.claimed, that is read in _claimable() but never incremented after a distribution. As a result the designated recipient can call claim() any number of times and receive the identical full allocation each time, so the vesting balance is drained repeatedly and the unlock schedule is effectively bypassed. The issue was credited to many wardens in the Sherlock contest, confirmed by the protocol team, and fixed by recording each distribution into self.claimed after a successful transfer.