Ammplify — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Ammplify, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 6
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 6 closed, publicly disclosed Ammplify 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 Ammplify
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Ammplify: Wide cross-zero ranges revert (InvertedRange) due to sign-loss in tick→index and no wrap support
Ammplify's tree-based tick routing loses the sign of negative ticks because tickToTreeIndex casts the signed quotient to uint24 before adding the rootWidth/2 offset and never applies a modulo. Combined with RouteImpl.make's strict left<=right requirement and no wrap handling, any cross-zero range wider than rootWidth/2*tickSpacing maps to an inverted (left>right) index interval and reverts with InvertedRange. This DoS affects legitimate wide-range (including near-full-range) positions unless the caller manually splits the interval, and the protocol confirmed a fix in Ammplify PR 25.
Ammplify: Some legitimate `UniV3Decomposer` decompose attempts will always revert due to incorrect liquidity offset calculation
Ammplify's UniV3Decomposer converts Uniswap v3 NFT positions into Ammplify Maker positions by burning the NFT for assets and re-minting the same liquidity inside a segment tree. Because burning rounds assets down and each of up to 42 segment mints rounds assets up, the composable position liquidity must be reduced by an offset; the code derives that offset solely from the token1 (asset1) side and rounds it down rather than up. For ranges where the token0 side is the binding constraint, the offset is too small, leaving the decomposer short of asset0 and causing mint attempts to revert, breaking a core feature. A concrete case (Ticks 70020/70080, offset 421 vs required 11065) reproduces the reverts, and the fix computes the offset from both assets using max(ceil-based L0, L1).
Ammplify: incompatible library used for Fee on Transfer tokens
Ammplify's competition scope explicitly promises support for fee-on-transfer ("Transfer of less than amount") tokens, but all token operations route through an external RFTLib library whose settle() function performs a strict balance-delta validation. For any fee-on-transfer token the received balance will always be less than the requested amount, so the `InsufficientReceive` guard always fires and the transaction reverts. As a result users cannot open maker positions with such tokens at all, producing a denial-of-service relative to the stated compatibility guarantees. The team acknowledged the issue and chose not to fix it.
Ammplify: Takers can pay significantly less fees with makers losing these amounts due to `subtreeBorrowedX` and `subtreeBorrowedY` being node's values instead of subtree's
Ammplify's liquidity walker stores `subtreeBorrowedX`/`subtreeBorrowedY` as per-node borrowed values rather than the true aggregate of the node plus its children, because unlike `subtreeMLiq`/`subtreeTLiq` these fields are never propagated upward from children during the liquidity up-walk. When taker fees are computed, the undercounted base amount is multiplied by the borrowing rate, causing takers to pay dramatically less than owed and making the fee total order-dependent. Depending on which range is updated first the total fees charged can be roughly 50-98% below the correct amount, and a malicious taker can keep updating a top range with tiny liquidity to keep taker fees artificially low.
Ammplify: NFTManager will break NFT metadata for users as tokenURI() will revert
Ammplify's NFTManager generates ERC721 metadata through AssetLib.getAsset, but because the NFTManager contract is separate from the diamond storage, the call resolves Store.assets() against the ERC721's own storage slot layout rather than the diamond's. Every asset therefore appears to have owner == address(0), causing the require check to revert whenever tokenURI() is invoked. As a result, minted position NFTs cannot be rendered by wallets, explorers, or marketplaces, breaking their external usability despite a successful mint. The protocol acknowledged the issue and fixed it by routing metadata generation through the IView facet instead of AssetLib.
Ammplify: Mismatch in actual pool's liquidity and pool node's liquidity infomation because of wrong `route` in `PoolWalker.settle`
Ammplify's concentrated-liquidity pool bookkeeping diverges because WalkerLib.modify computes the tree index for the high tick as treeTick(highTick)-1 while PoolWalker.settle uses treeTick(highTick) unchanged when building its walk route. This off-by-one causes the settlement walk to take a different branch and skip the correct right node, leaving the actual on-pool liquidity out of sync with the node's recorded liquidity. Because fee accrual, maker/taker creation, and asset removal all read this liquidity accounting, affected nodes become unusable — subsequent new makers, new takers, and removeMaker calls revert, and trapped balances remain in the maker facet or pool. The protocol team confirmed and fixed the issue by deducting one in settle() to match WalkerLib.modify.