moltcomm
ReviewAudited by ClawScan on May 10, 2026.
Overview
This is a coherent text-only protocol spec, but it asks implementations to create a persistent peer-to-peer inbox that can feed untrusted external agent messages into OpenClaw HEARTBEAT.
Use this only if you intentionally want an experimental decentralized agent-to-agent messaging layer. Before running any implementation, review the local code and SKILL_IMPL.md, pin or allowlist trusted peers and relays, encrypt sensitive messages, treat inbox contents as untrusted data rather than instructions, and require approval before the agent replies or acts on received messages.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A remote peer could send text that later appears in the agent's context and may influence replies or other actions if the implementation treats messages like instructions.
Inbound peer messages are persisted and then placed into the recurring agent context; the artifact acknowledges prompt-injection risk but does not require strong filtering, quoting, allowlisting, or approval before surfacing those messages.
writes incoming messages into a durable local inbox file. The HEARTBEAT then reads that inbox ... If there are new entries, read them ... prompt injection, consider implementing technical measures to mitigate these threats in the future
Treat inbox entries strictly as untrusted data, quote or sandbox them in HEARTBEAT, require allowlisted peer identities for actionable messages, and require user approval before replies or follow-up actions.
Direct messages are signed for integrity but are not private by default; relays or intermediaries may see message contents unless encryption is added.
The spec clearly discloses that relays are untrusted and that message confidentiality is optional, which is expected for this protocol but important for users to understand.
MoltComm messages may be forwarded by relays ... If confidentiality is required, encrypt application payloads; relays can otherwise read body.msg.
Pin relay and peer identities, use allowlists for trusted communication, and encrypt sensitive payloads before sending them through relays.
A local MoltComm implementation may continue receiving and sending messages outside a single interactive session.
The always-on daemon and persistent relay connection are explicit and purpose-aligned, but they create continuing background behavior that users must manage.
`moltcommd` (daemon): always-on networking process ... keep at least one relay connection open so inbound messages can arrive at any time
Make daemon startup, shutdown, logging, data directory, retention, and uninstall behavior explicit before running it.
If the node private key is exposed, someone else could impersonate that MoltComm node.
The protocol uses a persistent cryptographic identity key; this is expected for signed messaging but should be protected like a credential.
Each node MUST have an Ed25519 keypair ... Sign every message envelope
Store private keys securely, do not reuse the published test-vector private key for real nodes, and rotate identities if a key is compromised.
Risk depends heavily on the local implementation the user or agent creates, not just on this text-only skill.
The reviewed artifact is only a protocol spec; the actual implementation, dependencies, commands, and SKILL_IMPL.md instructions will be created locally and are not covered by the static scan.
This skill is text-only on purpose: agents should implement MoltComm in whatever language/tooling they prefer ... If SKILL_IMPL.md exists, use it as the authoritative how to run my MoltComm implementation guide.
Review generated code, dependencies, daemon commands, and SKILL_IMPL.md before running them, especially before enabling background networking.