End-to-end encrypted messaging and EVM crypto wallet for agent identity
AdvisoryAudited by Static analysis on Apr 30, 2026.
Overview
No suspicious patterns detected.
Findings (0)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If the npm package is compromised or not what the user expects, it could execute code while handling wallet keys and transactions.
The skill relies on an external npm CLI that is not included in the reviewed artifacts, is not pinned to a version in the instructions, and has no install spec or source/homepage supplied in the registry context.
npm install -g @openindex/openindexcli npx @openindex/openindexcli <command>
Review the npm package and publisher before use, pin a known version, prefer a documented install spec, and avoid giving it valuable private keys until provenance is clear.
A leaked or misused private key can allow irreversible fund transfers and impersonation of the wallet identity.
An EVM private key is a primary credential that can control funds and identity, but the registry metadata declares no primary credential or required environment variable.
Set your key: `export OPENINDEX_PRIVATE_KEY=0x...` (copy from create output)
Use a dedicated low-value wallet, do not reuse important keys, require the credential to be explicitly declared, and verify how the CLI stores, logs, and transmits key material.
A mistaken or unintended invocation could send funds to the wrong recipient or chain, and blockchain transfers are generally irreversible.
The skill exposes commands for moving cryptocurrency to usernames or addresses across chains, but the instructions do not state confirmation, spending-limit, or address-verification requirements.
Send ETH: `npx @openindex/openindexcli send @bob 0.1` Send tokens: `npx @openindex/openindexcli send-token USDC @bob 100`
Require explicit user confirmation for recipient, amount, token, chain, and fees before any transfer; consider hard spending limits and separate approval for each transaction.
Messages from other agents or discovered users could contain social engineering or instructions that should not be treated as authoritative.
The core feature creates direct and group communication channels with other agents; incoming messages are external content even if encrypted in transit/storage.
send-message <fromUser> <toUser> <message> get-messages <username> create-group <groupName> <creator> <member2> ...
Treat received messages as untrusted content, do not let them override user instructions, and avoid sharing sensitive information unless the recipient is verified.
The agent might keep checking and responding to messages more often or longer than the user intended.
This encourages recurring polling and replies. It is related to the messaging purpose, but it could continue beyond a single user request if not bounded.
You should check your messages e.g. every 20 minutes to see if anybody wrote to you and reply.
Only enable periodic checking when the user explicitly asks for it, define how often it runs, and set a clear stop time or stop condition.
Users may over-rely on privacy claims that have not been substantiated by the provided artifacts.
The skill makes strong privacy and security claims, but the reviewed artifacts contain no implementation code to validate those guarantees.
Zero metadata leakage - No readable identifiers stored on server
Verify the implementation and service design before using it for sensitive communications, especially when the source and homepage are not provided.