Base Wallet
WarnAudited by ClawScan on May 10, 2026.
Overview
This is a coherent Base wallet skill, but it gives an agent private-key, signing, and potentially irreversible crypto transaction authority without clear approval limits.
Only install this if you are comfortable giving the agent access to a dedicated wallet. Start with a new empty or testnet wallet, pin and inspect dependencies, avoid using your main wallet private key, require human confirmation for every signature or transaction, and protect or delete any managed wallet and mnemonic files.
Findings (6)
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 an agent uses a funded wallet, mistakes or prompt/tool misuse could authorize signatures or irreversible transfers.
This explicitly frames wallet signing and transactions as autonomous, but the artifacts do not define per-transaction confirmation, spending caps, recipient allowlists, dry-run defaults, or other containment.
Create wallets, sign messages (SIWE), send transactions programmatically. No browser extensions, no human intervention.
Use a new low-balance or testnet wallet by default and require explicit user approval, amount limits, recipient allowlists, and a dry-run summary before any signature or transaction.
A compromised or unexpected provider response could cause the agent to produce a valid wallet signature for an unintended identity assertion.
The script signs a message returned by the BaseMail API without displaying it to the user or validating expected SIWE fields such as domain, URI, nonce, and chain ID before signing.
const signature = await wallet.signMessage(startData.message);
Validate the SIWE message contents against expected values and require approval or at least a visible review step before signing provider-supplied messages.
Installing or invoking the skill can give the agent access to a wallet key whose signatures and transactions may have real financial or account consequences.
The skill consumes a wallet private key that can control crypto identity and funds, while the registry metadata declares no primary credential or env var contract.
if (process.env.PRIVATE_KEY) { ... return new ethers.Wallet(process.env.PRIVATE_KEY); }Declare the private-key/wallet-file requirement in metadata, restrict use to user-selected wallets, and require explicit approval before using any key for signing or transactions.
Anyone or any later agent run that can read these files can potentially control the wallet; accidental backup, sync, or commit could expose funds and identity.
Managed mode persistently stores wallet secrets for later reuse. The code uses restrictive permissions and prompts, so this is disclosed, but the stored material remains highly sensitive.
privateKey: wallet.privateKey, mnemonic: wallet.mnemonic.phrase ... fs.writeFileSync(filepath, JSON.stringify(walletData, null, 2), { mode: 0o600 });Prefer empty/test wallets, consider encrypted keystores or hardware-backed keys, keep wallet files out of sync folders and git, and delete mnemonic backups after secure offline storage.
A future dependency version could change behavior in code that handles wallet keys and signatures.
The wallet scripts depend on an npm package with a floating version range and no lockfile or install spec shown. This is normal for a Node skill but leaves dependency provenance/version drift to the user.
"dependencies": { "ethers": "^6.0.0" }Pin dependency versions with a lockfile and install from a trusted source before using the skill with any valuable wallet.
Users may store private keys too casually if they interpret environment variables or .env files as inherently secure.
The documentation contains strong security warnings, but this wording may understate that terminal output and .env files are still plaintext handling locations for private keys.
Secure by default โ Environment variables, no plaintext keys ... Then copy to your shell or `.env` file.
Treat stdout, shell history, and .env files as sensitive plaintext; revise the docs to state this explicitly.
