Fenix Finance — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Fenix Finance, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 2
- Total paid
- $0
- Critical
- 1
- Largest payout
- $0
This page collects the 2 closed, publicly disclosed Fenix Finance 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, 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 Fenix Finance
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Fenix Finance: Single-step process for critical ownership transfer is very risky
Fenix Finance's BribeFactoryUpgradeable inherits OpenZeppelin's single-step OwnableUpgradeable, so a one-call transferOwnership to a mistyped address permanently hands ownership to an address whose private key is unknown. Every onlyOwner-protected function — including changeImplementation, setVoter, addRewards and the default-token management calls — becomes unreachable, effectively bricking the factory's administrative surface. Because no confirmation from the new owner is required, the mistake is irreversible. The report recommends switching to Ownable2StepUpgradeable so the new owner must explicitly accept the transfer, matching the pattern already used by MinterUpgradeable in the same codebase.
Fenix Finance: First liquidity provider of a stable pair can DOS the pool
Fenix's stable Pair implements the UniswapV2 x3y+y3x invariant, but the intermediate normalized product _a=(x*y)/1e18 truncates to zero whenever the normalized reserve product falls below 1e18. When _a=0 the invariant k collapses to zero, removing any constraint on trades, so a trader can drain all remaining reserves. Because the borrowed MINIMUM_LIQUIDITY sqrt check does not protect the stable formula, the first liquidity provider can repeatedly open with minimal deposits, drain the pool, and repeat until the LP total supply overflows — permanently DoSing the pair. The proposed fix restricts the initial stable-pair deposit to equal normalized amounts and enforces a minimum invariant k.