Node Deployment Guide

Deploy the Dual-Mode Nexus Node to establish your sovereign execution presence.

Independent Nexus Node operation enables quantitative funds, latency-sensitive traders, and institutions to deploy self-hosted liquidity infrastructure with complete asset custody and highly customizable algorithmic trading strategies.

The Nexus Node distribution is a Dual-Mode Toolkit, operating as either a Maker Nexus (for liquidity provision and yield generation) or a Taker Nexus (for high-frequency arbitrage and strict fund protection).

📌 Nexus is self-custodial, meaning the asset owner retains control of their Bitcoin through their own infrastructure.

Deployment Fast-Lane

The following process outlines the safest and fastest way to bootstrap a standalone Nexus Node connected to the L1 Bitcoin Network and Nexus Composer.

1

Step 1: Infrastructure Provisioning

Deploy a secure environment for the Nexus Node binary. Recommended minimum specifications:

• 8 Core CPU

• 32GB RAM

• High-IOPS SSD (crucial for UTXO tracking and mempool synchronization).

2

Step 2: One-Command Installation

For first-time deployments and fast bootstrapping, execute the official installation script directly on your target server. This script fetches the necessary Docker topologies and environment scaffolds:

curl -fsSL https://on.nexus/install.sh | bash

For production environments, institutional operators are encouraged to review the script payload prior to execution.

3

Step 3: Wallet Initialization

During initialization, you must configure the operational wallets required by the Nexus Coordination Network. These variables will be injected into your .env configuration:

• POOLS_BTC_TOKEN: Assign specific UTXO subsets to power your passive Yield/Maker curves (e.g., FPSSL or CPMM).

• TAKERS_BTC_TOKEN: Assign separate, highly-liquid UTXO subsets to power your high-frequency Arbitrage routines.

• DOTSWAP_ACCOUNT_PRIVATE_KEY_HEX: The cryptographic credential proving node ownership to the Nexus Composer.

Note: In an Independent Nexus Node setup, these Trading Wallet keys sit in a hot/warm environment to enable millisecond response times. For enterprise cold-storage controls, refer to Institutional MPC Integration.

4

Step 4: Security Hardening (Critical)

Last but not least. Once your Nexus node is running stably and actively communicating with the Composer, you must perform the following critical security mitigation:

• Remove SSH Access: Return to your cloud firewall settings and disable rule 22 (SSH).

• Switch to Secure Tunnels: You should no longer connect via public SSH. Instead, rely exclusively on secure, in-browser identity management tools provided by your cloud host (e.g., AWS Session Manager, Linode Lish Console).

Advanced Configurations

If your institutional security policies prohibit arbitrary script execution (curl | bash), or if you require explicit mapping of Docker environment variables (APP_ENV, custom ZMQ_HOST endpoints) into existing CI/CD pipelines, you can utilize our Advanced Quick Deployment or Manual Source Deployment methods.

Please request the comprehensive Enterprise Configuration Manifest during your partner onboarding process via [email protected].

---

📚 Concept Guide

Trading Wallet

The specialized hot/warm wallet environment operated internally by the Self-Hosted Nexus Node. Unlike traditional custodial wallets, it serves purely as an execution vault, holding the private keys necessary exclusively for the cryptographic signing of off-chain intents at millisecond latencies.

Nexus Node

The core software binary hosted by participating institutions. It supports two concurrent operational models: Maker Nexus (configured specifically to run automated market-making algorithms to generate yield) and Taker Nexus (configured for high-frequency algorithmic traders and arbitrageurs to securely generate/sign optimal execution intents off-chain).