A2A SHIB Payment System
AdvisoryAudited by Static analysis on Apr 30, 2026.
Overview
No suspicious patterns detected.
Findings (0)
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 mistaken, manipulated, or over-autonomous agent command could send crypto or release escrowed funds.
The skill exposes direct financial and escrow-mutating operations as message-text commands. The artifacts mention security features, but they do not clearly show mandatory user approval, transaction previews, allowlists, or hard limits before funds can move.
`send [amount] SHIB to [address]` ... `escrow fund [id]` ... `escrow release [id]`
Require explicit human confirmation for every payment or escrow release, use dry-run previews, set low default amount limits, restrict recipients with allowlists, and log approvals separately from agent-generated commands.
If the agent, local files, or exposed endpoint are misused, funds in the configured wallet may be at risk.
A raw wallet private key grants spending authority over the wallet. This is especially concerning because the registry metadata declares no required environment variables and no primary credential.
`WALLET_PRIVATE_KEY` - Your Polygon wallet private key
Declare the wallet credential in metadata, use a dedicated low-balance hot wallet, avoid main wallets, prefer hardware-wallet or multisig flows for production, and document exactly which operations can use the key.
If the service is reachable by other local or remote agents, they may be able to submit payment-related commands unless authentication is enforced elsewhere.
The integration examples let other agent frameworks forward arbitrary text to the payment endpoint, but the shown calls do not include authentication, caller identity, or authorization boundaries.
description: "Send SHIB payments, create escrows, negotiate prices, check reputation" ... fetch("http://localhost:8003/a2a/jsonrpc", { method: "POST", headers: { "Content-Type": "application/json" }Require API keys or signed A2A messages for all sensitive endpoints, bind to localhost by default, avoid public exposure until hardened, and authorize payment actions per caller identity.
A long-running payment service can remain exposed or keep using wallet credentials if the user forgets it is running.
The deployment guide describes a persistent always-on payment agent and optional public tunnel. This is user-directed and coherent with a payment service, but users should understand the service can keep operating after setup.
Recommended: Cloudflare Tunnel + Systemd ... `Restart=always` ... `Agent auto-starts on boot.`
Only enable auto-start when needed, monitor logs, stop the service when not in use, and do not expose it publicly without hardened authentication and network controls.
Users have less registry-level assurance about where the installable package came from.
The Node/npm install mechanism is expected for this project, but the registry provenance is not clearly declared in the supplied metadata.
Source: unknown; Homepage: none; Install specifications: node | package: .
Verify the repository, package.json, dependency lockfile, and npm install scripts before installing, especially because the skill handles wallet credentials.
Transaction history, reputation data, auth configuration, and wallet material could be exposed through backups or local file access if permissions are weak.
The skill stores persistent payment, escrow, reputation, audit, auth, and wallet-related files. This is expected for the stated system, but it creates retained sensitive state that must be protected.
Critical Files: escrow-state.json, negotiation-state.json, reputation-state.json, auth-config.json ... Audit logs: audit-logs/*.jsonl ... Wallet: .env.local
Use strict file permissions, encrypt backups, exclude wallet files from routine archives unless securely stored, and document retention and deletion procedures.