Quickstart
Give your AI agent a persistent and structured memory on the DKG in under 10 minutes
By connecting your AI agent to the DKG Node, you give it three layers of persistent and structured memory on the DKG:
Working Memory — Private, local, free. Your agent's scratchpad. Write drafts, ingest documents, stage knowledge before sharing it. Nothing leaves your node. No cost, no coordination overhead. This is where all knowledge starts.
Shared Working Memory — Collaborative, gossip-replicated, no charge. Selectively share knowledge with specific peers (other agents) without publishing to a blockchain. Multiple agents can read from and write to the same Context Graph. This is where collective intelligence happens before anything needs to be verified.
Verifiable Memory — Blockchain-anchored, cryptographically provable. Promote knowledge that needs to last and be trusted. Once anchored on-chain, it's immutable, queryable by anyone, and carries a provenance trace from the agent that published it. Trust level is explicit: self-attested, endorsed, partially-verified, or consensus-verified. This is where knowledge graduates from "our working context" to "ground truth."
To better understand how DKG works, explore here.
Prerequisites
Node.js 22+, npm 10+. macOS, Linux, and Windows (PowerShell 5.1+ or WSL2) all supported.
Hermes
Install the DKG CLI and set up the default Hermes profile:
npm install -g @origintrail-official/dkg
dkg hermes setupEnable Hermes' API server and start the gateway:
echo 'API_SERVER_ENABLED=true' >> ~/.hermes/.env
hermes gateway run --replace -vdkg hermes setup bootstraps the DKG node config (no separate dkg init needed), starts the daemon, optionally funds wallets, and wires the Hermes profile with replace-by-default provider election (use --preserve-provider to opt out, --no-start / --no-fund for advanced flows).
By default this sets up the node on Gnosis mainnet (mainnet-gnosis). On a fresh node, pass --network mainnet-base or --network testnet to choose a different network (an already-configured node keeps its current network — switch it with dkg init --network). Wallet funding via the faucet only happens on testnet; on mainnet you fund the node's wallets yourself.
See the adapter guide for details.
OpenClaw
Restart the OpenClaw gateway if it does not auto-reload:
dkg openclaw setup is non-interactive and idempotent. It writes ~/.dkg/config.json, merges the adapter into ~/.openclaw/openclaw.json (under plugins.entries.adapter-openclaw.config — daemonUrl, memory.enabled, channel.enabled), syncs the canonical DKG node skill into the OpenClaw workspace at skills/dkg-node/SKILL.md, and verifies the install. The right-panel "Connect OpenClaw" button in the node UI runs the same in-process flow.
Use --no-start, --no-fund, and --no-verify only when the user or environment requires it.
By default this sets up the node on Gnosis mainnet (mainnet-gnosis). On a fresh node, pass --network mainnet-base or --network testnet to choose a different network (an already-configured node keeps its current network — switch it with dkg init --network). Wallet funding via the faucet only happens on testnet; on mainnet you fund the node's wallets yourself.
MCP
Two commands wire DKG V10 into MCP-aware clients (Cursor, Claude Code, Claude Desktop, Windsurf, VSCode + GitHub Copilot Chat, Cline, Codex CLI):
Restart the client and inspect DKG tools.
dkg mcp setup bootstraps the DKG node config (no separate dkg init needed), starts the daemon, optionally funds wallets, and registers MCP entries in each detected client (you confirm per client unless --yes is passed).
By default this sets up the node on Gnosis mainnet (mainnet-gnosis). On a fresh node, pass --network mainnet-base or --network testnet to choose a different network (an already-configured node keeps its current network — switch it with dkg init --network). Wallet funding via the faucet only happens on testnet; on mainnet you fund the node's wallets yourself.
See the MCP integration guide for client-by-client paths, mode overrides (--installed / --monorepo), the manual JSON shape, the contributor monorepo dev workflow, and troubleshooting (including the WSL2 caveat for Windows-side MCP clients).
Standalone node
Skip the framework wiring — run the daemon directly and use the CLI or HTTP API:
dkg init asks which network to join — Gnosis mainnet (mainnet-gnosis, the default), mainnet-base, or testnet — at the prompt, or pass --network <name> to skip it. Wallet funding via the faucet only happens on testnet; on mainnet you fund the node's wallets yourself.
For Core Node operation, initialize with the Core role:
Core Nodes are registered on-chain with a node profile (identityId). The daemon attempts this automatically on Core startup, but the primary operational wallet needs gas plus TRAC and the admin wallet must be present for profile/key-management transactions. If you fund or fix wallets after the daemon is already running, call POST /api/identity/ensure as described in Daemon Lifecycle.
Once running, open the dashboard at http://127.0.0.1:9200/ui, or query directly:
Last updated
Was this helpful?