githubEdit

Multi-Maker Routing

Sourcing optimal execution paths across a globally fragmented sovereign liquidity network.

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.

Last updated