Start Here
A visual first-page map for Collateral Rail: what it is, how requests move, who owns each boundary, and where to go next.
Collateral Rail is a Uniswap v4 settlement system for markets that need normal AMM liquidity plus controlled off-pool settlement capacity.
The pool still behaves like a pool. The extra machinery only wakes up when a swap intentionally carries signed settlement material.
System Components
These are the pieces you will see repeated across the docs. The important part is not memorizing every contract. It is knowing which component owns the decision you are looking at.
SDK
Builds payloads, exposes contract clients, decodes errors and events, and keeps app code from recreating protocol wiring by hand.
Quote Server
Validates requests and signs settlement material. This is the custody boundary for quote signing and issuer material.
Solver
Runs LI.FI intent execution, order wallet state, replay storage, fill checks, and finalisation checks.
Onchain Settlement
The router, hook, manager, controllers, broker adapter, and risk modules execute the swap-time path and enforce policy.
First, The Shape
The system is not a binary switch between issuer capacity and pool liquidity.
The quote server chooses the allocation and signs the settlement envelope. The
SDK carries it into the hook as signed hookData, and the hook verifies risk
before executing the quote-selected controlled leg exactly.

That is the core mental model:
- Pool liquidity only: if controlled settlement is not used, the pool can handle the whole swap.
- Controlled capacity only: issuer, vault, or controller capacity can settle the whole eligible amount when risk checks allow it.
- Mixed allocation: the quote server can allocate across controlled capacity and pool liquidity, for example when issuer capacity covers part of the balance and the pool handles the remainder.
- Reader takeaway: signed flow is not just a second lane; it is an allocation problem constrained by quote bounds, risk policy, and available liquidity.
What To Remember
The hook is an allocator
It verifies signed hookData, applies risk controls, and allocates against controlled capacity, pool liquidity, or both.
The manager is accounting
It sizes controlled capacity, consumes quote state, and keeps collateral and debt honest.
The quote server is custody
It validates requests and signs payloads without putting secrets in browser code.
Runbooks change state
Operations and administration pages are where health checks, pauses, roles, and deployment flows live.
One Signed Swap, Illustrated
This is the story most integrators need first:
1. Build The Executable Quote
2. Enter The Hook And Allocate
3. Settle And Close
The quote is not a vague offchain promise. It is a bounded envelope: signer,
trader, pool, amount, price, expiry, and replay identity all have to line up.
The router checks that envelope before the swap starts; the hook then uses it
during beforeSwap and afterSwap to size controlled settlement, leave any
remainder to the pool, and consume replay state exactly once.
The Four Planes
Use this map when you are trying to place a file, script, or page in your head. The control plane is drawn as a wrapper because it is not a late-stage check; it constrains every request, quote, and settlement action.

Fast Lookup
| If you are asking... | Go here |
|---|---|
| What should I run first? | First Local Run |
| Which endpoint signs this path? | Quote Server API |
| Which SDK export do I need? | SDK API |
| Which contracts matter? | Contracts |
| What is unhealthy right now? | Incident Response |
| Who is allowed to change this? | Administer |