Bob P2P - Beta
WarnAudited by ClawScan on May 10, 2026.
Overview
The skill is coherent for a crypto API marketplace, but it asks for full Solana wallet authority and can automatically spend tokens through remote marketplace endpoints without clearly bounded controls.
Install only if you understand this is a crypto-wallet client. Use a new wallet with minimal $BOB/SOL, verify the aggregator endpoint, inspect the code and npm dependencies, avoid sending secrets in API requests, and require explicit approval before any paid API call.
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.
Anyone or any process that can read or use that config could spend from the configured wallet, not just call the intended Bob APIs.
The setup flow asks for the user's full wallet secret or mnemonic and writes it into a persistent config file, while the registry metadata declares no primary credential.
echo "Private key (will be visible - mnemonic or key):" read -p "> " PRIVATE_KEY ... "privateKey": "$PRIVATE_KEY"
Use a dedicated low-balance wallet only, never a main wallet mnemonic; the skill should declare this credential, store it with hardened permissions, and preferably support scoped signing or spending limits.
An agent or user action that calls an API can spend $BOB tokens and SOL transaction fees, and blockchain payments are generally irreversible.
The documented API-call path performs a token payment automatically as part of execution, with no clearly documented confirmation prompt, max-spend limit, or allowlist.
The script will: 1. Request a queue position 2. Send $BOB payment automatically 3. Execute the API
Require explicit user confirmation before each payment, show provider wallet and total cost before signing, and add configurable spend limits.
Requests and payment-routing decisions depend on remote marketplace infrastructure whose identity and integrity are not clearly bounded in the artifacts.
The paid call flow trusts a remote aggregator response to supply the provider endpoint and payment wallet; the docs/config examples also show inconsistent aggregator defaults, including HTTP endpoints.
API_INFO=$(curl -s "$AGGREGATOR/api/$API_ID" 2>/dev/null) PROVIDER_WALLET=$(echo "$API_INFO" ...) node src/cli/consumer-execute.js ... --provider-wallet "$PROVIDER_WALLET"
Use only verified HTTPS aggregator endpoints, document which aggregator is authoritative, and verify/sign provider listings before using them for payments.
Installing the skill depends on npm package integrity and the user's trust in the bundled client source.
The setup script installs npm dependencies for the local client; this is expected for a Node-based P2P client but means external package code is trusted during setup.
npm install --silent 2>/dev/null || npm install
Review the source, prefer a lockfile or pinned dependency versions, and declare Node/npm requirements in metadata.
If provider mode is enabled, the machine may expose a service and process jobs beyond a one-off command.
Provider mode is optional and purpose-aligned, but it creates a long-running service that registers with aggregators and handles external requests.
This will: 1. Start the provider server 2. Register APIs with configured aggregators 3. Begin accepting and processing requests
Only enable provider mode intentionally, bind it to a safe interface, use rate limits, and stop it when not needed.