> ## Documentation Index
> Fetch the complete documentation index at: https://docs.novacula.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Igra

> Two-process (kaspad + igra-reth) EVM-compatible L2 anchored on Kaspa

Igra is an EVM-compatible L2 anchored on the Kaspa DAG. Every Igra node runs two processes: a **kaspad** node that follows the underlying Kaspa network, and an **igra-reth** execution layer (a reth fork tailored to the Igra L2) that serves the standard Ethereum JSON-RPC. The two share a JWT secret over the internal Engine API, just like an Ethereum execution-layer / consensus-layer pair; that link is internal to the node and you don't configure it.

Igra runs on Kubernetes only. Deploy it from the **Deploy Node** wizard against an executor that supports Igra. See [Provision on Kubernetes](/recipes/provision-on-kubernetes).

## Quick start on k3s

No full cluster? A lightweight distribution works too. **[k3s](https://k3s.io)** is a CNCF-certified, single-binary Kubernetes that stands up a working cluster in one command — enough to host the Novacula Operator and an Igra node.

<Steps>
  <Step title="Install a single-node k3s cluster">
    ```bash theme={null}
    curl -sfL https://get.k3s.io | sh -
    ```

    k3s ships a default `local-path` storage class, which the Operator's PVCs can use. It stores data on the node's own disk, so size that disk for Igra's volumes (see [Resource defaults](#resource-defaults) below). This is fine for a test or `galleon-testnet` node; for a production `mainnet` node use a real CSI storage class instead.
  </Step>

  <Step title="Install Helm">
    The Operator ships as a Helm chart, so you need [Helm](https://helm.sh):

    ```bash theme={null}
    curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4 | bash
    ```
  </Step>

  <Step title="Point your shell at the cluster">
    ```bash theme={null}
    export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
    ```

    k3s writes this kubeconfig as `root` with `600` permissions. If you aren't running as root, either use `sudo`, or install k3s with `--write-kubeconfig-mode 644` (append it to the install command above) so `kubectl` and `helm` can read the file.
  </Step>

  <Step title="Install the Operator">
    Copy the exact `helm upgrade --install` from the **Connect Executor** screen in the UI — it comes pre-filled with your Hub URL and executor key, so you don't fill those in by hand:

    ```bash theme={null}
    helm upgrade --install nvcl-operator oci://ghcr.io/rsquad/nvcl/charts/nvcl-operator \
      --namespace nvcl-system --create-namespace \
      --set image.tag="<version>" \
      --set gateway.tag="<version>" \
      --set hub.url="https://hub.novacula.io" \
      --set-string hub.token="<executor-api-key>" \
      --set hub.name="<executor-name>"
    ```

    Then confirm the Operator rolled out:

    ```bash theme={null}
    kubectl -n nvcl-system rollout status deploy/nvcl-operator
    ```

    The executor row in the UI flips to `online` within seconds. See [Connect an executor](/docs/executors/connect-an-executor) and the full [Provision on Kubernetes](/recipes/provision-on-kubernetes) walkthrough.
  </Step>

  <Step title="Deploy Igra">
    Open the **Deploy Node** wizard, pick Igra and a network, and deploy. See [Deploy a node](/docs/nodes/deploy-a-node).
  </Step>
</Steps>

## Networks

| Network           | Underlying Kaspa | Use         |
| ----------------- | ---------------- | ----------- |
| `mainnet`         | Kaspa `mainnet`  | Production. |
| `galleon-testnet` | Kaspa `testnet`  | Testing.    |

The wizard offers exactly the networks, clients, and versions the executor declares. Pick a network and the wizard pre-fills the resource and storage defaults for it. Igra has a single node type, **full**.

## Clients

| Role            | Client                    | Versions |
| --------------- | ------------------------- | -------- |
| Kaspa node      | **kaspad**                | `2.3`    |
| Execution layer | **igra-reth** (reth fork) | `2.3`    |

The two roles move in lock-step at the same version.

## Resource defaults

The wizard pre-fills these per network; you can raise them before deploying.

| Network           | Role      | CPU | Memory | Storage |
| ----------------- | --------- | --- | ------ | ------- |
| `mainnet`         | kaspad    | 4   | 24Gi   | 1500Gi  |
| `mainnet`         | igra-reth | 4   | 16Gi   | 1000Gi  |
| `galleon-testnet` | kaspad    | 2   | 24Gi   | 200Gi   |
| `galleon-testnet` | igra-reth | 2   | 8Gi    | 100Gi   |

kaspad is the heavier process — plan for a node well above 32Gi total RAM once both processes and the OS are accounted for.

## Ports

The Ethereum JSON-RPC is served on `:8545` (HTTP) and `:8546` (WebSocket). Point your apps at these.

## Configuration

Igra runs with a fixed, upstream-pinned configuration per network — there are no client config overrides to set when you deploy. The product picks the correct ports, chain identity, and bootstrap for the network you chose.

## Sync

* The **execution layer** receives blocks from kaspad over the internal Engine API; the L2 itself has no peer-to-peer chain-tip discovery.
* **Block Height** and **Sync Progress** are derived by comparing the node's local height against the public Igra explorer's tip on each reporting cycle. This requires outbound HTTPS from the executor to the public explorer (`explorer.igralabs.com`). If your network blocks that egress, **Sync Progress** will report stale.

## Monitoring

Open a node and select the **Monitoring** tab to read the common per-node metrics — **Block Height**, **Peers**, **Sync Progress**, plus **EL Finalized Block** and **EL Safe Block** extras — as charts. Kaspad-side health is surfaced too: **Kaspad DAA Score** (the kaspad chain height) and **Kaspad Sync** progress. See [Node monitoring](/docs/nodes/monitoring).

## Common patterns

* **RPC endpoint** — accept the defaults and expose `:8545` (HTTP) and `:8546` (WebSocket) to your apps. Check egress to the public Igra explorer is open, or **Sync Progress** won't track.