Trust Assessment
ercdata received a trust score of 82/100, placing it in the Mostly Trusted category. This skill has passed most security checks with only minor considerations noted.
SkillShield's automated analysis identified 2 findings: 0 critical, 1 high, 1 medium, and 0 low severity. Key findings include Private key exposed via command-line argument, Sensitive data visible in blockchain calldata for 'private' entries.
The analysis covered 4 layers: Manifest Analysis, Static Code Analysis, Dependency Graph, LLM Behavioral Safety. All layers scored 70 or above, reflecting consistent security practices.
Last analyzed on February 13, 2026 (commit 13146e6a). SkillShield performs automated 4-layer security analysis on AI skills and MCP servers.
Layer Breakdown
Behavioral Risk Signals
Security Findings2
| Severity | Finding | Layer | Location | |
|---|---|---|---|---|
| HIGH | Private key exposed via command-line argument The `ercdata-cli.py` script allows the Ethereum private key (`ERCDATA_KEY`) to be passed directly as a command-line argument (`--key`). This practice is insecure as command-line arguments can be exposed in process lists (`ps aux`), shell history, or logs, making the private key vulnerable to credential harvesting. While environment variables are used as a default, the explicit command-line override creates a significant risk. Remove the `--key` command-line argument option from all commands. Enforce the exclusive use of environment variables (e.g., `ERCDATA_KEY`) for providing the private key. If dynamic key provision is necessary, consider more secure input methods or temporary file-based approaches with strict permissions, rather than command-line arguments. | LLM | scripts/ercdata-cli.py:50 | |
| MEDIUM | Sensitive data visible in blockchain calldata for 'private' entries The skill facilitates storing data on the Ethereum blockchain, offering a 'private' option. However, the `SKILL.md` documentation explicitly states: 'raw transaction calldata is still visible on-chain explorers. For maximum privacy, encrypt data before storing.' This means that even data marked as 'private' is not truly private at the transaction level. Any sensitive information passed to the `store` command without prior client-side encryption could be exfiltrated to the public blockchain, despite the 'private' flag gating `getData()` access. Strongly advise users and agents to encrypt all sensitive data client-side before passing it to the `store` command, even when using the `--private` flag. Consider making the `store-encrypted` command the primary or only option for private data, or add a prominent warning in the CLI output for `store --private` if the data is not detected as encrypted. | LLM | SKILL.md:60 |
Scan History
Embed Code
[](https://skillshield.io/report/9fb0dac17cd2042c)
Powered by SkillShield