# Fast Execution Accounts

While [L1 Settlement](/protocol-architecture/l1-settlement.md) provides absolute finality, high-frequency quant trading and institutional market-making require execution speeds that transcend the 10-minute Bitcoin block time.

Nexus resolves the inherent scalability constraint of the Bitcoin network through Fast Execution Accounts (State Channels), an L2 Execution Layer that inherits all L1 security guarantees while enabling millisecond latency.

Settlement Layer (L1) vs Execution Layer (L2)

The architecture is explicitly separated:

* Layer 1 (L1) The Settlement Layer: Acts as the final custodian. L1 is strictly used for Funding (opening channels/injecting liquidity) and Settlement (closing channels/withdrawing funds).
* Layer 2 (L2) The Execution Layer: Functions as the high-velocity transaction highway. Trading, order matching, and FPSSL rebalancing occur off-chain via Commitment Transactions.

These deferred state updates are cryptographically signed via [PSBTs](/protocol-architecture/psbt-engine.md) by channel participants, but they are not broadcast to the Bitcoin mainnet until necessary. This aggregate state rolling enables near-zero gas fees per trade.

The 3/3 Channel Architecture

To abstract complex channel management away from the Taker, Nexus implements a "Joint Market Making" model backing the liquidity pools.

The "Counterparty" providing liquidity to a swapper is a 3-of-3 Multi-Sig Channel composed of:

1. Single-Sided LP A: Provides the Base Asset (e.g., BTC).
2. Single-Sided LP B: Provides the Quote Asset (e.g., USDC).
3. The Protocol Node: Acts as the network coordinator, routing requests and injecting dual-sided matching to facilitate channel settlement.

#### HTLC Safeguards & Rollup Dynamics

For dynamic clearance during high-oscillation periods, Fast Execution Accounts combine with Hash Time Locked Contracts (HTLCs).

Because Make/Take trades adjust the ratio of assets in the channel and accumulate trading fees, the protocol mathematically computes required "Rebalancing Amounts" in real-time (following the [FPSSL formulas](/yield-economics-and-amm-design/fpssl.md)). A new Commitment Transaction is signed within the channel, logically redistributing UTXO ownership between the internal LPs without requiring an immediate on-chain settlement.

Once LPs exit, the final netted state rolls up to L1.

***

#### 📚 Concept Guide

<details>

<summary><strong>Fast Execution Account</strong></summary>

A Layer-2 state channel implementation built on Hash Time Locked Contracts (HTLCs). It acts as the backbone for high-frequency market-making, allowing participants to consolidate hundreds of separate trades and fee payments off-chain, deferring the expensive L1 network settlement to a single aggregated closure.

</details>

<details>

<summary><strong>HTLC (Hash Time Locked Contract)</strong></summary>

A foundational Bitcoin script condition used extensively inside Fast Execution Accounts. It creates cryptographically secure escrows that mathematically guarantee funds will either be settled upon the revelation of a secret hash, or safely refunded after a predefined block height.

</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/protocol-architecture/fast-execution-accounts.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.