Smilee Finance — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Smilee Finance, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 11
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 11 closed, publicly disclosed Smilee Finance reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Price manipulation, Oracle manipulation, Access control, 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 Smilee Finance
- Price manipulation findings disclosed against Smilee Finance
- Oracle manipulation findings disclosed against Smilee Finance
- Access control findings disclosed against Smilee Finance
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Smilee Finance: Position Manager providing the wrong strike when storing user's position data
Smilee Finance's PositionManager lets users supply an arbitrary strike when minting a managed position, but the underlying IG (Inverse Gamma) vault mints at its own financeParameters.currentStrike, silently ignoring the user-provided value. When PositionManager records the new position it persists the user-supplied strike rather than the one IG actually used, so the sell/burn lookup cannot resolve the position and reverts with PositionNotFound, permanently freezing the minted NFT and the premium paid. The flaw triggers even without user error when an epoch rolls between transaction submission and execution, changing the effective correct strike. The protocol acknowledged the issue, and the Sherlock judge upheld the escalation as a valid Medium with duplicates.
Smilee Finance: Utilization rate for bonding curve purposes is calculated for a total of bull and bear usage, which can be abused to steal all vault funds
Smilee Finance's IG options vault derives quoted volatility from a bonding curve that feeds on the combined utilization of both bull and bear positions, rather than treating each side separately. Because bull and bear premiums differ in absolute magnitude when the underlying price sits away from the strike, a trader can buy the higher-priced option, buy the cheap counterpart to push the combined utilization (and thus volatility) up, then sell both sides — realizing a net profit each round because the price gain on the expensive side exceeds the loss on the cheap side. Repeating the four-step cycle hundreds of times lets an attacker drain essentially all vault funds, with the PoC showing ~6.8% loss over 100 iterations and full theft projected in roughly 1500 transactions. The team fixed it with a vega-weighted utilization rate, which the Lead Senior Watson reviewed and signed off on, leaving only non-exploitable edge cases.
Smilee Finance: Transferring ERC20 Vault tokens to another address and then withdrawing from the vault breaks `totalDeposit` accounting which is tied to deposit addresses
Smilee Finance's Vault is an ERC20 whose per-user deposit accounting (cumulativeAmount and the global totalDeposit) assumes the depositor is the one who later withdraws those shares, but vault shares can be freely transferred between users. By transferring nearly all shares to another address and withdrawing a single wei, a user can reduce totalDeposit by their entire original deposit while withdrawing almost nothing, letting them bypass the admin-set maxDeposit cap and redeposit beyond it, or conversely inflate totalDeposit without backing assets so the vault rejects all new deposits. The protocol acknowledged the issue, Sherlock upheld it as a valid medium, and a fix commit was provided, though a follow-up review noted the fix still allows deposit-limit bypass via transfers to the vault itself with lost funds.
Smilee Finance: Mint and sales can be dossed due to lack of safeApprove to 0
Smilee Finance's PositionManager and DVP contracts granted base-token spending rights via OpenZeppelin's safeApprove without first zeroing the allowance. Because safeApprove reverts when transitioning from one non-zero allowance to another, the first mint or sell permanently locks the allowance, so every subsequent mint, sell, and burn of that base token reverts. The result is a standing denial-of-service on core protocol functionality. Sherlock judges confirmed the finding as a valid medium and the protocol team fixed it in a follow-up commit, which the Lead Senior Watson signed off on.
Smilee Finance: PositionManager will revert when trying to return back to user excess of the premium transferred from the user when minting position
In Smilee Finance's PositionManager.mint, the contract computes a preliminary premium and pre-collects it from the user, later refunding any over-collected excess. The refund path uses baseToken.safeTransferFrom(address(this), msg.sender, ...), but PositionManager never approves itself for that transfer, and on Arbitrum both USDC and USDC.e transferFrom always verify allowance even for self-transfers. The refund therefore always reverts, making the mint call fail and blocking users from opening positions. Sherlock ruled the issue Medium and confirmed it remains valid even though the condition is currently unreachable due to a separate DVP pricing bug; the team fixed it by switching to safeTransfer.
Smilee Finance: FeeManager `receiveFee` and `trackVaultFee` functions allow anyone to call it with user-provided dvp/vault address and add any arbitrary feeAmount to any address, breaking fees accounting and temporarily bricking DVP smart contract
Smilee Finance's FeeManager exposes two fee-accounting entry points — trackVaultFee and receiveFee — that lack any role or address authentication. Because the only validation is that msg.sender implements vault()/baseToken(), any attacker can deploy a fake contract returning chosen addresses and inflate recorded fees for real vaults or DVP senders without transferring real collateral. Beyond corrupting the fee ledger so admins cannot determine true fee splits, an attacker can inflate a vault's accumulated fee to near uint256.max, causing every later trackVaultFee call — invoked on all DVP mints and burns — to revert on overflow, temporarily bricking the DVP until the FeeManager is redeployed and re-registered in the AddressProvider. The judge confirmed the issue as medium severity (no funds at risk, only DoS) and the protocol team fixed it by adding a whitelist of permitted callers.
All reports in this group
- Smilee Finance: Vault Inflation AttackLogic error$0
- Smilee Finance: The sign of delta hedge amount can be reversed by malicious user due to incorrect condition in `FinanceIGDelta.deltaHedgeAmount`Logic error$0
- Smilee Finance: Trading out of the money options has delta = 0 which breaks protocol assumptions of traders profit being fully hedged and can result in a loss of funds to LPsLogic error$0
- Smilee Finance: Whenever swapPrice > oraclePrice, minting via PositionManager will revert, due to not enough funds being obtained from user.Logic error$0
- Smilee Finance: If the vault's side token balance is 0 or a tiny amount, then most if not all IG Bear trades will revert due to incorrect check of computation error during delta hedge amount calculationLogic error$0