# Routers

## Routers

> **TL;DR – Why AEGIS DFM Is the Least‑Surprise Dynamic‑Fee Hook for Aggregators**
>
> * **Deterministic pricing.** Every fee component is a pure, on‑chain function.
> * **“Never‑higher” guarantee.** Your user pays ≤ the fee you simulated 99.75 % of the time …
> * **Edge‑case bounded & predictable.** That surge fee hits exactly one follower trade, then linearly decays to zero over the next few hours.
> * **No exotic math.** Pool invariant stays constant‑product; keep your usual Uniswap‑V3/V4 price‑impact logic.
> * **Gas‑friendly.** The only extra storage write burdening swaps is the oracle observation, similar to Uniswap V3.

***

### 1 — How the Fee Works

#### Base fee

**File & line:** `DynamicFeeManager.sol` 180‑222\
**Logic:** Clamps between per‑pool min / max using on‑chain volatility (`maxTicksPerBlock`).

#### Surge fee (only after a cap event)

| Step                     | What happens                                                                                              |
| ------------------------ | --------------------------------------------------------------------------------------------------------- |
| **Trigger**              | If a single block’s tick‑move exceeds `maxTicksPerBlock`, `TruncGeoOracleMulti` (150‑169) sets `capStart` |
| **Cap trade**            | Pays **no** surge (fee = base)                                                                            |
| **First follower trade** | Pays **base + surge**                                                                                     |
| **Subsequent trades**    | Surge decays linearly to 0 over `decaySecs` (228‑252)                                                     |

#### Public view for routers

```solidity
function getFeeState(bytes32 poolId)
        external view returns (uint24 base, uint24 surge);
```

*Returns the exact numbers the **next swap** will use—no hidden maths.*

#### No invariant changes

Permission bitmap excludes `beforeModifyPosition`; only swap callbacks enabled (`Spot.sol` 90‑111). Constant‑product forever.

### 2 — Why This Beats Other Dynamic‑Fee Hooks

| Usual pain‑point                | Typical dynamic hooks                   | **AEGIS DFM**                                         |
| ------------------------------- | --------------------------------------- | ----------------------------------------------------- |
| Hidden admin fee changes        | Upgradeable proxies, opaque owner calls | **On‑chain fee logic**                                |
| Fee can spike after simulation  | No public pre‑swap view                 | `getFeeState()` = what you will pay (unless rare cap) |
| Multiple paths to fee inflation | Policy gates, `beforeModifyPosition`    | **Single path** (cap event) + bounded surge           |
| Complicated invariants          | Logistic/TWAMM curves                   | Same *xy = k* maths you already implement             |

### 3 — Optional “Extra” Steps

1. **Whitelist byte‑code hash** (one‑time).
2. **Display live fee** to users via the same `getFeeState()` call.