metengine

SUSPICIOUS: The core API/payment behavior broadly matches the stated analytics purpose, and dependencies appear to come from normal registries. The main concerns are the unauthenticated self-update pattern that remotely overwrites the skill, required runtime wallet signing access, and version/documentation drift that reduces trust in the skill's integrity.

This module is not obviously malware/stealth code, but it implements a high-impact payment-for-access mechanism that automatically transfers real USDC based on recipient and amount provided by a remote server’s HTTP 402 response. Because there is no client-side allowlisting or bounds/intent validation (and token/memo are ignored), compromise or malicious behavior by the BASE_URL service (or manipulation of the 402 response) could redirect funds to attacker-controlled recipients and arbitrary amounts using the caller-provided private key. The most critical risk is financial exploitation rather than conventional malware behavior.

No clear indicators of embedded malware/backdoor behavior were observed in this fragment (no dynamic execution, command execution, or local credential harvesting). The principal security concern is a high-trust payment workflow: on HTTP 402, the server-provided `recipient` and `amount` directly drive a signed and broadcast USDC transfer using a private key from `SOLANA_PRIVATE_KEY`, and the resulting transaction signature is sent back to the server. This creates a significant supply-chain/trust risk if the payment endpoint or its 402 responses are compromised, or if operational polling amplifies costs. Treat this integration as security-sensitive and add strong safeguards (recipient/amount allowlists, max spend limits, domain pinning/TLS validation, and operator confirmation) before using in production.