kryvora-node: Running a Kryvora Verification Worker

kryvora-node's credentialed verification role

kryvora-node solves a specific operational problem for Kryvora Network participants: it connects worker hardware to the Kryvora Coordination Hub so the host can receive work, execute telemetry probes, verify peer state, and report proof of availability. Its intended users are node operators, infrastructure administrators, and participants in the Kryvora DePIN network. It is not a general-purpose monitoring agent that can join a network anonymously.

The admission requirement is strict. An operator needs an active Genesis Node Key, described in the README as a soulbound verification credential deployed on Arbitrum One at `0xBCf2cD12D1D37578fA7C69805fE77788e866BE1a`. The README also identifies the network as Arbitrum One, chain ID `42161`, and directs operators to `https://node.kryvora.network` for a bootstrap token. A node without a valid token is rejected by `hub.kryvora.network:4188`. This prerequisite narrows the audience considerably and makes credential acquisition part of installation rather than an optional setup detail.

The documentation assigns the standard worker two CPU cores, 2 GB of RAM, and 20 GB of available SSD storage, with 4 GB of RAM recommended. It supports x86_64 and arm64 systems and requires a stable broadband connection. Inbound port 4177 must be open for local telemetry probes, so this is not a firewalled server-only deployment with no ingress requirement.

Worker, telemetry, storage, and Hub data flow

The documented topology separates task execution from telemetry and shared state. A Worker Engine handles tasks and communicates with a Telemetry Daemon through an IPC or bus relationship. The telemetry process listens on port 4177, while the worker uses the Unix socket `/var/run/node.sock`. Both components use the Kryvora Storage Store for state, peer nonces, and telemetry data.

The host communicates outward with the Kryvora Coordination Hub at `https://hub.kryvora.network:4188`. The README identifies mutual TLS, gRPC or HTTP, a 30-second heartbeat, and verification probes as elements of that connection. Configuration exposes `hub.heartbeat_interval`, whose default is `30` seconds. This indicates a persistent node process rather than a one-shot command that submits telemetry and exits.

The local HTTP surface provides three documented routes: `GET /health` for daemon lifecycle status, `GET /status` for peer connectivity, current block height, and sync state, and `GET /metrics` for Prometheus-compatible counters. Telemetry is enabled by default. The architecture therefore creates two operational boundaries to consider: local operators can inspect health and metrics on port 4177, while the remote Hub governs activation and coordination. The README does not document an unauthenticated mode, fine-grained authorization for local routes, or behavior when telemetry verification fails.

Installing kryvora-node through systemd, Compose, or Go

The Linux systemd route is the shortest documented installation. The installer downloads the binary and registers a service, then prompts for the Genesis Node Key bootstrap token. Reviewing and running a remote shell pipeline has security implications, so operators should account for what `install.sh` executes before granting it root or service privileges.

curl -sSL https://raw.githubusercontent.com/kryvora-network/kryvora-node/main/install.sh | bash

After installation, service status should show the registered unit as running. The status output will depend on the host's systemd state, so a failed or inactive result should be investigated rather than treated as successful enrollment.

sudo systemctl status kryvora-node

For Docker Compose, clone the repository and create a local configuration file. The repository's Compose file mounts `config.example.yaml` at `/etc/kryvora/config.yaml`, publishes `4177:4177`, and supplies the token through `KRYVORA_BOOTSTRAP_TOKEN`.

git clone https://github.com/kryvora-network/kryvora-node.git
cd kryvora-node

cp config.example.yaml config.yaml
# Edit config.yaml and insert your bootstrap_token under auth:
# Or set KRYVORA_BOOTSTRAP_TOKEN in your environment

Start the service and inspect its logs with the documented commands.

KRYVORA_BOOTSTRAP_TOKEN="your_token_here" docker compose up -d

docker compose logs -f kryvora-node

A first status request should return JSON containing peer connectivity, block height, and sync information. A successful local response confirms that the daemon is serving its documented endpoint, but it does not by itself prove that Hub authorization succeeded.

curl -s http://127.0.0.1:4177/status

Building kryvora-node with the repository Makefile

Source installation requires Go 1.22 or newer, which matches the `go 1.22` declaration in `go.mod`. The Makefile builds `./cmd/kryvora-node` and writes the executable to `bin/kryvora-node`. Its test target delegates to Go's package test command, while its run target starts the daemon with `config.example.yaml`.

A source build is appropriate when the operator needs control over the binary or intends to inspect the repository before deployment. The documented build and first launch are:

git clone https://github.com/kryvora-network/kryvora-node.git
cd kryvora-node
make build
./bin/kryvora-node --config config.yaml --token "your_token_here"

The command expects `config.yaml` to exist and expects the token to be passed on the command line. That token exposure has an operational cost because process arguments may be visible to local users or process-monitoring tools. The README also documents `auth.bootstrap_token` and `KRYVORA_BOOTSTRAP_TOKEN`, but it does not recommend a preferred secret-loading mechanism for production hosts. The Compose configuration mounts its YAML file read-only and passes the token through the environment.

The repository provides `make clean` and `make test`, but the README's Quick Start does not walk through test execution or explain expected output. The Docker build uses Go 1.22 on Alpine, produces a static binary with `CGO_ENABLED=0`, and runs it on `alpine:3.19`. Operators using that image should account for the Alpine runtime rather than assuming a Debian-based host filesystem.

Configuration, exposure, and upgrade boundaries

The default configuration listens on `0.0.0.0:4177`, stores data under `/var/lib/kryvora`, and connects to `https://hub.kryvora.network:4188`. Binding to all interfaces is significant because the daemon exposes health, status, and Prometheus metrics. The requirement for inbound port 4177 conflicts with a conservative default-deny firewall policy, while publishing that port through Docker exposes the same surface on the host. The README does not document authentication or TLS termination for the local endpoint, so administrators should not infer that publication to an untrusted network is safe.

The Compose file persists `/var/lib/kryvora` in a named volume. The systemd installation's exact persistence and ownership configuration are not described in the README. Operators relying on systemd should inspect the registered unit and storage location rather than assume that node state survives package removal or reinstallation.

The latest listed releases are `v0.2.0`, `v0.1.2`, and `v0.1.0-alpha`, all dated 2026-09-22. The last repository push was also on 2026-09-22. This is recent repository activity, but the documentation does not provide release notes, migration procedures, compatibility guarantees, or a rollback process. Upgrading therefore requires checking the release contents and preserving the local state directory independently.

License metadata also requires direct inspection. The repository classification identifies the license as custom and not classifiable by GitHub, while the README displays an Apache License 2.0 badge and says to see `LICENSE` for details. Those statements conflict. The actual `LICENSE` file controls the operator's actual terms, and its text is not reproduced in the available documentation.

Operational limits and a different monitoring approach

The clearest limitation is network coupling. kryvora-node stores peer nonces, task data, and telemetry while coordinating with a hosted Hub, but the README does not provide a Hub deployment guide, offline workflow, local test network, or recovery procedure for Hub outages. An internet outage, certificate problem, expired credential, or rejected token can prevent normal operation even when the host and local daemon remain healthy.

It is also the wrong tool when the requirement is passive infrastructure monitoring without Kryvora enrollment. A generic Prometheus agent would collect metrics according to its own configuration and would not require this project's Genesis Node Key, telemetry probes, peer verification, proof-of-availability workflow, or Kryvora-specific state model. The documented `/metrics` route makes kryvora-node observable, but observability is only one part of what the daemon does.

The choice also changes failure handling. kryvora-node ties operator duties to service health, persistent state, Hub connectivity, token validity, and the availability of port 4177. Operators who cannot keep that service and ingress available should not treat a running process as proof of useful participation. The README does not document retries, token rotation, state migration, version compatibility, or what qualifies a host as having successfully reported availability.

Security reporting is handled directly through `[email protected]` rather than a public issue. That gives vulnerability reporters a defined contact, but it is operational policy rather than evidence about disclosure timing or remediation process. The `SECURITY.md` file should be consulted for details not included in the README.

Editorial conclusion

Adopt kryvora-node if you operate x86_64 or arm64 hardware that meets the stated requirements and already hold a valid Genesis Node Key bootstrap token. Do not choose it as a credential-free public node or as a generic telemetry server, because the Hub rejects unauthenticated nodes and the daemon is purpose-built around Kryvora verification state. Verify the actual terms in the repository's LICENSE file first, since the repository classification calls it a custom license while the README labels it Apache License 2.0. After installation, confirm that the systemd service or container remains healthy and that port 4177 is reachable from the intended probe source before treating the worker as operational.

Frequently asked questions

Official sources

1. Issues
2. kryvora-network/kryvora-node on GitHub
3. README
4. Releases