# Intent-Based Execution

> ‼️ Nexus is materially different from conventional Bitcoin yield offerings, including centralized yield desks, custodial trading venues, and wrapped-Bitcoin DeFi structures.

In standard DeFi protocols, traders must submit explicit on-chain instructions (e.g., "Swap 1 BTC for EXACTLY X RUNES, executing Route A -> Route B"). This leaks strategy to the mempool and severely limits execution optimization.

Nexus Protocol employs an Intent-Based Execution model. Takers (Trading Firms, Retail Swappers) only dictate their *desired outcome*, allowing the Nexus Composer to independently decipher the optimal execution path across all available Maker nodes.

#### Execution Architecture

The Intent-Based workflow separates the *discovery* of liquidity from the *settlement* of liquidity.

{% stepper %}
{% step %}

1. Intent Submission (Off-Chain)

The Taker submits an encrypted JSON intent to the Nexus network. The intent specifies the input asset, desired output asset, sizing, and explicit slippage/fee constraints.
{% endstep %}

{% step %}
2\. Quotation Engine

The Nexus Composer broadcasts this intent securely to the network of Institutional Makers and standalone Nexus Nodes. Each Maker's quantitative engine evaluates the request and responds with a guaranteed execution quote.
{% endstep %}

{% step %}
3\. PSBT Assembly

Once the Composer identifies the optimal path (often breaking the order into discrete tranches across multiple Makers via [Multi-Maker Routing](/trading-and-routing-strategies/routing.md)), it constructs the raw Partally Signed Bitcoin Transaction (PSBT).
{% endstep %}

{% step %}
4\. Client Verification & Signature

The compiled PSBT is routed back to the Taker. Because it strictly adheres to the PSBT layout, the Taker can cryptographically verify that the outputs meet the strict parameters of their original intent. If constraints are met, the Taker signs the final input payload.
{% endstep %}

{% step %}
5\. Finality

The fully formed transaction is either settled instantly to an [HTLC State Channel](/protocol-architecture/fast-execution-accounts.md) or broadcast directly into the L1 mempool for absolute finality.
{% endstep %}
{% endstepper %}

#### Programmable Risk Management

Because Intents dictate the exact mathematical boundaries of a trade before any on-chain action occurs, Takers can cryptographically encode strict risk-protection parameters directly into their request. The PSBT will mathematically fail to assemble if these parameters are violated by the market makers:

* Slippage Tolerance (1% - 50%): Enforces a rigid floor on the output amount. If volatility slippage or routing slippage causes the final output to fall below this parameter, the Taker's signature is never applied.
* Execution Deadlines: Using Bitcoin's native `nLockTime` or block-height constraints, intents can be programmed to automatically expire (e.g., after 6 blocks) to prevent stale liquidity from locking up operational capital.
* Fee Ceilings: Takers define an absolute maximum for L1 mining fees and routing network fees. If the network becomes congested and the fee exceeds this cap, the intent is safely discarded without costing the Taker any gas.

#### Unified Liquidity: Bridging AMM & CLOB

Because users only sign off-chain "Intents" (I want X for Y) rather than interacting with a discrete on-chain smart contract, the coordinating engine is completely agnostic to where the counter-liquidity originates.

This architecture fundamentally resolves the classic DeFi division between Automated Market Makers (AMM) and the Central Limit Order Book (CLOB):

* A Maker can deploy a quantitative `x*y=k` price curve (AMM).
* A Maker can deploy a static, single-price Limit Order (CLOB).

From the perspective of the Nexus Composer and the resulting PSBT, *they are mathematically identical*. Both are simply inputs and outputs waiting to be matched. A trader's intent can be seamlessly filled by routing $1M through a blend of CPMM curves and three overlapping Limit Orders simultaneously, settling them together into a single, unified execution path.

#### Institutional Execution Benefits

* No Execution Reverts: L1 transaction fees are ONLY paid when a fully valid, fully matched, cryptographically sound swap occurs. Failed intents do not cost gas.
* Complex Transaction Abstraction: Traders benefit from fragmented multi-maker liquidity depths without needing to comprehend the underlying UTXO graph merging.
* MEV Safety: Since intents are resolved purely off-chain, front-running bots cannot weaponize public mempool data.

***

#### 📚 Concept Guide

<details>

<summary><strong>Intent-Based Execution</strong></summary>

A structural pivot away from contract-driven DeFi. Rather than broadcasting specific execution commands (e.g., "Use Route A to swap X"), Takers only cryptographically sign their *desired outcome* (e.g., "I will output X only if I receive Y"). This closes the vulnerability to front-running and MEV since the strategy is never exposed.

</details>

<details>

<summary><strong>Nexus Composer</strong></summary>

The central parsing and routing entity. It receives market intents from Takers, matches them against the optimal liquidity curves generated by Maker nodes, and constructs the mathematical foundation of the draft PSBT. The Composer never holds funds.

</details>


---

# 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/trading-and-routing-strategies/intent-execution.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.