Nodes

Overview

Solarious nodes are independent network participants that maintain blockchain state, exchange blocks and transactions over the P2P network, and expose RPC and API interfaces for external services and applications.

To simplify deployment, we provide a ready-to-use Docker image and a docker compose configuration. A node can operate either as a regular network node or, if explicitly enabled, as a validator node.

In addition to network participation, Solarious supports an external reward mechanism for node operators. This mechanism is designed to encourage geographic distribution of nodes, improve P2P connectivity, and increase the availability of blockchain data across the network.

Node Types

Solarious currently supports two main node modes.

Full Node

A full node stores the complete blockchain history and provides the maximum amount of data to the network. This mode requires more disk space and generally more stable infrastructure, but it is also the preferred mode for operators who want the highest level of network participation and the highest reward tier.

Configuration:

PRUNING=nothing

Pruned Node

A pruned node stores only recent blockchain data and removes older blocks according to the configured pruning policy. This reduces storage requirements and lowers infrastructure costs, but also limits the amount of historical data the node can serve to other peers.

Configuration:

PRUNING=custom

Pruned nodes are suitable for operators who want to participate in the network with lower resource usage. Reward levels for pruned nodes are lower than for full nodes.

Recommended Hardware

Minimum recommended resources for both node types:

• CPU: 4 cores
• RAM: 8 GB
• Storage: 200 GB SSD (for full nodes, more may be required over time)
• Network: stable high-speed internet connection

Full nodes and validators benefit significantly from better SSD performance, lower latency, and stable peer connectivity.

Reward Model

Solarious uses an external reward service to distribute rewards to node operators. Rewards are not produced by the consensus protocol itself and are not part of the standard staking reward flow. Instead, the external service evaluates node activity and sends rewards to the configured wallet address.

Rewards depend on the following factors:

• node availability and uptime
• synchronization status
• node type
• successful heartbeat reporting
• compliance with the required network configuration
• minimum staking requirements on the reward recipient account

Each node periodically reports its status to the reward server using the configured heartbeat settings.

Docker Compose Configuration

Use the following docker compose configuration to run a node:

services:
  solarious-node:
    image: ghcr.io/0xdino/solarious-node:latest
    container_name: solarious-node
    restart: unless-stopped
    environment:
      # Set: nothing, custom
      - PRUNING=nothing
      # Set: recipient address
      - ACCOUNT=0x0000000000000000000000000000000000000000
 
      - CHAIN_ID=804223
      - MONIKER=solarious-node
      - LOGLEVEL=info
      - CHAINDIR=/solarious
 
      - PRUNING_KEEP_RECENT=10000
      - PRUNING_INTERVAL=10
      - MIN_RETAIN_BLOCKS=10000
 
      - MIN_GAS_PRICES=1000000000asolar
      - SEEDS=
      - PERSISTENT_PEERS=bb377d040b4b0c3fb7fb019eedced2ec6ab67dc3@113.30.190.39:26656
      - EXTERNAL_ADDRESS=
 
      - ENABLE_API=true
      - ENABLE_JSON_RPC=true
      - ENABLE_WS=true
      - ENABLE_GRPC=true
      - ENABLE_PROMETHEUS=true
 
      - HEARTBEAT_RPC=http://localhost:26657
      - HEARTBEAT_SERVER=https://relayer-testnet.solarious.io/nodes/heartbeat
      - HEARTBEAT_INTERVAL=60s
 
      # Keep empty to disable validator mode.
      # If VALIDATOR_MNEMONIC is set, entrypoint starts validator bootstrap flow.
      # IMPORTANT: PRUNING must be nothing.
      # IMPORTANT: Save copy of generated keys and state files:
      # data/config/priv_validator_key.json
      # data/config/priv_validator_state.json
      # data/config/node_key.json
      - VALIDATOR_MNEMONIC=
      - VALIDATOR_KEY_NAME=validator
      - VALIDATOR_NODE_RPC=http://127.0.0.1:26657
      - VALIDATOR_DENOM=asolar
      - VALIDATOR_MIN_DELEGATION=5000000000000000000000
      - VALIDATOR_MIN_SELF_DELEGATION=1
      - VALIDATOR_GAS_PRICES=1000000000asolar
      - VALIDATOR_COMMISSION_RATE=0.10
      - VALIDATOR_COMMISSION_MAX_RATE=0.20
      - VALIDATOR_COMMISSION_MAX_CHANGE_RATE=0.01
      - VALIDATOR_RPC_WAIT_ATTEMPTS=30
      - VALIDATOR_RPC_WAIT_SECONDS=2
      - VALIDATOR_BLOCK_WAIT_ATTEMPTS=512
      - VALIDATOR_BLOCK_WAIT_SECONDS=2
    ports:
      - '26656:26656'
      - '26657:26657'
      - '1317:1317'
      - '8545:8545'
      - '8546:8546'
      - '9090:9090'
    volumes:
      - ./data:/solarious
    logging:
      driver: 'json-file'
      options:
        max-size: '50m'
        max-file: '3'
    stop_grace_period: 1m
    mem_reservation: 512m
    healthcheck:
      test: ['CMD', 'curl', '-f', 'http://localhost:26657/status']
      interval: 30s
      timeout: 5s
      retries: 5

Validator Requirements

Before enabling validator mode, make sure the following conditions are met:

• the node is running in full node mode
• the node is fully synchronized
• the wallet contains enough balance for validator creation
• the infrastructure is stable enough for continuous operation
• validator key files are properly backed up

Validator Keys

The following files are critical for validator operation:

• /data/config/priv_validator_key.json
• /data/config/priv_validator_state.json
• /data/config/node_key.json

These files must be backed up after validator creation.

Slashing Risks

Running a validator introduces operational risks:

• downtime may lead to penalties
• double-signing may result in slashing
• running multiple nodes with the same validator key is unsafe
• incorrect state restoration may break validator operation

Validator mode should only be used by experienced operators.