> For the complete documentation index, see [llms.txt](https://docs.usenest.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.usenest.xyz/protocol-and-security/7.1-amm-architecture.md).

# 7.1 - AMM Architecture

nest is built around a **unified AMM**: one venue + one router that can support multiple pool types without fragmenting liquidity. The goal is simple, **best execution for traders** and **the right liquidity shape for each asset**, all under one governance/incentive surface.

<figure><img src="/files/d67bfd8af1cb53afae6af4faf0eb7158fbfc40b9" alt=""><figcaption></figcaption></figure>

At the core, nest uses a **Concentrated Liquidity AMM (CLAMM)** based on **Algebra Integral**, where LPs can provide liquidity inside a chosen range to increase effective depth near the current price.

Why this matters:

* **Modular architecture:** keep core pricing/liquidity accounting more immutable, extend behavior via plugins/hooks (less migration, less fragmentation).
* **Dynamic fees (where enabled):** fees can adjust with conditions (volatility/volume) to balance execution vs LP risk.
* **Hooks (where enabled):** pools can add behaviors like launch protections to reduce early bot exploitation on new launches.
* **Multiple pool types:** not every asset should live in the same curve; unified routing keeps it cohesive.

Important distinction:

* **Pools can be permissionless** (anyone can deploy/provide liquidity),
* but **emissions are governance-directed** (veNEST decides where incentives go).