/dkg-node

name: dkg-node
description: The DKG V10 Node is your primary memory system. This skill teaches you to operate your node's three-layer verifiable memory — write and retrieve private drafts in Working Memory, share with peers in Shared Working Memory, and publish permanently to Verifiable Memory on-chain.

DKG V10 Node Skill

You are connected to an **OriginTrail Decentralized Knowledge Graph (DKG) V10** node. Use the [agent context pack](https://docs.origintrail.io/agent-context/context-pack) for task procedures and completion evidence. For exact operations, use this installed skill and your runtime's discovered tool schemas; the website may describe newer features.

1. Node Info

> This section is dynamically generated from node state at serve-time.

• **Node version:** {{nodeVersion}}
• **Base URL:** {{baseUrl}}
• **Peer ID:** {{peerId}}
• **Node role:** {{nodeRole}}
• **Available extraction pipelines:** {{extractionPipelines}}

If the Node UI injects a target context graph for the turn, use that target directly. If no target is injected or configured, call `dkg_list_context_graphs` / `GET /api/context-graph/list`; agent tool surfaces default that list to the caller's created/joined context graphs, with `scope: "all"` for every graph the node knows about.

Context Graph IDs

For write or mutation routes, always pass the injected target context graph id, an exact existing context graph id from `dkg_list_context_graphs` / `GET /api/context-graph/list`, or the full `did:dkg:context-graph:<id>` URI.

• A context graph created locally can have a bare canonical id, for example

`local-notes`, with full URI `did:dkg:context-graph:local-notes`.

• A joined or curated context graph can have a curator-scoped canonical id, for

example `0x1234567890abcdef1234567890abcdef12345678/team-notes`, with full URI `did:dkg:context-graph:0x1234567890abcdef1234567890abcdef12345678/team-notes`.

Do not guess from the display name, shorten a curator-scoped id, or pass only a suffix slug such as `team-notes` when the listed id is `0x.../team-notes`. Write routes reject unknown, ambiguous, or non-canonical targets before writing so they cannot accidentally create shadow context graphs.

1a. Operating the node (install, update, troubleshoot)

> **Before reasoning about install state, run `dkg doctor`.** Detects orphan repository clones, version skew between the daemon and the global `dkg` CLI, served-UI / source mismatch, broken plugin install roots, and other install-layout anomalies. Use `dkg doctor --json` for a machine-parsable report; the `state` field always carries the full diagnostic snapshot (daemon entry point, install mode, node role, dkg-home, current version + commit, auto-update settings) independent of any anomaly findings.

**Updating DKG:**

• The canonical update verb is `dkg update`. It resolves the next release from the npm registry and applies it.
• **Do not `git pull`.** Do not clone the repository. Do not edit files under `~/.dkg/releases/` (on Core nodes — Edge nodes have no `~/.dkg/releases/` at all under RFC-41).
• If `dkg doctor` reports orphan clones at `~/dkg/`, `~/Projects/dkg/`, or similar, ask the operator before touching them — they are not the running daemon.
• `dkg update --check` previews the available version without applying.
• `dkg update --allow-prerelease` allows published prerelease channels when the network policy permits.
• `dkg rollback` reverts to the previous version (Edge: re-installs the prior npm version recorded in `~/.dkg/previous-version`; Core: flips the blue-green slot symlink).

**Detecting current install state:**

• `dkg --version` — the global CLI's version.
• `curl http://127.0.0.1:9200/api/status | jq '{version, commit, commitShort, buildTime, distTag, installMode, nodeRole}'` — the running daemon's version, commit, and install mode. Mismatch between `dkg --version` and the daemon's version is the §1a version-skew condition; `dkg doctor` reports it explicitly.
• `cat ~/.dkg/config.json | jq .nodeRole` — `edge` (default; daemon runs from npm-global install, no release slots) or `core` (operator opted into blue-green slots via `dkg init --role core`).

**Troubleshooting common confusion:**

• "There seem to be multiple DKG installations on this machine" → run `dkg doctor`; the `state.cli.globalPath`, `state.daemon.entryPoint`, and orphan-repos check together identify the canonical install and any stray clones.
• "The UI shows an old version even after I updated" → run `dkg doctor`; the served-UI / source-mismatch check flags stale browser / PWA / service-worker caches.
• "I ran `npm install -g @origintrail-official/dkg@latest` but the daemon still reports the old version" → on Edge nodes, run `dkg stop` and then `dkg start` so the daemon picks up the new install (`--timeout <ms>` extends the default 120-second API readiness wait; a “still starting” timeout leaves the daemon running—check `dkg status`). On Core nodes, the slot mechanism gates the visible version on `dkg update`'s atomic swap, not on `npm install -g` directly — use `dkg update` for Core nodes.
• "Publishing or context-graph registration intermittently fails with an RPC/503 error" → the node uses **multiple chain RPC endpoints with automatic failover**. Each supported network ships a curated set of public RPCs: `chain.rpcUrl` is the primary and `chain.rpcUrls` is an ordered list of backups. A transient failure (rate-limit/timeout/network) on one endpoint silently fails over to the next; on-chain reverts and other application errors do **not** trigger failover. A `503`/`504` from a publish/register/identity/PCA route means **every** configured endpoint was exhausted — retry, or add a faster/private endpoint. Configure backups via `chain.rpcUrls` in `~/.dkg/config.json` or the **"Backup RPC URLs"** prompt in `dkg init`. Precedence: an operator-set `chain.rpcUrls` **replaces** the network defaults; setting only a private `chain.rpcUrl` keeps the public defaults as failove