Good Entry — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Good Entry, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 12
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 12 closed, publicly disclosed Good Entry 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, Front-running / MEV, Access control, Oracle manipulation, 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 Good Entry
- Front-running / MEV findings disclosed against Good Entry
- Access control findings disclosed against Good Entry
- Oracle manipulation findings disclosed against Good Entry
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Good Entry: When price is within position's range, `deposit` at TokenisableRange can cause loss of funds
Good Entry's TokenisableRange.deposit charges a portion of a user's fresh deposit as protocol fees whenever the pool's live slot0 spot price sits inside the position's tick range, splitting the amount using LiquidityAmounts.getAmountsForLiquidity at that transient price. Because the split is computed from the momentary spot price, a price move between transaction submission and execution — whether from market fluctuation or a deliberate frontrunner — can push the price out of range, which returns a zero token amount for one leg and converts that leg's entire deposit into fees. The follow-on increaseLiquidity call still succeeds because the per-leg 95% minimum is satisfied by the discounted remaining amount, so the depositor loses a full token leg to fees instead of gaining position liquidity. The sponsor initially disputed the report, then confirmed it and removed the fee-clawing mechanism entirely in PR#4.
Good Entry: Incorrect parameters passed to UniV3 may cause funds stuck in the vault
Good Entry's GeVault rebalancing flow can wedge user funds: when removing liquidity from a Uniswap V3 position, the vault passes zero amounts to NonfungiblePosition.collect in edge cases where the liquidity delta is tiny, and UniV3 reverts on collecting (0,0). Because the revert fires inside the rebalancing path, deposits, withdrawals and rebalancing all fail, freezing vault capital. The flaw was proven on live Arbitrum mainnet via a forge fork test, confirmed by the Good Entry team, judged Medium for availability impact, and fixed by guarding the collect call against zero amounts.
Good Entry: V3Proxy swapTokensForExactETH does not send back to the caller the unused input tokens
Good Entry's V3Proxy wraps the Uniswap V3 router, exposing a swapTokensForExactETH entry point that pulls a caller-specified maximum amountInMax of an input ERC-20 but only pays the router the exact input consumed by the swap. Because the function never returns the delta between amountInMax and the actually-consumed amount to the caller, every user who specifies an input allowance larger than the swap needs permanently loses that excess, with the funds left stranded in the V3Proxy contract. The flaw is confirmed by the sponsor and was fixed in a follow-up PR that refunds the unused balance; a reproducible Foundry PoC demonstrates the missing refund via a failing balance assertion. Economically this amounts to a systematic overcharge equivalent to locked funds for the protocol's users, which is why it is rated high severity.
Good Entry: V3 Proxy does not send funds to the recipient, instead it sends to the msg.sender
Good Entry's V3 proxy wrapper exposes swap functions intended to be compatible with the Uniswap V2 interface, but these functions ignore the caller-supplied destination address and instead route output tokens to msg.sender. Any caller who passes a different `to` address loses the economic value of the swap — for instance a user blacklisted on the output token, or one whose allowance/signature was compromised and who tries to divert proceeds to a safe address, ends up with funds sent back to the caller. The issue was confirmed by the protocol and the judge rated it Medium; the final fix added an explicit `require(msg.sender == to)` to enforce that swaps only ever go to the caller, which is safe for the OPM-only usage the module was designed for.
Good Entry: First depositor can break minting of liquidity shares in GeVault
GeVault's deposit function issues liquidity shares proportional to the vault's live token balances as reported by getTVL(), which reads the contract's aToken balances. Because the very first mint sets the initial share price at a fixed 1e10 wei baseline, a malicious first depositor can mint a negligible share, withdraw down to one wei of shares, and directly donate a large amount of the underlying to the vault, inflating the per-share value dramatically. A subsequent legitimate depositor then receives a near-zero share count for a large deposit, so most of their funds are effectively stolen, and the require(liquidity > 0) check bricks small deposits. The judge confirmed this as Medium severity since it requires front-running a brand-new zero-supply vault and only affects vault deployment.
Good Entry: User can steal refunded underlying tokens from `initRange` operation inside `RangeManager`
Good Entry's RangeManager.initRange bootstraps a TokenisableRange by pulling underlying tokens and delegating the Uniswap v3 NFT mint to TokenisableRange.init, returning only the minted TR token to the owner. Uniswap v3 minting routinely refunds unused underlying dust, which TokenisableRange.init routes back into the RangeManager, but initRange never sweeps those funds back to the owner. A user watching the mempool can back-run the admin's transaction by calling removeAssetsFromStep, whose internal cleanup() deposits the stranded balances into the lending pool under the caller's own account. The team confirmed the finding, argued it was low severity due to the dust being a small leftover, and mitigated it with a cleanup() call plus a return-value check.
All reports in this group
- Good Entry: Unused funds are not returned and not counted in `GeVault`Logic error$0
- Good Entry: Incorrect Solidity version in FullMath.sol can cause permanent freezing of assets for arithmetic underflow-induced revertOracle manipulation$0
- Good Entry: Overflow can still happen when calculating `priceX8` inside `poolMatchesOracle` operationOracle manipulation$0
- Good Entry: TokenisableRange's incorrect accounting of non-reinvested fees in "deposit" exposes the fees to a flash-loan attackOracle manipulation$0
- Good Entry: Incorrect calculations in deposit() function in TokenisableRange.sol can make the users suffer from immediate lossLogic error$0
- Good Entry: addDust does not achieve the goal correctly and may overflow revertLogic error$0