# Partnerships

Most "partnerships" in the Web3 space are little more than co-marketing announcements. For institutions, integrating with a decentralized exchange usually means taking on immense counterparty risk—wrapping assets, bridging funds, or surrendering capital to an audited (but exploitable) central smart contract.

The industry operates under the Liquidity Silo Illusion: the belief that to participate in a liquidity network, you must physically move your money into it.

OnNexus flips this model. We are not building a walled garden; we are building a Sovereign Execution Backend. A partnership with OnNexus does not mean you send us capital. It means you deploy a Nexus Node behind your own firewall, plugging your existing capital into a global coordination layer while retaining absolute cryptographic custody.

We are actively seeking integration with four specific profiles of institutional partners:

#### Proprietary Trading Teams (Quants) & Liquidity Providers

For latency-sensitive traders and quantitative funds, OnNexus offers a direct programmatic pipeline to retail and institutional order flow.

* The Proposal: Deploy a Maker Node. Connect your proprietary algorithmic pricing models (CPMM, CLMM, Limit Orders) directly to the Nexus Composer.
* The Value: Execute high-frequency market-making strategies directly from your own self-custodial wallets. Zero smart contract risk. Zero cost for un-filled orders. Pure, non-dilutable fee generation.

#### Asset Management Firms & Treasuries

For Bitcoin miners, family offices, and enterprise treasuries holding massive, idle BTC reserves.

* The Proposal: Deploy a passive Maker Node using our [Fair Proportion Single-Sided Liquidity (FPSSL)](/yield-economics-and-amm-design/fpssl.md) architecture.
* The Value: Generate continuous, mathematically predictable yield on your native Bitcoin without ever exposing your principal to impermanent loss against volatile quote assets. Your Treasury remains secure in your [MPC policy engine](/deployment-and-integration/institutional-mpc.md).

#### Centralized Exchanges (CEX)

CEXs historically struggle to offer their users deep, native DeFi access without incurring massive bridge-building overhead or forcing users onto fragmented L2s.

* The Proposal: Integrate the Nexus Composer API directly into your exchange's backend or Web3 wallet offering. Additionally, deploy your idle exchange treasury into a Maker Node.
* The Value:
  * For your users: They gain immediate, seamless access to native Bitcoin liquidity and trading pairs, routed effortlessly through your frontend.
  * For your exchange: You monetize your idle cold-storage treasury by acting as a Liquidity Provider for the network, earning OnNexus yield without moving funds out of institutional custody.

#### Bitcoin Asset Bridges

For bridging protocols attempting to unify liquidity across disparate Bitcoin Layer 2s and sidechains.

* The Proposal: Utilize OnNexus as your underlying cryptographic settlement engine.
* The Value: Route cross-chain intents through the Nexus coordination layer to ensure your users receive the best possible execution price natively on L1 before the asset is bridged, ensuring zero slippage and MEV protection during the transition.

***

#### Technical Integration & Contact

Integration with OnNexus is a technical deployment, not a marketing exercise. We provide the binaries, the API documentation, and direct engineering support to ensure your Nexus Node is tightly coupled with your internal risk-engines.

If your institution fits the profiles above and is ready to deploy sovereign capital, initiate the technical onboarding process:

📧 Contact the Infrastructure Team: <hello@on.nexus>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.on.nexus/resources-and-legal/partnership.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
