> For the complete documentation index, see [llms.txt](https://docs.on.nexus/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.on.nexus/trading-and-routing-strategies/routing.md).

# Multi-Maker Routing

Institutional trades often exceed the optimal liquidity depth of a single market maker. To prevent compounding slippage, the Nexus Composer utilizes Multi-Maker Routing, transforming single, monolithic swaps into highly optimized, distributed execution paths.

#### Optimal Liquidity Aggregation

Multi-maker routing is treating liquidity as a distributed optimization problem. The Nexus Composer aggregates the yielding curves from all active CPMM, CLMM, and FPSSL Nodes into a unified order book.

Multi-Objective Optimization Matrix:

1. Order Book Aggregation: Merge independent Maker liquidity curves into a unified depth-by-price mapping.
2. Greedy Price Optimization: Intelligently slice the total order size, distributing tranches to the most cost-effective liquidity sources until the order is filled or the slippage constraint is breached.
3. PSBT Partitioning: Allocate distinct UTXO input/output sets to correspond to each selected maker within a single, atomic PSBT.
4. Synchronous Signatures: Collect off-chain signatures simultaneously from the distributed makers.

#### Execution Quality

By splitting a 10 BTC order into five distinct 2 BTC tranches across completely independent Institutional Maker Nodes, the trader bypasses the steep curve penalty associated with executing a 10 BTC trade against a single CPMM pool.

| Trade Scenario | Direct Single Execution  | Multi-Maker Routing Execution |
| -------------- | ------------------------ | ----------------------------- |
| Liquidity Used | One Maker (Deepest Pool) | 3 Independent Makers          |
| Slippage Curve | Steep exponentially      | Shallow step-wise             |
| Price Impact   | High                     | Minimized                     |

#### Algorithmic Safeguards

When aggregating multi-party quotes within a single PSBT, operational reliability becomes the primary failure vector.

* Latency Optimization: The routing engine actively tracks the ping/response metrics of Maker nodes, systematically routing around non-responsive hardware.
* Atomic Settlement Assurance: The PSBT requires ALL selected Makers to sign. If one Maker drops offline mid-execution, the entire PSBT draft is invalidated, ensuring the Taker never enters a state of partial, unintended fulfillment.