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
Component | Minimum | Recommended |
---|---|---|
CPU | 4+ cores | 8+ cores |
RAM | 16GB | 32GB |
Storage | 100GB SSD | 500GB+ SSD |
Network | 100Mbps | 1Gbps+ |
OS | Ubuntu 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
π‘ Remote Node (Recommended)
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
Feature | Solana | Arch 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 Type | Access | Staking | Rewards |
---|---|---|---|
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