L1 Settlement

Bitcoin Layer 1 settlement provides the cryptographic and consensus foundation for all DotSwap Nexus operations. The protocol leverages three core Bitcoin primitives to achieve trustless multi-party coordination without introducing additional security assumptions.

Core Primitives

DotSwap Nexus builds upon Bitcoin's fundamental cryptographic and consensus mechanisms:

• UTXO Model: Every transaction output represents verifiable ownership through cryptographic signatures, enabling precise tracking of asset states and ownership transfers

• Multi-Signature Scripts: Native Bitcoin functionality requiring multiple parties for spending authorization, eliminating single points of control

• PSBT Standard: Secure format for coordinating signatures across multiple parties before transaction broadcast, enabling complex multi-party transactions

Settlement Workflow

The protocol implements a systematic approach to transaction coordination that maintains security while enabling complex operations:

1. Intent Submission → User submits swap parameters with slippage tolerance
2. PSBT Construction → Nexus Composer builds transaction with multi-party inputs/outputs  
3. Maker Signature → Liquidity providers sign their respective inputs
4. Taker Signature → User reviews and signs final transaction
5. Broadcast & Settlement → Transaction propagates to Bitcoin network for confirmation

Trust Model

DotSwap Nexus achieves cryptographic trustlessness through systematic elimination of trusted third parties and reliance solely on Bitcoin's consensus mechanism.

Fundamental Trust Assumptions:

• Bitcoin's consensus mechanism remains secure and operational

• Cryptographic signatures provide reliable ownership proof

• PSBT standard correctly implements multi-party transaction coordination

Trustless Operation Mechanisms:

Component	Trust Elimination Method	Verification Approach
Asset Custody	Funds remain in user-controlled wallets until atomic execution	Users verify ownership through private key control
Transaction Execution	All operations embedded in verifiable Bitcoin transactions	Complete blockchain transparency and auditability
Price Formation	Aggregated from publicly declared curves	Real-time verification through node operation or API queries
Settlement Finality	Bitcoin consensus provides irreversible confirmation	Standard block explorer verification

User Verification Capabilities:

Independent Node Operation: Users can run personal Bitcoin nodes to independently verify complete transaction history and UTXO states, Runes and BRC-20 token transfers through blockchain indexing, and DotSwap protocol compliance through transaction analysis.

Protocol Transparency: All protocol operations remain visible through open-source node implementations enabling independent verification, public PSBT templates and signature verification, and transparent fee calculations and distribution mechanisms.

Permissionless Auditing: Any party can verify protocol integrity through blockchain analysis tools tracking all protocol transactions, independent curve verification against published liquidity data, and statistical analysis of execution quality and fee distribution.

Security Guarantees:

• No Rug Pull Risk: Impossible due to non-custodial design and atomic execution

• No Smart Contract Risk: Pure Bitcoin script execution without complex contract logic

• No Bridge Risk: Direct Bitcoin Layer 1 settlement eliminates cross-chain dependencies

• No Upgrade Risk: Protocol changes require explicit user adoption rather than forced updates

Channel Extensions

For enhanced performance, the protocol supports additional settlement mechanisms:

• 2-of-2 Multi-sig Channels: Enable rapid settlement for frequent traders

• HTLC Safeguards: Ensure unilateral fund recovery if counterparties become unavailable

L1 Settlement vs. L2 High-Frequency Execution

The Nexus Protocol employs a layered architecture to resolve the scalability constraints of the Bitcoin network while inheriting its security.

• Layer 1 (L1) The Settlement Layer (Bitcoin Mainnet):

  • Role: Acts as the "Supreme Court" and final custodian of assets.

  • Function: L1 is utilized strictly for Funding (opening channels/injecting liquidity) and Settlement(closing channels/withdrawing funds).

  • Security: All assets within the 3/3 channels are anchored by on-chain UTXOs, ensuring that users retain cryptographic control over their funds.

• Layer 2 (L2) The Execution Layer (Nexus State Channels):

  • Role: Functions as the high-velocity transaction highway.

  • Function: Trading, order matching, and state updates occur off-chain via Commitment Transactions. These updates are cryptographically signed by channel participants but are not broadcast to the Bitcoin mainnet until necessary, enabling millisecond-level latency and near-zero gas fees.

  • Mechanism: Users transact within these state channels. The channel state is updated locally, and only the final balance is settled to L1 upon exit.

Counterparty Architecture: Who Are You Trading With?

Nexus introduces a "Joint Market Making" model that abstracts complex channel management into a unified liquidity pool experience.

• The User’s Perspective (Trader):

  • Traders interact with the Nexus L2 Liquidity Pool. The experience mirrors a standard AMM (like Uniswap), in which users swap assets (e.g., BTC for USDC) against the pool without managing channel complexity.

• The Liquidity Provider’s Perspective (The 3/3 Channel):

  • The "Counterparty" backing the pool is not a single entity but a 3-of-3 Multi-Sig Channel composed of three distinct parties:

    • Single-Sided LP A: Provides the Base Asset (e.g., BTC).

    • Single-Sided LP B: Provides the Quote Asset (e.g., USDC).

    • The Protocol Node: Acts as the coordinator and "Connector," injecting dual-sided assets to facilitate channel settlement and routing.

  • The "Joint" Logic: The protocol matches single-sided LP A with single-sided LP B. Together with the Protocol Node, they form a consolidated liquidity position that the Trader executes against.

FPSSL and 3/3 Channel Rebalancing

To ensure the Fair Single-Sided Liquidity Provision (FPSSL) promised by our mathematical framework, which specifically entails symmetric Impermanent Loss (IL) and fair fee distribution, the 3/3 channel performs dynamic internal rebalancing.

• The Trigger:

  • As traders swap against the pool, the ratio of assets in the channel changes, and the price (P) shifts.

  • According to the FPSSL Uniqueness Theorem, specific allocation weights (α_BTC and α_USD) must be maintained to ensure fairness.

• The Rebalancing Mechanism:

  • Calculation: The protocol calculates the required "Rebalancing Amount" based on the new price and accumulated fees to ensure both LPs maintain their fair share of the channel's total value.

  • Execution: A new Commitment Transaction is constructed within the L2 channel. This transaction logically redistributes the ownership of the underlying UTXO between the BTC side and the USD side without requiring an on-chain transaction.

  • Result: This mechanism ensures that when LPs eventually withdraw to L1, their realized returns (including fees and IL) strictly adhere to the "Equal Native-Percentage Performance" principle, regardless of which asset they originally deposited.