# Bridge Nodes (Celestia)
Source: https://docs.krews.xyz/dashboard/bridge-nodes

Live map of Celestia Bridge Nodes with country and provider distribution.

The **Bridge Nodes** page (Celestia‑specific) visualizes nodes that bridge Celestia’s DA to consensus endpoints, enabling data availability guarantees for the network.

<img alt="Bridgenodes1 Pn" />

## Metrics

* **Node Count** — Total observed bridge nodes.
* **Countries / Providers** — Jurisdictional and infra breakdown.
* **Live status** — Updated continuously from telemetry feeds.

<img alt="Bridgenodes2 Pn" />

## Uses

* Identify centralization risks in DA bridge topology.
* Confirm the presence of bridge nodes in your geographic region for latency budgeting.
* Monitor the growth/shrink dynamics of the bridging layer.


# Decentralization
Source: https://docs.krews.xyz/dashboard/decentralization

Geographic and provider distribution of nodes/validators with a 2-hour refresh cadence. Investigate concentration risks quickly.

The **Decentralization** page maps nodes/validators globally, surfacing geographic and provider concentration.

<img alt="Decentralization1 Pn" />

## What you see

* **Map view** with pins per node/validator. Popovers include **moniker**, **provider**, **location**, and (when available) **IP**.
* **Stats**: **Total Nodes**, **Countries**, **Providers**.
* **Charts**:
  * **Nodes by Country** — Which jurisdictions host the most nodes.
  * **Nodes by Provider** — Cloud/DC concentration.
* **Node List** table with **Moniker**, **Region**, **Country**, **City**, **Provider** and filters.

<img alt="Decentralization2 Pn" />

## Why decentralization matters

* **Jurisdictional risk**: Excess concentration in a single country increases correlated regulatory or outage risk.
* **Single‑provider risk**: Heavy reliance on one provider (e.g., a large cloud) creates common‑mode failure exposure.
* **Routing & latency**: Global spread can improve propagation and proposer timing stability.

## Practical analysis

* Filter by **provider** to check for outsized dependence (e.g., a single hyperscaler).
* Inspect **country** distribution before onboarding more validators or recommending infra choices to delegators.
* Use the table to verify operator diversity (regional mix, providers, and cities).


# Missed Proposals (Celestia)
Source: https://docs.krews.xyz/dashboard/missed-proposals

Recent proposer activity and misses, with context from block time dynamics.

The **Missed Proposals** page highlights proposer activity in recent blocks for **Celestia** and overlays it with timing signals.

<img alt="Missed Proposals1 Pn" />

## What is a missed proposal?

A **missed proposal** occurs when the designated proposer does not produce a valid block in the allotted round, leading to a round increment and a new proposer. This often manifests as:

* **Longer block intervals** (temporary spike in **Block Time (Avg)**), and
* Diagnostic traces showing round transitions.

## How to use the page

* Watch the **red markers/lines** for misses and compare with block interval changes.
* Correlate streaks of misses with **network health** or **regional outages**.
* Export segments where available for incident reviews.


# Validators
Source: https://docs.krews.xyz/dashboard/validators

Network-wide validator analytics: KPIs, distribution, and a sortable table for deep inspection across supported networks (Celestia, Story, Sunrise).

The **Validators** page provides a real-time overview of validator health, participation, and stake distribution. It combines high-level KPIs with an interactive table so you can quickly pivot from macro trends to specific operators.

<img alt="Validators2 Pn" />

## Key KPIs

* **Active Validators / Inactive Validators** — Count of validators currently in the active set versus those outside the set. Useful for tracking churn and network participation.
* **APR** — Network staking Annual Percentage Rate before validator commission. Values can vary by era/epoch and network economics.
* **Min Stake** — The smallest effective stake among validators in the **active** set. Indicates the current threshold to enter/maintain active status.
* **Avg. Commission** — Mean commission rate of the active set. Helps estimate post‑commission yield.
* **Block Time (Avg)** — Rolling average of block intervals. Spikes often correlate with network congestion or proposer round retries.
* **Bonded Tokens** — Total staked tokens securing the network.
* **Total Delegators** — Count of unique delegator accounts across validators.

**Time windows:** Top charts support **7D / 1M / 3M / All** to analyze short‑term vs long‑term trends for **Block Time**, **Bonded Tokens**, and **Total Delegators**.

## Validators Table

Sortable & searchable table with the following columns:

* **Moniker** — Validator display name.
* **Voting Power** — Effective stake. Sort to inspect concentration.
* **Cumulative Share** — Cumulative distribution curve position. Reveals how quickly stake concentrates.
* **Delegators** — Number of delegators bonded to the validator.
* **Uptime** — Observed signing participation over the selected window.
* **Commission** — Validator fee charged on rewards.

### Usage Scenarios

* **Find concentration risk:** Sort by **Voting Power** and read the **Cumulative Share** to detect the top X validators holding a majority of stake.
* **New delegator discovery:** Filter by **Commission** and **Uptime** to shortlist operators.
* **Trend audit:** Track **Block Time (Avg)** and **Bonded Tokens** together to correlate performance with staking behavior.

### Tips

* Use the search box to find a moniker or operator address.
* Combine column sorting with the top KPI charts’ time window for context.
* Click any validator row to open a detailed view (where supported by the network).


# Weekly Status
Source: https://docs.krews.xyz/dashboard/weekly-status

Week-over-week validator performance snapshots: uptime distribution, stake dynamics, and operator rankings. 

The **Weekly Status** page aggregates validator performance by ISO week, creating a consistent baseline for comparisons over time.

<img alt="Weekly Status1 Pn" />

## Headline Cards

* **Active Validators** — Validators observed as active during the selected week.
* **Highest / Lowest Uptime** — Best and worst weekly uptime among validators.
* **Avg. Mean Uptime** — Average of validators’ **mean uptime** during the week.
* **Net VP Change** — Sum of positive minus negative **Voting Power** changes across validators for the week.
* **Total VP Change** — Aggregate absolute VP movement (adds both increases and decreases).
* **Delegator Change** — Net change in the number of delegator accounts.
* **Replacements** — Count of operators that entered or exited the active set.

## Rankings

* **Top 5 Performers** — Validators with minimal misses and highest mean uptime.
* **Bottom 5 Performers** — Validators with elevated misses or low uptime.
* **Overall Uptime Range** — Distribution of weekly uptime (min–max bands).
* **VP Change Distribution** — Histogram showing stake shifts across operators.

## Table Columns

* **Moniker / Address**
* **Mean Uptime** (percentage) and **Mean Uptime (float)** (exact decimal, e.g., 99.3650%)
* **Max / Min Uptime**
* **Missed** — Count of missed blocks/proposals for the week (network‑specific logic)
* **Signed** — Signed block count
* **VP Change** — Voting Power change in the week

### How metrics are computed

* **Mean Uptime**: Average signing participation over all relevant blocks in the week for a validator.
* **Missed / Signed**: Derived from per‑block signatures; chain clients can expose this via RPC or indexers.
* **VP Change**: Computed from week‑start vs week‑end stake snapshots per validator.

### How to read the page

* Look at **Avg. Mean Uptime** to understand overall network health.
* Use **Top/Bottom 5** to spot outliers and potential incidents.
* Cross‑reference **VP Change Distribution** with **Delegator Change** to see if stake movement is retail‑ or whale‑driven.


# Installation
Source: https://docs.krews.xyz/full-node-installation/aptos

Run an Aptos Public Fullnode (PFN) on mainnet or testnet using Docker or from source. This guide follows the official Aptos docs and keeps only the essential steps.

<Note>
  This guide installs a **Public Fullnode (PFN)**. Choose **mainnet** or **testnet** by downloading the matching genesis & waypoint files.
</Note>

## 1) Prerequisites

* Linux x86\_64
* Docker (for the Docker path) **or** Rust toolchain (for source build)
* 1TB+ SSD recommended for longevity; see official requirements page if needed.

## 2) Create a PFN working directory

```bash theme={null}
mkdir -p ~/aptos-pfn && cd ~/aptos-pfn
```

## 3) Download network files (genesis & waypoint)

**Mainnet**:

```bash theme={null}
curl -O https://raw.githubusercontent.com/aptos-labs/aptos-networks/main/mainnet/genesis.blob
curl -O https://raw.githubusercontent.com/aptos-labs/aptos-networks/main/mainnet/waypoint.txt
```

**Testnet** (use the matching paths under `aptos-networks/testnet/`):

```bash theme={null}
# Example (confirm the exact filenames in the repo):
# https://github.com/aptos-labs/aptos-networks/tree/main/testnet
```

## 4) Create a PFN config

Copy the template and edit paths:

```bash theme={null}
# If building from source, after cloning aptos-core:
# cp config/src/config/test_data/public_full_node.yaml fullnode.yaml

# Alternatively, create a minimal fullnode.yaml and set:
# base:
#   waypoint:
#     from_file: "./waypoint.txt"
#   data_dir: "/var/lib/aptos/data"  # choose your data dir
# execution:
#   genesis_file_location: "./genesis.blob"
```

***

## Path A — Run with Docker

### A1) Prepare a local config file

Place `fullnode.yaml` in `~/aptos-pfn` (as shown above).

### A2) Start the container

```bash theme={null}
docker pull aptoslabs/validator:mainnet

docker run -d --name aptos-pfn   -v $(pwd):/opt/aptos/etc   -p 8080:8080 -p 9101:9101   aptoslabs/validator:mainnet   aptos-node -f /opt/aptos/etc/fullnode.yaml
```

* `-p 8080:8080` exposes the REST API.
* `-p 9101:9101` exposes metrics.

You can swap the image tag to the **testnet** variant if running on testnet.

***

## Path B — Build and run from source

### B1) Clone and build

```bash theme={null}
git clone https://github.com/aptos-labs/aptos-core.git
cd aptos-core
git checkout --track origin/mainnet   # or 'testnet'
cargo build -p aptos-node --release
```

### B2) Copy config and run

```bash theme={null}
cp config/src/config/test_data/public_full_node.yaml ~/aptos-pfn/fullnode.yaml
cd ~/aptos-pfn

# Edit fullnode.yaml so:
# - base.data_dir points to your data dir
# - base.waypoint.from_file points to ./waypoint.txt
# - execution.genesis_file_location points to ./genesis.blob

# Start the node
cargo run -p aptos-node --release -- -f ./fullnode.yaml
```

***

## 5) Verify the node

Once running, check health:

```bash theme={null}
curl -s http://localhost:8080/v1 | jq
```

Or follow the **Verify PFN** guide from Aptos docs.


# Installation
Source: https://docs.krews.xyz/full-node-installation/avail

Install and run an Avail full node on Mainnet or Turing Testnet using pre-built binaries, Docker, or by building from source. This guide is minimal by design—no upgrade or misc. command sections.

## System requirements

| Component       | Minimum  | Recommended |
| --------------- | -------- | ----------- |
| RAM             | 8 GB     | 16 GB       |
| CPU (amd64/x86) | 4 cores  | 8 cores     |
| Storage (SSD)   | 20–40 GB | 200–300 GB  |

Prefer a stable Linux server distribution. Plan a persistent data directory (e.g., `/var/lib/avail`).

## Choose a network

* **Mainnet**: `--chain mainnet`
* **Turing Testnet**: `--chain turing` (if your binary supports it) or use the Turing **chainspec** from Network Info and pass its file path: `--chain /path/to/turing/chainspec.raw.json`.

## Option A — Pre-built binary (recommended)

1. Download the latest tarball from [**Releases**](https://github.com/availproject/avail/releases/) and extract it.
2. Run the node with a persistent data path:

```bash theme={null}
mkdir -p /var/lib/avail
./avail-node --name "<your-node-name>" --chain mainnet -d /var/lib/avail
```

**Run on Turing (testnet):**

```bash theme={null}
./avail-node --name "<your-node-name>" --chain turing -d /var/lib/avail
# or provide the explicit chainspec file if needed:
# ./avail-node --name "<your-node-name>" --chain /path/to/turing/chainspec.raw.json -d /var/lib/avail
```

## Option B — Docker

```bash theme={null}
docker run --restart=on-failure -d   -v /root/avail/node-data:/da/node-data   -p 9944:9944 -p 30333:30333   docker.io/availj/avail:<LATEST-AVAIL-NODE-VERSION>   --chain mainnet -d ./output --name "<your-node-name>"
```

**Turing (testnet):**

```bash theme={null}
docker run --restart=on-failure -d   -v /root/avail/node-data:/da/node-data   -p 9944:9944 -p 30333:30333   docker.io/availj/avail:<LATEST-AVAIL-NODE-VERSION>   --chain turing -d ./output --name "<your-node-name>"
```

Replace `<LATEST-AVAIL-NODE-VERSION>` with the latest tag from Docker Hub or the Releases page.

## Option C — Build from source

```bash theme={null}
# Install Rust (if missing)
curl https://sh.rustup.rs -sSf | sh
source $HOME/.cargo/env

# Build
git clone https://github.com/availproject/avail.git
cd avail
cargo build --release --locked

# Run (Mainnet)
mkdir -p /var/lib/avail
./target/release/avail-node --name "<your-node-name>" --chain mainnet -d /var/lib/avail
```

**Run on Turing:**

```bash theme={null}
./target/release/avail-node --name "<your-node-name>" --chain turing -d /var/lib/avail
# or with an explicit chainspec file:
# ./target/release/avail-node --name "<your-node-name>" --chain /path/to/turing/chainspec.raw.json -d /var/lib/avail
```

## Verify the node

* Logs should show peers and heights, e.g. `Idle (N peers), best: #<height> ... finalized #<height> ...`
* Check **Telemetry**: find your node by its `--name` under the **Mainnet** or **Turing** tab.


# Installation
Source: https://docs.krews.xyz/full-node-installation/celestia

Install and run Celestia nodes (Light, Full Storage, Bridge) with a simple, production-ready workflow. This guide covers network selection for Mainnet and Mocha testnet.

<Note>
  This guide focuses on **celestia-node** (DA network) with optional notes for **celestia-app** (consensus). The steps below are intentionally minimal and point to the official docs for version specifics.
</Note>

## Prerequisites

* Ubuntu 22.04+ (or any modern Linux)
* `curl`, `jq`, `git`, `wget`, `make`
* Open the following ports on your firewall:
  * **2121** P2P
  * **26658** RPC
  * **26659** REST Gateway (optional)

<Steps>
  <Step title="Install celestia-node binary">
    ```bash theme={null}
    # Build from source (recommended official path)
    cd $HOME
    rm -rf celestia-node
    git clone https://github.com/celestiaorg/celestia-node.git
    cd celestia-node

    # Install (installs 'celestia' and 'cel-key' binaries to $GOBIN if configured)
    make node-install

    # Verify
    celestia version
    cel-key --help
    ```
  </Step>

  <Step title="Choose your network">
    Common options:

    * **Mainnet**: `--p2p.network celestia`
    * **Mocha testnet**: `--p2p.network mocha` (alias: `mocha-4`)

    Your node store will be created under `~/.celestia-<type>-<network>` (e.g., `~/.celestia-light-mocha-4`).
  </Step>

  <Step title="Run a Light Node (recommended to start)">
    ```bash theme={null}
    # Initialize (creates key + config)
    celestia light init --p2p.network mocha

    # (Optional) Quick sync via trusted hash & height — see Quick Start guide for details
    # Start the node, pointing to a consensus RPC endpoint
    celestia light start --p2p.network mocha       --core.ip rpc-mocha.pops.one       --core.port 9090
    # Mainnet example:
    # celestia light start --p2p.network celestia --core.ip <mainnet-rpc-host> --core.port 9090
    ```

    <Note>
      Replace the RPC host with a reliable endpoint (your own, or a known public one). Using a trusted hash/height speeds up first sync—see the Quick Start guide.
    </Note>
  </Step>

  <Step title="Run a Full Storage Node">
    ```bash theme={null}
    # Initialize the store
    celestia full init --p2p.network celestia

    # Start
    celestia full start --p2p.network celestia
    # Testnet example:
    # celestia full start --p2p.network mocha
    ```

    Full storage nodes store block data and serve light nodes.
  </Step>

  <Step title="Run a Bridge Node">
    ```bash theme={null}
    # Initialize
    celestia bridge init --p2p.network celestia

    # Start — requires access to a consensus endpoint (celestia-app RPC/gRPC)
    celestia bridge start --p2p.network celestia       --core.ip <consensus-rpc-host>       --core.port 26657
    ```

    The bridge node connects the DA layer with consensus (celestia-app). Ensure your **celestia-app** RPC (26657) and gRPC (9090) are reachable.
  </Step>

  <Step title="(Optional) Install celestia-app (consensus)">
    ```bash theme={null}
    # Fastest: download prebuilt (see official docs for latest)
    # Or build from source:
    cd $HOME
    rm -rf celestia-app
    git clone https://github.com/celestiaorg/celestia-app.git
    cd celestia-app
    make install

    # Verify
    celestia-appd version
    ```

    If you run your own **celestia-app** endpoint, you can point light/bridge nodes at it via `--core.ip` and `--core.port`.
  </Step>
</Steps>

## Service management (systemd)

Below is a minimal template for a **light** node. Adjust `ExecStart` for `full` or `bridge` accordingly.

```bash theme={null}
sudo tee /etc/systemd/system/celestia-light.service > /dev/null <<EOF
[Unit]
Description=Celestia Light Node
After=network-online.target

[Service]
User=${USER}
ExecStart=$(which celestia) light start --p2p.network mocha --core.ip rpc-mocha.pops.one --core.port 9090
Restart=on-failure
RestartSec=5
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable celestia-light
sudo systemctl start celestia-light
journalctl -u celestia-light -f -o cat
```

## Verify & Health

```bash theme={null}
# Check process
celestia version

# RPC (celestia-node)
curl -s localhost:26658/health

# P2P check (firewall/ports)
ss -ltnp | grep -E "2121|26658|26659"
```

<Note>
  For issues, see the official troubleshooting page and confirm required ports: **2121** (P2P), **26658** (RPC), **26659** (gateway). Keep your binaries updated per the official guides.
</Note>


# Installation
Source: https://docs.krews.xyz/full-node-installation/dymension

Run a Dymension Hub full node (Cosmos SDK). Build the `dymd` binary, join the right network, and sync.

<Note>
  This keeps to the official flow: build `dymd`, fetch the **genesis** and **seeds**, select **mainnet** or **testnet**, then start and monitor sync.
</Note>

## Prerequisites

* Linux with **Go** toolchain.
* Open typical Cosmos ports (26656 p2p, 26657 RPC, 1317 REST, 9090 gRPC) as needed.

## 1) Build `dymd`

```bash theme={null}
git clone https://github.com/dymensionxyz/dymension.git --branch v3.2.0
cd dymension
make install
dymd version --long
```

If `dymd` isn’t on your PATH:

```bash theme={null}
export PATH=$PATH:$(go env GOPATH)/bin
```

## 2) Initialize

```bash theme={null}
dymd init mynode --chain-id dymension_1100-1
```

## 3) Genesis & seeds

* Download the **genesis.json** and **seed nodes** from the “Join a network” page, then place the files here:

```bash theme={null}
# genesis
cp /path/to/genesis.json ~/.dymension/config/genesis.json

# seeds (comma-separated) into app.toml / config.toml as instructed
```

## 4) Start & monitor

```bash theme={null}
dymd start
# In another terminal:
dymd status | jq .SyncInfo
```

Sync is complete when `catching_up` becomes `false` and the latest block height matches public explorers.

## 5) (Optional) Snapshot

To accelerate sync, use a trusted **snapshot** (community-provided) and ensure `~/.dymension/data` is emptied beforehand, then restart the node.

## Notes

* Mainnet chain-id: **dymension\_1100-1**.
* After you’re fully synced, you can proceed to validator creation separately.


# Installation
Source: https://docs.krews.xyz/full-node-installation/espresso

Install and run an Espresso sequencer node on the Decaf testnet using Docker. Includes hardware requirements, environment variables, and optional staking registration/delegation on Ethereum Sepolia.

<Note>
  Decaf is a **testnet**. Operator access may be **limited**; see Espresso’s announcement and contact form for inclusion. Staking on Decaf uses **Ethereum Sepolia** and the **Decaf stake table**.
</Note>

## Requirements

| Node type       |     CPU |  RAM |     Storage | Notes                                |
| --------------- | ------: | ---: | ----------: | ------------------------------------ |
| Non‑DA node     |  1 core | 2 GB |  negligible | Suitable for observation and testing |
| DA / Sequencer  | 4 cores | 8 GB | 1.2 TB SSD+ | Requires PostgreSQL for SQL storage  |
| PostgreSQL (DA) | 2 cores | 4 GB |   \~100 GB+ | Size grows with chain history        |

<Steps>
  <Step title="Prepare the host">
    Ensure **Docker** is installed and your firewall allows the advertised **libp2p UDP port** you will configure.\
    Create directories for persistent data and keys:

    ```bash theme={null}
    mkdir -p /opt/espresso/{store,keys}
    chmod 700 /opt/espresso/keys
    ```
  </Step>

  <Step title="Provide keys">
    You can pass keys either via a single **key file** or via two environment variables.

    * Key file path inside the container: `/mount/sequencer/keys/0.env`
    * Or set:
      * `ESPRESSO_SEQUENCER_PRIVATE_STAKING_KEY="BLS_SIGNING_KEY~..."`
      * `ESPRESSO_SEQUENCER_PRIVATE_STATE_KEY="SCHNORR_SIGNING_KEY~..."`
  </Step>

  <Step title="Set Decaf environment">
    Export environment variables (edit values as needed). The Docker image tag below is the current Decaf release.

    ```bash theme={null}
    export IMAGE_TAG="20251106-patch1" # Decaf image tag
    export L1_HTTP="https://sepolia.infura.io/v3/<API_KEY>"          # Ethereum Sepolia HTTP
    export L1_WS="wss://sepolia.infura.io/v3/<API_KEY>"              # Ethereum Sepolia WS (recommended)
    export API_PORT="8080"                                           # Sequencer API/metrics
    export LIBP2P_BIND="0.0.0.0:18000/udp"                           # Bind address (UDP)
    export LIBP2P_ADVERTISE="<PUBLIC_IP_OR_DNS>:18000/udp"           # Publicly reachable address

    # Decaf bootstrap/config + core services
    export ESPRESSO_SEQUENCER_CONFIG_PEERS="https://cache.decaf.testnet.espresso.network"
    export ESPRESSO_SEQUENCER_ORCHESTRATOR_URL="https://orchestrator-UZAFTUIMZOT.decaf.testnet.espresso.network/"
    export ESPRESSO_SEQUENCER_CDN_ENDPOINT="cdn.decaf.testnet.espresso.network:1737"
    export ESPRESSO_STATE_RELAY_SERVER_URL="https://state-relay.decaf.testnet.espresso.network"
    export ESPRESSO_SEQUENCER_GENESIS_FILE="/genesis/decaf.toml"

    # Paths inside the container
    export ESPRESSO_SEQUENCER_STORAGE_PATH="/mount/sequencer/store/"
    export ESPRESSO_SEQUENCER_KEY_FILE="/mount/sequencer/keys/0.env"

    # Optional: identify your node in Espresso’s node dashboard
    export ESPRESSO_SEQUENCER_IDENTITY_NODE_NAME="espresso-sequencer-01"
    export ESPRESSO_SEQUENCER_IDENTITY_COMPANY_NAME="YourOrg"
    export ESPRESSO_SEQUENCER_IDENTITY_COMPANY_WEBSITE="https://your.org"
    export ESPRESSO_SEQUENCER_IDENTITY_OPERATING_SYSTEM="$(uname -sr)"
    export ESPRESSO_SEQUENCER_IDENTITY_NETWORK_TYPE="Hosted"         # Residential | Hosted | AWS | GCP | Azure
    export ESPRESSO_SEQUENCER_IDENTITY_COUNTRY_CODE="TR"             # ISO-3166 Alpha-2
    ```
  </Step>

  <Step title="Run a Regular (non‑DA) node">
    ```bash theme={null}
    docker run -d --name espresso-sequencer --restart unless-stopped       -p "${API_PORT}:${API_PORT}"       -v /opt/espresso/store:/mount/sequencer/store       -v /opt/espresso/keys:/mount/sequencer/keys:ro       -e ESPRESSO_SEQUENCER_L1_PROVIDER="${L1_HTTP}"       -e ESPRESSO_SEQUENCER_L1_WS_PROVIDER="${L1_WS}"       -e ESPRESSO_SEQUENCER_CONFIG_PEERS       -e ESPRESSO_SEQUENCER_ORCHESTRATOR_URL       -e ESPRESSO_SEQUENCER_CDN_ENDPOINT       -e ESPRESSO_STATE_RELAY_SERVER_URL       -e ESPRESSO_SEQUENCER_GENESIS_FILE       -e ESPRESSO_SEQUENCER_STORAGE_PATH       -e ESPRESSO_SEQUENCER_KEY_FILE       -e ESPRESSO_SEQUENCER_LIBP2P_BIND_ADDRESS="${LIBP2P_BIND}"       -e ESPRESSO_SEQUENCER_LIBP2P_ADVERTISE_ADDRESS="${LIBP2P_ADVERTISE}"       -e ESPRESSO_SEQUENCER_API_PORT="${API_PORT}"       -e ESPRESSO_SEQUENCER_IDENTITY_NODE_NAME       -e ESPRESSO_SEQUENCER_IDENTITY_COMPANY_NAME       -e ESPRESSO_SEQUENCER_IDENTITY_COMPANY_WEBSITE       -e ESPRESSO_SEQUENCER_IDENTITY_OPERATING_SYSTEM       -e ESPRESSO_SEQUENCER_IDENTITY_NETWORK_TYPE       -e ESPRESSO_SEQUENCER_IDENTITY_COUNTRY_CODE       ghcr.io/espressosystems/espresso-sequencer/sequencer:${IMAGE_TAG}         sequencer -- http -- catchup -- status
    ```
  </Step>

  <Step title="Run a DA (sequencer) node with PostgreSQL">
    Requires a reachable PostgreSQL instance and extra storage.

    ```bash theme={null}
    docker run -d --name espresso-sequencer-da --restart unless-stopped       -p "${API_PORT}:${API_PORT}"       -v /opt/espresso/keys:/mount/sequencer/keys:ro       -e ESPRESSO_SEQUENCER_L1_PROVIDER="${L1_HTTP}"       -e ESPRESSO_SEQUENCER_L1_WS_PROVIDER="${L1_WS}"       -e ESPRESSO_SEQUENCER_CONFIG_PEERS       -e ESPRESSO_SEQUENCER_ORCHESTRATOR_URL       -e ESPRESSO_SEQUENCER_CDN_ENDPOINT       -e ESPRESSO_STATE_RELAY_SERVER_URL       -e ESPRESSO_SEQUENCER_GENESIS_FILE       -e ESPRESSO_SEQUENCER_KEY_FILE       -e ESPRESSO_SEQUENCER_API_PORT="${API_PORT}"       # add your Postgres connection env (e.g., DATABASE_URL) as required by your setup       ghcr.io/espressosystems/espresso-sequencer/sequencer:${IMAGE_TAG}         sequencer -- storage-sql -- http -- catchup -- status -- query
    ```
  </Step>

  <Step title="(Optional) Register & delegate on Sepolia">
    Register the node once to enter the staking set; then delegate to activate.

    ```bash theme={null}
    # Register
    docker run -e L1_PROVIDER="${L1_HTTP}"       -e STAKE_TABLE_ADDRESS="0x40304fbe94d5e7d1492dd90c53a2d63e8506a037"       -e MNEMONIC -e ACCOUNT_INDEX       -e CONSENSUS_PRIVATE_KEY -e STATE_PRIVATE_KEY       ghcr.io/espressosystems/espresso-sequencer/staking-cli:main         staking-cli register-validator --commission 0.10

    # Delegate (bootstrap your own validator or from another account)
    docker run -e L1_PROVIDER="${L1_HTTP}"       -e STAKE_TABLE_ADDRESS="0x40304fbe94d5e7d1492dd90c53a2d63e8506a037"       -e MNEMONIC -e ACCOUNT_INDEX       ghcr.io/espressosystems/espresso-sequencer/staking-cli:main         delegate --validator-address $ADDRESS --amount $DELEGATION_AMOUNT
    ```
  </Step>

  <Step title="Health checks & networking tips">
    * Verify logs: `docker logs -f espresso-sequencer`
    * Ensure the **UDP** libp2p port is open from the Internet to your host.
    * The first start needs `ESPRESSO_SEQUENCER_CONFIG_PEERS`. Subsequent restarts should reuse cached config.
    * Apply **TCP optimizations** per Espresso docs (sysctl or Docker flags).
  </Step>
</Steps>

<Note>
  *Supported networks:* **Espresso Decaf testnet**.
</Note>


# Installation
Source: https://docs.krews.xyz/full-node-installation/initia

Step-by-step guide to run an Initia L1 full node using the Weave CLI (recommended) or the raw initiad binary. Covers both Mainnet (interwoven-1) and Testnet (initiation-2).

<Note>
  This guide is based on the official Initia docs and registry. Network details and genesis links are maintained by Initia. Refer to the **Initia L1 Networks** page for the latest chain IDs, endpoints, and minimum gas prices.
</Note>

## Quick facts

* **Binary**: `initiad`
* **Recommended helper CLI**: [`Weave`](https://github.com/initia-labs/weave)
* **Mainnet Chain ID**: `interwoven-1`
* **Testnet Chain ID**: `initiation-2`
* **Min gas price**: `0.015uinit` (see *Initia L1 Networks*)
* **Genesis (Mainnet)**: `https://storage.googleapis.com/init-common-genesis/interwoven-1/genesis.json`
* **Genesis (Testnet)**: See the **Networks** page for the latest file.

<Note>
  We recommend the **Weave CLI** path for the simplest, interactive setup and automatic (Cosmovisor) upgrades. If you prefer manual control, use the **Raw initiad** path below.
</Note>

## Option A — Install with Weave (recommended)

<Steps>
  <Step title="Install prerequisites">
    * Linux/macOS host (Ubuntu 22.04+ recommended).
    * If building Weave from source: **Go 1.23+** and **lz4** are required.
    * Otherwise, use prebuilt or Homebrew on macOS.

    **macOS (Homebrew):**

    ```bash theme={null}
    brew install initia-labs/tap/weave
    ```

    **Linux:** follow the instructions in the Weave repo’s README or releases page.
  </Step>

  <Step title="Initialize your node (guided)">
    Run the guided bootstrap and select **Mainnet (interwoven-1)** or **Testnet (initiation-2)** when prompted. The wizard also configures pruning, API endpoints, peers/seeds, and **Cosmovisor** if you opt in.

    ```bash theme={null}
    weave initia init
    ```

    After the wizard finishes, config files live in `~/.initia/config/{app.toml,config.toml}` and snapshot/state-sync (if chosen) is handled automatically.
  </Step>

  <Step title="Start the node">
    ```bash theme={null}
    weave initia start
    ```

    Use `--detach` to run in the background. Logs stream from Cosmovisor if enabled.
  </Step>
</Steps>

## Option B — Raw `initiad` (manual)

<Steps>
  <Step title="Install initiad">
    Build from source or use a prebuilt release:

    ```bash theme={null}
    # From source (example)
    sudo apt update && sudo apt install -y build-essential golang lz4
    git clone https://github.com/initia-labs/initia.git
    cd initia
    git checkout <TAG>   # e.g., v1.x.y matching your target network
    make install         # installs initiad into $GOBIN or $GOPATH/bin
    initiad version
    ```
  </Step>

  <Step title="Initialize and pick network">
    ```bash theme={null}
    # Choose one:
    export CHAIN_ID=interwoven-1   # Mainnet
    # export CHAIN_ID=initiation-2 # Testnet

    initiad init my-node --chain-id $CHAIN_ID
    ```
  </Step>

  <Step title="Download the genesis file">
    **Mainnet example:**

    ```bash theme={null}
    curl -L https://storage.googleapis.com/init-common-genesis/interwoven-1/genesis.json -o $HOME/.initia/config/genesis.json
    ```

    **Testnet:** fetch the current testnet genesis URL from the **Initia L1 Networks** page or the **Initia Registry** and place it at the same path.
  </Step>

  <Step title="Configure peers, seeds, and gas">
    Edit `$HOME/.initia/config/config.toml`:

    ```toml theme={null}
    # persistent_peers = "peer1@ip1:26656,peer2@ip2:26656"
    # seeds = "seed1@ip:26656"
    ```

    Edit `$HOME/.initia/config/app.toml` to set **minimum-gas-prices**:

    ```toml theme={null}
    minimum-gas-prices = "0.015uinit"
    ```
  </Step>

  <Step title="(Optional) Systemd service">
    ```bash theme={null}
    sudo tee /etc/systemd/system/initiad.service >/dev/null <<'EOF'
    [Unit]
    Description=Initia L1 Node
    After=network-online.target

    [Service]
    User=%i
    ExecStart=$(which initiad) start
    Restart=always
    RestartSec=3
    LimitNOFILE=65535

    [Install]
    WantedBy=multi-user.target
    EOF

    sudo systemctl daemon-reload
    sudo systemctl enable --now initiad.service
    journalctl -u initiad -f
    ```
  </Step>
</Steps>

## Verify sync

```bash theme={null}
curl -s localhost:26657/status | jq .result.sync_info
```

<Note>
  For **latest chain IDs, genesis URLs, peers/seeds, and gas price policy**, check the official  Initia L1 Networks page and the  Initia Registry.
</Note>


# Installation
Source: https://docs.krews.xyz/full-node-installation/lava

Run a Lava RPC Provider using `lavap`. Configure endpoints, start the provider, test it, then stake.

<Note>
  Lava “providers” serve RPC traffic for supported chains and are **not** typical full nodes. You run the **lavap** process, point it at your own backend nodes (or trusted endpoints), and then **stake** to make the service public.
</Note>

## Prerequisites

* Linux host with the **Lava binaries** (at least `lavap`) installed.
* A synced backend node for each chain you plan to serve.
* A Lava wallet funded with **LAVA** tokens.

## 1) Create a provider config

Example: Lava testnet provider (`lava-provider.yml`) and Ethereum provider (`eth-provider.yml`). Adjust hosts/ports to your setup.

```yaml theme={null}
# lava-provider.yml
endpoints:
  - api-interface: tendermintrpc
    chain-id: LAV1
    network-address:
      address: 127.0.0.1:2224
      disable-tls: true
    node-urls:
      - url: ws://127.0.0.1:26657/websocket
      - url: http://127.0.0.1:26657
  - api-interface: grpc
    chain-id: LAV1
    network-address:
      address: 127.0.0.1:2224
      disable-tls: true
    node-urls:
      url: 127.0.0.1:9090
  - api-interface: rest
    chain-id: LAV1
    network-address:
      address: 127.0.0.1:2224
      disable-tls: true
    node-urls:
      url: http://127.0.0.1:1317
```

```yaml theme={null}
# eth-provider.yml
endpoints:
  - api-interface: jsonrpc
    chain-id: ETH1
    network-address:
      address: 127.0.0.1:2223
      disable-tls: true
    node-urls:
      url: wss://your-ethereum-node/ws/
```

## 2) Start the provider

```bash theme={null}
# Replace --from with your wallet name; pick the correct Lava chain-id
# lava-mainnet-1 for mainnet, lava-testnet-2 for testnet
screen -S lava-provider
lavap rpcprovider lava-provider.yml --from <wallet_name> --geolocation 1 --chain-id lava-testnet-2 --log_level debug
```

You can run multiple configs (e.g., Ethereum) in separate terminals.

## 3) Pre-flight test (before staking)

```bash theme={null}
lavap test rpcprovider --from <wallet_name> --endpoints "<ENDPOINTS>"
```

## 4) Stake the provider (make it public)

```bash theme={null}
# Stake a single service; amounts and geolocation depend on chain specs
lavap tx pairing stake-provider <CHAIN_ID> <AMOUNT> <ENDPOINT ...> <GEO> <VALIDATOR> --chain-id lava-testnet-2
```

A new stake applies at the next epoch (about 30 blocks).

## 5) Verify

List providers for a chain:

```bash theme={null}
lavap query pairing providers "<NETWORK_NAME>" --node "<LAVA_RPC_NODE>"
```

## Notes

* TLS and `lavavisor` are recommended for production deployments.
* Use the official **Supported Chains** list to ensure your `api-interface`/endpoints match each spec.


# Installation
Source: https://docs.krews.xyz/full-node-installation/sunrise

How to run a Sunrise full consensus node (mainnet sunrise-1). Includes dependencies, genesis, peers, gas prices, and start options.

<Note>
  This guide follows the official Sunrise documentation. Use mainnet values unless you intentionally target the testnet.
</Note>

## Quick facts

* **Binary**: `sunrised`
* **Chain ID (mainnet)**: `sunrise-1`
* **Go toolchain**: 1.24.2 (min per docs)
* **Recommended min gas price**: `0.025uusdrise` (protects from spam)
* **Mainnet genesis**: `https://raw.githubusercontent.com/sunriselayer/network/main/sunrise-1/genesis.json`

## Install & initialize

<Steps>
  <Step title="Install dependencies and Go">
    Ubuntu 22.04 LTS is used in the official guide.

    ```bash theme={null}
    # Install Go 1.24.x (example using tarball; or use your package manager)
    wget https://go.dev/dl/go1.24.2.linux-amd64.tar.gz
    sudo rm -rf /usr/local/go && sudo tar -C /usr/local -xzf go1.24.2.linux-amd64.tar.gz
    echo 'export PATH=$PATH:/usr/local/go/bin' | tee -a ~/.profile
    source ~/.profile
    go version
    ```
  </Step>

  <Step title="Build the sunrise binary">
    ```bash theme={null}
    git clone https://github.com/sunriselayer/sunrise.git
    cd sunrise
    git checkout <TAG>   # Use the binary version appropriate for your sync height
    make install         # installs sunrised in $GOBIN
    sunrised version
    ```
  </Step>

  <Step title="Initialize node">
    ```bash theme={null}
    export CHAIN_ID=sunrise-1
    export MONIKER="my-node"
    sunrised init "$MONIKER" --chain-id $CHAIN_ID
    ```
  </Step>

  <Step title="Fetch genesis (mainnet)">
    ```bash theme={null}
    rm -f $HOME/.sunrise/config/genesis.json
    curl -L https://raw.githubusercontent.com/sunriselayer/network/main/sunrise-1/genesis.json -o $HOME/.sunrise/config/genesis.json
    ```
  </Step>

  <Step title="Set minimum gas prices">
    ```bash theme={null}
    sed -i.bak -e 's/^minimum-gas-prices *=.*/minimum-gas-prices = "0.025uusdrise"/' $HOME/.sunrise/config/app.toml
    ```
  </Step>

  <Step title="(Optional) Seeds & persistent peers">
    Seeds and peers are published in the **network** repo. Example (mainnet seeds):

    ```bash theme={null}
    SEEDS=$(curl -sL https://raw.githubusercontent.com/sunriselayer/network/main/sunrise-1/seeds.txt | tr '\n' ',')
    sed -i.bak -e "s/^seeds *=.*/seeds = \"$SEEDS\"/" $HOME/.sunrise/config/config.toml
    ```

    You can also populate `persistent_peers` similarly.
  </Step>

  <Step title="(Optional) Storage & indexing">
    If connecting to a bridge node or running an archive, enable tx indexing and retain all block data:

    ```toml theme={null}
    # config.toml
    indexer = "kv"

    # app.toml
    min-retain-blocks = 0
    ```
  </Step>

  <Step title="Start the node">
    **With Cosmovisor** (recommended for upgrades): follow the official Cosmovisor setup, then start.\
    **Without Cosmovisor**:

    ```bash theme={null}
    sunrised start
    ```
  </Step>
</Steps>

## Verify sync

```bash theme={null}
curl -s localhost:26657/status | jq .result.sync_info.catching_up
```

<Note>
  Mainnet endpoints and the latest release tags are listed under **Run a Sunrise Node → Networks → Mainnet**. Snapshots are often provided by third parties (e.g., Polkachu). Validate source and height before use.
</Note>


# Introduction
Source: https://docs.krews.xyz/index

Krews is an independent validator and infrastructure team. We run high-performance Proof-of-Stake validators on multiple networks and publish open dashboards, explorers, and documentation so anyone can verify performance, uptime, and network health.

<img alt="Krews Banner" />

## Who We Are

Krews is a validator and infrastructure team formed by professionals who have worked together across multiple projects. We combine practical ops experience with dedicated, bare-metal infrastructure to deliver secure, reliable staking services. Our goal is simple: empower projects and communities with verifiable performance and transparent operations.

## Our Mission

* **Security First** — Enterprise-grade, dedicated servers (ECC memory, power and data redundancy) and a global sentry topology designed to minimize downtime and slash risk.
* **Reliability at Scale** — Bare-metal only, with carefully tuned setups for predictable performance under load.
* **Transparency** — We surface validator behavior, performance, and network health via public dashboards and explorers.
* **Sustainability** — We prioritize energy-efficient choices and practices to reduce carbon footprint without sacrificing performance.

## What We Do

* **24/7 Live Monitoring & Incident Response**\
  Continuous monitoring with automated alerting and human on-call. We detect anomalies fast and remediate quickly.
* **Bare-Metal Infrastructure & Sentries**\
  Dedicated servers only—no shared virtualization. Global sentry nodes harden network access and increase resilience.
* **Open Reporting**\
  Public dashboards, explorers, and weekly status views so delegators and teams can audit us in real time.
* **Documentation & How-Tos**\
  We maintain docs and runbooks so operators and delegators can follow clear, repeatable processes.

## Public Tools & Dashboards

<Card title="Celestia Dashboard" icon="https://cloudflare-snapshots.krews.xyz/celestia.png" href="https://celestia-dashboard.krews.xyz/celestia/validators">
  Real-time validator uptime, missed proposals, performance metrics and decentralization analytics for Celestia Network.
</Card>

<Card title="Monatlas" icon="https://cloudflare-snapshots.krews.xyz/monad.png" href="https://monatlas.io/">
  Real-time Monad analytics with live consensus, validator insights and network metrics.
</Card>

<Card title="Story Dashboard" icon="https://cloudflare-snapshots.krews.xyz/story.png" href="https://story-dashboard.krews.xyz/story/validators">
  Live Story Protocol validator analytics, uptime tracking, missed-signature insights and full snapshot services.
</Card>

<Card title="Sunrise Dashboard" icon="https://cloudflare-snapshots.krews.xyz/sunrise.png" href="https://sunrise-services.krews.xyz/sunrise/validator-status">
  Specialized tools and monitoring services for Sunrise Network, including uptime, node health and validator analytics.
</Card>

<Card title="Sunrise Explorer" icon="https://cloudflare-snapshots.krews.xyz/sunrise.png" href="https://risescan.krews.xyz/">
  Block explorer for RiseChain providing transaction tracking, validator insights and on-chain activity monitoring.
</Card>

## Why Choose Krews

1. **Verifiable performance** — We publish metrics and history so anyone can check signing, missed blocks, and trends.
2. **Operational discipline** — Safe rollouts, redundancy, and quick rollback strategies to reduce operational risk.
3. **Clarity over hype** — Concrete dashboards, explorers, and docs instead of vague claims.

## **Supported Projects**

<div>
  <CardGroup>
    <Card title="Celestia" icon="https://cloudflare-snapshots.krews.xyz/celestia.png" href="/networks/celestia">
      Celestia is a modular data availability network that separates consensus from execution, enabling scalable and efficient blockchain deployment.
    </Card>

    <Card title="Story" icon="https://cloudflare-snapshots.krews.xyz/story.png" href="/networks/story">
      Story Protocol is a decentralized framework for intellectual property, enabling creators to register, manage, and monetize their works on-chain.
    </Card>

    <Card title="Avail" icon="https://cloudflare-snapshots.krews.xyz/avail.png" href="/networks/avail">
      Avail is a modular blockchain base layer that ensures high data availability, enabling developers to build scalable and interoperable applications.
    </Card>

    <Card title="Monad" icon="https://cloudflare-snapshots.krews.xyz/monad.png" href="">
      Monad is a high-performance Layer 1 blockchain that enables fast and efficient execution for EVM-based applications.
    </Card>

    <Card title="Canton" icon="https://cloudflare-snapshots.krews.xyz/canton.png" href="">
      Canton Network is a privacy-focused blockchain network that enables secure and interoperable workflows for regulated institutions.
    </Card>

    <Card title="Aligned" icon="https://cloudflare-snapshots.krews.xyz/aligned.png" href="/networks/aligned">
      Aligned is a decentralized network that verifies zero-knowledge proofs, improving scalability and efficiency for blockchains.
    </Card>

    <Card title="Initia" icon="https://cloudflare-snapshots.krews.xyz/initia.png" href="/networks/initia">
      Initia is a next-gen Layer 1 blockchain designed for full-stack applications, combining modular infrastructure with seamless interoperability.
    </Card>

    <Card title="Sunrise" icon="https://cloudflare-snapshots.krews.xyz/sunrise.png" href="/networks/sunrise">
      Sunrise is a specialized Data Availability (DA) layer that introduces Proof of Liquidity (PoL) to enhance scalability and liquidity for modular blockchains.
    </Card>

    <Card title="Espresso" icon="https://cloudflare-snapshots.krews.xyz/espresso.png" href="/networks/espresso">
      Espresso is a decentralized sequencing layer that delivers fast finality and enhances rollup interoperability using BFT consensus.
    </Card>

    <Card title="Aptos" icon="https://cloudflare-snapshots.krews.xyz/aptos.png" href="/networks/aptos">
      Aptos is a Layer-1 blockchain built with the Move language. It emphasizes safety and performance with features like parallel execution (Block-STM), low-latency confirmations, and a flexible fee model.
    </Card>

    <Card title="Dymension" icon="https://cloudflare-snapshots.krews.xyz/dymension.png" href="/networks/dymension">
      Dymension is a modular Layer 1 network that powers RollApps, enabling scalable and interconnected blockchain ecosystems.
    </Card>

    <Card title="Lava" icon="https://cloudflare-snapshots.krews.xyz/lava.png" href="/networks/lava">
      Lava Network is a modular protocol that decentralizes blockchain data access, providing scalable and reliable RPC and API services for multi-chain ecosystems.
    </Card>

    <Card title="IOTA" icon="https://cloudflare-snapshots.krews.xyz/%C4%B1ota.png" href="/networks/IOTA">
      Lava Network is a modular protocol that decentralizes blockchain data access, providing scalable and reliable RPC and API services for multi-chain ecosystems.
    </Card>
  </CardGroup>
</div>


# Overview
Source: https://docs.krews.xyz/networks/aligned

It's a proof verification layer developed on top of the EigenLayer using restaking and proof aggregation. This will enable cost-effective verification of any SNARK proof, leveraging Ethereum validator

[Website](https://alignedlayer.com/) <Icon icon="arrow-up-right" /> | [Twitter](https://x.com/alignedlayer) <Icon icon="arrow-up-right" /> | [Github](https://github.com/yetanotherco/aligned_layer) <Icon icon="arrow-up-right" /> | [Resources](https://blog.alignedlayer.com/) <Icon icon="arrow-up-right" />

<CodeGroup>
  ```API API theme={null}
  https://alignedlayer-api.krews.xyz/
  ```

  ```RPC RPC theme={null}
  https://alignedlayer-rpc.krews.xyz/
  ```

  ```Explorer Explorer theme={null}
  https://explorer.krews.xyz/alignedlayer
  ```
</CodeGroup>

## FAQ

<AccordionGroup>
  <Accordion title="What wallets are supported for Aligned Layer?">
    Aligned Layer operates as an AVS (Actively Validated Service) on EigenLayer, and does not require a traditional wallet UI like Metamask. However, any wallet or tooling that supports Ethereum staking and EigenLayer restaking (e.g., MetaMask + EigenLayer frontend, or CLI tools) can be used to interact with the system.
  </Accordion>

  <Accordion title="Is there a fee?">
    Yes. Krews charges a 10% commission on staking rewards. This commission is applied to any earnings you receive from participating in proof verification through Aligned Layer. Rewards may be distributed based on the pay-per-verification or subscription-based staking model adopted by the network.
  </Accordion>

  <Accordion title="What is the unbonding period?">
    Aligned Layer does not have its own unbonding logic. If you are restaking ETH or other assets via EigenLayer, the unbonding period depends on EigenLayer’s unbonding parameters, which typically range from 7 to 10 days, but may vary depending on the staking configuration.
  </Accordion>

  <Accordion title="How do I stake with Krews on Aligned Layer?">
    1. Stake ETH (or supported assets) via EigenLayer.
    2. Opt in to Aligned Layer as an AVS.
    3. Delegate to Krews Validator if selection is available.
    4. Your stake contributes to securing Aligned’s proof verification layer.
    5. You will start receiving rewards proportional to your stake, minus the 10% commission.
  </Accordion>

  <Accordion title="How can I claim and restake rewards?">
    Rewards are distributed automatically through EigenLayer’s mechanisms. To increase your stake, you can manually restake additional ETH or ALIGN via EigenLayer’s dashboard. Krews does not currently offer auto-restake functionality for Aligned Layer.

    <Note>
      Ensure your wallet has enough ETH to cover transaction fees when claiming or restaking.
    </Note>
  </Accordion>
</AccordionGroup>


# Overview
Source: https://docs.krews.xyz/networks/aptos

Aptos is a Layer-1 blockchain built with the Move language. It emphasizes safety and performance with features like parallel execution (Block-STM), low-latency confirmations, and a flexible fee model.

[Website](https://aptosnetwork.com/) <Icon icon="arrow-up-right" /> | [Twitter](https://x.com/Aptos) <Icon icon="arrow-up-right" /> | [Github](https://github.com/aptos-labs) <Icon icon="arrow-up-right" /> | [Resources](https://aptos.dev/) <Icon icon="arrow-up-right" />

## FAQ

<AccordionGroup>
  <Accordion title="What is Aptos?">
    Aptos is a Layer-1, proof-of-stake blockchain that uses the Move programming language, designed for asset safety and expressive smart contracts. The network implements parallel execution (Block-STM) to improve throughput and latency.
  </Accordion>

  <Accordion title="What wallets are supported for Aptos?">
    Aptos supports multiple Move-compatible wallets. Common options include **Petra** (by Aptos Labs) and third-party wallets such as **Martian** and **Pontem**. Dapps integrate wallets via the Aptos Wallet Adapter standard.
  </Accordion>

  <Accordion title="Is there a fee?">
    Yes. Transactions pay gas in **APT**. Fees include execution/IO costs and storage fees; gas parameters are configurable via on-chain governance. Developers can specify gas price and limits; users typically just confirm in their wallet.
  </Accordion>

  <Accordion title="What is the unbonding (unlock) period?">
    Aptos uses delegated staking. You can request to unlock at any time, but funds become **withdrawable only after the delegation pool’s lockup cycle ends**. The lockup duration is set by governance and can vary by pool/cycle; always check the pool’s current unlock date in the UI.
  </Accordion>

  <Accordion title="How do I stake or delegate APT?">
    1. Install a supported wallet (e.g., Petra).
    2. Open the official explorer or a partner interface that supports delegated staking.
    3. Choose a validator / pool and delegate your APT.
    4. Rewards accrue per protocol rules; when you unlock, you can withdraw after the pool’s lockup cycle ends.
  </Accordion>
</AccordionGroup>


# Overview
Source: https://docs.krews.xyz/networks/avail

Avail is a Substrate-based, modular data-availability layer designed to provide scalable, decentralized data storage for downstream blockchains. By separating settlement from data-availability, Avail enables developers to deploy rollups, DA chains, and other layer-2 systems with minimal overhead. As a validator service, Krews operates high-performance nodes on the Avail network, ensuring reliable block production, robust finality, and continuous uptime for our delegators.

[Website](https://www.availproject.org/) <Icon icon="arrow-up-right" /> | [Twitter](https://x.com/AvailProject) <Icon icon="arrow-up-right" /> | [Github](https://github.com/availproject) <Icon icon="arrow-up-right" /> | [Resources](https://blog.availproject.org/) <Icon icon="arrow-up-right" />

## FAQ

<AccordionGroup>
  <Accordion title="What wallets are supported for Avail?">
    Any wallet that supports Substrate-based networks and has Avail configuration will work. Common options include Talisman, Polkawallet, SubWallet, or Polkadot.js (configured for Avail).
  </Accordion>

  <Accordion title="Is there a fee?">
    Yes. Krews charges a 10% commission on staking rewards. The APR displayed on your dashboard reflects the network’s gross yield before deducting Krews’s commission.
  </Accordion>

  <Accordion title="What is the unbonding period?">
    Avail enforces a **28-day unbonding period**. When you decide to unstake, your AVAIL tokens enter a 28-day lockup during which they do not earn rewards and cannot be transferred. After 28 days, you are free to withdraw or redelegate.
  </Accordion>

  <Accordion title="How do I stake with Krews on Avail?">
    1. Install and configure a compatible wallet (e.g., Talisman) with Avail’s network endpoint.
    2. Transfer AVAIL tokens into your staking account.
    3. Visit the Avail Staking Dashboard (e.g., [https://staking.avail.tools/#/validators](https://staking.avail.tools/#/validators)).
    4. Connect your wallet and search for “Krews Validator” under the validator list.
    5. Submit a nomination (bond) transaction to delegate your AVAIL to Krews.
    6. Once the next era is reached, your stake becomes active, and you start earning rewards (minus our 10 % commission).
  </Accordion>

  <Accordion title="How can I claim and restake rewards?">
    You may claim rewards manually via the Staking Dashboard by clicking “Withdraw Rewards” under your account’s staking page. To compound your yield, use the “Bond Extra” function to re-delegate the claimed AVAIL in a single transaction. Krews does not currently offer an auto-restake (REstake) service on Avail; all restaking must be performed manually.

    <Note>
      Always ensure you have enough AVAIL in your wallet to cover transaction fees. If you plan to withdraw or redelegate, account for the 28-day unbonding lock-up period before your funds become available again.
    </Note>
  </Accordion>
</AccordionGroup>


# Overview
Source: https://docs.krews.xyz/networks/celestia

Celestia is a modular blockchain network that provides a dedicated data availability (DA) layer for scalable rollups and modular blockchains. By separating consensus and data availability from execution, Celestia enables developers to deploy sovereign rollups with minimal setup and security overhead.

[Website](https://celestia.org/) <Icon icon="arrow-up-right" /> | [Twitter](https://x.com/celestia) <Icon icon="arrow-up-right" /> | [Github](https://github.com/celestiaorg) <Icon icon="arrow-up-right" /> | [Resources](https://blog.celestia.org/) <Icon icon="arrow-up-right" />

## FAQ

<AccordionGroup>
  <Accordion title="What wallets are supported for Celestia?">
    Wallets commonly used with Cosmos SDK–based chains work with Celestia. Official guides cover **Keplr** and **Leap** (Gem is also documented). To delegate/stake, connect your wallet to a supported staking interface such as the Celestia explorers.guru portal.

    <br />

    <small>See: wallet & staking docs and the validator portal.</small>
  </Accordion>

  <Accordion title="Are there fees or commissions?">
    Transactions pay gas in **TIA**. Validator commissions are set by each validator and shown in staking dashboards; check the validator’s profile before delegating.
  </Accordion>

  <Accordion title="What is the unbonding period?">
    Celestia currently enforces a **21-day unbonding period**. During unbonding, TIA is locked and does not earn rewards. (An upgrade proposal/roadmap item targets \~14 days, but mainnet parameters today remain 21 days.)
  </Accordion>

  <Accordion title="How do I stake TIA?">
    1. Install a supported wallet (e.g., Keplr or Leap).
    2. Fund your wallet with **TIA**.
    3. Open a staking portal (e.g., explorers.guru Celestia validators), pick a validator, and **Delegate**.
    4. Confirm in your wallet to start earning per protocol rules.
  </Accordion>

  <Accordion title="How do I claim and restake rewards (auto-compound)?">
    Rewards can be claimed in your wallet or via the staking UI. Auto-compounding is **not automatic by default**, but many validators enable it via **REStake** using Cosmos **Authz**—you can opt-in and revoke at any time.
  </Accordion>
</AccordionGroup>


# Overview
Source: https://docs.krews.xyz/networks/dymension

Dymension is a settlement Layer-1 for modular blockchains called RollApps. It connects users and liquidity to RollApps and provides tooling for launching, settling, and operating application-specific chains.

[Website](https://dymension.xyz/) <Icon icon="arrow-up-right" /> | [Twitter](https://x.com/dymension) <Icon icon="arrow-up-right" /> | [Github](https://github.com/dymensionxyz) <Icon icon="arrow-up-right" /> | [Resources](https://docs.dymension.xyz/) <Icon icon="arrow-up-right" />

## FAQ

<AccordionGroup>
  <Accordion title="What is Dymension?">
    Dymension is a delegated proof-of-stake L1 that powers **RollApps**—application-specific rollups that connect to the Dymension Hub for security, user access, and liquidity.
  </Accordion>

  <Accordion title="What wallets are supported?">
    On the Hub, Cosmos wallets like **Keplr** and **Leap** are commonly used (via the official Portal UI). Individual RollApps may support additional wallets depending on their stack; check each RollApp’s docs.
  </Accordion>

  <Accordion title="Are there fees?">
    Hub transactions pay gas in **DYM**. RollApps set their own fee policies; consult each RollApp’s documentation.
  </Accordion>

  <Accordion title="What is the unbonding period?">
    The unbonding period on Dymension is **21 days**. During unbonding, tokens are locked and do not generate rewards.
  </Accordion>

  <Accordion title="How do I stake or delegate DYM?">
    Use the Dymension Portal or a supported wallet to select a validator and delegate. Rewards accrue per protocol rules; after you start an unstake, tokens become withdrawable when the 21-day unbonding ends.
  </Accordion>
</AccordionGroup>


# Overview
Source: https://docs.krews.xyz/networks/espresso

Espresso is a global confirmation network and shared sequencer for rollups. Using the HotShot BFT consensus, it provides fast, credible confirmations and optional decentralized sequencing/DA to improve security and cross-chain composability.

[Website](https://www.espressosys.com/) <Icon icon="arrow-up-right" /> | [Twitter](https://x.com/EspressoSys) <Icon icon="arrow-up-right" /> | [Github](https://github.com/EspressoSystems) <Icon icon="arrow-up-right" /> | [Resources](https://docs.espressosys.com/) <Icon icon="arrow-up-right" />

## FAQ

<AccordionGroup>
  <Accordion title="What is Espresso?">
    Espresso is a global confirmation layer and shared sequencer for rollups. It leverages the HotShot BFT consensus so rollup transactions can be credibly confirmed within seconds, providing early, shared certainty before L1 finality.
  </Accordion>

  <Accordion title="Is Espresso live on mainnet?">
    Yes. Espresso is live as “Mainnet 0,” a production phase with a preregistered operator set and a roadmap toward broader proof-of-stake participation.
  </Accordion>

  <Accordion title="What wallets are supported?">
    Wallets depend on the integrated rollup and release. Most Espresso-enabled rollups use Ethereum-compatible wallets (e.g., MetaMask); operator/integration flows may also interact with L1 contracts.
  </Accordion>

  <Accordion title="How are fees handled?">
    Builders deposit ETH into an L1 fee-token contract to pay HotShot data-processing fees; HotShot tracks working balances. Withdrawals are planned in a future release. Users otherwise pay gas on the chains they interact with.
  </Accordion>

  <Accordion title="How can I test or integrate a rollup with Espresso?">
    Use the persistent **Decaf** testnet and the official integration guides in the docs. Start on testnet, then follow release-specific mainnet instructions as they evolve.
  </Accordion>
</AccordionGroup>


# Overview
Source: https://docs.krews.xyz/networks/initia

Initia is a Cosmos‑based Layer‑1 with enshrined modularity: an Interwoven L1 paired with native rollups and tooling. By unifying execution, networking, and economics, Initia enables developers to launch interoperable app‑chains (“Minitias”) while the L1 provides shared security, routing, and liquidity primitives.

[Website](https://initia.xyz/) <Icon icon="arrow-up-right" /> | [Twitter](https://x.com/initia) <Icon icon="arrow-up-right" /> | [Github](https://github.com/initia-labs) <Icon icon="arrow-up-right" /> | [Resources](https://docs.initia.xyz/) <Icon icon="arrow-up-right" />

## FAQ

<AccordionGroup>
  <Accordion title="What wallets are supported for Initia?">
    You can use the official <strong>Initia App</strong> to manage assets and staking across the ecosystem, as well as Cosmos‑compatible wallets like <strong>Leap</strong>, <strong>Keplr</strong>, or <strong>Cosmostation</strong>. Feature coverage can differ by wallet, so prefer the Initia App or Leap for the most complete experience.
  </Accordion>

  <Accordion title="What is the unbonding period?">
    Initia currently uses a <strong>21‑day unbonding period</strong> on the L1. After initiating an undelegation, your INIT becomes withdrawable only after the 21‑day window completes.
  </Accordion>

  <Accordion title="How do I stake on Initia?">
    1. Connect a supported wallet or the Initia App to the <strong>interwoven‑1</strong> network (mainnet).<br />
    2. Fund your address with <strong>INIT</strong> and open the staking/validators page.<br />
    3. Select a validator, review commission and uptime, then submit a <em>Delegate</em> transaction.<br />
    4. To switch validators without unbonding, use <em>Redelegate</em>.
  </Accordion>

  <Accordion title="Are there commissions or minimums?">
    Validator <strong>commissions</strong> are set per operator and displayed in wallets/dashboards. Network gas fees apply. Minimum delegation is determined by the interface you use (wallets often enforce small thresholds for practicality).
  </Accordion>

  <Accordion title="How can I claim and restake rewards?">
    Claim staking rewards in your wallet or the Initia App. To compound, delegate the claimed INIT again. Keep a small balance to cover gas when claiming or redelegating.
  </Accordion>
</AccordionGroup>


# Overview
Source: https://docs.krews.xyz/networks/iota

IOTA is a programmable blockchain platform with an EVM-compatible smart contract chain (IOTA EVM) live on mainnet and an evolving Layer 1 architecture focused on performance, safety, and real-world adoption.

[Website](https://www.iota.org/) <Icon icon="arrow-up-right" /> | [Twitter](https://x.com/iota) <Icon icon="arrow-up-right" /> | [Github](https://github.com/iotaledger) <Icon icon="arrow-up-right" /> | [Resources](https://blog.iota.org/) <Icon icon="arrow-up-right" />

## FAQ

<AccordionGroup>
  <Accordion title="What is IOTA?">
    IOTA is a programmable blockchain platform designed for internet-scale applications. Today, the ecosystem includes **IOTA EVM**—a fully EVM-compatible smart contract chain running on the IOTA mainnet—and a broader roadmap that brings improved scalability, developer ergonomics, and mainstream-friendly tooling to Layer 1.
  </Accordion>

  <Accordion title="What wallets are supported?">
    For **IOTA EVM**, you can use standard EVM wallets such as **MetaMask**. Developer quickstarts cover connecting a wallet, funding testnets, and deploying contracts. For the evolving Layer 1, follow the official wallet and tooling guides referenced from IOTA’s documentation and blog.
  </Accordion>

  <Accordion title="How are fees handled?">
    On **IOTA EVM**, transactions pay gas in **IOTA** (MIOTA). Typical fees are low (often under a cent) and shown in the network explorer’s gas tracker. Fee behavior on the Layer 1 will follow protocol specifications as they evolve; check the official docs for the latest parameters.
  </Accordion>

  <Accordion title="How do developers get started?">
    1. Review the **IOTA EVM Quickstart** (wallet setup, RPC, bridge/faucet for testnets).
    2. Explore official docs for SDKs, CLI tools, and examples.
    3. Use the **IOTA EVM Explorer** to verify contracts, track transactions, and inspect gas usage.
    4. Monitor the IOTA blog and GitHub for updates to the Layer 1 and Move-based tooling.
  </Accordion>

  <Accordion title="Where can I follow updates and network activity?">
    Official announcements appear on the **IOTA Blog** and X (Twitter). On-chain activity (transactions, contracts, gas) for IOTA EVM is visible in the public **Blockscout explorer**.
  </Accordion>
</AccordionGroup>


# Overview
Source: https://docs.krews.xyz/networks/lava

Lava is a modular, decentralized data-access network (RPC & APIs). A Cosmos SDK appchain coordinates providers that serve relays off-chain for performance, while payments/quality-of-service and pairing are handled on-chain.

[Website](https://www.lavanet.xyz/) <Icon icon="arrow-up-right" /> | [Twitter](https://x.com/lavanetxyz) <Icon icon="arrow-up-right" /> | [Github](https://github.com/lavanet) <Icon icon="arrow-up-right" /> | [Resources](https://docs.lavanet.xyz/) <Icon icon="arrow-up-right" />

## FAQ

<AccordionGroup>
  <Accordion title="What is Lava?">
    Lava is a Cosmos-SDK–based network that decentralizes blockchain data access. Providers serve RPC/API relays via an off-chain protocol; staking, pairing, payments, and incentives are settled on-chain.
  </Accordion>

  <Accordion title="What wallets are supported?">
    Common Cosmos wallets include **Keplr** and **Leap** (Ledger supported). You can add the Lava chain directly in these wallets per the official docs.
  </Accordion>

  <Accordion title="Are there fees?">
    On-chain transactions pay gas in **LAVA**. For RPC/API usage, developers buy on-chain subscription plans measured in **Compute Units (CU)**; rewards are distributed to providers based on relays served and QoS.
  </Accordion>

  <Accordion title="What is the unbonding period?">
    The staking unbonding period is currently \~**21 days** (Cosmos staking module). Parameters can change via governance; always check current chain parameters.
  </Accordion>

  <Accordion title="How do I stake or delegate LAVA?">
    Add the Lava chain in a supported wallet (e.g., Keplr/Leap), choose a validator, and delegate. Rewards accrue per protocol rules; after starting an unstake, funds become withdrawable once the unbonding period ends.
  </Accordion>
</AccordionGroup>


# Overview
Source: https://docs.krews.xyz/networks/story

Story Protocol is a modular, EVM-first blockchain focused on programmable intellectual property (IP). By separating execution from staking with Cosmos-style modules, Story lets creators register IP on-chain, set licensing terms, and monetize usage while validators secure the network. As a validator service, Krews runs high-availability infrastructure on Story to deliver reliable performance and continuous uptime for our delegators.

[Website](https://www.story.foundation/) <Icon icon="arrow-up-right" /> | [Twitter](https://x.com/StoryProtocol) <Icon icon="arrow-up-right" /> | [Github](https://github.com/storyprotocol) <Icon icon="arrow-up-right" /> | [Resources](https://www.story.foundation/blog) <Icon icon="arrow-up-right" />

## FAQ

<AccordionGroup>
  <Accordion title="What wallets are supported for Story?">
    Story is EVM-compatible. Any modern EVM wallet works via WalletConnect—common choices include MetaMask, Rabby, Rainbow, and Coinbase Wallet. Hardware wallets (e.g., Ledger) can be used through these wallets’ EVM integrations. If your wallet needs network parameters, add Story from Chainlist or the official docs.
  </Accordion>

  <Accordion title="Is there a fee?">
    Yes. Krews charges a 10% commission on staking rewards. The APR you see on dashboards reflects the network’s gross yield before deducting Krews’s commission.
  </Accordion>

  <Accordion title="What is the unbonding period?">
    Story uses a **14-day unbonding period**. After you initiate unstake, tokens wait \~14 days without accruing rewards. Once unbonded, withdrawals are processed through a queue (processed in batches each block). When your request is executed, you can withdraw the tokens to your wallet.
  </Accordion>

  <Accordion title="How do I stake with Krews on Story?">
    1. Connect an EVM wallet (e.g., MetaMask).
    2. Acquire IP tokens and fund the wallet with a small amount for fees.
    3. Open the official **Story Staking Dashboard**: [https://staking.story.foundation/](https://staking.story.foundation/)
    4. Find “Krews” in the validator list and open the validator page.
    5. Choose your staking type (flexible or fixed, if available for your token type) and amount.
    6. Confirm the transaction in your wallet. Rewards start accruing after your stake is active.
  </Accordion>

  <Accordion title="How can I claim and restake rewards?">
    Claim rewards from the Staking Dashboard when available under your account/validator position. To compound, delegate claimed IP back to Krews in a new stake transaction. If you plan to unstake, remember the **14-day unbonding** applies before you can withdraw.

    <Note>
      Keep a small IP balance for network fees. Some fixed-term staking options restrict unstaking until the term ends; flexible staking can be unstaked anytime but still observes the 14-day unbonding before withdrawal.
    </Note>
  </Accordion>
</AccordionGroup>


# Overview
Source: https://docs.krews.xyz/networks/sunrise

Sunrise is a next‑generation Layer‑1 that unifies a high‑throughput Data Availability layer with a native Liquidity Hub. By integrating Proof‑of‑Liquidity (PoL) and fee abstraction, Sunrise enables rollups and app‑chains to access shared liquidity, flexible gas payments, and scalable off‑chain blobs for data‑intensive use cases.

[Website](https://sunriselayer.io/) <Icon icon="arrow-up-right" /> | [Twitter](https://x.com/SunriseLayer) <Icon icon="arrow-up-right" /> | [Github](https://github.com/sunriselayer) <Icon icon="arrow-up-right" /> | [Resources](https://docs.sunriselayer.io/) <Icon icon="arrow-up-right" />

## FAQ

<AccordionGroup>
  <Accordion title="What wallets are supported for Sunrise?">
    Sunrise works with Cosmos SDK–compatible wallets such as <strong>Keplr</strong>, <strong>Leap</strong>, or <strong>Cosmostation</strong>. You can also use the Sunrise App to delegate or manage locked assets as described in the docs. Availability of features (governance, staking views, etc.) may vary by wallet.
  </Accordion>

  <Accordion title="What is the unbonding period?">
    Sunrise enforces a <strong>21‑day unbonding period</strong>. After submitting an undelegation, your RISE or vRISE remains locked and non‑transferable for 21 days; once the period ends, funds become withdrawable.
  </Accordion>

  <Accordion title="How do I stake on Sunrise?">
    1. Install a Cosmos‑compatible wallet (e.g., Keplr or Leap) and connect it to the Sunrise network or open the Sunrise App.<br />
    2. Acquire <strong>RISE</strong> (or manage <strong>vRISE</strong> if applicable) and choose a validator from the staking interface.<br />
    3. Submit a <em>Delegate</em> transaction and keep a small balance for gas.<br />
    4. To change validators without waiting, use <em>Redelegate</em> (subject to chain rules).
  </Accordion>

  <Accordion title="Are there validator commissions or fees?">
    Yes. Each validator sets a <strong>commission rate</strong> on staking rewards. Review a validator’s commission and performance before delegating. Network gas fees also apply to transactions.
  </Accordion>

  <Accordion title="How can I claim and restake rewards?">
    Rewards can be claimed from your wallet or the Sunrise App’s staking page. To compound, claim rewards and delegate them again to your chosen validator. Always leave a small amount of RISE for gas.
  </Accordion>
</AccordionGroup>


# Installation (Holesky/Mainnet)
Source: https://docs.krews.xyz/node-installation-mainnet/aligned

Run the Aligned Layer Operator binary using the official steps. This guide is trimmed to the essential build, configure, and start sequence.

<Note>
  **Note:** You must be [**whitelisted**](https://docs.google.com/forms/d/e/1FAIpQLSdH9sgfTz4v33lAvwj6BvYJGAeIshQia3FXz36PFfF-WQAWEQ/viewform) to operate on Aligned. Current operator version in docs: `v0.19.1` ([check docs for updates](https://github.com/yetanotherco/aligned_layer/releases/tag/v0.19.1)).
</Note>

## 1) Requirements

* Linux x86\_64
* Go, Rust, Foundry
* Build deps: `pkg-config`, `libssl-dev`, `g++`

| **Component** | **Specification** |
| ------------- | ----------------- |
| **CPU**       | 16 cores          |
| **Memory**    | 32 GB RAM         |
| **Bandwidth** | 1 Gbps            |
| **Storage**   | 256 GB disk space |

## 2) Clone and build

```bash theme={null}
git clone https://github.com/yetanotherco/aligned_layer.git --branch v0.19.1
cd aligned_layer

# Install Foundry
make foundry_install && foundryup

# Build operator (testnet example: Holesky/Hoodi)
make operator_build ENVIRONMENT=testnet

# For mainnet build:
# make operator_build ENVIRONMENT=mainnet
```

## 3) Configure your operator

Provide RPC endpoints, keys, and strategy-specific settings in your config file(s). See the docs for the required fields and supported strategies list.

## 4) Register the operator

Follow the registration step in docs (requires whitelisting and EigenLayer operator registration).

## 5) Start the operator

```bash theme={null}
# From the repo root, using your config
./operator/build/aligned-operator --config <path_to_config.toml>
```

(Optional) Run with systemd as shown in the docs for persistence.

## 6) Check version & status

```bash theme={null}
./operator/build/aligned-operator --version

# Telemetry (replace <operator_address>):
# Mainnet
curl https://mainnet.telemetry.alignedlayer.com/versions/<operator_address>
# Holesky
curl https://holesky.telemetry.alignedlayer.com/versions/<operator_address>
```


# Installation
Source: https://docs.krews.xyz/node-installation-mainnet/story

Set up a Story mainnet full node (execution: story-geth, consensus: story) with Cosmovisor-based management.

## System requirements (official)

| Component | Recommended (Mainnet) |
| --------- | --------------------- |
| CPU       | Dedicated **8 cores** |
| RAM       | **32 GB**             |
| Disk      | **500 GB NVMe**       |
| Bandwidth | **25 MBit/s**         |

<Steps>
  <Step title="System prep">
    * Ubuntu 22.04 LTS
    * Open ports: **30303** (Geth P2P), **8545/8546** (JSON-RPC/WS, optional), **26656/26657** (consensus P2P/RPC), **26660** (Prometheus)

    ```bash theme={null}
    sudo apt update && sudo apt install -y curl git unzip wget jq make build-essential lz4
    ```
  </Step>

  <Step title="Install story-geth (execution)">
    ```bash theme={null}
    # Download latest mainnet binary
    cd $HOME
    curl -L -o story-geth https://github.com/piplabs/story-geth/releases/latest/download/geth-linux-amd64
    chmod +x story-geth && sudo mv story-geth /usr/local/bin/story-geth

    # Verify
    story-geth version
    ```
  </Step>

  <Step title="Install story (consensus) + Cosmovisor">
    ```bash theme={null}
    # Cosmovisor
    go install cosmossdk.io/tools/cosmovisor/cmd/cosmovisor@v1.6.0
    cosmovisor version

    # Download latest story binary
    cd $HOME
    curl -L -o story https://github.com/piplabs/story/releases/latest/download/story-linux-amd64
    chmod +x story && sudo mv story /usr/local/bin/story
    story version
    ```
  </Step>

  <Step title="Initialize node data">
    ```bash theme={null}
    # Initialize consensus store for mainnet
    cosmovisor init $(which story)
    cosmovisor run init --network story --moniker "$HOSTNAME"
    ```
  </Step>

  <Step title="Create services">
    ```bash theme={null}
    # story-geth
    sudo tee /etc/systemd/system/story-geth.service > /dev/null <<EOF
    [Unit]
    Description=Story Geth (execution) — Mainnet
    After=network-online.target
    [Service]
    User=${USER}
    ExecStart=/usr/local/bin/story-geth --story --syncmode full
    Restart=on-failure
    RestartSec=5
    LimitNOFILE=65535
    [Install]
    WantedBy=multi-user.target
    EOF

    # story via Cosmovisor
    sudo tee /etc/systemd/system/story.service > /dev/null <<EOF
    [Unit]
    Description=Story (consensus) via Cosmovisor — Mainnet
    After=network-online.target
    [Service]
    Type=simple
    User=${USER}
    ExecStart=$(which cosmovisor) run run --api-enable --api-address=0.0.0.0:1317
    Restart=on-failure
    RestartSec=5s
    LimitNOFILE=65535
    Environment="DAEMON_NAME=story"
    Environment="DAEMON_HOME=$HOME/.story/story"
    Environment="DAEMON_ALLOW_DOWNLOAD_BINARIES=false"
    Environment="DAEMON_RESTART_AFTER_UPGRADE=true"
    Environment="DAEMON_DATA_BACKUP_DIR=$HOME/.story/story/cosmovisor/backup"
    WorkingDirectory=$HOME/.story/story
    [Install]
    WantedBy=multi-user.target
    EOF

    sudo systemctl daemon-reload
    sudo systemctl enable story-geth story
    sudo systemctl start story-geth story
    journalctl -u story -f -o cat
    ```
  </Step>

  <Step title="Verify">
    ```bash theme={null}
    # Execution (JSON-RPC): latest block
    curl -s -X POST -H "Content-Type: application/json"       --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'       http://localhost:8545

    # Consensus (Tendermint RPC): status & peers
    curl -s localhost:26657/status | jq
    curl -s localhost:26657/net_info | jq '.result.peers[].node_info.moniker'
    ```
  </Step>
</Steps>

<Note>
  For versions and release notes, always consult the official **Story** release pages before installing/upgrading.
</Note>


# Installation
Source: https://docs.krews.xyz/node-installation-testnet/story

Set up a Story Aeneid testnet full node (execution: story-geth with --aeneid, consensus: story --network aeneid).

## System requirements (baseline)

Use the **same baseline** as mainnet for best compatibility:

| Component | Recommended (Aeneid baseline) |
| --------- | ----------------------------- |
| CPU       | Dedicated **8 cores**         |
| RAM       | **32 GB**                     |
| Disk      | **500 GB NVMe**               |
| Bandwidth | **25 MBit/s**                 |

<Note>
  Resource usage on testnet can be lower, but keeping mainnet-class specs avoids sync issues and reorg sensitivity during testnet events.
</Note>

<Steps>
  <Step title="System prep">
    * Ubuntu 22.04 LTS
    * Open ports: **30303** (Geth P2P), **8545/8546** (JSON-RPC/WS, optional), **26656/26657** (consensus P2P/RPC), **26660** (Prometheus)

    ```bash theme={null}
    sudo apt update && sudo apt install -y curl git unzip wget jq make build-essential lz4
    ```
  </Step>

  <Step title="Install story-geth (execution) for Aeneid">
    ```bash theme={null}
    cd $HOME
    curl -L -o story-geth https://github.com/piplabs/story-geth/releases/latest/download/geth-linux-amd64
    chmod +x story-geth && sudo mv story-geth /usr/local/bin/story-geth
    story-geth version
    ```
  </Step>

  <Step title="Install story (consensus) + Cosmovisor">
    ```bash theme={null}
    go install cosmossdk.io/tools/cosmovisor/cmd/cosmovisor@v1.6.0
    cosmovisor version

    cd $HOME
    curl -L -o story https://github.com/piplabs/story/releases/latest/download/story-linux-amd64
    chmod +x story && sudo mv story /usr/local/bin/story
    story version
    ```
  </Step>

  <Step title="Initialize node data for Aeneid">
    ```bash theme={null}
    # Consensus store
    cosmovisor init $(which story)
    cosmovisor run init --network aeneid --moniker "$HOSTNAME"
    ```
  </Step>

  <Step title="Create services (Aeneid)">
    ```bash theme={null}
    # story-geth (Aeneid)
    sudo tee /etc/systemd/system/story-geth.service > /dev/null <<EOF
    [Unit]
    Description=Story Geth (execution) — Aeneid Testnet
    After=network-online.target
    [Service]
    User=${USER}
    ExecStart=/usr/local/bin/story-geth --aeneid --syncmode full
    Restart=on-failure
    RestartSec=5
    LimitNOFILE=65535
    [Install]
    WantedBy=multi-user.target
    EOF

    # story via Cosmovisor (Aeneid)
    sudo tee /etc/systemd/system/story.service > /dev/null <<EOF
    [Unit]
    Description=Story (consensus) via Cosmovisor — Aeneid
    After=network-online.target
    [Service]
    Type=simple
    User=${USER}
    ExecStart=$(which cosmovisor) run run --api-enable --api-address=0.0.0.0:1317
    Restart=on-failure
    RestartSec=5s
    LimitNOFILE=65535
    Environment="DAEMON_NAME=story"
    Environment="DAEMON_HOME=$HOME/.story/story"
    Environment="DAEMON_ALLOW_DOWNLOAD_BINARIES=false"
    Environment="DAEMON_RESTART_AFTER_UPGRADE=true"
    Environment="DAEMON_DATA_BACKUP_DIR=$HOME/.story/story/cosmovisor/backup"
    WorkingDirectory=$HOME/.story/story
    [Install]
    WantedBy=multi-user.target
    EOF

    sudo systemctl daemon-reload
    sudo systemctl enable story-geth story
    sudo systemctl start story-geth story
    journalctl -u story -f -o cat
    ```
  </Step>

  <Step title="Verify">
    ```bash theme={null}
    # Execution
    curl -s -X POST -H "Content-Type: application/json"       --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'       http://localhost:8545

    # Consensus
    curl -s localhost:26657/status | jq
    curl -s localhost:26657/net_info | jq '.result.peers[].node_info.moniker'
    ```
  </Step>
</Steps>

<Note>
  Use separate data directories/wallets between mainnet and Aeneid. The `--aeneid` flag reconfigures **story-geth** to the testnet with different bootnodes and network IDs.
</Note>


# Upgrade
Source: https://docs.krews.xyz/upgrade-mainnet/aligned

Upgrade the Aligned Layer operator by checking out the target tag and rebuilding.

<Note>
  You must be **authorized/whitelisted** to operate. Follow the exact tag required by the network announcement.
</Note>

## Rebuild to a target version

```bash theme={null}
# From the repo root
cd ~/aligned_layer || git clone https://github.com/yetanotherco/aligned_layer.git ~/aligned_layer && cd ~/aligned_layer

# Fetch and checkout the target tag (example: v0.19.1; replace as announced)
git fetch --tags
git checkout v0.19.1

# Build (example: testnet)
make operator_build ENVIRONMENT=testnet
# For mainnet:
# make operator_build ENVIRONMENT=mainnet
```

## Restart

```bash theme={null}
# If you used systemd
sudo systemctl restart aligned-operator && journalctl -u aligned-operator -f -o cat

# Or run the binary directly with your config
./operator/build/aligned-operator --config <path_to_config.toml>
```

## Verify

```bash theme={null}
# Local version
./operator/build/aligned-operator --version
```


# Upgrade
Source: https://docs.krews.xyz/upgrade-mainnet/aptos

Upgrade an Aptos Public Fullnode (PFN) installed via Docker or from source. Minimal, correct steps with verification links.

<Note>
  These steps apply to **PFN** on **mainnet** or **testnet**. Your network is determined by the **docker image tag** or **git branch** and the **genesis/waypoint** files in your config.
</Note>

## A) Docker-based PFN

```bash theme={null}
# 1) Pull the new image
docker pull aptoslabs/validator:mainnet    # use :testnet for testnet

# 2) Stop + remove the old container (adjust the name if different)
docker stop aptos-pfn || true && docker rm aptos-pfn || true

# 3) Start with the SAME volume and your config (fullnode.yaml + genesis/waypoint)
docker run -d --name aptos-pfn   -v $(pwd):/opt/aptos/etc   -p 8080:8080 -p 9101:9101   aptoslabs/validator:mainnet   aptos-node -f /opt/aptos/etc/fullnode.yaml
```

## B) Source-based PFN

```bash theme={null}
# 1) Update source
cd aptos-core || git clone https://github.com/aptos-labs/aptos-core.git && cd aptos-core
git fetch --tags
git checkout origin/mainnet   # or origin/testnet

# 2) Rebuild
cargo build -p aptos-node --release

# 3) Restart your service/process using the new binary
# e.g., systemd: systemctl restart aptos-pfn
```

## Verify

* **REST**: `curl -s http://127.0.0.1:8080/v1 | jq` (returns chain\_id and ledger info)
* **Metrics**: `curl -s http://127.0.0.1:9101/metrics | head`
* **NHC** (optional): follow the Node Health Checker guide above.


# Upgrade
Source: https://docs.krews.xyz/upgrade-mainnet/avail

Upgrade an Avail full node (Mainnet or Turing) installed via pre-built binaries, Docker, or from source. Minimal, clear steps with verification and links to official docs.

<Note>
  This page covers **full/RPC nodes**. Validator operators should consider the **Slow & Safe Upgrade** (rolling replacement with key rotation) described in the official guide.
</Note>

## Before you start

* Check the latest version and [**release notes**](https://github.com/availproject/avail/releases/) on the GitHub Releases page.
* Plan a maintenance window if you expose RPC to users.
* The procedure is identical for **Mainnet** and **Turing**; your `--chain` flag selects the network.

## A) Upgrade — Pre-built binary

Replace the existing `avail-node` binary with the latest release, then restart the service.

```bash theme={null}
# 1) Stop the service
sudo systemctl stop avail.service

# 2) Download & extract the latest binary (choose the right file for your OS/arch)
cd /usr/local/bin
curl -L -O https://github.com/availproject/avail/releases/download/<LATEST-TAG>/<YOUR-SYSTEM-BIN>.tar.gz
tar -xzvf <YOUR-SYSTEM-BIN>.tar.gz

# 3) Replace the old binary (keep a backup just in case)
sudo mv avail-node avail-node.bak || true
sudo mv ./avail-node /usr/local/bin/avail-node
sudo chmod +x /usr/local/bin/avail-node

# 4) Start and follow logs
sudo systemctl start avail.service
journalctl -u avail.service -f -o cat
```

Some packages/bundles name the binary `data-avail`. If that's your case, replace `avail-node` in the commands above with `data-avail`.

## B) Upgrade — Docker

```bash theme={null}
# 1) Pull the new image tag
docker pull availj/avail:<LATEST-TAG>

# 2) Stop & remove the existing container (name it if you didn't before)
docker stop avail && docker rm avail

# 3) Start a new container with the same volumes/ports
docker run --name avail --restart=on-failure -d   -v /root/avail/node-data:/da/node-data   -p 9944:9944 -p 30333:30333   docker.io/availj/avail:<LATEST-TAG>   --chain mainnet -d ./output --name "<your-node-name>"
# For Turing, switch --chain to `turing` (or provide an explicit Turing chainspec path if needed)
```

## C) Upgrade — Build from source

```bash theme={null}
# 1) Ensure Rust toolchain is installed
curl https://sh.rustup.rs -sSf | sh
source $HOME/.cargo/env

# 2) Update sources and build
cd /opt/avail || git clone https://github.com/availproject/avail.git /opt/avail && cd /opt/avail
git fetch --tags
git checkout <LATEST-TAG>
cargo build --release --locked

# 3) Replace the running binary and restart
sudo systemctl stop avail.service
sudo install -m 0755 ./target/release/avail-node /usr/local/bin/avail-node
sudo systemctl start avail.service
journalctl -u avail.service -f -o cat
```

## Verify the upgrade

* **Logs** show the new version near startup (e.g., `version 2.x.x-<git-hash>`).
* **Telemetry**: find your node by `--name` on the correct network tab and confirm the reported version.
* **RPC** (if enabled): `curl http://127.0.0.1:9944 -H 'Content-Type: application/json' -d '{"id":1,"jsonrpc":"2.0","method":"system_version","params":[]}'`

<Note>
  After protocol/runtime upgrades, nodes running an **outdated client** may fail to sync or build blocks. Keep up with release announcements and upgrade promptly.
</Note>


# Upgrade
Source: https://docs.krews.xyz/upgrade-mainnet/celestia

Safely upgrade celestia-node and celestia-app, including Cosmovisor-managed consensus upgrades.

## celestia-node (DA) upgrade

<Steps>
  <Step title="Stop node & fetch latest release">
    ```bash theme={null}
    # Stop your service (example name)
    sudo systemctl stop celestia-light || true
    sudo systemctl stop celestia-full || true
    sudo systemctl stop celestia-bridge || true

    # Update from source
    cd $HOME/celestia-node || { cd $HOME; rm -rf celestia-node; git clone https://github.com/celestiaorg/celestia-node.git; cd celestia-node; }
    git fetch --all --tags
    git checkout $(git describe --tags --abbrev=0)
    make node-install

    celestia version
    ```
  </Step>

  <Step title="Restart & verify">
    ```bash theme={null}
    sudo systemctl start celestia-light || true
    sudo systemctl start celestia-full || true
    sudo systemctl start celestia-bridge || true

    journalctl -u celestia-light -f -o cat || true
    ```
  </Step>
</Steps>

## celestia-app (consensus) upgrade with Cosmovisor

<Steps>
  <Step title="Install/verify Cosmovisor">
    ```bash theme={null}
    # As per Cosmos SDK tooling (see official docs)
    go install cosmossdk.io/tools/cosmovisor/cmd/cosmovisor@v1.6.0
    cosmovisor version
    ```
  </Step>

  <Step title="Prepare the new binary">
    ```bash theme={null}
    # Build or download new celestia-appd and place under the target upgrade dir
    # Example layout:
    mkdir -p $HOME/.celestia-app/cosmovisor/upgrades/<UPGRADE_NAME>/bin
    cp $(which celestia-appd) $HOME/.celestia-app/cosmovisor/upgrades/<UPGRADE_NAME>/bin/
    ```
  </Step>

  <Step title="Schedule the upgrade">
    Use your chain’s **governance proposal** (if applicable) or the advised block **height/time** from Celestia release notes. Cosmovisor will switch binaries automatically when the upgrade triggers.
  </Step>

  <Step title="Monitor & rollback plan">
    ```bash theme={null}
    journalctl -u cosmovisor -f -o cat
    # If needed, stop services and revert to the previous binary placed under `genesis/bin`.
    ```
  </Step>
</Steps>

<Note>
  Always confirm the **target version / upgrade height** from the official release notes and the network announcements before scheduling upgrades.
</Note>


# Upgrade
Source: https://docs.krews.xyz/upgrade-mainnet/dymension

Upgrade the Dymension Hub full node by building the target tag and restarting.

<Note>
  Confirm the **latest mainnet tag** from the official repository or docs before upgrading.
</Note>

## Build the target version

```bash theme={null}
cd ~/dymension || git clone https://github.com/dymensionxyz/dymension.git ~/dymension && cd ~/dymension
git fetch --tags
git checkout v3.2.0   # replace with the announced version
make install          # installs 'dymd' to $GOBIN
dymd version --long
```

## Restart

```bash theme={null}
# If using systemd
sudo systemctl restart dymd
journalctl -u dymd -f -o cat

# Or run in foreground
dymd start
```

## Verify

```bash theme={null}
curl -s localhost:26657/status | jq '.result.sync_info'
```


# Upgrade
Source: https://docs.krews.xyz/upgrade-mainnet/espresso

Safe upgrade procedure for Espresso sequencer nodes on the Decaf testnet. Covers image tags, backups, health checks, and rollback.

<Steps>
  <Step title="Review release notes & confirm target image">
    Open the Decaf **release** page and note the latest **Docker image tag** for the sequencer. For example, the current tag is:

    ```bash theme={null}
    ghcr.io/espressosystems/espresso-sequencer/sequencer:20251106-patch1
    ```

    Also check for any changes to **endpoints**, **genesis file**, or **staking rules**.
  </Step>

  <Step title="Backup data & keys">
    Back up your mounted directories (adjust paths if different):

    ```bash theme={null}
    sudo systemctl stop docker || true
    # or just stop the container:
    docker stop espresso-sequencer || true

    # back up sqlite store (non-DA) or any local data
    rsync -aH /opt/espresso/store/ /opt/espresso/backup/store-$(date +%F)/

    # back up key material
    rsync -aH /opt/espresso/keys/ /opt/espresso/backup/keys-$(date +%F)/
    ```

    If you operate a **DA node**, back up your **PostgreSQL** database per your DB’s backup procedure.
  </Step>

  <Step title="Pull new images">
    ```bash theme={null}
    export NEW_TAG="20251106-patch1"   # replace with the tag from release notes
    docker pull ghcr.io/espressosystems/espresso-sequencer/sequencer:${NEW_TAG}
    docker pull ghcr.io/espressosystems/espresso-sequencer/staking-cli:main
    ```
  </Step>

  <Step title="Update environment & restart">
    Confirm your environment is still valid for **Decaf** (notably, the **genesis file** and **endpoints**):

    ```bash theme={null}
    export ESPRESSO_SEQUENCER_GENESIS_FILE="/genesis/decaf.toml"
    export ESPRESSO_SEQUENCER_CONFIG_PEERS="https://cache.decaf.testnet.espresso.network"
    export ESPRESSO_SEQUENCER_ORCHESTRATOR_URL="https://orchestrator-UZAFTUIMZOT.decaf.testnet.espresso.network/"
    export ESPRESSO_SEQUENCER_CDN_ENDPOINT="cdn.decaf.testnet.espresso.network:1737"
    export ESPRESSO_STATE_RELAY_SERVER_URL="https://state-relay.decaf.testnet.espresso.network"
    ```

    Then restart the container using the **new tag**:

    ```bash theme={null}
    docker rm -f espresso-sequencer || true
    docker run -d --name espresso-sequencer --restart unless-stopped       -v /opt/espresso/store:/mount/sequencer/store       -v /opt/espresso/keys:/mount/sequencer/keys:ro       -e ESPRESSO_SEQUENCER_L1_PROVIDER -e ESPRESSO_SEQUENCER_L1_WS_PROVIDER       -e ESPRESSO_SEQUENCER_CONFIG_PEERS -e ESPRESSO_SEQUENCER_ORCHESTRATOR_URL       -e ESPRESSO_SEQUENCER_CDN_ENDPOINT -e ESPRESSO_STATE_RELAY_SERVER_URL       -e ESPRESSO_SEQUENCER_GENESIS_FILE       ghcr.io/espressosystems/espresso-sequencer/sequencer:${NEW_TAG}         sequencer -- http -- catchup -- status
    ```
  </Step>

  <Step title="Validate the upgrade">
    * Watch logs: `docker logs -f espresso-sequencer` and ensure the node **joins** and **syncs**.
    * Confirm **/status** and/or metrics are exposed on your configured API port.
    * Check **libp2p** connectivity (UDP port reachable, peers listed).
  </Step>

  <Step title="Rollback (if needed)">
    ```bash theme={null}
    export PREV_TAG="202510XX-some-previous"  # your last known good tag
    docker rm -f espresso-sequencer || true
    docker run -d --name espresso-sequencer       -v /opt/espresso/store:/mount/sequencer/store       -v /opt/espresso/keys:/mount/sequencer/keys:ro       ghcr.io/espressosystems/espresso-sequencer/sequencer:${PREV_TAG}         sequencer -- http -- catchup -- status
    ```

    Restore from your **store/** and **keys/** backups if corruption is suspected.
  </Step>
</Steps>

<Note>
  *Supported networks:* **Espresso Decaf testnet**.
</Note>


# Upgrade
Source: https://docs.krews.xyz/upgrade-mainnet/initia

How to handle Initia node upgrades using Cosmovisor (auto) or manual binary replacement.

## Recommended: Cosmovisor (auto-upgrade)

<Steps>
  <Step title="Enable Cosmovisor during setup">
    If you used **Weave**, select the **automatic upgrades via Cosmovisor** option in the wizard. This will wire your node so new binaries are picked up at governance-scheduled heights.
  </Step>

  <Step title="Service layout & env">
    Cosmovisor expects a directory layout under `~/.initia/cosmovisor/` with `genesis/` and `upgrades/<name>/bin/`. When an upgrade triggers, the daemon switches to the new binary automatically.
  </Step>

  <Step title="Monitor upcoming proposals">
    Keep an eye on governance proposals that schedule upgrades. Confirm the **target version tag** and the **upgrade height** before the event.
  </Step>
</Steps>

## Manual upgrade (if not using Cosmovisor)

<Steps>
  <Step title="Find the target tag">
    Identify the correct **release tag** for your network (Mainnet `interwoven-1` or Testnet `initiation-2`). Use the official releases and notes.
  </Step>

  <Step title="Build or download the new binary">
    ```bash theme={null}
    cd ~/initia || git clone https://github.com/initia-labs/initia.git && cd initia
    git fetch --all
    git checkout <NEW_TAG>
    make install
    initiad version
    ```
  </Step>

  <Step title="Stop, replace, restart">
    ```bash theme={null}
    sudo systemctl stop initiad || true
    # If using a static path, ensure $(which initiad) now points to the new binary
    sudo systemctl start initiad
    journalctl -u initiad -f
    ```
  </Step>

  <Step title="Post-upgrade checks">
    ```bash theme={null}
    initiad version
    curl -s localhost:26657/status | jq .result.node_info.network
    curl -s localhost:26657/status | jq .result.sync_info.catching_up
    ```
  </Step>
</Steps>

<Note>
  If your node falls behind or you upgraded late, consider **state sync** or a **snapshot** provider compatible with your chain and height. Always verify integrity and provenance.
</Note>


# Upgrade
Source: https://docs.krews.xyz/upgrade-mainnet/lava

Upgrade the Lava RPC Provider (lavap) by building the latest tag and restarting the process.

<Note>
  The provider fronts your own chain nodes. Upgrading `lavap` does not upgrade those underlying nodes.
</Note>

## Build latest

```bash theme={null}
cd ~/lava || git clone https://github.com/lavanet/lava.git ~/lava && cd ~/lava
git fetch --tags
# Checkout a specific tag if announced, else build default
# git checkout vX.Y.Z
LAVA_BINARY=lavap make install
lavap version || lavap --version
```

## Restart

```bash theme={null}
# If systemd-managed
sudo systemctl restart lavap && journalctl -u lavap -f -o cat

# Or run directly (example)
lavap rpcprovider lava-provider.yml --from <wallet_name> --geolocation 1 --chain-id lava-mainnet-1
```

## Verify

```bash theme={null}
# Connectivity test
lavap test rpcprovider --from <wallet_name>
```


# Upgrade
Source: https://docs.krews.xyz/upgrade-mainnet/story

How to upgrade Story clients: story-geth (execution) and story (consensus), including Cosmovisor scheduling.

## Upgrade story-geth

<Steps>
  <Step title="Stop services">
    ```bash theme={null}
    sudo systemctl stop story-geth || true
    sudo systemctl stop story || true
    ```
  </Step>

  <Step title="Install new story-geth binary">
    ```bash theme={null}
    cd $HOME
    curl -L -o story-geth https://github.com/piplabs/story-geth/releases/latest/download/geth-linux-amd64
    chmod +x story-geth && sudo mv story-geth /usr/local/bin/story-geth
    story-geth version
    ```
  </Step>

  <Step title="Restart">
    ```bash theme={null}
    sudo systemctl start story-geth
    sudo systemctl start story
    journalctl -u story-geth -f -o cat
    ```
  </Step>
</Steps>

## Upgrade story (consensus)

<Steps>
  <Step title="Manual binary switch">
    ```bash theme={null}
    sudo systemctl stop story

    # Download new binary
    cd $HOME
    curl -L -o story https://github.com/piplabs/story/releases/latest/download/story-linux-amd64
    chmod +x story && sudo mv story /usr/local/bin/story

    sudo systemctl start story
    story version
    ```
  </Step>

  <Step title="Schedule with Cosmovisor (recommended)">
    ```bash theme={null}
    # 1) Place the new binary
    export UPGRADE_NAME=<upgrade_name>
    mkdir -p $HOME/.story/story/cosmovisor/upgrades/$UPGRADE_NAME/bin
    cp /usr/local/bin/story $HOME/.story/story/cosmovisor/upgrades/$UPGRADE_NAME/bin/

    # 2) Schedule at announced height
    source $HOME/.bash_profile || true
    cosmovisor add-upgrade $UPGRADE_NAME $HOME/.story/story/cosmovisor/upgrades/$UPGRADE_NAME --force --upgrade-height <height>

    # 3) Monitor
    journalctl -u story -f -o cat
    ```
  </Step>
</Steps>

<Note>
  Always confirm **target versions** and **upgrade height/time** from official announcements before scheduling. Ensure the node is fully synced and has free disk space.
</Note>


# Upgrade
Source: https://docs.krews.xyz/upgrade-mainnet/sunrise

Handle Sunrise chain upgrades safely. Cosmovisor automation and manual procedures for soft/hard forks.

## Cosmovisor (recommended)

<Steps>
  <Step title="Set up Cosmovisor">
    Configure Cosmovisor per the official tutorial so it manages your `sunrised` binary under `~/.sunrise/cosmovisor/`. Enable:

    ```bash theme={null}
    export DAEMON_ALLOW_DOWNLOAD_BINARIES=true
    ```
  </Step>

  <Step title="Follow governance proposals">
    Upgrades are scheduled via on-chain governance. Confirm proposed **height** and **target binary version** before the event.
  </Step>

  <Step title="Automatic switch at upgrade height">
    With Cosmovisor, the process switches to the prepared binary at the scheduled height with minimal downtime. Ensure your `upgrades/<name>/bin/sunrised` is present beforehand.
  </Step>
</Steps>

## Manual upgrades (no Cosmovisor)

<Steps>
  <Step title="Identify the correct tag">
    Check the **network** repository for your chain (e.g., `sunrise-1`) and the latest release on GitHub for the required `sunrised` version.
  </Step>

  <Step title="Build and install">
    ```bash theme={null}
    cd ~/sunrise || git clone https://github.com/sunriselayer/sunrise.git && cd sunrise
    git fetch --all
    git checkout <NEW_TAG>
    make install
    sunrised version
    ```
  </Step>

  <Step title="Restart and verify">
    ```bash theme={null}
    sudo systemctl stop sunrised || true
    sunrised start &
    curl -s localhost:26657/status | jq .result.sync_info.catching_up
    ```
  </Step>
</Steps>

### Soft vs Hard Fork

* **Soft fork**: same chain-id, binary changes handled by an upgrade handler; Cosmovisor can automate.
* **Hard fork**: new `genesis.json` and often a **new chain-id**; syncing starts from height 1; follow migration notes provided in the proposal.