Skillv1.0.1

ClawScan security

8004 Skill · ClawHub's context-aware review of the artifact, metadata, and declared behavior.

Scanner verdict

SuspiciousFeb 16, 2026, 3:42 PM

Verdict: suspicious
Confidence: medium
Model: gpt-5-mini
Summary: The skill's code and scripts match its stated blockchain identity/reputation purpose, but the package metadata omits required credentials and file-paths and the runtime instructions ask for sensitive private keys and optional pinning tokens—this mismatch and access to local key files is concerning and deserves caution before use.
Guidance: This skill implements on-chain registration and reputation and legitimately needs a signing key to submit transactions — but the registry metadata incorrectly lists no required credentials while the scripts and SKILL.md require TRON_PRIVATE_KEY/PRIVATE_KEY or a private-key file (~/.clawdbot/wallets/.deployer_pk) and optionally a PINATA_JWT. Before installing or running: 1) Do not use your mainnet production private key — use a throwaway/test key or hardware wallet; 2) Prefer using temporary or testnet keys and funds for initial testing; 3) Inspect utils.js (getPrivateKeyOrExit) to see exactly how keys are read and whether they are stored or logged; 4) Confirm contract addresses independently (e.g., via tronscan / bscscan) before sending transactions; 5) If you need IPFS pinning, create a dedicated pinning token, not one shared with other services; 6) Run npm install and consider doing commands in an isolated environment (container or VM) and run npm audit; 7) If you cannot review the code or do not trust entering a raw private key, do not install — instead interact with contracts via a hardware wallet or a custody service. The main red flag is the metadata omission of required secrets and the hard-coded local key file path — treat this as a configuration/information coherence issue and proceed cautiously.

Review Dimensions

Purpose & Capability: concernName/description (ERC-8004 identity/reputation on TRON+BSC) align with the included JS scripts, ABIs, and contract addresses. However, the skill registry metadata declares no required env vars or credentials while the SKILL.md and scripts clearly require a signing private key (TRON_PRIVATE_KEY or PRIVATE_KEY) or a file at ~/.clawdbot/wallets/.deployer_pk and optionally PINATA_JWT — this mismatch is incoherent.
Instruction Scope: concernSKILL.md and scripts instruct the agent/user to load a private key (env var or file) and run node scripts that will sign and send transactions and may upload metadata to IPFS (Pinata). The runtime instructions therefore access sensitive secrets and a specific home-directory path; the skill also directs interactions with external RPC endpoints (TronGrid, BSC RPC). There are no instructions that read unrelated system files, but the explicit private-key file path and optional PINATA_JWT are outside what the registry metadata declared.
Install Mechanism: noteThis is instruction-only from the registry perspective (no install spec), but the package includes code and a package.json that depends on tronweb and ethers. Users must run npm install themselves. No remote binary downloads or obscure URLs are used; dependencies are standard npm libs. This is moderate-risk (running arbitrary JS) but not anomalous for the stated purpose.
Credentials: concernThe skill requires a wallet private key for signing transactions (TRON_PRIVATE_KEY / PRIVATE_KEY) or a local key file and optionally a PINATA_JWT for IPFS pinning. Those credentials are directly relevant to blockchain registration and thus proportionate to the feature — however they are not declared in the registry metadata (required env vars: none, primary credential: none), creating a dangerous gap: users may grant sensitive keys unintentionally. Requesting a plaintext private key or a file under ~/.clawdbot/wallets increases risk if users reuse production keys.
Persistence & Privilege: okThe skill does not request always:true and does not modify other skills or system-wide settings. It runs as scripts when invoked. There is no evidence it persists beyond its own files or tries to enable itself automatically.