Node of COC testnet

Operate COC (ChainOfClaw) blockchain nodes — install, start, stop, monitor, and remove validator, fullnode, archive, gateway, and dev nodes. Use when the use...

Security Scan

The skill's declared purpose (manage COC nodes) matches most of its behavior, but metadata and instructions are inconsistent about which environment variables are required and the skill will execute code from a local COC repo you provide — review provenance and env usage before installing.

Purpose & Capability

Name/description align with required binaries (node, coc-node/openclaw) and the npm package install. Managing a COC node legitimately needs Node.js and the coc-node CLI. Minor oddity: the metadata lists CLAW_MEM_DATA_DIR as the primaryEnv (a path variable, not a secret credential), which is unusual but explainable because the skill shares a data-root convention with other @chainofclaw plugins.

Instruction Scope

SKILL.md instructs the agent to spawn code from a local COC source repo (node/src/index.ts) to start nodes — this means the skill executes arbitrary code from whatever clone is pointed to by COC_REPO_PATH. The docs also reference several environment variables ($COC_REPO_PATH, $COC_NODE_DATA_DIR, $CLAW_MEM_DATA_DIR, $OPENCLAW_STATE_DIR, $COC_NODE_CONFIG) that are not listed in the skill's declared required envs. While most referenced operations (editing node-config.json, probing whitelisted RPC methods, reserving disk space via fallocate) are coherent with node management, the combination of executing repo code and undeclared env usage is a scope concern.

Install Mechanism

Install uses an npm package (@chainofclaw/node) from the public registry which will create the coc-node binary — an expected and traceable mechanism. npm installs are moderate risk compared to reviewed system packages, so verify the package source and its install scripts before installing.

Credentials

Metadata reports no required env vars but the runtime docs rely on several environment variables (COC_REPO_PATH, COC_NODE_DATA_DIR, CLAW_MEM_DATA_DIR, OPENCLAW_STATE_DIR, COC_NODE_CONFIG). The declared primaryEnv is CLAW_MEM_DATA_DIR (a filesystem path) which is not a secret credential — this is an inconsistent use of the platform's 'primary credential' field. The skill does not request sensitive tokens, but the mismatch between declared and referenced env vars is misleading and should be clarified.

Persistence & Privilege

always:false and user-invocable:true — the skill does not request forced persistent activation. There is no indication it modifies other skills or global agent configuration. It can, however, create and delete on-disk node data (default behavior deletes data on node remove unless --keep-data is used) and may reserve disk space; those are expected capabilities for this purpose.

What to consider before installing

This skill appears to do what it claims (manage COC nodes), but take these precautions before installing: - Verify the npm package provenance: inspect the @chainofclaw/node package source (repo, package.json, install scripts) on npm/GitHub to ensure no unexpected install-time scripts run. - Understand that starting a node runs code from the COC repository on your machine (node/src/index.ts). Only point COC_REPO_PATH at a trusted clone — the skill will execute that code with your Node runtime. - The SKILL.md references several environment variables (COC_REPO_PATH, COC_NODE_DATA_DIR, CLAW_MEM_DATA_DIR, OPENCLAW_STATE_DIR, and COC_NODE_CONFIG) but metadata lists no required envs; decide and document which envs you will set and why. - Be mindful of disk and network effects: the skill will reserve storage (fallocate), may delete node data on remove by default, and can bind RPC ports — ensure you have adequate disk space and firewall rules to avoid unintentionally exposing RPC endpoints. - If you need stronger isolation, run the plugin in a sandboxed environment or a dedicated host, and back up any data directories before using node-install/start or removal commands. If you want, I can: (a) fetch and summarize the @chainofclaw/node package source (package.json, install scripts) so you can inspect it, or (b) list the exact env vars referenced in SKILL.md and where they affect behavior.

coc-node — COC blockchain node lifecycle

Operate a COC node on this machine. The skill is backed by the npm package @chainofclaw/node which ships both a standalone coc-node CLI and an OpenClaw plugin (skill id coc-node).

What this skill can do

• Install a new COC node of any type: validator, fullnode, archive, gateway, or dev
• Start / stop / restart nodes; follow logs across the node / agent / relayer streams
• Report status — block height, peer count, BFT activity, process PID, per-service health
• Edit a node's node-config.json in $EDITOR
• Probe any COC RPC endpoint safely (whitelisted methods only: eth_blockNumber, eth_getBlockByNumber, net_peerCount, coc_chainStats, coc_getBftStatus, eth_syncing, eth_chainId, …)

Zero-config on install (1.2.0+)

Everything you can do without a COC source repo works immediately after openclaw plugins install — no further setup. The activation banner makes it explicit:

[coc-node] data dir: /home/<you>/.claw-mem/coc-node
[coc-node] storage quota: advertised=256 MiB, reserved=256 MiB, enforce=true
[coc-node] tracked nodes: 0
[coc-node] coc repo: detected at /home/<you>/COC — install/start commands enabled
[coc-node] Loaded — no nodes yet, run `openclaw coc-node node install <name>` to add one
[coc-node] CLI is mounted at `openclaw coc-node ...`. ...

Or, if no COC repo is on this machine:

[coc-node] coc repo: not detected — read-only mode (list / status / coc-rpc-query work; install / start need bootstrap.cocRepoPath or $COC_REPO_PATH pointing at a COC source clone)

That second line is the only thing you need to read to know whether node install / node start will work. Everything else (list, status, log inspection, RPC probes against an already-running node) is unconditionally available.

Data directory

Auto-resolves to a writable path along a chain that's intentionally aligned with @chainofclaw/claw-mem and @chainofclaw/soul so the three plugins share one operator-managed root. Priority (highest first):

1. config.dataDir (per-instance plugin config)
2. $COC_NODE_DATA_DIR (coc-node-specific operator override)
3. $CLAW_MEM_DATA_DIR/coc-node (shared with claw-mem + soul — set this once and all three move together)
4. $OPENCLAW_STATE_DIR/coc-node (sandbox-managed state dir)
5. ~/.claw-mem/coc-node (default — shared root with claw-mem + soul)
6. ~/.chainofclaw (legacy pre-1.2.0 fallback; only picked when nodes.json already exists there)

Fails fast at activation with an actionable EACCES error naming each tried path, rather than silently breaking mid-command. /tmp is intentionally not a fallback.

What needs setup to start a node yourself

Actually starting a node process requires the COC source repository (it spawns node/src/index.ts from there). Tell the skill where the repo is via one of:

• COC_REPO_PATH environment variable (simplest)
• bootstrap.cocRepoPath in plugin config
• Run inside (or anywhere under) the COC repo — auto-discovered via marker files
• Place a clone at ~/COC — also auto-discovered

Plus ≥ 256 MiB free disk for the P2P storage reservation (mandatory COC network entry requirement).

The activation banner tells you whether the auto-detection succeeded. If COC_REPO_PATH is unset and no clone is at ~/COC, node install and node start fail with a clear error pointing here — list / status / log / RPC commands keep working.

Relationship with claw-mem and coc-soul

The three @chainofclaw/* skills are fully decoupled at the npm-dependency level. Each can be installed independently. They cooperate through shared on-disk conventions, not through code coupling:

Skill	Owns	What it adds when paired
coc-node	Local node lifecycle (install / start / stop / status / RPC probe)	Independent of the other two.
claw-mem2db	Persistent agent memory (chat + tool capture, FTS5 search, hybrid recall)	Pure agent-side; doesn't touch the chain. coc-node doesn't read or write to its DB.
coc-soul	On-chain DID, IPFS backup, guardian recovery, carrier resurrection	Reads claw-mem's SQLite DB (when present) for semantic snapshots. Also independent of coc-node.

Shared dataDir convention. All three default to writing under ~/.claw-mem (or under $CLAW_MEM_DATA_DIR / $OPENCLAW_STATE_DIR), each in a scoped subdirectory:

• claw-mem → ~/.claw-mem/{claw-mem.db, config.json, ...}
• coc-soul → ~/.claw-mem/keys/agent.key
• coc-node → ~/.claw-mem/coc-node/{nodes.json, <node>/...}

So one CLAW_MEM_DATA_DIR=/somewhere/writable env var moves all three. Operators in sandboxed Docker hosts (where ~/.claw-mem is read-only) only have one knob to turn.

How to invoke

Inside OpenClaw (recommended — works automatically after plugins install):

openclaw coc-node node install --type fullnode --network testnet
openclaw coc-node node list
openclaw coc-node node status
openclaw coc-node node logs <name> --follow --all

Standalone bin (only if you ran npm i -g @chainofclaw/node separately):

coc-node node install --type dev --network local --name dev-1 --rpc-port 28780
coc-node node list

openclaw plugins install does NOT install the standalone coc-node binary into your PATH. Use openclaw coc-node ... (with the openclaw prefix), or install the bin globally via npm if you want the bare command.

Typical flows

1. Spin up a dev node against local hardhat — coc-node node install --type dev --network local then coc-node node start dev-1.
2. Join testnet as a fullnode — coc-node node install --type fullnode --network testnet --rpc-port 28780 then coc-node node start.
3. Stand up a validator — coc-node node install --type validator --network testnet --advertised-bytes 1073741824 (1 GiB storage contribution).
4. Diagnose a flaky node — coc-node node status (snapshot) → coc-node node logs --follow (tail) → coc-node node config show (inspect config) → coc-node node restart if needed.
5. Decommission a node — coc-node node stop NAME then coc-node node remove NAME --yes (delete data) or coc-node node remove NAME --yes --keep-data.

When NOT to use this skill

• Deploying COC smart contracts — that's a contracts/ hardhat / script task, not node lifecycle.
• On-chain identity / backup / recovery — use the coc-soul skill.
• Agent memory / session capture — use the claw-mem2db skill.

Reference

Detailed references live alongside this file:

• references/cli.md — every coc-node subcommand with flags and examples
• references/config.md — complete ~/.claw-mem/coc-node/config.json schema
• references/node-types.md — validator vs fullnode vs archive vs gateway vs dev tradeoffs
• references/troubleshooting.md — common failure modes and fixes

Source and issue tracker: https://github.com/NGPlateform/claw-mem/tree/main/packages/node.