XMTP
ReviewAudited by ClawScan on May 10, 2026.
Overview
The skill is mostly purpose-aligned XMTP agent documentation, but it includes an unsafe attachment-saving example and sensitive wallet/payment guidance that should be reviewed before use.
Review this before using it in production. Treat it as documentation, not malware, but fix the attachment save-to-disk pattern, use a dedicated agent wallet, protect .env secrets, add explicit confirmations for payments and group changes, and document any external storage or profile lookup providers used by your agent.
Findings (4)
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.
If a developer copies this pattern, a malicious sender could use a crafted attachment filename to overwrite or create files outside the intended downloads folder where the agent process has permission.
The filename comes from a received remote attachment and is used directly in a local filesystem path without showing basename sanitization, path normalization, overwrite protection, or a check that the resolved path stays under ./downloads.
const attachment = await downloadRemoteAttachment(ctx.message.content, agent); ... fs.writeFileSync(`./downloads/${attachment.filename}`, attachment.data);Generate safe local filenames or sanitize with path.basename, validate size and MIME type, resolve and verify the final path is inside the downloads directory, avoid overwriting existing files, and require user/admin approval before saving untrusted attachments.
An agent built from these examples could prompt wallet transfers too easily if command parsing, recipient resolution, or amount handling is permissive.
The skill provides patterns for generating and sending USDC wallet-call requests. This is disclosed and aligned with the transaction feature, but it is financial-action guidance and the snippet does not show an explicit confirmation, limit, or allowlist step.
const walletSendCalls = createUSDCTransferCalls(...); ... await ctx.conversation.sendWalletSendCalls(walletSendCalls);
Before sending wallet calls, require explicit confirmation showing network, token, recipient, and amount; set amount limits; prefer testnets during development; and add allowlists or policy checks for production agents.
Using a main wallet key or exposing the .env file could let compromised project code impersonate the agent identity or affect wallet-linked operations.
The built agent is expected to operate with a wallet private key and local database encryption secret. No leakage is shown, but these are sensitive credentials and the registry metadata lists no primary credential or required env vars.
`XMTP_WALLET_KEY` | Private key for wallet | `0x1234...abcd` ... `XMTP_DB_ENCRYPTION_KEY` | Database encryption key
Use a dedicated low-value wallet for the agent, store secrets in a secret manager or protected .env file, avoid pasting keys into chats or logs, and declare required credentials clearly in project documentation.
Even when file contents are encrypted, filenames, object URLs, storage metadata, and encrypted blobs may persist with an external provider.
The attachment examples upload encrypted blobs to public third-party storage providers. This is disclosed and purpose-aligned, but retention, URL exposure, metadata, and deletion behavior depend on the provider configuration.
const upload = await pinata.upload.public.file(encryptedFile); ... return `https://${process.env.S3_BUCKET}.s3.amazonaws.com/${key}`;Avoid sensitive filenames, use private buckets or signed URLs when appropriate, configure retention/deletion policies, and tell users when attachments are stored through external providers.