Validator Staking Guide
This guide will walk you through the process of staking ARCH tokens to become a validator on the Arch Network. As a validator, you'll 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
Contact the Arch Network team for current staking requirements, including:
- Minimum stake amounts
- Lockup periods
- Commission rates
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
cli validator start \
--network-mode mainnet \
--titan-rpc-endpoint your_endpoint \
--titan-rpc-port your_port \
--titan-rpc-username your_username \
--titan-rpc-password your_password \
--titan-rpc-wallet your_wallet
Monitoring & Maintenance
📊 Health Checks
# Node status
cli validator status
# Performance metrics
cli validator metrics
🔄 Sync Management
# Check sync status
cli validator sync-status
# Force resync if needed
cli validator resync
Understanding Staking in Arch Network
🔐 What is Staking?
Staking in Arch Network is fundamentally different from traditional Proof of Stake systems. Instead of using staking for consensus, Arch Network uses 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
- Registration: Complete validator registration through the network portal
- Stake Deposit: Transfer ARCH tokens to the validator staking contract
- 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
📊 Staking Economics
Validator Requirements
- Minimum Stake: Contact Arch Network team for current requirements
- Lockup Period: Network-defined based on security requirements
- Uptime Requirement: High availability expected for signing participation
- Performance Bonding: Stake acts as bond for correct behavior
Reward Structure
- 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
🔄 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