Is aetherstacey/erc8004-register safe?

get_wallet() reads ERC8004_MNEMONIC or ERC8004_PRIVATE_KEY from the environment and returns a fully-capable eth_account Account object. This account is then used to sign ANY transaction submitted via send_transaction(). The skill's own commands are limited to the ERC-8004 registry, but nothing enforces that at the code level — a manipulated invocation with a different contract address would execute with the same signed authority.

The self-check command sends the wallet address derived from the user's mnemonic/private key to https://agentscan.info/api/agents without any disclosure, consent mechanism, or documentation of this data flow. This leaks wallet identity to a third party and could be used to correlate on-chain activity.

The register command alone submits two on-chain transactions. update and fix each submit one. All are broadcast to mainnet chains (Base, Ethereum, Polygon, Monad, BNB). An agent confused about user intent, or one tricked into calling register repeatedly via prompt manipulation, could rack up significant gas costs and create unwanted on-chain registrations that cannot be undone.

decode_data_uri() is called on every tokenURI returned from the blockchain. When the URI begins with http:// or https://, the function fetches it with a 10-second timeout. Since tokenURIs are set by token owners and can point to any URL, an attacker who owns an on-chain agent can craft a URI pointing to an internal network address, a credential-harvesting endpoint, or a timing oracle — causing the agent host to make out-of-band requests when any info, validate, fix, or self-check command is run.

SKILL.md's Cross-Skill Workflows section instructs agents to run scripts from erc8004-reputation (reputation.py) and erc8004-discover (discover.py) as natural follow-on steps after registration. These scripts are not present in this skill directory and have not been audited. A malicious companion skill installed alongside this one would share the same process environment, inheriting wallet credentials.

The skill requires pip install web3 eth-account prior to use. web3.py has a large transitive dependency tree. A malicious release of any dependency could harvest the wallet credentials or private keys passed through these libraries during transaction signing.

The Heartbeat Integration section provides a ready-to-paste crontab entry that runs self-check every hour. If an agent were manipulated into implementing this as written, it would establish hourly execution of the skill's Python binary — a persistence mechanism that survives session termination.

The audit infrastructure cloned github.com/openclaw/skills.git with --depth 1 --no-checkout, then used sparse-checkout to extract only the skill subdirectory. The only external network connection during install was to 140.82.121.3:443 (GitHub). No unexpected processes were spawned, no files were written outside /home/oc-exec/skill-under-test/, and no background listeners were left running.

inotify and auditd showed access to .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and GCP credentials at timestamps 1771940415 (pre-clone) and 1771940433 (post-install). The git clone begins at 1771940421 and skill files are copied at 1771940428 — confirming these accesses belong to the Oathe audit framework's own canary setup and integrity-check routines. No skill code references these file paths. Canary integrity check confirms all files unmodified.