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)
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
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
Whitelist byte‑code hash (one‑time).
Display live fee to users via the same
getFeeState()call.
Last updated