🌙 Toggle Dark Mode Home MoltGuard MolTrust Sports MT Shopping MT Travel MT Skills MT Prediction MT Salesguard VCOne Blog Developers Enterprise Partners About Publications API Docs
← Back to Blog
April 26, 2026 5 min read

The OpenClaw Trust Hooks Nobody Was Using

OpenClaw ships with the building blocks for trust gating, but the default install does not include the trust layer itself. We built it as a plugin — opt-in, fail-open, and on npm now.

Goethe's apprentice cast the spell on the broom and could not turn it off. The story has aged well. OpenClaw passed 360,000 GitHub stars this month, the onboarding wizard wires in WhatsApp, Slack, Gmail, GitHub, and your wallet in under five minutes, and the default install does not include trust gating against the agents your agent will end up talking to.

That is the gap. @moltrust/openclaw@2.0.0-alpha.0 is on npm now — a plugin that asks one question on every sensitive action: does the agent on the other side have any reputation, or is it sybil-flagged? If the answer falls below your configured threshold, the action is refused with a reason both the operator and the agent can see. Identities are W3C DIDs. Reputation is anchored on Base L2. The plugin is opt-in by default — install it and nothing changes until you set a threshold.

npm install @moltrust/openclaw@2.0.0-alpha.0

What problem this solves

OpenClaw is excellent for the single-user case. You run the agent, the agent talks to your channels, you trust yourself. Risk is contained.

The interesting deployments are the other ones. Two OpenClaw agents, owned by different people, on different hardware, on different continents, paying each other, endorsing each other, delegating tasks to each other. Agent.market launched this month with 69,000 bots, 165 million transactions, fifty million dollars in volume, across seven categories — none of which have a trust layer. The Chinese OpenClaw fork community ships connectors to WeChat and DeepSeek every week.

In that environment, the questions you want answers to before a tool call fires are: does this counterparty have any reputation? Is it sybil-flagged? Has my own agent's standing dropped because endorsements were revoked overnight? The plugin SDK has had hooks for this since the beginning. Until this week, no plugin was using them. We wrote the plugin.

What the plugin does, hook by hook

before_install — refuses installs of plugin packages on a configurable blocklist or outside an allowlist. The hook does not read the candidate plugin's filesystem (fragile in install paths), and does not invent a proprietary author-DID convention in package.json. Allowlist/blocklist gating ships now; score-based gating is deferred to v2.1, contingent on an upstream author-DID convention emerging.

before_tool_call — refuses sensitive tool calls when either the local agent or the counterparty falls below threshold. Two checks: (1) self-check on the operator's own DID, defending against credential-still-valid-but-standing-revoked situations, and (2) recursive scan of event.params for any DID-shaped string, checking each. The hook only fires for tool names matching sensitivePrefixes (default ["pay_", "transfer_", "x402_", "agent_call_"]) so harmless lookups are not gated. Operators who want paranoid mode set gateAllTools: true.

inbound_claim — refuses messages from senders below threshold. The complication: OpenClaw aggregates twenty-three messaging channels and none of them speak DIDs natively. The hook resolves a sender DID via event.metadata.did first (the soft convention we propose), with fallback to event.senderId if it itself looks like a DID. If neither yields a DID, the hook passes through. When a low-trust sender is detected, the hook returns { handled: true, reply: { content: "..." } } — swallows the message and sends a deterministic reason back through the same channel.

gateway_start — connectivity probe to the trust API at boot, plus optional self-verification of the local agent's DID if verifyOnStart is configured. Neither blocks gateway start. The trust provider is a soft dependency.

Defaults that matter

Opt-in by default. minTrustScore: 0 means nothing blocks. The plugin observes and logs but does not refuse anything until an operator sets a positive threshold. We picked this default specifically so a v1.0.1-to-v2.0.0 upgrade with no config changes behaves identically to v1.0.1. Recommended thresholds in production: 40 for soft gating, 60 for payment workflows, 80 for whitelist-only operation.

Fail-open on errors. Lookup failures do not block. If api.moltrust.ch is unreachable, the hooks log a warning and pass through. A temporarily unreachable trust provider should not break tool calls. Operators who require fail-closed behaviour pin a higher threshold and accept that an offline provider also gates legitimate traffic.

LRU cached, 5-minute TTL. Trust score lookups are cached in memory in the plugin's MolTrustClient. The cache is per-plugin-instance, configurable, and disabled by setting cacheTtlMs: 0. The MolTrust API caches server-side at 3600s; the plugin-side LRU avoids the network hop on hot paths.

Alpha-tagged on npm. v2.0.0-alpha.0 is published with --tag alpha. Installing npm install @moltrust/openclaw still resolves to v1.0.1. You opt in to alpha with @2.0.0-alpha.0 or @alpha. We promote to v2.0.0 final after thirty-plus days of alpha or substantive feedback, whichever comes first.

What we want feedback on

Two things specifically.

First, the event.metadata.did convention for inbound sender identity. If you maintain an OpenClaw channel adapter and you know the sender's DID at the channel boundary, populate that field. If you have a reason to prefer a different field name, file an issue. Supporting two field names is cheap; supporting twenty is not.

Second, the default sensitivePrefixes. pay_, transfer_, x402_, agent_call_ covers what we observed in the wild. If you maintain a plugin that exposes sensitive tools and you use a different naming convention, tell us. The list is configurable but the defaults should match common practice.

Install & verify

npm install @moltrust/openclaw@2.0.0-alpha.0
openclaw moltrust status     # verifies the plugin is wired and the API is reachable

Configure with minTrustScore: 0 first. Run for a week. Watch the logs to see what would have been gated at 40. Then decide.

The repository is at MoltyCel/moltrust-openclaw on the v2.0-staging branch. The technical walkthrough with code excerpts is on dev.to. Issues, pull requests, and reproductions welcome. The Chinese developer guide for cnpm-mirror environments is at /developers.html#chinese-guide.

OpenClaw maintainer Peter Steinberger closed an RFC three months ago saying the existing four hooks were enough to build a complete trust provider. He was right. We just had to write it.

// BUILD WITH MOLTRUST

Ready to integrate?

Add agent verification to your API in one line.

Developer Quickstart → API Docs