# Takers pay significantly higher fees than expected due to borrow amounts being split across segments

Bug Deep Dive #18 · 14 December 2025

Bug Deep Dives · [The Contest Academy](https://0xsimao.com/the-contest-academy) · 0xSimao

---

| Title | Takers pay significantly higher fees than expected due to borrow amounts being split across segments |
| Reward | $4432, Unique |
| Contest | Ammplify - 2 Sep 2025 on Sherlock |
| Author | panprog |
| Context | Fee Logic |

When takers pay their fees, the taker rate is applied to amounts of token0 and token1 derived from the geometric mean price of the interval, in `Data.computeBorrows`:

```solidity
int24 gmTick = lowTick + (highTick - lowTick) / 2; // The tick of the geometric mean.
```

For example, if there is 1e18 taker liquidity in the **\[-122880..245760]** range, the borrow amounts for this interval should be:

- borrowX = 0.046e18
- borrowY = 21.6e18

The issue is that taker liquidity is stored in a segment tree, so internally the range is broken into two segments. The amounts of token0 and token1 are then calculated from the geometric mean of each segment rather than the original price, which inflates the borrow amounts badly:

- for **\[-122880..0]**: borrowX = 20.6e18, borrowY = 0.044e18
- for **\[0..245760]**: borrowX = 0.00214e18, borrowY = 464.7e18

These sum to `borrowX = 20.6e18` and `borrowY = 464.8e18`, at least **200x** the expected borrow amount.

With a 10% taker rate, the taker expects to pay `0.0046e18` token0 and `2.16e18` token1. Because of how the liquidity is stored and calculated, they actually pay `2.06e18` token0 and `46.48e18` token1.

**Alpha:** the fee paid varies with the state — specifically the number of segments at that moment — which is inconsistent and always worth reporting. Check that fees are consistent for the same outcome.

**Conclusion**

This finding would earn you **\$4432**. It requires knowing exactly how the fees work, and how much they can vary for the same outcome.

[**Full Report**](https://audits.sherlock.xyz/contests/1054/report)\
[**Codebase**](https://github.com/itos-finance/AmmplifyPublic/tree/beb942cfbd54990fc9434fbfa99a1fc251d73689)

---

Newer: [Borrow fee uses APY as per-second rate, causing extreme overcharging](https://0xsimao.com/the-contest-academy/bug-deep-dive-19) · Older: [Incorrect inside fees calculation for uninitialized uniswap ticks causes positions funds being stuck in the contract](https://0xsimao.com/the-contest-academy/bug-deep-dive-17)