Running Your Node

⚠️ Mainnet Status: Arch Network mainnet has not launched yet. This guide currently covers testnet operations. ARCH token staking and mainnet validator operations will be available when mainnet launches. More details coming soon.

πŸ”’ Validator Pool Status: The staking validator pool is currently closed membership. When mainnet launches, the validator pool will initially be limited to approved participants and will be opened to the public at some point in the future.

This guide will walk you through the process of operating an Arch Network validator node on testnet, including future staking mechanisms and network participation. When mainnet launches, validator operators will be an integral part of the network’s security and computation infrastructure.

Prerequisites

πŸ–₯️ System Requirements

ComponentMinimumRecommended
CPU4+ cores8+ cores
RAM16GB32GB
Storage100GB SSD500GB+ SSD
Network100Mbps1Gbps+
OSUbuntu 20.04+ / macOS 12.0+Latest LTS

πŸ”‘ ARCH Tokens (Future Mainnet)

⚠️ Not yet available: ARCH token staking will be available for approved validators when mainnet launches. The staking validator pool is currently closed membership.

  • Minimum stake amounts (TBD)
  • Lockup periods (TBD)
  • Commission rates (TBD)
  • Application process for validator pool membership (TBD)

Current Testnet: No ARCH tokens required - use the faucet for test tokens.

More details about mainnet staking and validator pool access will be announced closer to mainnet launch.

Validator Responsibilities

πŸ”„ Transaction Processing

  • Execute programs in Arch VM
  • Validate transaction signatures
  • Process Bitcoin-related transactions
  • Maintain transaction history

🀝 Consensus Participation

  • Participate in ROAST protocol
  • Contribute to threshold signing
  • Coordinate transaction finality
  • Verify state transitions

πŸ“Š State Management

  • Track UTXO states
  • Validate Bitcoin operations
  • Maintain state consistency
  • Verify network state

Setup & Configuration

1. Install Arch Network CLI

macOS - Apple Silicon

curl -L -o cli https://github.com/Arch-Network/arch-node/releases/latest/download/cli-aarch64-apple-darwin
chmod +x cli
sudo mv cli /usr/local/bin/

macOS - Intel

curl -L -o cli https://github.com/Arch-Network/arch-node/releases/latest/download/cli-x86_64-apple-darwin
chmod +x cli
sudo mv cli /usr/local/bin/

Linux - x86_64

curl -L -o cli https://github.com/Arch-Network/arch-node/releases/latest/download/cli-x86_64-unknown-linux-gnu
chmod +x cli
sudo mv cli /usr/local/bin/

Linux - ARM64

curl -L -o cli https://github.com/Arch-Network/arch-node/releases/latest/download/cli-aarch64-unknown-linux-gnu
chmod +x cli
sudo mv cli /usr/local/bin/

Verify installation:

cli --version

2. Configure Bitcoin Node Access

Regtest/Development:

--bitcoin-rpc-endpoint bitcoin-node.dev.aws.archnetwork.xyz \
--bitcoin-rpc-port 18443 \
--bitcoin-rpc-username bitcoin \
--bitcoin-rpc-password your_password \
--bitcoin-rpc-wallet testwallet

Testnet:

--bitcoin-rpc-endpoint bitcoin-node.test.aws.archnetwork.xyz \
--bitcoin-rpc-port 49332 \
--bitcoin-rpc-username bitcoin \
--bitcoin-rpc-password your_password \
--bitcoin-rpc-wallet testwallet

πŸ–₯️ Local Node

For advanced users who want full control. See our Bitcoin Node Setup Guide.

Local Regtest Configuration:

--bitcoin-rpc-endpoint 127.0.0.1 \
--bitcoin-rpc-port 18443 \
--bitcoin-rpc-username your_username \
--bitcoin-rpc-password your_password \
--bitcoin-rpc-wallet regtest

Local Testnet Configuration:

--bitcoin-rpc-endpoint 127.0.0.1 \
--bitcoin-rpc-port 18332 \
--bitcoin-rpc-username your_username \
--bitcoin-rpc-password your_password \
--bitcoin-rpc-wallet testnet

Local Mainnet Configuration:

--bitcoin-rpc-endpoint 127.0.0.1 \
--bitcoin-rpc-port 8332 \
--bitcoin-rpc-username your_username \
--bitcoin-rpc-password your_password \
--bitcoin-rpc-wallet mainnet

3. Start Your Validator

⚠️ Current Status: Mainnet is not yet available. Use testnet for current operations.

For Testnet (Currently Available):

cli validator-start \
  --network-mode testnet \
  --titan-endpoint titan-node.test.aws.archnetwork.xyz \
  --titan-socket-endpoint titan-node.test.aws.archnetwork.xyz:49332

For Mainnet (Future):

# Mainnet configuration will be available when mainnet launches
cli validator-start \
  --network-mode mainnet \
  --titan-endpoint <mainnet-endpoint-tbd> \
  --titan-socket-endpoint <mainnet-socket-tbd>

Monitoring & Maintenance

πŸ“Š Health Checks

# Node status
arch-cli validator status

# Performance metrics
arch-cli validator metrics

πŸ”„ Sync Management

# Check sync status
arch-cli validator sync-status

# Force resync if needed
arch-cli validator resync

Understanding Staking in Arch Network (Future)

⚠️ Note: The staking mechanisms described below are planned for mainnet launch and are not currently available. Current testnet operations do not require ARCH token staking.

πŸ” What will Staking be?

Staking in Arch Network will be fundamentally different from traditional Proof of Stake systems. Instead of using staking for consensus, Arch Network will use staked validators to participate in the ROAST protocol for secure Bitcoin transaction signing.

flowchart TB
    subgraph Staking["Staking Process"]
        direction TB
        V[Validator Node] -->|1. Stakes ARCH| N[Network]
        N -->|2. Assigns Share| DKG[Distributed Key]
        DKG -->|3. Participates in| ROAST[ROAST Protocol]
    end

    subgraph Validation["Transaction Validation"]
        direction TB
        TX[Transaction] -->|1. Submitted| L[Leader]
        L -->|2. Distributes| VS[Validator Set]
        VS -->|3. Execute & Sign| R[Results]
        R -->|4. Aggregate| BTC[Bitcoin Network]
    end

    style Staking fill:#f3e5f5,stroke:#4a148c
    style Validation fill:#e8f5e9,stroke:#1b5e20

πŸ€” Solana vs. Arch Network: Validator Comparison

FeatureSolanaArch Network
Consensus Role Validators vote on blocks and produce blocks when selected as leader Validators execute transactions and sign Bitcoin transactions using threshold signatures
Economic Model Block rewards + transaction fees Transaction fees + commission from Bitcoin operations
Selection Mechanism Stake-weighted leader selection Stake-weighted participation in threshold signing committee
Performance Metrics Vote signing speed, block production, uptime Transaction execution correctness, signing participation, uptime
Slashing Conditions Double signing, unavailability Malicious signing, transaction manipulation attempts
Hardware Requirements High-end CPU, 128GB+ RAM, 2TB+ NVMe 4+ CPU cores, 16GB+ RAM, 100GB+ SSD

πŸš€ From Solana to Arch: Operational Transition Guide

If you’re an experienced Solana validator operator, here’s what you need to know about running an Arch Network validator:

βš™οΈ Technical Setup

  • Lower Hardware Requirements: Arch Network requires less powerful hardware than Solana
  • Bitcoin RPC Access: Validators need Bitcoin node access (remote or local)
  • Key Management: Different key structure focusing on distributed key generation
  • Monitoring: Focus on signing participation rather than block production

πŸ’° Economic Considerations

  • Staking Return Model: Fee-based with transaction execution rewards
  • Reward Distribution: Based on stake proportion and signing participation
  • Commission Structure: Set during validator configuration
  • Lockup Periods: Network-defined based on security requirements

πŸ”„ Operational Differences

  • Signing vs. Voting: Focus on correct transaction execution and signing
  • Performance Metrics: Measured by signing participation and availability
  • Updates: Less frequent than Solana's rapid release cycle
  • Network Bandwidth: Lower requirements due to different architecture

πŸ›£οΈ Onboarding Process (Future Mainnet)

  • Application: Apply for validator pool membership (initially closed membership)
  • Approval: Await approval for validator participation
  • Registration: Complete validator registration through the network portal (TBD)
  • Stake Deposit: Transfer ARCH tokens to the validator staking contract (TBD)
  • Configuration: Set up your validator with proper Bitcoin node access
  • Key Generation: Participate in distributed key generation ceremony
  • Activation: Begin participation after stake activation period

Note: The validator pool will initially be limited to approved participants and will open to the public in the future.

πŸ§ͺ Current Testnet Onboarding

  • No Registration Required: Simply start a testnet validator
  • No Stake Required: Testnet operation is free
  • Configuration: Set up your validator with testnet endpoints
  • Testing: Deploy programs and test functionality
  • Immediate Participation: Begin testing immediately

πŸ“Š Staking Economics (Future Mainnet)

Validator Requirements (Planned)

  • Minimum Stake: TBD - Details will be announced before mainnet launch
  • Lockup Period: Network-defined based on security requirements (TBD)
  • Uptime Requirement: High availability expected for signing participation
  • Performance Bonding: Stake will act as bond for correct behavior

Reward Structure (Planned)

  • Base Rewards: From transaction fees distributed proportionally to stake
  • Signing Rewards: Additional rewards for participating in threshold signing
  • Commission: Set percentage of rewards retained by validator
  • Distribution Frequency: Continuous as transactions are processed

Current Testnet Operations

  • Open Access: Anyone can run a testnet validator
  • No Staking Required: Testnet validators operate without ARCH token requirements
  • Test Tokens: Use the faucet to get test tokens for transactions
  • No Rewards: Testnet operation is for testing and development only
  • Free Operation: No costs beyond infrastructure for testnet participation

Validator Types Comparison

Validator TypeAccessStakingRewards
Testnet Validators Open to all No staking required No rewards (testing only)
Mainnet Staking Validators Closed membership initially ARCH tokens required (TBD) Transaction fees + signing rewards

πŸ”„ ROAST Protocol Integration

The ROAST (Robust Asynchronous Schnorr Threshold) protocol enables validators to collectively sign Bitcoin transactions:

sequenceDiagram
    participant C as Client
    participant L as Leader
    participant V as Validators
    participant B as Bitcoin Network
    
    C->>L: 1. Submit Transaction
    L->>V: 2. Distribute to Validators
    V->>V: 3. Execute in Arch VM
    V->>L: 4. Sign Results
    L->>B: 5. Submit to Bitcoin

πŸ›‘οΈ Security Model

flowchart LR
    subgraph Security["Security Layers"]
        direction TB
        UTXO[UTXO Validation] -->|Verifies| Own[Ownership]
        Own -->|Ensures| State[State Consistency]
        State -->|Commits to| BTC[Bitcoin]
    end

    subgraph Threshold["Threshold Signing"]
        direction TB
        Val[Validators] -->|t-of-n| Sign[Signature]
        Sign -->|ROAST| Agg[Aggregation]
        Agg -->|Submit| Final[Final Transaction]
    end

    style Security fill:#e1f5fe,stroke:#01579b
    style Threshold fill:#fff3e0,stroke:#e65100

Key Features

  • Distributed key generation for secure signing
  • Threshold signature scheme (t-of-n) for fault tolerance
  • Bitcoin-based finality guarantees
  • Automatic malicious node detection