# DKG V10 OpenClaw Adapter

`@origintrail-official/dkg-adapter-openclaw` connects a local OpenClaw agent to a DKG V10 node.

The adapter is a thin bridge into the DKG node. It does not run its own DKG node. The DKG daemon owns the node, triple store, P2P networking, `/.well-known/skill.md`, the right-side UI chat surface, and DKG-backed chat and memory persistence.

## What It Does

- bridges the DKG node UI to a local OpenClaw agent
- keeps connected-agent chat persisted in DKG Working Memory via the `chat-turns` assertion of the `agent-context` context graph
- registers the DKG memory provider as OpenClaw's memory-slot capability, so slot-backed recall reads flow through real V10 primitives (assertion-scoped SPARQL queries with `view: 'working-memory'`, `'shared-working-memory'`, and `'verifiable-memory'`) rather than the legacy filesystem-watcher path
- exposes DKG agent-network tools to the OpenClaw runtime
- funds the generated admin wallet plus operational wallets via the testnet faucet on first setup (skippable with `--no-fund`; failures are non-fatal and log manual `curl` instructions)

Memory writes are not exposed as an adapter tool. The agent persists memory through direct daemon routes listed in `packages/cli/skills/dkg-node/SKILL.md` §5: `POST /api/knowledge-assets` (create) on first use of a fresh project CG, then `POST /api/knowledge-assets/:name/wm/write` for each write. To anchor knowledge beyond Working Memory, the agent continues the canonical 5-stage lifecycle — `wm/finalize` (seal) → `swm/share` → `vm/publish` (mint on chain, returns the asset's UAL) — see SKILL.md §5 / §10 for the full flow and response body. The daemon serves the skill document at `GET /.well-known/skill.md`, so the agent sees it on startup and calls the routes directly.

## What It Does Not Do Anymore

- it is not the source of truth for `SKILL.md`
- it does not copy workspace skill files during setup
- it does not try to be the product-level owner of the DKG install and UI experience

## Quick Start

Install the DKG CLI and run setup:

```bash
npm install -g @origintrail-official/dkg
dkg openclaw setup
```

The setup flow is non-interactive and idempotent. It writes `~/.dkg/config.json`, merges the adapter into `~/.openclaw/openclaw.json` (including the adapter's runtime config under `plugins.entries.adapter-openclaw.config`), writes the adapter's workspace scratch state under `<workspace>/.dkg-adapter`, starts the daemon if requested, and verifies the node.

The node UI's right-panel "Connect OpenClaw" button runs this same setup flow in-process — clicking it from a fresh install is equivalent to running `dkg openclaw setup` on the command line (issue #198).

If the OpenClaw gateway does not auto-reload after the config change, run:

```bash
openclaw gateway restart
```

### Flags

| Flag | Default | Purpose |
| --- | --- | --- |
| `--network <name>` | `mainnet-gnosis` (fresh node) | Network to set up on (`mainnet-gnosis` \| `mainnet-base` \| `testnet`), persisted as `config.networkConfig`. Applies to a FRESH node only; an existing node keeps its current network (switch with `dkg init --network`). |
| `--no-fund` | off | Skip the testnet faucet call during setup. Use this if your wallets are already funded, the faucet is unreachable, or you're running offline. |
| `--no-start` | off | Skip starting the DKG daemon (configure only). |
| `--no-verify` | off | Skip the post-setup verification pass. |
| `--dry-run` | off | Preview the setup actions without writing anything. |

Faucet funding only runs on testnet (mainnet networks have no faucet) and is best-effort: a failed call logs a manual `curl` block and setup continues. See the main repo's [Funding](../../README.md#funding) section and [`TESTNET_FAUCET.md`](../../docs/archive/internal/setup/TESTNET_FAUCET.md) for request/response semantics, rate limits, and error codes.

## Verification

A healthy setup should satisfy all of the following:

- `dkg_status` works from the OpenClaw agent
- the DKG node UI loads at `http://127.0.0.1:9200/ui`
- the right-side chat surface can connect to OpenClaw and send a message successfully
- the conversation survives UI reload because the turns are persisted in DKG memory

## Config Files

| File | Owner | Purpose |
| --- | --- | --- |
| `~/.dkg/config.json` | DKG node | node config: networking, chain, auth, API |
| `~/.openclaw/openclaw.json` | OpenClaw | plugin loading config; the adapter's runtime config also lives here under `plugins.entries.adapter-openclaw.config` |
| `<workspace>/.dkg-adapter/` | DKG adapter | workspace-local scratch state such as chat-turn watermarks |

## Adapter Config

These keys live under `plugins.entries.adapter-openclaw.config` in `~/.openclaw/openclaw.json`. `dkg openclaw setup` populates them with first-wins semantics — customizations survive re-runs unless `--port` is passed explicitly (which refreshes `daemonUrl`).

| Key | Default | Purpose |
| --- | --- | --- |
| `daemonUrl` | `http://127.0.0.1:9200` | DKG daemon HTTP URL (env `DKG_DAEMON_URL` overrides at runtime) |
| `stateDir` | `<workspace>/.dkg-adapter` after setup | adapter runtime state directory; setup-owned workspace defaults store chat-turn watermarks at `<workspace>/.dkg-adapter/chat-turn-watermarks.json`; custom `stateDir` values keep the legacy nested layout under `<stateDir>/dkg-adapter/` |
| `memory.enabled` | `true` after setup | register the DKG memory-slot capability on attach (slot-backed recall via `api.registerMemoryCapability`; no adapter-side write tool — writes go through SKILL.md direct routes) |
| `channel.enabled` | `true` after setup | enable the DKG UI to OpenClaw bridge |
| `channel.port` | `9201` (optional) | standalone bridge port when gateway route registration is unavailable; setup does not write this key — set it manually on the entry config if you need to override the default |

Environment override: `OPENCLAW_STATE_DIR` overrides the adapter state root at runtime. Manual state roots are operator-owned; unless they resolve to a known workspace default, watermarks stay nested under `<stateDir>/dkg-adapter/`. `~/.openclaw` remains the OpenClaw runtime home, not the adapter scratch directory.

**Disconnect semantics.** The node UI's "Disconnect" button removes `plugins.entries.adapter-openclaw` entirely from `~/.openclaw/openclaw.json` (including any customized `config` values) AND removes `$WORKSPACE_DIR/skills/dkg-node/SKILL.md` (the canonical DKG node skill installed by setup). Other skills under `skills/` and sibling files under `skills/dkg-node/` are untouched. If you had set a non-default `daemonUrl` (for example via `dkg openclaw setup --port 9300` or a remote daemon URL), re-run `dkg openclaw setup --port <N>` after Reconnect to restore it — Reconnect also re-installs the skill document. Default-port users see no visible difference across a Disconnect/Reconnect cycle aside from the brief absence of the skill file.

Memory flows exclusively through `api.registerMemoryCapability` for slot-backed recall reads (handled by `DkgMemorySearchManager`, which fans out four parallel SPARQL queries — one against `agent-context` / `chat-turns` in working memory plus three against the resolved project CG's `memory` assertion with `view: 'working-memory'`, `'shared-working-memory'`, and `'verifiable-memory'` — and ranks the merged results with a trust-weighted score) and through the daemon routes documented in `packages/cli/skills/dkg-node/SKILL.md` for writes (`POST /api/knowledge-assets` on the first write to a fresh project CG, then `POST /api/knowledge-assets/:name/wm/write` for each write after that).

## Notes

- The DKG node serves the canonical `SKILL.md` at `GET /.well-known/skill.md`.
- Connected-agent chat in DKG V10 belongs in the right-side shell chat surface, not the legacy Agent Hub tab.
- The adapter package includes a lightweight `setup-entry.mjs` so newer OpenClaw setup/runtime flows can load setup-safe surfaces separately from the full runtime.
