Agent-Wallet
v1.2.4Single-source wallet skill for generate, import, get-balance, sign, and send flows using local wallet files plus executable Node scripts. Use when the user a...
Security Scan
Capability signals
These labels describe what authority the skill may exercise. They are separate from suspicious or malicious moderation verdicts.
OpenClaw
Suspicious
medium confidencePurpose & Capability
Name/description (local wallet: generate/import/balance/sign/send) match the scripts and file-based workflows. WALLET_SECRET_KEY is logically required for encrypting/decrypting local signer material.
Instruction Scope
SKILL.md is explicit about actions, file paths (wallet/signer.json, wallet/config.json), confirmation gates (overwrite, mainnet double confirmation), and avoids printing raw secrets. The runtime instructions limit activity to wallet generation, signing, balance checks, and sending via configured RPCs.
Install Mechanism
No install spec is provided even though SKILL.md declares a runtime dependency on Node >=18 and the 'viem' package. The bundle includes Node scripts but provides no guidance to ensure 'viem' is installed — this is an operational gap (not necessarily malicious) that can cause failures or unexpected behavior if the runtime differs from the developer's environment.
Credentials
The scripts legitimately require WALLET_SECRET_KEY (used by secret-crypto.js to derive the AES key). However, the registry metadata supplied earlier lists 'Required env vars: none' while the SKILL.md frontmatter and code require WALLET_SECRET_KEY — an inconsistency that should be resolved before trusting the skill.
Persistence & Privilege
The skill does not request elevated privileges or permanent always: true presence. It reads/writes only its own wallet files under 'wallet/'. It does rely on the agent being able to run the included Node scripts (normal for a code-backed skill).
What to consider before installing
This skill appears to be a legitimate local wallet tool, but there are a few things to check before installing or using it:
- Confirm the WALLET_SECRET_KEY requirement: SKILL.md and the code require WALLET_SECRET_KEY (used to encrypt/decrypt wallet material). The registry metadata showing no required env var is contradictory — ask the publisher to fix the metadata or document why it's missing.
- Ensure your environment has Node 18+ and the 'viem' dependency installed; the skill provides scripts but no install instructions for dependencies. Run in an isolated environment if you can.
- Protect WALLET_SECRET_KEY: treat it as a high-value secret (store in a secure vault/OS keychain) because possession allows decrypting local signer files and signing/sending transactions.
- Review wallet/config.json RPC URLs before use. RPC endpoints are necessary but can be malicious or log requests — use trusted RPCs and test on a non‑mainnet chain first.
- Backup wallet/signer.json and test generate/import/get-balance flows on testnets before broadcasting any mainnet transaction. The skill enforces confirmations, but human verification is still recommended.
If the author can correct the registry metadata and add installation guidance for dependencies, that will remove the main inconsistencies flagged here.Like a lobster shell, security has layers — review code before you run it.
latest
Agent Wallet Skill
Changelog: CHANGELOG.md
Purpose
Use this file as the only wallet skill entrypoint for local wallet workflows.
Runtime Requirements
- Runtime: Node.js 18+
- Required package:
viem - Required secret key:
WALLET_SECRET_KEY(used for local secret encryption/decryption) - Wallet signer file:
wallet/signer.json - Network config file:
wallet/config.json
Executable Scripts
Run these scripts from agent-wallet-skills for each action:
generate-wallet:node scripts/generate-wallet.js --method=<private-key|seed-phrase> [--overwrite=true]import-wallet:node scripts/import-wallet.js --seedPhrase="<words>" [--overwrite=true]or--privateKey=0x...get-balance:node scripts/get-balance.js --address=0x... [--tokenAddress=0x...] [--decimals=18] [--symbol=TOKEN]sign-messages:node scripts/sign-messages.js --message="hello from wallet"send(native):node scripts/send.js --to=0x... --amount=<native-amount> --confirm=true [--confirmMainnet=true]send(token):node scripts/send.js --to=0x... --amount=<token-amount> --tokenAddress=0x... [--decimals=18] [--symbol=TOKEN] --confirm=true [--confirmMainnet=true]
Notes:
- Wallet material is stored in
wallet/signer.jsonas encrypted fields only. - Default network is loaded from
wallet/config.jsonwith shape[{ rpc_url, chain_id, current }]. send.jsrequires explicit--confirm=true.- Mainnet broadcasts require an additional
--confirmMainnet=true.
Routing Logic
- Identify user intent:
- create/recover/import wallet ->
generate-walletorimport-wallet - check native/token balance ->
get-balance - sign arbitrary payload/message ->
sign-messages - transfer/broadcast transaction ->
send
- create/recover/import wallet ->
- Precheck
wallet/config.jsonfor read/write chain operations (get-balance,send, and any network-aware generation flow):- require array format
[{ rpc_url, chain_id, current }] - require exactly one entry with
current: true - require non-empty
rpc_urlandchain_idon the current entry - if invalid, stop and ask user to set defaults first
- require array format
- Execute the script mapped to the action:
generate-wallet->node scripts/generate-wallet.js --method=<private-key|seed-phrase>import-wallet->node scripts/import-wallet.js --seedPhrase="<words>"or--privateKey=0x...get-balance->node scripts/get-balance.js --address=0x... [--tokenAddress=0x...]sign-messages->node scripts/sign-messages.js --message="hello from wallet"send(native) ->node scripts/send.js --to=0x... --amount=<native-amount> --confirm=true [--confirmMainnet=true]send(token) ->node scripts/send.js --to=0x... --amount=<token-amount> --tokenAddress=0x... [--decimals=18] [--symbol=TOKEN] --confirm=true [--confirmMainnet=true]
- If
wallet/signer.jsonalready exists and user asks to regenerate/import over it, require explicit confirmation first. - If intent is unclear, ask one focused question:
- "Do you want to generate/import a wallet, check balance, or send a transaction?"
- If a script fails, return the error with corrected input guidance.
Generate / Import Workflow
Inputs:
- Seed phrase (12/24 words), or private key (
0xprefixed or raw hex), or generation request - Optional
--overwrite=truewhen replacing existingwallet/signer.json
Rules:
- Default generation method is
private-keyunless user requests mnemonic. - Do not overwrite existing signer file unless user requested it and confirmed.
- Validate private key as 64 hex chars (after optional
0xremoval). - Validate seed phrase word count and normalize whitespace.
- Derive address before persisting.
- Encrypt signer secrets before writing to disk.
- Never print full seed phrase/private key in normal responses.
Expected wallet/signer.json structure:
{
"method": "seed_phrase",
"address": "0x...",
"encryptedSeedPhrase": "<encrypted-secret>",
"encryptedPrivateKey": null,
"createdAt": "2026-04-13T00:00:00.000Z",
"updatedAt": "2026-04-13T00:00:00.000Z"
}
Balance Workflow
Inputs:
--address(required)--tokenAddress(optional for ERC-20 mode)- optional
--decimalsand--symbol
Rules:
- Always validate
addressandtokenAddress(when provided). - Always require a valid current network in
wallet/config.json. - Native mode: query
getBalanceand return raw + formatted values. - Token mode: query
balanceOf; readdecimals/symbolwhen possible, otherwise fall back to defaults.
Send Workflow
Inputs:
--torecipient (required)--amountamount to transfer (required)--tokenAddress(optional for ERC-20 mode)- optional
--decimalsand--symbol(token mode only) --confirm=true(required to broadcast)--confirmMainnet=true(required on mainnet chain IDs)
Rules:
- Load signer from
wallet/signer.json(seed_phraseorprivate_key). - Decrypt signer material with
WALLET_SECRET_KEYbefore deriving account. - Require valid current network in
wallet/config.json. - Validate recipient address,
tokenAddress(when provided), and positive amount. - Native mode: precheck native balance and send via value transfer.
- Token mode: resolve token decimals/symbol, precheck
balanceOf, then call ERC-20transfer. - Require explicit broadcast confirmation; require double confirmation for mainnet (
--confirmMainnet=true). - Return tx hash on success, and include transfer mode (
nativeortoken).
Sign Workflow
Inputs:
--message(required)
Rules:
- Load signer from
wallet/signer.json(seed_phraseorprivate_key). - Decrypt signer material with
WALLET_SECRET_KEYbefore deriving account. - Require non-empty message content.
- Return deterministic signature and signer address; do not broadcast or require chain config.
Shared Safety Rules
- Never expose full seed phrases/private keys in chat, logs, or summaries.
- Never store plaintext signer secrets in
wallet/signer.json. - Keep wallet files local (
wallet/signer.json,wallet/config.json). - Default to non-broadcast/read-only behavior unless user explicitly asks to send.
- If chain is unspecified, prefer a testnet and state the selection.
- On failure, return actionable correction steps and do not continue automatically.
Failure Handling
- Invalid mnemonic/private key -> stop and request corrected input.
- Missing/invalid
wallet/signer.json-> request generate/import first. - Missing/invalid
wallet/config.json-> request default network setup first. - Multiple or zero
current: trueentries -> stop and request normalization. - Insufficient balance for transfer -> return required vs available values.
- RPC timeout/network errors -> retry once, then ask for alternate RPC.
Completion Requirements
Before finishing:
- confirm action executed (
generate,import,balance,send) - confirm secret material was not exposed in plain text
- confirm chain and wallet address used (when applicable)
- provide one next action (backup, verify balance, or track transaction)
Standard Response Contract
Return this structure across all actions:
action:generate|import|balance|sign|sendchain: chain id/name used, ornonefor offline-only generation/importaddress: active wallet or queried addresstxHash: transaction hash when available, elsenullstatus:success|failed|needs_confirmationnext_step: one clear follow-up action
Comments
Loading comments...
