Is brettcleary/coinfello safe?

The send_prompt workflow is fully server-driven: the CoinFello API returns ask_for_delegation clientToolCalls that specify any chainId and delegation scope (including functionCall with arbitrary contract targets and ABI selectors). The CLI autonomously signs and submits these delegations without an additional confirmation step per delegation. A malicious or compromised API can escalate delegation scope to drain user funds or execute arbitrary on-chain calls.

The create_account command generates an Ethereum private key and writes it in plaintext JSON to ~/.clawdbot/skills/coinfello/config.json. Any process with filesystem read access — including other installed skills, background processes, or a compromised npm package — can read this file and take full control of the associated blockchain account and any delegated funds.

All skill commands invoke npx @coinfello/agent-cli without a version specifier. npx resolves the latest published version at runtime. The binary itself was not present in the skill repository and was not scanned during this audit. A malicious update to the npm package would silently execute with full user-level permissions on next invocation, with access to the filesystem, network, and all stored credentials.

User prompts, SIWE authentication messages, and signed blockchain delegations are all transmitted to https://hyp3r-58q8qto10-hyperplay.vercel.app/ (or an operator-configured override). This is a third-party Vercel deployment outside the user's control. A server-side compromise or DNS hijack redirects all sensitive cryptographic material to an attacker.

The REFERENCE.md delegation scope table includes a functionCall type with targets (contract addresses) and selectors (4-byte ABI selectors) fields. The server can request this scope with any target addresses and any function selectors. If signed by the user's smart account, the resulting delegation could authorize the delegate to call any function on any contract on the user's behalf.

sign_in writes the SIWE session token to the same config.json file as the private key. A single file read compromises both the signing key (enabling on-chain actions) and the API session (enabling authenticated server-side actions) simultaneously.

The send_prompt command makes the agent's subsequent actions contingent on responses from the CoinFello API. The API's clientToolCalls field instructs the CLI whether to create delegations, what scope to request, and what chain to use. While this is declared behavior, it creates an indirect prompt-injection surface: a compromised or malicious API response can redirect the agent's blockchain actions without user awareness.

scripts/setup-and-send.sh chains create_account, sign_in, send_prompt, and get_transaction_status in sequence without per-step user confirmation. If an agent executes this script directly (e.g., in response to a social-engineering prompt), it would create a new private key, authenticate, and potentially sign a server-requested delegation in a single automated flow.

A persistent TLS connection to 185.125.188.59:443 (Canonical/Ubuntu infrastructure) was present during the monitoring window. This connection predates the skill install and is attributable to the oathe VM's existing update infrastructure, not the skill. Noted for completeness.

Honeypot files (.env, id_rsa, .aws/credentials, .npmrc, .docker/config.json, gcloud credentials) were opened at timestamps 1771923075 (pre-install canary setup) and 1771923092 (post-install canary integrity check). Timing and process context confirm these accesses originated from the oathe audit system, not from the skill or its install process. All canary files remained unmodified.