MoltPay Core
SuspiciousAudited by ClawScan on May 10, 2026.
Overview
MoltPay matches a resource-transfer concept, but it uses Moltbook account authority to post transfers and stores a persistent local vault without clear credential declarations, approval limits, or reversibility.
Treat this as a review-before-use skill. Do not use it with a valuable Moltbook account or real balances unless you are comfortable granting account-posting authority, storing a persistent local vault, and having transfer metadata written to Moltbook. If testing, use a separate low-privilege account/token, require manual approval for every link or send action, and ask the maintainer to document credentials, visibility, cleanup, and safety limits.
Findings (6)
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.
Installing or using the skill may give it authority to act through your Moltbook account, even though that credential requirement is not clearly declared.
The skill requires and uses a live Moltbook bearer token for account-authenticated access, while the registry metadata declares no primary credential or required environment variable.
def __init__(self, auth_token): ... requests.get(f"{self.api_base}/agents/me", headers={"Authorization": f"Bearer {self.auth_token}"})Declare the credential requirement explicitly, use least-privilege scoped tokens if available, and require user approval before any account-mutating operation.
A mistaken or autonomous invocation could create transfer records or move protocol resources without a clear human approval step.
The transfer function signs and submits arbitrary recipient/amount transfers as Moltbook posts, but the artifacts do not show confirmation prompts, amount caps, recipient checks, or rollback controls.
def send(self, to_id, amount): ... "op": "transfer", "from": self.agent_id, "to": to_id, "amt": str(amount) ... requests.post(f"{self.api_base}/posts"Require explicit confirmation for each transfer, validate recipients and amounts, add safe defaults such as dry-run mode and limits, and document whether transfers are reversible.
Users may over-trust the protocol or rush to link an account because of security assurances and a limited bootstrap reward that are not fully supported by the artifacts.
The main documentation makes strong security and incentive claims, but the visible code still uses bearer/API keys for account calls and does not show a real ledger enforcing replay rejection or grant allocation.
Your primary access tokens are never exposed... Replay Protection... The first 500 Verified Operators... will receive a 500 Resource Unit grant
Replace marketing-style assurances with precise threat-model documentation, disclose actual credential use, and substantiate or remove the grant and replay-protection claims.
The skill can leave behind persistent identity state that may continue to affect future linking or transfer behavior after the initial task.
The skill creates a persistent local vault containing a generated secret identifier tied to the account, using a hardcoded root workspace path and no visible permission hardening or unlink/cleanup workflow.
self.vault_path = "/root/.openclaw/workspace/projects/moltpay/data/vault.json" ... data = {"secure_id": secure_id, "public_id": public_id, "linked_node_id": self.node_id}Document the vault path and contents, set restrictive file permissions, provide an unlink/delete command, and make persistence opt-in or clearly confirmed.
Your agent ID, recipient ID, amounts, and transfer metadata may be written to Moltbook posts as part of the protocol.
Transfer details are serialized into Moltbook posts for the agent-to-agent layer; this appears purpose-aligned, but the main usage text does not clearly explain the data boundary or visibility of these records.
tx = {"p": "mlt", "op": "transfer", "from": self.agent_id, "to": to_id, "amt": str(amount), ...}; ... "content": json.dumps(tx), "submolt_name": "agents"Clearly disclose where transfer records are stored, who can read them, and how long they persist; minimize metadata if privacy is important.
It is harder to verify who maintains the skill, how it should be installed, and whether the packaged code is the intended runtime.
The artifact has limited provenance and no install specification even though code and a package entrypoint are present; this is a reviewability gap rather than proof of malicious behavior.
Source: unknown; Homepage: none; No install spec — this is an instruction-only skill.
Prefer skills with a clear source repository, documented install process, pinned dependencies, and reproducible release metadata.