Several architectures, several onchain LPs
HyperMatch aggregates liquidity from several onchain LPs built on different technical architectures, and chooses between them by explicit rules. Every route needs a readable market model, verified permissions and a working exit.
Three architectures
Order-book LPs
Prices come from a public order book: an order fills by walking the book at its size, so depth decides the cost. Holding a position pays or receives funding between longs and shorts. These LPs usually trade gold at a persistent premium over spot, which the monitor measures instead of assuming it away.
Oracle-priced LPs
Orders fill at an oracle mark plus a price impact that grows with size; there is no public book to walk. Holding costs follow the long/short mix of the market, so a snapshot of today’s rate is not a forecast. Trading hours can follow the underlying market.
Partner books
Independently operated books and pools that publish their counterparty, pricing and custody terms and pass the same checks as any other route.
To protect the routing strategy, public pages do not name individual LPs. After sign-in, the console shows the channels you use as “Liquidity channel 1/2/3”; when you sign, your wallet shows the actual counterparty.
How routes qualify
- The market rules are readable: contract units, quote direction, trading session and minimum size.
- Prices are fresh; a stale or incomplete book pauses new decisions instead of guessing.
- Depth is compared with the intended size; a route too thin for the order is marked and skipped.
- Fees, funding and exit cost are known before the decision, at the intended size.
- There is an independent exit, and every authorization can be revoked by the customer.
- On anomalies (an uncertain result, a missing report) new risk pauses; exits are never blocked by entry filters.
Collateral is not automatically shared across LPs. Each eligible destination needs its own available margin. A route change applies to new decisions; existing positions stay where they were opened.
Independent & partner books
The adapter design supports established protocols and independently operated books under the same acceptance standard. Market data, fees, execution evidence, account permissions and withdrawal rules must be inspectable.
HyperMatch supports persistent principal paper accounts with positions, margin, realized P&L and a dealer ledger. Administrators distinguish agency, principal and hybrid configurations. Each published book identifies its counterparty, pricing and custody terms. The separate USDC account uses confirmed deposits, isolated margin and funded company capital; the server blocks new positions until custody and continuous risk supervision are ready.
Risks by architecture
- Order books. Thin depth at size, funding that can swing sharply in a single hour, liquidation, and the operator’s own vault or market-maker risk.
- Oracle-priced. Oracle delay or failure, impact that grows with size, holding costs that change with the market mix, and session closures.
- All onchain LPs. Smart-contract risk, network congestion, restricted withdrawals, the LP’s own operational risk and your wallet’s security. Permission limits and a non-custodial design do not remove these risks.
LP availability and market specifications can change. Being part of the network is not an approved route or a promise of execution.